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

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

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

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

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

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

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

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

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

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

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

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

Разделы сайта:
Мой канал в Telegram
t.me/vsobolev

Оцените пожалуйста статью:

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

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

Сожалеем, что вы поставили низкую оценку!

Позвольте нам стать лучше!

Расскажите, что вам не понравилось, как сделать контент сайта лучше? Это совершенно анонимно.

Случайная заметка

Ваш комментарий

Please enter your comment!
Please enter your name here

Новые комментарии:

Все комментарии vsobolev.com/forum/

Разделы сайта

Последние записи