Комментарии 7
В it с определением времени выполнения работы есть трудности. Я 35 лет в it но не всегда могу оценить обьем работ. Но оценка может быть неверной в обе стороны. Может оказаться что трудная на первый взгляд задача реалезуется за пару часов. А может быть что простая, казалась бы задача, может потребовать не одну неделю работы.
Очень частая ситуация - для решения задачи существует библиотека, возможно не одна. В таком случае интеграция библиотеки не сложная задача. Но в процессе интеграции может выяснится что не одна из библиотек не работает стабильно, имеет баги или недочеты. При этом еще не известно что займет меньше времени - правка чужой библиотеки или написание своей.
Так же есть существенная разница между it и другими отраслями. На стройке плохой каменщик кладет 100 кирпичей в час а хороший 150. В it производительность труда хорошего и плохого программиста может отличатся в сто раз.
То что один програмист делает за месяц, двое за два, трое за три, а десять за год))))
Проблема с оценкой была есть и будет. Эту проблему решает риск менеджмент, который как правило не упоминается в методиках разработки ПО. Для решения этой проблемы всего то требуется получить ТЗ с оценкой задач и заложить риски на весь проект 10-50% в зависимости от сложности проекта. И как результат менеджер просто спокойно выделяет время на задачи с которыми ошиблись в оценке. Ничего сложного.
Но к сожалению в ИТ об этом не говорят, там повсеместно либо scrum либо agile. Скрам это когда победил менеджмент, а agile когда победила команда разработки. В обоих случаях будут проблемы, это просто смещение фокуса. Хорошее ТЗ + менеджмент рисков являются решением этих проблем. Проблемы из статьи не имеют никакого отношения к методологии разработки, это некомпетентность руководства и не способность организовать бизнес процесс.
Когда-то люди поймут что оценка задач бесполезное занятие
А разве люди этого не понимают? Проблема в том, что человечество упорствует в огромном количестве абсолютно идиотских практик и в каждом случае у этого есть фундаментальная причина не имеющая никакого отношения ни к непониманию ни к глупости. Конкретно с оценкой времени имеем
цель деятельности как уведичение капитала. Капиталу всё равно куда вкладываться, чтобы решить куда ему нужны оценка выгод и оценка затрат. Первую определяет талант бизнесмена, в здоровом обществе состоящий в способности понимать истинные, см. Джобс, потребности окружающих, а вторую - опыт бизнесмена, в случае быстро изменяющейся среды типа ИТ мало полезный, и любые ухищрения типа оценок задач.
использование работы по найму. Связанные с ней интересанты, начиная со слоя менеджеров, нуждаются в оценках как для того, чтобы говорить с капиталом, так и для укрепления власти и отсева имперсонаторов.
Таким образом, оценка задач - неизбежное зло. Попытка от этого избавиться без устранения обеих фундаментальных причин - сделает только хуже.
За много-много лет видел всего два решения.
в СССР полным аналогом оценки была необходимость составления квартального плана. Решение - включение в план только уже выполненных работ.
в стартапе в США талантливый менеджер не давал заданий, не спрашивал сроков, а объяснял направление развития. Иногда, правда, говорил типа - вот эти две фичи нужны к следующему понедельнику, отдел продаж их уже продал.
В обоих случаях вопрос о вложении капитала был решён до того, а проблема менеджмента и имперсонаторов была решена внеэкономическими методами.
Вывод; если нет возможности организовать производство совсем иначе, не так как все, обратно см. Джобс, то терпите и не дёргайтесь.
Добрый день!
Решение - включение в план только уже выполненных работ.
А можно тут поподробнее? Заполнять план задним числом? Или просто отставать/опережать на квартал по документам?
Это же рецепт идеального agile - спокойно делать задачи по приоритетам, а на планировании заполнять следующий спринт итогом предыдущего)
У меня было в управлении 2 команды - веб и мобилки, с частью общих сервисов, где как раз оценки фронтов были близки к правде, а оценки на сервисы сильно расходились с действительностью именно в мобильной команде.
Что сделали: мобилки согласовали некий шаблон оценки задач и рисков при ее решении, и мы договорлись, что задачи со средней степенью неопределенности и сложнее мы идем и оцениваем дольше, выделяя время в спринте только на оценку (с неким исследованием). Если задача в принципе неоцениваема, мы выделяли отдельной задачей поиск решения, согласовывали на это выделение времени, и после поиска задача сводилась из высокой неопределенности к средней или набору простых, и оценки бились. Оценки нужны для 2х вещей: чтобы спринт был наполнен, а не перегружен (то есть чтобы разработчик честно сказал, я не сделаю - и не сделал), а так же чтобы бизнесовому заказчику делать ограничения с 2х сторон на периоде (сделаем не раньше такого-то и не позже такого-то).
Итог довольно простой: в командах вопрос на ретро "почему ты не сделал, хотя мы же планировали" перестал подниматься в принципе, отношения стали гораздо лучше, а для бизнеса стало понятнее, что если они хотят что-то впихнуть, то придется чем-то жертвовать. Я продакт, то есть я представлял тот самый бизнес, но так как я же и проджект (ну не было отдельного, епрст), я же и понимал необходимость ограничений, прекрасно понимал своих парняг и девчин в команде, и как следствие, у нас доверие, чилл, отсутствие авралов по вине перепланирования, не было кранчей - мне спокойно, людям спокойно.
а если приходить сверху и как заказчик "а к среде сделаете? а почему?", не разбираться в процессах, не иметь понимания технологий и ограничений, не видеть ситуацию изнутри - то да, проблема оценок стоит остро, тогда "эти они виноватые, а я все сделал" и прочие радости эффективного менеджмента вылезают. Вы одно целое с командой, один продукт делаете, один хлеб едите, так и двигайтесь к общим интересам
Мы когда приходили с проблемой оценок в команду, мы тоже с вторым коллегой-продактом приходили не с ноги "вы все косяки", а с проблемой "у нас есть запрос озвучивать границы, мы уже и перезакладываемся, и че тока не делаем, но все равно случается попадос, и влетаем - ребяты, как можно сделать лучше".
и ретры не ради ретр, а ретры от лица любого члена команды с подобными вопросами имеют место быть, с совместным же решением, благодарностями, участием. Вот тогда щасье
Поэтому и существует скрам и подобные методологии - не для организации работы (разработчикам скрам не нужен), а чтобы дать "заказчикам сверху" ту степень предсказуемости, которая реально существует. Чтобы PM или техлид говорили с бизнесом на языке реалий и не обманывали друг друга вымышленными сроками. Команда для себя отщипнула от бэклога вот столько на ближайший спринт, еще в бэклоге есть столько-то задач, которые в принципе удалось оценить, по темпам работы, которые наблюдались раньше, похоже, что это еще на пару спринтов. И еще в бэклоге есть миллион задач, которые мы даже не видим смысла пока оценивать - но вы на стороне бизнеса можете каким-то из них поставить высокий приоритет, и тогда мы будем что-то отщипывать от них для следующего спринта.
Оценка времени выполнения задач: желаемое и реальное