Блоги сообщества аналитиков

Бизнес-форум KM Russia-2011 был в конце ноября и я делился впечатлениями в блоге. А сейчас, наконец, завершил и выложил отчет о нем.

Прошу прислать или дать ссылку на книгу Вигерса "Разработка..." где есть 91 и 92 страницы

Мне очень любопытна тема методов, которыми мы пользуемся или которыми стоило бы пользоваться при анализе. В отличие от целостных методологий, подминающих под себя целые компании, отдельные методы - гораздо более тонкие инструменты, применение или неприменение которых часто может оставаться на усмотрение аналитика. Успешное или не успешное применение их определяет личный успех специалиста или его поражение. Но успешное применение маловероятно без понимания смысла метода и его границ применимости. Любопытным справочником по методам анализа в этом смысле является BABOK Guide, содержащий 34 метода с определениями, краткими описаниями, а также достоинствами и недостатками каждого из них. Отталкиваясь от него, как от основы, я попробую разобрать что тут к чему и зачем.

Меня часто спрашивают - а каким образом можно сравнить (предоставить ЛПР) данные о выборе той или иной Системы/Платформы/Решения...

Нагляднее всего это представить в виде таблицы, где по горизонтали идут важные для вас Характеристики, а по вертикали Системы.

На пересечении Характеристик и Систем идут показатели - на сколько хорошо удовлетворяет Система данной Характеристики по выбранной шкале. Можно добавить еще веса для каждой Характеристики и в итоге даже можно посчитать количественно - на сколько вам подходит Система. Я использую разную шкалу - по 10и, 5и бальной шкале или просто +/- (удовлетворяет или нет)

Пример такого сравнения платформ 1С и SAP для нужд определенной компании с кол-вом сотрудников 500-1000 человек находится во вложении к этому посту.

Глава 1. стр.5 Взаимодействие между разработчиками и заказчиками ограничивается внешним видом пользовательского интерфейса и не затрагивает того, что же действительно клиенты собираются делать с помощью приложения

На работе начали внедрять систему бюджетирования- попытка не первая, поэтому исхожу из того , что заказчик с ней знаком , однако пока как в книге- до фунционала не доходит , пока только про внешний вид

стр.6. Основной закон: требования должны быть документированы - Был выбор из нескольких WMS , как выяснилось документированных требований нет - пока ничего не выбрали, адресное хранение товаров делаю сам

Очень понравилось как подтверждение своего мнения- постоянно с этим сталкиваюсь -

Уровни требований по Вигерсу

рисунок 1-1 стр 8

стр 11. - каких требований не должно быть- Спецификация требований не содержит деталей дизайна или реализации (кроме известных ограничений) ...

В этом посте речь пойдет не об известной книге Энтони Лаудера, которая выделяет четыре культуры на основе западной истории IT-компаний. Кстати, если кто не знаком - рецензию Стаса Фомина на книгу можно прочитать здесь. А в этом посте речь пойдет о тех культурах российских IT-компаний, видение которых у меня сформировалось в результате общения на конференциях в этом году, окончательно сфокусировавшись на SQA Days.

Итак, большинство российских, а также украинских и белорусских, IT-компаний можно отнести к одной из двух культур. Я сразу хочу сказать, что я сознательно не буду называть эти культуры конкретными словами, потому что мне не удалось подобрать нейтральную пару слов. Любая пара, которая приходила на ум, однозначно несла предпочтительную оценку одной из культур. А они - просто разные. Поэтому я буду называть культуры Первая и Вторая, по времени возникновения - Первая появилась немного раньше.

Наткнулся на интересную презентацию "Эффективное сочетание компетенций в IT: Project Manager + Business Analyst", Мария Бондаренко, SPMConf-2011.

Да, действительно встречал много случаев, когда Аналитик становится менеджером проекта (ПМ), и выполняет две эти функции и даже был сам в такой роле.

Мое отношение к такой роли (Аналитик-ПМ) двоякое:

• С одной стороны иногда это даже необходимо
• С другой стороны на полноценном проекте один человек совмещать эти две роли не может

Рассмотрим плюсы и минусы данной роли.

Плюсы:

Всем привет!

Здесь я буду пробовать выкладывать свои мысли по  аналитике и проектной деятельности.  Кроме того рассчитываю, что по затрагиваемым вопросам я буду получать обратную связь, дабы находить что то новое в процессе обсуждения и комментариев :)))

Так вот. Начать я хочу наверно сегодня с Технического задания и его пунктов.

И сегодня я хотел бы поговорить о таком исопльзуемым мной пункте ТЗ как:

1) "Цель проекта"

Теперь вопрос - Для чего ?

Цель проекта. Цель проекта берется либо из другого документа проекта (протокол встречи при предпродажном обследовании, контракте на услуги и т.п.), либо формируется самостоятельно на основании диалога с заказчиком. 

Во-первых: мы ставим "первый ориентир" нашего проекта. Исходя из этой цели мы определяем первые наброски планов работ на проекте.

Например: "Необходимо реализовать систему регистрации заявок типа N" и "Необходимо создать платформу для регистрации всевозможных заявок на предприятии".

Во-вторых: во время планирования работ мы уже можем на основании цели "отсекать лишнее" :))

Декабрь - время борьбы Деда Мороза с Дедом Лайном. Потырено у Левенчука. Мне понравилось

Посмотрел на этих выходных выступление Сергея Гевлича на KMrussia про Объясняшки. На самом форуме я в это время был в другом зале и пропустил, но по общению второго дня понял, что пропустил зря. Видео всей конференции еще не выложено, но это выступление было опубликовано на youtube, и ссылка дана в группе TopClassInternational на facebook, где идет общение по управлению знаниями.

Реально вдохновился идеей. С точки зрения теории - ничего нового. Давно известно, что наиболее эффективная передача информации - при сочетании каналов видео и аудио, в динамике. Более того, есть известные и популярные рисованные мультики RSA-студии. Что, кстати, видно из вопросов после выступления - автору указывали на книги, где все это тоже написано.