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

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

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

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

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

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

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

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

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

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

Моя презентация с конференции PMDays 2008.

• Скачать презентацию в PPT
• Скачать пример концепции в PPT
• Видео выступления на PM Days

План рассказа

• Что такое Концепция
  • Зачем она нужна
  • Чем она отличается от ТЗ
  • Когда её стоит писать
  • Чем чреват пропуск Концепции
• Как она устроена
  • Инженерный документ VS художественный текст
  • Процесс создания и составляющие
  • Демонстрация примера

Концепция неформально

1. Кто чего хочет и почему
2. Почему сейчас этого не получается
3. Как должно быть устроено, чтобы всем нравилось
4. Что самое главное надо сделать, чтобы этого добиться

Назначение концепции

1. Инструмент выработки и согласования понимания:
   • Проблемы
   • Результата
   • Способа его достижения
     среди ключевых участников
2. Инструмент коммуникации, обеспечивающий:
   • Донесение понимания до всех участников процесса разработки
   • Мотивированность и чёткое видение цели и собственного вклада в результат
3. Основание для ТЗ и принятия решений
4. Фильтр для инициации проекта (лакмусовая бумажка)

Чем концепция отличается от ТЗ

• Фокус на причинах, целях проекта и ключевых свойствах продукта (а не детальных описаниях свойств)
• Краткость (3-10 страниц, против 30-80)
• Не меняется в ходе проекта

Почему её часто не пишут

1. «И так всё понятно»:
   недоосмыслена ценность фиксации и коммуникации
2. «Да вот же концепция — в письме Фёдора Ивановича!»:
   недоосмыслена ценность формализации
3. «Чего писать, работать надо!»:
   прокрастинация
   (предпочтение делать интересное, а не нужное).

Когда стоит делать концепцию?

ВСЕГДА

Если проект мал — полстраницы А4

Риски работы без концепции

• Goal Creep + Scope Creep
• Потеря мотивации
• Необоснованность ТЗ
• Конфликты
• Недостижение целей проекта!

Процесс создания концепции

1. Кто и чего хочет?
   • Выявление заинтересованных лиц
   • Выявление явных и скрытых интересов
2. Что сейчас? Описание текущей ситуации:
   • Формулировка проблем заинтересованными лицами
   • Выявление истинных причин проблем и их взаимосвязей
3. Что потом?
   • Построение вариантов целевой ситуации (как устойчивого равновесия интересов сторон)
   • Совместный выбор оптимального варианта
4. Как добиться?
   • Определение способа генерации путей достижения целей
   • Порождение необходимых для достижения целей верхнеуровневых работ и свойств системы

Свойства художественного текста

Коммуникационная задача — формирование, передача образа и ощущений:

• Свобода изложения (неструктурированность)
• Увлекательность
• Эмоциональная окрашенность

Свойства инженерного документа

Коммуникационная задача — создание чёткой обоснованной картины:

• Структурированность
• Взаимосвязанность
• Последовательность (от общего к частному)
• Трассируемость (прослеживаемость) утверждений

Структура концепции

Целеполагание

Разработка программы достижения целей

Источники

• RUP Vision Document
• ГОСТ РД 50
• PMBOK Project Charter

Из наблюдений за индустрией консалтинга и создания продуктов и систем мне видится, что есть 3 основных подходов к тому, чтобы решить какую-то сложную (или не очень) задачу в этой области.

1. Экспертный
В экспертном подходе вся или по крайней мере ключевая часть работы выполняется одним экспертом. Причём эксперт отличается от специалиста тем, что обладает не только исключительными компетенциями в своей сфере, но и достаточно значимыми – в соседних, смежных сферах. Результат работы эксперта рождается в ходе наблюдения, осмысления и генерации ведения – причём эта деятельность внешне выглядит крайне неформализовано. Поскольку для создания сколько-то сложного продукта требуется учёт различных аспектов и точек зрения, эксперт умудряется представлять их с некоторой степенью достоверности за счёт большого накопленного опыта удачных и неудачных решений. Эксперты, очевидно, редки. Для некоторых областей знаний их просто не существует, например, в силу новизны или большой сложности сферы. К таковой можно отнести социальное проектирование в масштабах мегаполиса. Эксперт выдаёт как идеальные, так и провальные результаты.

