Comments 9
Оценка времени на выполнения задачи важна не только как KPI эффективности, но и для планирования в целом. Без estimations все бы развалилось
Непонятно, за что минус. Оценка времени выполнения задач нужна и важна.
1) Руководителю нужно планировать работу подразделения. Какой бы приблизительной не была эта оценка, "5 задач на 80 часов" всё равно лучше, чем "5 задач". Тем более, что каждый конкретный руководитель конкретного подразделения вырабатывает для себя эмпирические правила типа "40 часов задач - это две человеко-недели рабочего времени".
2) На основе таких оценок можно принимать не только "стратегические", но и "тактические" решения. Например, если уже готово к работе задач на 100500 часов, то можно отменить еженедельное совещание по разбору и оценке новых задач.
3) Если кто-то уже четвёртый день работает над задачей, оцененной в 8 условных часов, это повод разобраться в причинах. Возможно, он бьётся над задачей "не по рангу" вместо того, чтобы обратиться за советом к более опытному сотруднику.
4) Если у вас решение задачи заняло сильно больше времени, чем запланировано, то стоит задуматься и самому себе честно ответить на вопрос "почему?". Не обязательно делиться ответом с коллегами.
Есть ощущение, что оценка задачи и сроки - не одно и то же.
если задача оценена в 2 дня, это не значит что через 2дня она будет готова.
Философски - проблема сроков никогда и никуда не денется - пока есть закон неубывания энтропии и связанная с ним стрела времени. Вот когда все процессы будут нейтральны относительно времени (или хотя бы когда денежные потоки станут нейтральными - в смысле перестанут дисконтироваться) - тогда никто не будет спрашивать за сроки. Но это не при нашей жизни...
С другой стороны, неопределенность в разработке тоже никуда не собирается уходить (точно так же как, например никуда не делась неопределенность в геологоразведке, строительстве новых ракет, изобретениях и проч). Соответственно - построение моста между реальным миром (со сроками) и миром разработки (с неопределенностью) - является обязанностью менеджмента.
Практика показывает, что в других отраслях для этого используются статистика и теория вероятности (актуарная математика в страховании, теория надежности в механических и электронных системах, и так далее). И в ИТ оно туда же идет... Но идти будет долго, потому что обычно в менеджеры идет тот, у кого не хватило упорства и способностей получить техническое образование. Поэтому когда вы начнете говорить с сегодняшними менеджерами о потоке задач, о распределении вероятности, о моделировании монте-карло - у них начинает болеть голова, и у многих - случается иллюзия умственного переутомления...
А потом они тебя берут за пуговицу - и говорят: "...ну это все конечно понятно - про распределения ваши, про перцентили - но ты мне скажи, какой срок в договоре с клиентом поставить ?".
Занавес...
Хороший комментарий.
"Статистика и теория вероятности, актуарная математика в страховании, теория надежности в механических и электронных системах" - они ведь работают большим количеством элементов и эти элементы не так уникальны как задачи в ИТ. Как думаете?
У меня есть впечатление, что вот прямо уникальных-уникальных задач в ИТ сейчас на порядки меньше, чем во времена первых ЭВМ. Тогда, без языков программирования высокого уровня, без интерактивной отладки, с ненадежной электроникой - даже сортировка пузырьком была подвигом и могла потребовать для своей разработки - любого наперед заданного количества времени.
Сейчас - в большинстве случаев, все алгоритмы уже реализованы в библиотеках. Соответственно, задача программиста - взять их и написать клей (и кусочки бизнес-логики). В этом смысле, все задачи между собой (после достаточного дробления) - очень-очень друг на друга похожи. Я лично вообще в последнее время стараюсь не употреблять слово "сложность", потому что нашел лучший термин в COCOMO2: (un-) precedentness - сиречь мера незнакомости. Если проходя через уровень лида или архитекта задачи оказываются побиты на куски с таким уровнем незнакомости, что команда может их обработать - я считаю вполне валидным канбан-подход, когда мы считаем историческое распределение lead-time и потом методом монте-карло предсказываем сколько задач с какой вероятностью будет сделано за заданный промежуток времени.
Разумеется, может прилететь задача с уровнем прецендентности для команды "...да вообще фиг знает с какого бока начинать!". И тут два варианта - либо нанимать человека, который знает что с таким делать - либо начинать НИОКР: давать время команде для изучения вопроса и экспериментов (без гарантии выхода годного вообще).
Всё это похоже на некий мозговой штурм, очень много статей вышло про эту тему (и не только на хабре)
Накину немного своего взгляда
Необходимо разделять оценку задач по степеням готовности
Согласен с автором что потребность в оценке может исходить от ТОП менеджмента
Дополню автора, от конкретного разработчика она так же может исходить (хороший специалист ценит своё время, и даёт некую оценку, а очень хороший специалист в неё укладывается - важно понимать, что он закладывает время размышлений и поиска решения, даже если решение ему известно)
Предложу так же разграничить уровень оценки по этапам жизненного цикла конкретного проекта/продукта:
Обсуждение идеи - одна оценка (цель останется, но вот подход может измениться)
Первичная проработка архитектуры - другая оценка (определяет границы, но содержание может меняться)
Декомпозиция по итерациям - третья оценка (определяется набор функций, но и он может меняться)
Согласование условий оплаты и сроков - четвертая оценка (хочешь быстро и качественно плати много)
Есть жизненный цикл разработки, там свои этапы и способы оценки
Есть жизненный цикл поддержки со своей спецификой
Задача на самом деле комплексная и многогранная, для себя давно решил, что лучший способ - это адаптация под правила компании с применением здравого смысла, участники процесса должны понимать откуда взялась та или иная оценка и иметь возможность на неё повлиять, при условии понятного обоснования
Про оценку времени выполнения задач в ИТ