Системный анализ в IT

Большинство статей, которые встречаются в сети на тему структуры бизнес-планов, предлагают эту самую структуру, но никак не объясняют, в каком порядке и как именно она формируется. Я решил устранить эту досадную проблему, используя метод инженерного анализа (reverse engineering).Какие ключевые факты должен сообщать бизнес-план на выходе?

1. Первичный объём вложений
2. Срок окупаемости
3. Целевой уровень и процент доходности
4. Потенциал роста

Откуда эти цифры берутся? Они складываются из планов доходов и планов расходов.

1. План доходов включает в себя план продажи услуг и товаров, например, рекламы и пользовательских сервисов, а также партнёрских отчислений.
2. План расходов включает разовые и периодические расходы на недвижимость, оборудование, инструменты, расходные материалы, персонал, лицензии.

Под планом я понимаю набор точек формата Время, Сумма, Назначение.Чем определяются эти финансовые планы? В основном — ходом процесса создания продукта или услуги и их предоставления клиентам, а именно:Производственные планы:

1. Планом исследований
2. Планом разработки продукта/услуги
3. Планом продвижения

Обеспечивающие планы:

1. Планом закупок
2. Планом аренды
3. Кадровым планом

Все эти планы достаточно взаимозависимы, но ключевым всё-таки следует признать план разработки — что именно и в каком порядке должно появляться определяет большинство затратных статей на обспечение деятельности и вывод продукта на рынок.Итого, собирая всё вместе, получаем следующую картину зависимостей и порядка разработки документа:Что забыл?Далее в программе — на основании чего и как именно формируется план разработки.

Теперь объясню, к чему вопросы про источники WBS.

При планировании проекта по созданию ИС или ПО, например, при создании старт-ап компании, в рамках заказа системы несофтверной компанией или скажем, создании сайта наподобие livejournal.com, зачастую нет взаимоувязанного набор работ, которые необходимо провести для получения желаемого результата. Причём, на мой взгляд, одна из важнейших проблем в сложившихся подходах – понимание в качестве результата некоторого “объекта поставки”, а не ситуации.

Например, если вы будете считать, что в результате проекта по созданию сайта вам нужны следующие объекты поставки:

1) сам сайт;
2) какая-то документация к нему.

и будете строить весь проект исходя из получения такого результата, то вы легко можете придти к ситуации, когда заказчику будет передана CD-болванка с установленной и настроенной под проект CMS-системой и какой-то документацией. Формально результаты получены, но оказывается, что сайт:

1) не развёрнут на домене,
2) не наполнен контентом, или
3) он есть, но он не посещается, или он экстремально неудобен и т.д. и т.п. -
т.е. “не работает” не с точки зрения техники, а с точки зрения бизнеса, как некоторый инструмент автоматизации существующего или создаваемого бизнеса.

И страусиная позиция многих разработчиков – “ну мы типа только программы делаем, всё остальное не наша забота, что хотите с этой системой то и делайте” мне кажется сильно недальновидной и неуместной в современных условиях необходимости тесного сотрудничества бизнеса и IT.

На мой взгляд возможно свести воедино весь комплекс работ по созданию работающей с точки зрения бизнеса системы, если использовать нечто вроде “глобального сценария” или “обобщённого бизнес-процесса”, описывающего желаемую ситуацию относительно создаваемого продукта. Для многих проектов по созданию массовых веб-приложений, таким сценарием, на мой взгляд, мог бы быть следующий:
П. Пользователь приходит на сайт
Н. Пользователь получает нужное
Д. Пользователь остаётся довольным
Р. Пользователь рекомендует сайт знакомым
В. Пользователь возвращается на сайт

Далее можно рассматривать каждый шаг сценария как некоторое глобальное условие, которое должно быть выполнено и под него подкладывать детализированный набор задач и новых условий, к которому его можно свести. Само собой, этот сценарий можно и нужно модифицировать под проект, например за счёт введения пункта “О. Пользователь оплачивает продукт или услугу” и т.д.

NB: А вот и мой доклад об этом, детально раскрывающий содержание метода с видео и материалами на конференции Российские Интернет Технологии 2007.

Тезис: Не используйте проценты для контроля хода выполнения работ

Для многих людей в IT управление проектами ассоциируется с MS Project, диаграммами Ганнта, графиками загрузки и т.д. Ничего не имею против всех этих вещей, но есть одна гадость, которая не даёт мне спокойно спать, а именно – отслеживание статуса хода проекта по разработке ПО по процентам выполнения задачи.

Процент выполнения задачи по всей видимости происходит из более традиционных видов человеческой деятельности – строительство, выпуск продукции и т.д. Одна из важных характеристик такой деятельности – её однородность. Речь вот о чём – здесь вполне применимы понятия “копать и не копать”, т.е. производительность труда есть величина постоянная для конкретного типа производственного ресурса, таким образом объём сделанной работы прямо пропорционален затраченному на неё времени. Таким образом можно говорить о количестве произведённого результата или затраченном времени – и обе эти величины будут достаточно хорошо характеризовать динамику процесса.

Если же посмотреть на типичные задачи по разработке ПО – “спроектировать БД”, “настроить интеграцию с Outlook”, “реализовать компонент фильтрации данных”, то мы увидим, что задачи эти неоднородны по характеру выполняемой работы в пределах одной работы. Что значит “компонент реализован на 23%”? Что значит “интеграция выполнена на 78%”? Понятно, что как минимум единицы процентов в общем случае ничего не говорят о реалиях, если только в проекте нет специально оговорённой метрики процента, а такое практически никогда не случается. Но говорят ли что-либо десятки процентов? Да, в общем случае они выражают видение исполнителя относительно количества оставшейся трудоёмкости по доведению задачи до завершения. Вместе с тем, достаточно небольшое количество разработчиков может похвастаться адекватными оценками. Для отрасли вцелом характерны постоянный недоучёт рисков возникновения трудностей из-за самого характера работы, что влечёт за собой появление ряда абсурдных в своей безысходности эвристик “возьми оценку трудоёмкости разработчика и умножь на Pi”.

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