2. Синергетический
Создание продукта происходит посредством определённым образом организованной коллективной деятельности команды профессионалов в разных областях, касающихся данного продукта. Каждый из них не обязан быть абсолютным экспертом, скорее должен превосходить уровень специалиста и уметь работать в команде. Команда формируется не только на основе профессиональных компетенций, но и командных ролей. Одна из ключевых составляющих такой работы – опытный куратор команды, который её формирует и организует её работу. Главная особенность синергетического подхода – частые мозговые штурмы, перемежающиеся этапами сбора и отработки различных идей. На мой взгляд, команда может давать результаты, близкие к идеальным и достаточно быстро. Другое дело, что ресурсная стоимость создания и поддержания такой команды достаточно высока, такой подход могут позволить себе немногие в индустрии. Антипаттерн – Design by Commitee.

3. Процессный
Подход на основе разделения зон ответственности и специализации, когда работа строится на основе ИСР, workflow, где каждую операцию выполняют отдельные специалисты довольно длительное время и передают результаты следующему специалисту. Понятно, что креативность и гениальность здесь минимальны, вероятность создать идеальный продукт невелика, но зато есть возможность стабильно воспроизводить “новый” продукт с некоторым приемлемым уровнем качества. Также велика роль постановщика процессов, хотя при отработке конвейера он может устраниться из процесса. Требования к специалистам самые малые.

NB: Такой перечень подходов немного напоминает типовые оргструктуры по Минцбергу и стадии развития организации по Адизесу.

Кстати, выстроилась некоторая очевидная, наверное, секвенция: Эксперт > Профессионал > Специалист.

Я в основном в своей жизни участвовал в процессных и псевдо-экспертных подходах (когда человек пытается всё сделать сам, экспертом не являясь).

Мой ответ на этот вопрос, заданный в форуме SQL.ru:

Почему так популярна и востребована профессия руководителя проекта?
Зачем их так много??

Давайте посмотрим с малого – зачем вообще нужны лидеры в любом коллективе. Скажем, собралась группа из N людей пойти в кино. И тут выясняется, что одним нравятся боевики, другим детективы, одни не хотят ехать на другой конец города, третьи не могут в выходные и у каждого есть своё мнение. Происходит гвалт, до какого момента?

Л. Выделяется лидер, который ставит цель, ограничивает число вариантов, проводит голосование или настаивает на определённом выборе, аргументируя его определённым образом.

С. Коллектив договаривается о правилах выбора куда, когда и как идти и что делать в случае изменений, по каким правилам взаимодействовать.

По методу Л работает классическая теория лидерства и руководства. По методу С – теория самоорганизации однородных систем.

Что мешает вам и вашим друзьям (программистам) пойти и придумать идею продукта, взять кредит в банке, разработать систему и продавать её, живя в своё удовольствие?

1. Нежелание брать на себя риски востребованности продукта, сроков и качества его реализации
2. Отсутствие необходимых навыков целеполагания, планирования, контроля, маркетинга и т.д.
3. Нежелание брать на себя риски того, что в коллективе произойдёт конфликт/ы, которые:
   а) могут происходить систематически и фактически саботировать разработку;
   б) могут привести к распаду коллектива

Что мешает вам, оставаясь в коллективе в компании в качестве наёмного работника, обходиться без менеджера проекта?

• Отсутствие навыков и желания общаться с заказчиком.
• Отсутствие навыков долгосрочного планирования.
• Отсутствие навыков ведения эффективных переговоров.
• Отсутствие навыков согласования интересов разных сторон.
• Отсутствие навыков финансовых расчётов.
• Отсутствие навыков и методов управления рисками.
• Отсутствие практики точного следования договорённостям.
• Отсутствие навыков предотвращения и разрешения конфликтов.
• Отсутствие желания заниматься обеспечением ресурсами.

