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

Правильная постановка задачи = половина успеха. Правильно поставленную задачу сможет выполнить даже средний специалист. Плохо поставленная задача это половина провала. Плохо поставленную задачу завалит даже опытный эксперт.

Вывод: правильная постановка задач важна для результатов. (спасибо кэп!).

Формулировки требований крайне важны и ошибка в одно слово, может вызвать ошибку оценки стоимости и сроков разработки в несколько раз.

Потому тут стоит провести аналогию:

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

2. Требования = Пассажиры

3. Формулировки требований = ФИО

 

Теперь представьте ситуацию, что поезд уехал, а заказчик говорит «А я тут забыл, вот еще пассажир есть» или «Ой, там не Петров Владимир Владимирович, а Путин Владимир Владимирович». Что в этом случае произойдет? В этом случае пассажир останется ждать следующего поезда (новое ТЗ).

 

Конечно эта аналогия показывает лишь крайний случай. Всегда можно договориться или наверстать упущение.

Возвращать поезд? Садить пассажира на коня и догонять поезд?

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

Потому если изменения требований ТЗ или их формулировок все же случились, то стоит быть готовым к их последствиям:

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

2. Если же какая-либо сторона не согласна с изменениями, то тут появляется два варианта: или изменение доп. условий типа стоимости и сроков, или новое ТЗ.

Какие еще особенности нужно знать в связи с этими данными?

1. Изменение условий ТЗ может возникнуть не только со стороны Заказчика, но и со стороны Исполнителя. Например исполнитель в ходе разработки выясняет иной метод решения. Предлагает, аргументирует. И Заказчик может согласовать изменение условий или нет.

2. Учитывая распространенность этих ситуаций именно в разработке ПО, были придуманы принципы Agile-разработки. Ошибки в составе требований или формулировках слишком часто возникают именно в мире разработки ПО. Потому единственный верный выход здесь, это умение фокусироваться на приоритетах и короткие циклы планирования, которые минимизируют риски. А именно это и дает нам Agile. Напротив проектный подход увеличивает цикл планирования и контроля, а потом увеличивает риски и когда возникает ситуация что существенная часть требований упущена, и возникла уже в ходе работы, а другая часть содержит ошибки в формулировках, то проекты очень быстро взрываются и разлетаются на мелкие кусочки. Именно поэтому смертность проектов в мире ИТ столь высока.

Вывод: делайте ПО через Agile. Забудьте о проектах. И уделяйте максимум внимания составу требований и формулировкам.