Как на самом деле должна работать Политика качества
Политика качества зачастую рождается как «работа над ошибками». Расскажем о внутреннем проекте, над которым работали много лет назад и на котором совершили те самые ошибки.

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

Что удалось выяснить
Вводные данные:
Релиз предполагал двухнедельный спринт. Команда состояла из ПМа, который подключался лишь изредка, трех разработчиков и одного QA. Планируемая оценка – 150 часов с учетом отвлечения специалистов на другие проекты.
Исследование показало:
К середине первой недели спринта — при передаче проекта от одного ПМа к другому — забыли объяснить часть логики реализации фичи. Road map давно не актуализировался, описание задач было недостаточным. Когда вспомнили про фичу к середине второй недели спринта, это добавило еще 60 часов разработки и ретеста.
В конце первой недели спринта от проекта отвлекли самого осведомленного разработчика и подключили нового. Погружение для него не провели. В конце второй недели главный разработчик вернулся на проект и переписал код новичка. Результат – еще 40 часов разработки.
При смене QA-специалиста также выяснилось, что документацию на том внутреннем проекте не вели. В итоге новый QA затратил еще 25 часов, чтобы разобраться в логике.
Проект потребовал 275 часов реализации: вышел из запланированных двух недель, бюджет превышен в два раза.

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

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