Comments 3
Выжимка-догадка: В ИТ топах появился человек, который может сказать "Нет." и ему ничего за это не будет. В итоге с команды сняли стрессы и демотивацию и она начала работать как положено без чрезмерного выжигания.
Я давно пришёл к выводу, что управление ожиданиями всех вовлеченных сторон - единственное, что влияет на оценку проекта как успешного/неуспешного.
Сравните 2 формулировки, типа 2 варианта того, как сказал клиент по итогам проекта (проект вымышленный):
Мы не смогли уложиться ни в бюджет, ни в сроки. Мы вынуждены были сдвинуть наши маркетинговые активности дважды, но в конце концов запустили продукт на 5 месяцев позже. Мы не считаем проект успешным, потому что мы не уложились в изначальные эстимейты
Команда дала эстимейт на старте проекта, но в течение первого месяца мы поняли, что сложность проекта не была правильно оценена, потому что скоуп постоянно рос. И хотя нам пришлось пересмотреть наши маркетинговые планы дважды, мы все таки смоги запустить продукт на 5 месяцев позже. Тем не менее, мы считаем проект успешным, поскольку изначально поставленная задача была решена, хотя мы и не уложились в первоначальные эстимейты
В обоих случаях проект мог быть выполнен за одно и то же время и в рамках одного и того же бюджета.
называть заказчику предположительные экспертные сроки с учётом стадий продукта;
не брать к исполнению задачи, если они не недостаточно проработаны командой, не ясны всем участникам;
Интересно, как вам (им?) удавалось называть экспертные сроки недостаточно проработанных задач?
Надеемся, статья была полезной. В следующем материале по этому кейсу мы расскажем о том, как именно Сбер оптимизировал работу IT-команды над этим проектом технически.
Прям вот весь Сбер оптимизировал одну команду? Или это будет история, как одна команда вместо самоорганизации старательно училась работать по правилам?
Кстати, если уж речь пойдет про оптимизацию, не забудьте, пожалуйста, сравнение "было-стало".
Кейс-лайфхак: как IT-команда Сбера научилась комфортно укладываться в сроки, нужные бизнесу