SDLC открывают, когда PM нужно видеть разработку не как набор разрозненных задач, а как жизненный цикл поставки: от идеи и требований до реализации, тестирования, релиза и поддержки. Это полезно там, где без карты стадий быстро теряется понимание, на каком участке реально застрял результат.
Что это за подход
SDLC полезен как high-level модель стадий software delivery. Для PM его ценность в том, что он помогает видеть переходы между этапами и понимать, где именно нужны артефакты, решения, проверки и handoff.
Когда он нужен
- проект связан с разработкой ПО;
- нужно объяснить общую логику движения изменения;
- теряется понимание, где именно ломается поставка;
- несколько ролей работают на разных участках жизненного цикла.
Когда он не нужен
- если его используют как абстрактную картинку без управленческой пользы;
- если команда уже держит жизненный цикл на практике без отдельного ярлыка;
- если PM путает SDLC с конкретной delivery-методологией.
Что из него реально применимо для PM
- видеть переходы между стадиями;
- понимать, какие артефакты нужны на каком участке;
- диагностировать, где в жизненном цикле появился сбой;
- строить более точную коммуникацию между ролями.
Какие артефакты, ритуалы и правила важны
- карта стадий или хотя бы явное понимание их последовательности;
- критерии переходов;
- ответственные на handoff;
- связь со статусом, релизом и support.
Какие ошибки чаще всего делают при внедрении
- рисуют SDLC, но не используют его для решений;
- не определяют переходы и критерии между стадиями;
- считают, что SDLC сам по себе решает проблемы взаимодействия;
- смешивают жизненный цикл и ритуалы команды.
Чем можно заменить или упростить
- простой картой потока поставки конкретной команды;
- разделением discovery / delivery, если важнее разграничить только верхний уровень;
- потоком релиза, если основной фокус уже на финальных участках.