Как правильно менять сроки проекта

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

Как правильно менять сроки проекта
Change request — молодежи гуглить Фитиль №183-02 «Порожняк» (1969)

Для подготовки технического решения в сторону завода были выдано ТЗ и завод запустил разработку техрешения. Шло время (2 месяца), наши технари конечно же не сидели без дела и им в буйную голову пришла очередная светлая мысль. Возможно кто-то делал ремонт дома или у кого-то жена, как у меня сестра, ни квартала без перестановок или … Причин может быть много, но мысль была следующей — А что если один из шкафов переставить на другую сторону? Это же даст оптимизацию, удобство, экономию и возможно даже какую-то денежку в виде премии за рацуху!

Не откладывая в долгий ящик и пока не забыли, технари побежали к представителю завода:
— Слушай мистер, у нас тут вот такая идея, помнишь мы вам ТЗ давали, а вы техрешение делаете? Так вот, мы подумали, вы же техрешение нам еще не выдали, там надо один шкаф перенести, делов-то всего на полчаса. Вот новое ТЗ взамен старого и пачка бумаги, если вдруг уже печатать начали.

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

— Вот смотрите, на заводе работает инженерная группа. У неё ограниченные ресурсы и эти ресурсы расписаны на месяцы вперед. Ваше ТЗ попало в очередь 2 месяца назад и по нему уже какая-то работа началась. Сегодня вы принесли новые требования и настаиваете на них. Значит, согласно процедуре, мы прекращаем работу по старому ТЗ, выкидываем его из стека задач, а новое ТЗ вставляем в начало стека. Правда есть нюанс, за прошедшие 2 месяца к нам поступило достаточно много других запросов, поэтому инженерная группа перегружена и сейчас время выдачи нового техрешения составит не менее 7 месяцев.

Технари вздохнули, забрали папочку с новым ТЗ и угрюмо пошли к себе в офис.

Лучшее враг хорошего. Техрешение было выполнено по первоначальному ТЗ, оборудование установлено, и насколько я в курсе, до сих пор успешно эксплуатируется.

Вы можете спросить, ну а почему действительно нельзя было на ходу принять корректировки? Потому что переделывать всегда сложнее, чем разработать с нуля. Это вам любой программист скажет. Огромные риски упустить что-то, оставить какие-то артефакты, которые потом вылезут в процессе эксплуатации в самый неподходящий момент.

— А как же Agile? — спросит не любой программист. А я не верю в Agile для конечного заказчика. Похоже это возрастное или побочка от коронавируса такая.

P.S.: Справедливости ради отмечу, что не преклоняюсь фанатично перед бизнес- процессами западных компаний, у них тоже хватает косяков, вот например 10 крупных провалов и ошибок.

Не забудь подписаться на Telegram канал, чтобы не пропустить что-нибудь интересное! Или по электронной почте.

Оцените статью:

Среднее: 5 / 5. Всего оценок: 4

Оценок пока нет. Вы будете первым!

Оставьте комментарий