Comments 12
Требования меняются. Не если, а когда. Пока программировали первую фичу, заказчик увидел черновой макет и понял, что хотел не так. Пока обсуждали с юристами, вышел новый закон, который меняет логику. Пока писали ТЗ, конкурент выкатил похожую фичу, и стейкхолдеры захотели помериться кое чем и выкатить еще лучше. Средний проект, который я вел, переживал 3–5 серьезных изменений скоупа за время разработки. Замечу - средний
Agile вам в помощь.
И он вполне неплохо позволяет выпускать релизы в срок.
Сроки в IT срываются из-за того, что мы пытаемся оценить то, что по природе своей плохо оценивается.
Тут может быть столько разных причин: от "надо вчера" до "просто не научился планировать".
Крупные заказчики, работающие через тендеры не хотят и слышать про эджайлы эти ваши. Водопад. Только он. С дорожной картой, прописанными работами и.т.д. Выход один - он в статье - учитывать и показывать риски в самом начале.
Ну тут либо шашечки, либо ехать.
Перед крупными заказчиками не обязательно махать красной тряпкой флагом с манифестом. Отказываться от технологий, которые специально созданы для разработки в меняющихся условиях - ваш (автора статьи) выбор. Изобретать велосипед и собирать все грабли при этом вам (автору статьи) никто не запретит.
Заведите где угодно, хоть в таблице, журнал: что оценили, что получилось по факту, какой был коэффициент промаха. Через 10 проектов у вас будет собственный множитель для типовых задач. У нас в одной из команд он был стабильно 1,8. Это значит, что оценку разработчика мы смело умножали на 1,8 и чаще всего попадали.
Вот это прям про производительность команды в story point-ах
Как agile методология позволяет ставить временные оценки завершения проекта в формате "диапазон дат"? Искренне интересно.
В целом эта методология позволяет вносить небольшие изменения, но часто.
Через это тренируется навык декомпозиции, приоретизации и получения обратной связи от заказчиков.
То есть снижаются риски того, что команда потратит драгоценное время на создание никому не нужного продукта/функционала.
А через хорошую декомпозицию получается довольно точно оценивать задачи с привязкой к производительности команды.
Всю дорожную карту на год с точностью до дня не оценишь, но это и не нужно, как мне кажется. Вы же не планируете свой обед с точностью до секунды.
Я видел владельца продукта, который через некоторое время оценивал трудоемкость задач и примерное количество задач в спринте настолько точно, что "предсказывал" результаты планирования.
Так что вполне возможно, что такоц владелец продукта спросит: что нужно в первую очередь? И сможет довольно точно сказать сроки по первоочередным задачам, плюс ориентировочные сроки по дальнейшему списку. И будет каждый спринт вносить коррективы (аргументированные) в эту дорожную карту.
Есть свой коэффициент промаха по команде, или все еще надеетесь, что в этот раз обойдется?
Есть. Два хороших, эмпирически подобранных за много лет коэффициента - 2,72 и 3,14.
Основная проблема в другом - реальный срок может быть не приемлем вот прямо так сразу. Но при этом если уже начать и сделано почти все - то как бы некуда деваться и придется сроки сдвигать, потому что лучше превысить бюджет, чем перечеркнуть все.
Вообще это всегда так. Мы бы не начинали многих вещей, если бы знали реальные затраты на них. Как говорил папа дяди Федора - Был бы у меня такой кот… Я может и не женился бы никогда!.. Т.е. многие вещи не состоялись бы, если бы люди знали заранее с чем столкнуться и не строили радужных иллюзий. Но раз уж начали - то приходится доводить.
Вот прям в точку сказано! Согласен
Золотые слова, с языка снятые. Все врут по срокам заказчику, а тот и рад, что все так быстро на бумаге. Не раз слышал, что фича уже работает у других, более маленьких игроков рынка, а у нас ее нет. Когда говоришь реальные сроки, начинается недоверие. А когда говоришь, "сделаем, не проблема", то даже сроков не спрашивают, ведь так удобно.
А все аутсорсники врут своим клиентам, особенно менеджеры, которые на словах за месяц могут внедрить новую программу вместо текущей системы учёта. Но смеяться при руководстве нельзя, скажут что мешаешь и вставляешь палки в колеса. Здесь говорю, дайте план действий и кто ответственность возьмёт по составлению ФТ? Сразу тишина, на этом и расходимся довольные.
Спасибо автору, есть действительно рабочие методы, которые применяю сам и довольно успешно
Но хочется подсветить одну очень банальную вещь. Оценка задач это навык, который не так сложно развить. И если у вас разработка регулярно не попадает в оценку на 70%, значит компетенции у разработки недостаточно и ее нужно развивать, а не воспринимать как нормальную историю
В реальный срок добавляется еще куча всего: ревью кода, правки по ревью, тестирование, правки по тестированию, согласования с аналитиком, созвоны по уточнениям, ожидание доступов от DevOps, ожидание, пока заказчик посмотрит, ожидание, пока кто-нибудь развернет на стейдже
Все, что вы тут перечислили должно быть заложено и проработно менеджером на этапе планирования, эти риски стандартны и возникают почти на любом проекте
Скажу честно, отчасти с автором я согласен, но если которые ведёт менеджер регулярно НЕ сдаются в срок, значит компетенции менеджера недостаточно и в первую очередь нужно работать над собой, а не пытаться себя оправдывать тем что в большинстве проектов так. И тут автору еще раз спасибо, действительно действительные способы
Молчать до дедлайна и геройствовать в выходные — классический путь к провалу проекта и команды
Ох, вспомнил, были времена... Это действительно не работает и, разработчику может казаться лучшим планом, но на практике - это худшее, что можно придумать. Сколько я в своё время потратил нервов на это...
Потому что не зря в Америке менеджерам столько платят.
А у нас вместо менеджеров сидят инженеры адепты вотерфола.
Почему сроки в IT почти всегда срываются. И почему, кажется, это всех устраивает