<Назад

Процесс разработки: Планирование

В этой публикации мы начнем рассматривать процесс разработки. Он достаточно большой, поэтому я разделю его на несколько абстрактных частей: 1. Планирование, 2. Разработка, 3. Тестирование, 4. Ввод в эксплуатацию. Сегодня поговорим про планирование.

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

На разных этапах создания ИТ-решения требуется разный уровень глубины планирования. На этапе разработки этот уровень максимальный. 

Чтобы перейти к этому этапу, нужно располагать минимальным набором проектной документации:

1. Техническое задание. 

2. ER-диаграмма.

3. UML-диаграмма. Для маленьких проектов — этот пункт можно пропустить.

4. Дизайн интерфейса, если того требует продукт.

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

Планирование: Процесс

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

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

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

После того, как сроки проставлены, тех. лид просматривает все оценки и, при необходимости, корректирует их. А в моем случае, кроме корректировки сроков, тех. лид помогает разобраться с «затыками».

Модели

Я выделяю две основные модели планирования:

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

2. Параллельная. Это нестандартный случай, когда у вас разгар конкурентной борьбы и все меняется буквально ежедневно. В таких ситуациях подключается аналитик, который совместно с проектным менеджером и тех. лидом динамично меняют план, опираясь на рынок, конкурентов, потребителей и другие важные аспекты. Такие «качели» могут произойти между несколькими ИТ-стартапами, которые пытаются разделить рынок. Такое бывает редко, но если попасть в эту ситуацию и продолжать последовательное планирование, то конкурент вас обойдет.

Заключение

Планирование — это очень важный этап, которым частенько пренебрегают в пользу быстрого выхода продукта и экономии денег. Да, такой подход возможен, когда срок реализации ИТ-решения не более 1 месяца. Но когда речь идет о 4-5 месячной разработке, пренебрежение планированием — большая ошибка, за которую приходится дорого платить.