Как бы ни было грустно, но мы разбираем последний шаг из цепочки повествования о срыве сроков. Главное, чтобы оказалось полезно и применимо на практике.
Управляем рисками и собираем статистику
Хорошей идеей будет заложить бюджет по деньгам, ресурсам и срокам больше, чем в смете. Это на случай если что-то пойдёт не так. Просто заложите между этапами буфер в сколько-то процентов от стоимости этапа. Но никому и никогда не сообщайте о размере этого буфера и его существовании вообще.
Иногда делаются ошибки, сроки срываются. Бывает, что выясняется, что при проработке требований что-то было упущено и нужны дополнительные работы. Это изменения сметы, которые должны согласовываться с вами. Не согласованно — не оплачивается. Но если согласованно, то должен быть бюджет, из которого это можно оплатить.
Кроме того, вы сами, когда получите возможность протестировать готовые этапы, после приобретения пользовательского опыта, можете решить, что системе нужны доработки. И у вас будет бюджет на реализацию ваших доработок.
Важным показателем является отклонение фактических затрат от запланированных. Чем чаще происходит такое отклонение , тем более тревожный это сигнал. Когда у вас на руках есть зафиксированные требования, разбивка по этапам и смета, проводить переговоры с отделом/департаментом/дирекцией разработки куда проще.
В крайнем случае вы можете получить рыночную оценку и поставить вопрос о замене исполнителей. Когда люди понимают, что и их можно заменить, и вопрос лишь в стоимости замены, диалог начинает налаживаться.
Подведение итогов
✅Мы с вами рассмотрели последовательность действий, которую может выполнить нетехнический специалист. При её выполнении не нужно особых знаний технологий либо навыков управления людьми. В чём-то последовательность этих действий напоминает то, что делает хороший руководитель проекта.
Конечно, чтобы быть хорошим руководителем проектов в IT, нужно разбираться в технологиях, координировать работу специалистов и управлять коммуникацией. Но суть работы всё равно будет заключаться в управлении образом системы в головах всех участников проекта и управлении поэтапной реализацией образа.
Помним, что бизнес-заказчик — это тоже участник проекта. Он тоже выполняет работу над проектом, причём важную. А не только приходит за готовым результатом.
Кто-то может написать, что всё же и так понятно и очевидно. Зачем переливать из пустого в порожнее? На что можно ответить, что раз всё так понятно и очевидно, то почему так много людей пропускают эти этапы и делают ошибки?
Даже более того. На самом деле ровно такие же проблемы возникают при постройке частного дома либо при работе отделочной бригады. Часто возникают.
Ну а ещё, мы наконец-то узнали, что такое ТЗ на самом деле, и почему просить написать «нормальное ТЗ» бизнес-заказчика — плохая идея.