Метод Л в разработке ПО – это классический проектный менеджмент из серии “вот приедет дядя, дядя нас рассудит”.

Метод С в разработке ПО – это то, что предлагает Agile и что естественным образом происходит во многих стартапах.

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

PS: Там, как обычно, тусовка базданщиков устроила сральню с меряньем пиписьками, но уж такая культура на форуме.

С тем, что на этапе инициации проекта можно ограничиться сбором бизнес-требований, я ещё могу согласиться, но вот то, что пользователь, по мнению PMI, не входит в число основных заинтересованных лиц — это довольно показательно.

Теперь есть формальное объяснение тому, почему PMI-подход так плохо совместим с разработкой публичных веб-систем.

Помимо прочего, под бизнес-моделированием они понимают только изучение устройства деятельности заказчика.

Не могу не поделиться выводами из вчерашней беседы с Сергеем Boatman’ом (см. его статью “Цели ИТ-проекта“).

Общий тезис — люди не любят ставить чёткие цели, т.к. они накладывают ответственность.

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

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

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

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

Разработчик не любит чётко поставленные цели, т.к. ему приходится работать на результат, а не в своё удовольствие (смотреть YouTube, читать bash.org, писать систематическую систематизированную систему) и разрыв между текущим состоянием работы и целевым формирует гнёт.

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

Решил зафиксировать общее место, которое, тем не менее, остаётся неозвученным.

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

Итак, типовые интересы, на мой взгляд, выглядят так:

Заказчик

• Получить продукт, приносящий деньги
• Повысить эффективность бизнеса

Компания-разработчик

• Заработать денег
• Пополнить портфолио успешных проектов

Разработчик

• Заработать денег
• Изучить новую технологию

Пользователь

• Получить инструмент удовлетворения своих потребностей
• Снижение трудоёмкости выполнения производственных задач

Соответственно, когда эти интересы замкнуты друг на друга — повышение эффективности бизнеса или прибыльность продукта зависят от степени удовлетворённости Пользователя, которую обеспечивает Разработчик, делающий успешный проект для Работодателя — то это работает на успех. Если какой-то интерес повисает в воздухе или конфликтует с другим — это источник постоянного недовольства и проблем.

Собственно, именно потому так плохо дело обстоит с госпроектами и проектами по автоматизации больших компаний — у первых достижение интересов Заказчика обычно очень мало связано с интересами Пользователя, а вторые ими часто пренебрегают, считая процессные характеристики бизнеса более важными, чем операционные («не нравится работать в этой программе? уволим, наймём на это место другого»).

Сообщество AgileRussia проводит открытый семинар на тему «Методология Scrum»
13 сентября, в 19.00 на территориии офиса Luxoft

Scrum — одна из самых популярных методологий гибкой разработки. Одна из причин ее популярности — простота. Если коротко, Scrum — это итеративная и инкрементальная разработка самоорганизующихся и самоуправляемых команд.

В нашей программе две части:
«Обзор методологии Scrum» и «Внедрение Scrum: Опыт одной компании».

Обзор методологии Scrum

1. Зачем нужен Scrum?
2. Основа методологии Scrum
3. Роли, артефакты и жизненный цикл
4. Преимущества и применимость методологии

Ведущий – Асхат Уразбаев

Внедрение Scrum: Опыт одной компании

1. Состояние до внедрения Scrum
2. Внедрение Scrum
3. Трудности, с которыми мы встретились
4. Как мы с ними справлялись
5. К чему стремимся сейчас

Ведущий – Никита Филиппов

Семинар бесплатный, чтобы на него — запишитесь здесь по кнопке [Участвую], указав при регистрации в системе свои реальные ФИО (этого требует пропускная система Luxoft).

AgileRussia Community

13 сен	Семинар – Методология Scrum Luxoft, 13 Сентября 2007 в 19:00:01 (Москва, Россия)

Коллега прислал на рецензирование ТЗ на очередной поток доработок одного муниципального веб-ресурса.

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

