В армии ходит старая пословица о том, как у старшины, держащего свои полки в чистоте и порядке, ведущего каталогизацию всего имущества, просят еще один комплект снаряжения -- "Склады предназначены для хранения. Если бы я должен был выдавать снаряжения, они бы назывались пунктами выдачи".
Я вспоминаю об этом обескураживающем разговоре, когда слышу, как разработчик получает выговор от руководителя проекта -- который пытается держать свой burndown chart аккуратным и упорядоченным -- за несоответствие результатов работы оценке. Это всего лишь оценка -- наиболее вероятное предположение, сколько времени уйдет на задание, а не точные сроки поставки.
Я жду того дня, когда разработчик перекрутит на свой лад слова старого ворчливого старшины и ответит руководителю проекта: "‘Оценка’, потому что от слова ‘оценивать’. Если бы она была определенной, то называлась бы ‘точной’".
Я не хочу критиковать руководителей проектов. Это неблагодарное занятие, и честно говоря, далеко не из любимых. Руководитель проекта постоянно находится под давлением -- от него требуют спрогнозировать точную дату поставки. Единственный возможный способ это сделать -- отталкиваться от оценок, предоставленных командой разработчиков. Не забывайте, "время -- деньги", а суть оценки -- время.
Проблема заключается в надежности оценок в целом. Пока полная оценка для всех заданий в пределах срока поставки более или менее точна, не столь важно, если кто-то выйдет за ее пределы, а другие справятся быстрее.
Надежная оценка сводится к использованию навыков и опыта и требует от разработчика тщательных раздумий. Оценка "наугад" существенно отличается от продуманной должным образом. Одним из признаков опытного, профессионального разработчика является возможность выполнить надежную оценку.
источник
Я вспоминаю об этом обескураживающем разговоре, когда слышу, как разработчик получает выговор от руководителя проекта -- который пытается держать свой burndown chart аккуратным и упорядоченным -- за несоответствие результатов работы оценке. Это всего лишь оценка -- наиболее вероятное предположение, сколько времени уйдет на задание, а не точные сроки поставки.
Я жду того дня, когда разработчик перекрутит на свой лад слова старого ворчливого старшины и ответит руководителю проекта: "‘Оценка’, потому что от слова ‘оценивать’. Если бы она была определенной, то называлась бы ‘точной’".
Я не хочу критиковать руководителей проектов. Это неблагодарное занятие, и честно говоря, далеко не из любимых. Руководитель проекта постоянно находится под давлением -- от него требуют спрогнозировать точную дату поставки. Единственный возможный способ это сделать -- отталкиваться от оценок, предоставленных командой разработчиков. Не забывайте, "время -- деньги", а суть оценки -- время.
Проблема заключается в надежности оценок в целом. Пока полная оценка для всех заданий в пределах срока поставки более или менее точна, не столь важно, если кто-то выйдет за ее пределы, а другие справятся быстрее.
Надежная оценка сводится к использованию навыков и опыта и требует от разработчика тщательных раздумий. Оценка "наугад" существенно отличается от продуманной должным образом. Одним из признаков опытного, профессионального разработчика является возможность выполнить надежную оценку.
источник
Комментариев нет:
Отправить комментарий