Как я, тимлид, оцениваю проекты

[DenisTrunin]

А как вы оцениваете время тимлида на оценку? или часы тимлида просто включаются по формуле(например +20% от разработки)
некоторые пункты тоже не очень понятны, например

Если это возможно, вывожу разработчиков “в поле”

Чтобы вывести разработчиков смотреть как работают кассы, необходимо чтобы клиент подтвердил что он согласен что именно мы разрабатываем это ПО для касс, а для этого оценка уже должна быть дана в каком-то виде

[imater]

Спасибо за вопрос. Речь о существовании двух оценок, первая для клиента разом, для оценки проекта и его стоимости и такая оценка обычно делается или в «одно лицо» или с проверяющими и дополняющими. А потом при каждом спринте уже нужна оценка задач на спринт и основная цель этой оценки, не «стоимость» задач, а определить такой объём спринта, чтобы к концу остаться без задач и при этом не бездельничать несколько дней.

Так вот для общей мотивации команды и точности оценки спринтов (т.е. второго вида оценки, которая делается весь проект каждые пару недель), команда должна представлять бизнес клиента как можно точнее и пощупать его для этого самое то.

[imater]

Тимлид оценивает проект за 3-5 дней, а проекты длятся месяцами, поэтому его трудозатраты «ничтожны» в соотношении и вообще, работу тимлида лучше считать отдельно, как фикс. Когда тимлид трекает время, при том что у него несколько десятков задач в день это недальновидная политика компании.

[OasisInDesert]

Интересно. Спасибо.

[Areso]

Обучающий курс за 8 лет?
Да он через 8 лет даже большинству ВУЗов будет не нужен.

[Viktor_Vita]

А это нормально, что техники выполняет задачи тимлида.?

[RiCnRoM]

правильные мысли изложены, но вот действительно интересно, что насчет прошлого опыта

[MetaAbstract]

Эта статья прекрасно отражает как на рынке формируется стоимость проекта, потому что, что можно сказать об объеме работ не спроектировав систему? Только тыкнуть пальцем в небо.

[Varim]

А что можно сказать об объеме спроектировав систему? Верно ли что на 100% спроектированная система идентична написанному коду?

[MetaAbstract]

По проекту можно метрики получить и посчитать стоимость разработки.

Верно ли что на 100% спроектированная система идентична написанному коду?

Очень странный вопрос. А как иначе? Код мимо проекта? При этом понятно, что процесс итерационный и проект меняется в процессе разработки.

[Varim]

Я к тому, что спроектировав архитектуру системы, написав различные диаграммы вы всё еще будете тыкать пальцем в небо да же если бы требования не менялись. Расписав техническую документацию которую тоже сразу на 100% не напишешь, но допустим написали на 100%, все равно при сроках будем тыкать пальцем в небо. Потому что разработчику нужно думать, а это процесс слабо управляемый и подающийся прогнозам.

[MetaAbstract]

Если проект системы сделан качественно, то разработчику надо не думать, а реализовывать функционал системы в рамках не функциональных требований. Если разработчик много думает, значит проект не качественный. По проекту системы можно метрику и стоимость проекта посчитать.
Опять же понятно, что процесс итерационный.

[Jayalljust]

imater Спасибо за статью, очень информативно, и все же вопросы возникают. Основной вот в чем: вы пишите, что даете точную оценку вместо «от» и «до». Хотел бы уточнить, фиксируете ли вы для себя эти от до или совсем без них работаете. И если без них, то как идентифицируете и предотвращаете риски?

[imater]

Мне понравилась методика указания колонок «от» и «до» и по формуле вывод среднего значения. Заказчику выдаём уже среднее значение, а от разбега дельты между «от» до среднего и «до» понятно, насколько рискованный пункт и насколько он неясен. Т.е. там где задача от 5 часов до 50 часов, это неточные требования к задаче. А там где от 5 часов до 7 часов, за эту задачу можно не переживать.
Так эта таблица и остаётся в истории и потом можно проанализировать. Но по секрету скажу, что потом эти таблицы никому не интересны, так как это просто элемент продаж, а основное планирование происходит на этапе планирования спринта.