Итак, продолжаем про разработку в рамках этапа 2 "Разработка и настройка". Как я писал в предыдущем посте, требуется задать правила разработки.

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

В первую очередь следует сформулировать последовательность работ по каждой задаче на разработку (и даже неважно, как вы это сделаете просто словами, в формате RACI или как-то ещё - это уже детали):

1. Формализация задачи на разработку. Исполнитель - аналитик.

2. Проверка на соответствие сформулированной задачи рамкам проекта (общее ТЗ) и детализированным требованиям, и передача задачи аналитику для (Исполнитель - функциональный или технический архитектор в зависимости от задачи, далее ФА или ТА соответственно):

▫️ а. Правки постановки по замечаниям;

▫️ б. Передачи задачи в разработку/бэклог проекта.

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

4. Принятие задачи в разработку и проведение работ. Исполнитель - разработчик (для простоты не буду делить front-end и back-end, иначе цепочка удлинится).

5. Проведение технической проверки (правила написания кода, комментирование, отсутствие дублирования функций и т.д., далее - код-ревью) и отправка разработчику для (исполнитель - ТА):

▫️а. Исправления недочётов по результатам код-ревью;

▫️ б. Передачи на тестирование.

6. Проведение тестирования и отправка (исполнитель - тестировщик):

▫️а. Разработчику для исправления ошибок и недочётов;

▫️б. Аналитику для проведения демо ответственному лицу по автоматизируемому бизнес-процессу;

7. Проведение демонстрации разработанной функциональности (исполнитель - аналитик) и:

▫️а. Включение задачи в выкатку на площадку, где будут проводиться предварительные испытания для допуска в ОЭ, в случае если замечаний в результате демонстрации не поступило;

▫️б. Анализ замечаний, разделение замечаний на то, что "соответствует ТЗ и детализации требований" (и доработка по ним) и "новые требования" (и отправка РП для того, чтобы он решил, что с этим делать).

8. Выкатка функциональности по задачам 7а. Исполнитель - системный инженер.

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

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

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

Дальше я пройдусь по указанным выше пунктам, про прочие ключевые результаты этапа также не забуду.