Даже при достаточно хорошо сформулированных требованиях к ПО большая часть работы по проектированию проходит в голове человека, разработчик может размышлять над возможным решением 3 дня, а потом сесть и описать его за 3 часа. Вот почему, на мой взгляд, метрика в духе “сделано 56% работы” плохо соотносится с реальностью – разработчик мог оценить задачу в 3 дня, а на поверку окажется, что её получилось сделать только за 5, причём к вечеру 3-го, и даже 4-го дня никаких осязаемых результатов задачи ещё даже не существовало.

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

1. статус выполнения работы в виде логического признака – сделана/не сделана;
2. оценка количество потраченного на работу времени в абсолютном выражении (+/- час);
3. отношение количества потраченного на задачу времени к первоначально запланированному.

Рекомендация, которую можно сделать на таких наблюдениях, следующая – разбивайте проект на достаточно мелкие задачи, чтобы их трудоёмкость не превышала нескольких дней, а лучше – дня. Если трудоёмкость задачи составляет несколько дней, попросите разработчика разбить её на отдельные подзадачи.

Я предлагаю взять рассуждения Брукса о вехах проекта и применить его для всех задач:

«Как управлять большим проектом по жесткому графику? Прежде всего, надо иметь график. У каждого из событий, называемых вехами, должна быть дата. Выбор дат – уже обсуждавшаяся задача оценки, и он решающим образом зависитот опыта.

Для выбора всех вех есть только одно пригодное правило. Вехами должны служить конкретные особые события, которые можно идентифицировать с полной определенностью. В качестве отрицательных примеров отметим, что написание программы “закончено на 90 процентов” в течение половины всего времени кодирования. Отладка “закончена на 99 процентов” почти всегда. “Планирование завершено” – событие, которое можно объявить почти произвольно.

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

Наличие четко очерченных границ и недвусмысленность важнее, чем возможность легкой проверки начальником. Едва ли человек станет лгать о прохождении вехи, если она очерчена столь ясно, что от не может себя обманывать. А вот если веха расплывчата, начальник часто воспринимает доклад
иначе, чем тот, кто ему докладывает. Дополняя Софокла, скажем, что никто не любит и сам приносить дурные вести, поэтому они смягчаются без злого намерения ввести в заблуждение.»

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

Многие знают про формулу, пропорцию, принцип Парето. Одна из прикладных его трактовок гласит – “80% работы можно выполнить 20% усилий”.

Ок, берём задачу, для решения которой нужно 5 часов. Выбираем наиболее эффективную точку приложения и за 1 час делаем 80% работы. Осталось 20% работы и 4 часа времени.

Из оставшегося объёма работы выбираем наиболее эффективную часть, повторно применяем принцип Парето, и за 48 минут делаем 80% оставшейся работы. Таким образом, получаем, что за 1ч и 48м, а именно за 36% времени можно выполнить 96% работы.

Отсюда следуют забавные “наблюдения”:
а) если точный объём выполненной работы не так важен, то правильно выбрав точку приложения усилий, можно сэкономить 2/3 времени.
б) если точный объем важен, то такая “оптимизация” приводит к тому, что большую часть времени выполнения работ они имеют статус выполненения “сделано 90%” – никого не напоминает? %)

Всё ли правильно в рассуждениях?

Не могу понять, есть ли какой-то единый принцип формирования иерархической структуры работ в проекте по созданию ПО и ИС, или хотя бы какой-то конкретный набор подходов.

Прежде всего интересует, откуда берутся первый-второй уровни WBS при планировании проекта или его конкретной итерации при итерационном подходе. В PMBOK ничего конкретного не нашёл.

Пока обнаружил следующие подходы с использованием источников:

A. Аналогичный проект, выполненный ранее, в качестве шаблона.

B. Бизнес-компоненты системы (Обработка заказов, Управление запасами, и т.д.) – для этого нужно иметь хотя бы концепцию системы. 2-й и более низкий уровень описывают работы, которые должны быть сделаны.

D. Дисциплины – в качестве первого уровня выступают “Менеджмент”, “Бизнес-анализ”, “Требования”, “Проектирование”, “Реализация”, “Тестирование”, “Документирование” и т.д.

F. Функции – система описана в виде набора функций. Похоже на B, но привязка не у бизнес-сегментам и бизнес-процессам, а бизнес/техническим функциям.

R. Дерево требований – похоже на B и F, только есть уже готовые 3-4 уровня требований, под которые осталось подложить задачи.

T. Технические компоненты (Интерфейс, Бизнес-логика, БД, подсистема интеграция) – аналогично B, но техноцентрично.

U. Пользовательские истории (user stories), прецеденты (use-cases) – является по сути развитием F.

Похоже, что выбор того или иного подхода в основном связан c используемой методологией, но большая часть подходов на мой взгляд страдает неполнотой, т.к. сконцентированы только на создании системы, а не на достижении желаемого целевого состояния бизнеса (в широком смысле). Опускаются маркетинговые работы, подготовка технической инфраструктуры, часто опущено обучение, малое внимание уделяется обеспечению эффективности работы системы. На мой взгляд, это следствие отсутствия целостного, интегрированного подхода к планированию “из одной точки”.