Верхнеуровневая и точная оценка сроков
Сегодня хотел бы поговорить об оценке сроков, как со стороны исполнителя, так и со стороны руководителя. Последние 7-8 лет я участвую в оценке сроков, как на собственные задачи, так и на задачи команд и отделов в целом. Поэтому сразу хотелось бы сказать, что мы можем говорить о реальных сроках на задачи и верхнеуровневых оценках.
Верхнеуровневые оценки и работа с бизнесом
Верхнеуровневые оценки нужны для долгосрочного планирования и обычно их нужно давать по очень расплывчатым описаниям, но без этого, в рамках большинства бизнес процессов, невозможно строить планирование развития продукта. Основной проблемой тут является то, что сроки эти, естественно, никогда не бывают точными. Это понятно каждому исполнителю по причине отсутствия достаточного количества деталей для оценки. Однако, бизнес команда обычно очень сильно цепляется за такие сроки и потом начинаются интересные процессы согласования реальных сроков. Какого-то идеального решения я не знаю, советую закладывать хорошие запасы на максимально видимую постановку задачи. Не соглашайтесь на убеждения, что задача будет простой просто пока не ясно на сколько, скорректировать сроки в минус всегда можно без особых проблем и споров, а вот в плюс почти никогда не работает без проблем. Также, при каждой оценке приучайте коллег к пониманию, что сроки будут пересчитаны при детализации задач. С некоторыми в итоге это приведет к вполне конструктивному общению в рамках планирования.
Как собирать сроки с людей
С конкретными задачами, тоже все не очень ладно. Почти каждый руководитель понимает, что нужно делать наценку на непредвиденные ситуации, но, когда собирает информацию с исполнителей, забывает учить каждого этому простому подходу. В итоге обычно собираются очень оптимистичные сроки и запаса не хватает. Что же делать? Не требовать ответ с людей в моменте и даже не принимать его. Дайте людям все хорошо взвесить, найти проблемные места и заложить на это время. Я стараюсь собирать итог не раньше чем через день (если только не горящая задача, но такие обычно берутся в работу и делаются пока не будут готовы в первом приоритете). В итоге такой подход + ваша наценка, дадут неплохое представление о времени реализации задачи.
Как закладывать сроки разработчику
Будучи разработчиком, я тоже всегда продумывал все моменты, где что-то может пойти не так, где надо заложить времени и где могут понадобиться дополнительные усилия. Советую каждому не пытаться дать ответ о сроках сходу. Это довольно сложно, наш мозг любит отбрасывать «мелочи» при беглом просмотре, а из таких мелочей может состоять 80% времени реализации задачи. Берите время на проработку и оценку. Не пытайтесь угадывать, анализируйте и оценивайте.
В целом решать проблемы с точностью оценок нужно через адекватное восприятие невозможности всегда попадать на 100% и ретроспективы, на которых разбираться, что пошло не так и что можно улучшить. Главное пытаться устранить причины плохой оценки, а не искать виноватых.
Максим Шаламов.
#тимлиду #разработчику #agile_который_работает
Сегодня хотел бы поговорить об оценке сроков, как со стороны исполнителя, так и со стороны руководителя. Последние 7-8 лет я участвую в оценке сроков, как на собственные задачи, так и на задачи команд и отделов в целом. Поэтому сразу хотелось бы сказать, что мы можем говорить о реальных сроках на задачи и верхнеуровневых оценках.
Верхнеуровневые оценки и работа с бизнесом
Верхнеуровневые оценки нужны для долгосрочного планирования и обычно их нужно давать по очень расплывчатым описаниям, но без этого, в рамках большинства бизнес процессов, невозможно строить планирование развития продукта. Основной проблемой тут является то, что сроки эти, естественно, никогда не бывают точными. Это понятно каждому исполнителю по причине отсутствия достаточного количества деталей для оценки. Однако, бизнес команда обычно очень сильно цепляется за такие сроки и потом начинаются интересные процессы согласования реальных сроков. Какого-то идеального решения я не знаю, советую закладывать хорошие запасы на максимально видимую постановку задачи. Не соглашайтесь на убеждения, что задача будет простой просто пока не ясно на сколько, скорректировать сроки в минус всегда можно без особых проблем и споров, а вот в плюс почти никогда не работает без проблем. Также, при каждой оценке приучайте коллег к пониманию, что сроки будут пересчитаны при детализации задач. С некоторыми в итоге это приведет к вполне конструктивному общению в рамках планирования.
Как собирать сроки с людей
С конкретными задачами, тоже все не очень ладно. Почти каждый руководитель понимает, что нужно делать наценку на непредвиденные ситуации, но, когда собирает информацию с исполнителей, забывает учить каждого этому простому подходу. В итоге обычно собираются очень оптимистичные сроки и запаса не хватает. Что же делать? Не требовать ответ с людей в моменте и даже не принимать его. Дайте людям все хорошо взвесить, найти проблемные места и заложить на это время. Я стараюсь собирать итог не раньше чем через день (если только не горящая задача, но такие обычно берутся в работу и делаются пока не будут готовы в первом приоритете). В итоге такой подход + ваша наценка, дадут неплохое представление о времени реализации задачи.
Как закладывать сроки разработчику
Будучи разработчиком, я тоже всегда продумывал все моменты, где что-то может пойти не так, где надо заложить времени и где могут понадобиться дополнительные усилия. Советую каждому не пытаться дать ответ о сроках сходу. Это довольно сложно, наш мозг любит отбрасывать «мелочи» при беглом просмотре, а из таких мелочей может состоять 80% времени реализации задачи. Берите время на проработку и оценку. Не пытайтесь угадывать, анализируйте и оценивайте.
В целом решать проблемы с точностью оценок нужно через адекватное восприятие невозможности всегда попадать на 100% и ретроспективы, на которых разбираться, что пошло не так и что можно улучшить. Главное пытаться устранить причины плохой оценки, а не искать виноватых.
Максим Шаламов.
#тимлиду #разработчику #agile_который_работает
Илон Маск заявил, что все его сотрудники, считающие работу исключительно в офисе устаревшей концепцией, могут притворяться, что работают в другой компании. Что мы думаем по поводу подобных высказываний знаменитого предпринимателя? Что ж, гений и миллиардер может себе и такое позволить. Всем остальным советуем изучать, как считаются метрики эффективности при удаленной работе команды.
#тимлиду
#тимлиду