Ну т.е. ладно я понимаю, что цели совсем не SMART, ну ладно, когда в качестве Целей пишут Задачи («автоматизация»), но писать в качестве оных ДЕЯТЕЛЬНОСТЬ («модернизация») — это имхо уже слишком

Люди! Умоляю вас, ТЗ не должно высасываться из пальца. ТЗ — это взвешенная качественная обоснованная постановка задачи, сделанная на основе АНЛИЗА ПРОБЛЕМЫ, а ПРОБЛЕМА выявляется в ходе ОБСЛЕДОВАНИЯ, либо как отдельного проекта, в случае новой системы, либо в ходе МОНИТОРИНГА, в случае существующей.

И цели проекта, поставленные в ТЗ, очень тесно связаны с целесообразностью, соответствием целям более высокого уровня. В этом смысле МОДЕРНИЗАЦИЯ отвечает цели более высокого уровня ПОТРАТИТЬ ДЕНЬГИ, СОЗДАВ ВИДИМОСТЬ РАБОТЫ, а цели типа ПОВЫСИТЬ ИНФОРМИРОВАННОСТЬ и УДОВЛЕТВОРЁННОСТЬ РЕСУРСОМ ЖИТЕЛЕЙ РЕГИОНА остаются вне фокуса, в пролёте.

А ведь казалось бы, что может быть проще — возьмите в качестве метрики показатель «Процент жителей региона, удовлетворённых качеством ресурса», далее составьте список потребностей-задач из 20-30 пунктов, согласуйте его и расширьте через механизм опроса на сайте, сделайте анализ удовлетворённости, получите цифру. Затем эту цифру увеличьте в N раз, получив абсолютную и относительную величину прироста удовлетворённости и постулируйте в качестве цели достижение этой величины в течении заданного времени. Тогда и проверить достижение целей проекта можно будет, и увидеть расход ИТ-бюджета на одного жителя, а следовательно — рост эффективности расходования тоже.

Тогда показатель «Процент жителей региона, удовлетворённых качеством ресурса» можно свести к произведению 2-х: а) Процент жителей региона, пользующихся интернетом прямо или опосредованно; б) Процент жителей региона, пользователей интернета, довольных качеством ресурса. И ставить задачи, исходя из целей увеличения на некоторую величину как первой так и второй составляющей. Потому что если всего в регионе интернетом пользуются 1-5% населения, то высокое качество ресурса не спасёт.

На диаграмме представлена текущая Оргожаба подразделения разработки систем.
На входе у Оргожабы – вселенский ХАОС.
На выходе – новый, с иголочки, блистательный, функциональный, супернадёжный и удобный ПРОДУКТ.

(по ссылке доступна версия в формате обоев для рабочего стола).

Лица с богатым воображением могут развить анималистические аналогии, например:

• Менеджеры (М) – это глаза Жабы, обозревают Хаос, координируют, спасают от опасностей,
• Аналитики (Ан) – рот и нос, тщательно впитывают и разжёвывают Хаос, превращая его в постижимую материю,
• Архитекторы (Ар) – мозг и сердце, заставляют Жабу существовать и двигаться,
• Разработчики (Р) – лёгкие, желудок, печень и т,д., выполняют жизненно важные функции,

ну и т.д., но все эти фантазии останутся на совести воображающего.

Я исхожу из такого текущего состава Жабы (всего ~20 человек):

• 2 менеджера
• 2 аналитика
• 2 архитектора
• 4 верстальщика
• 8 программистов
• 2 тестировщика
• 1 инженер поддержки

Линии между сотрудникам означают наиболее активные коммуникации (на мой взгляд).

Жаба (Ж) стоит перед непростым выбором. Команда переезжает в новый офис.
В нём есть 2 помещения, ориентировочно на 8 и 12 человек (или 6 и 14).
Итого – Жабе предстоит разделиться на две части

Есть 2 принципиальных варианта:

1. Почкованием – в результате получим Большую и Малую Жабу, по форме и свойствам похожую на текущую.
2. Ядерным делением – в результате получим 2 абсолютно новых существа пока неизвестных биологических видов.

Предлагаю вам принять посильное участие в судьбе зверька.