Оценка и соблюдение сроков времени выполнения задач в ИТ довольно больная тема.
Недавно на Хабре вышли две статьи, и я предлагаю вынести на обсуждение довольно важный тезис - «Убедитесь, действительно ли вам нужна оценка задач, кому она нужна и какую проблему она решает?». И можно ли решить эту проблему иначе?
Внешний клиент и заказная разработка — тут больше про юридические риски и оплату. Кто-то подписывается под фиксированной стоимостью, а кто-то продаёт время.
Большая компания, много разных команд и проектов — тут больше про синхронизацию отделов и команд, внутренние конфликты и «политические игры». Может быть прозрачность и улучшение коммуникаций даст больший эффект, чем жесткие дедлайны?
Не ИТ-компания с ИТ-отделом, или небольшая компания с одной командой разработки — тут больше про недопонимание, инерцию мышления и/или подражание. «Вы не Гугл», что тут скажешь.
Моё личное мнение, что может происходить следующая цепочка событий:
Топ-менеджмент, на бизнес-обучении узнает о постановке целей по методике SMART (или по любой похожей методике), о необходимости ставить сроки и контролировать их выполнение. “Если цель не ограничена во времени, не будет ощущения срочности и, следовательно, выполнение цели растянется надолго” или в другом переводе - "Если срок забыли обозначить, то сотрудники будут откладывать выполнение задач и переключаться на другие, с понятными приоритетами во времени."
Применение данного подхода транслируется на подчиненных, по всей цепочке должностной иерархии. Формально или не формально.
В какой-то момент, способность дать точные сроки и уложиться в них становится показателем профессионализма сотрудника.
В качестве примера, цитата из статьи
№3. В конце проскорили полученные метрики через ключевые, на наш взгляд, характеристики, определяющие эффективность производства: соблюдение сроков; ...
Кажется, что профессионализм должен оцениваться как-то иначе и по разному, для разных профессий. А не единой, но более простой метрикой.
Кажется, что в ИТ, сроки нарушали, нарушают и будут нарушать.
Менеджеры могут увеличить прессинг и возможные последствия тоже известны: завышение сроков (даже для простых задач), неэффективная трата ресурсов компании на сложные методики оценки и конфликты, выгорание и текучка кадров.
Более конструктивной выглядит идея снижения важности или замены сроков на WIP-лимиты и Канбан.
И ещё одна мысль про метрики, начну с цитаты:
Итак, как же теперь использовать метрики?
Первое, чем они оказались полезны, так это тем, что ввод фиксированного набора метрик позволил нам всех заинтересованных лиц привести к одному знаменателю в вопросе понимания эффективности.
Использование метрик для понимания эффективности — это не самоцель, а промежуточный этап и хороший способ «выбить премию». Найти способ взломать метрики по KPI займёт некоторое время, была бы мотивация.
Метрики должны помогать принимать решения, правильные решения. И не всё можно оцифровать.
Вся история начинается с топ-менеджмента, которому часто нужны не столько сроки и метрики, сколько ответы на вопросы: А сотрудники хорошо работают? Не ленятся? Не врут?
Но контролировать сроки гораздо проще. Это очень традиционный и привычный способ, из очень давних времён, когда ИТ не было.
Комментарии (9)
ruomserg
21.12.2023 09:10Философски - проблема сроков никогда и никуда не денется - пока есть закон неубывания энтропии и связанная с ним стрела времени. Вот когда все процессы будут нейтральны относительно времени (или хотя бы когда денежные потоки станут нейтральными - в смысле перестанут дисконтироваться) - тогда никто не будет спрашивать за сроки. Но это не при нашей жизни...
С другой стороны, неопределенность в разработке тоже никуда не собирается уходить (точно так же как, например никуда не делась неопределенность в геологоразведке, строительстве новых ракет, изобретениях и проч). Соответственно - построение моста между реальным миром (со сроками) и миром разработки (с неопределенностью) - является обязанностью менеджмента.
Практика показывает, что в других отраслях для этого используются статистика и теория вероятности (актуарная математика в страховании, теория надежности в механических и электронных системах, и так далее). И в ИТ оно туда же идет... Но идти будет долго, потому что обычно в менеджеры идет тот, у кого не хватило упорства и способностей получить техническое образование. Поэтому когда вы начнете говорить с сегодняшними менеджерами о потоке задач, о распределении вероятности, о моделировании монте-карло - у них начинает болеть голова, и у многих - случается иллюзия умственного переутомления...
А потом они тебя берут за пуговицу - и говорят: "...ну это все конечно понятно - про распределения ваши, про перцентили - но ты мне скажи, какой срок в договоре с клиентом поставить ?".
Занавес...
RouR Автор
21.12.2023 09:10Хороший комментарий.
"Статистика и теория вероятности, актуарная математика в страховании, теория надежности в механических и электронных системах" - они ведь работают большим количеством элементов и эти элементы не так уникальны как задачи в ИТ. Как думаете?
ruomserg
21.12.2023 09:10У меня есть впечатление, что вот прямо уникальных-уникальных задач в ИТ сейчас на порядки меньше, чем во времена первых ЭВМ. Тогда, без языков программирования высокого уровня, без интерактивной отладки, с ненадежной электроникой - даже сортировка пузырьком была подвигом и могла потребовать для своей разработки - любого наперед заданного количества времени.
Сейчас - в большинстве случаев, все алгоритмы уже реализованы в библиотеках. Соответственно, задача программиста - взять их и написать клей (и кусочки бизнес-логики). В этом смысле, все задачи между собой (после достаточного дробления) - очень-очень друг на друга похожи. Я лично вообще в последнее время стараюсь не употреблять слово "сложность", потому что нашел лучший термин в COCOMO2: (un-) precedentness - сиречь мера незнакомости. Если проходя через уровень лида или архитекта задачи оказываются побиты на куски с таким уровнем незнакомости, что команда может их обработать - я считаю вполне валидным канбан-подход, когда мы считаем историческое распределение lead-time и потом методом монте-карло предсказываем сколько задач с какой вероятностью будет сделано за заданный промежуток времени.
Разумеется, может прилететь задача с уровнем прецендентности для команды "...да вообще фиг знает с какого бока начинать!". И тут два варианта - либо нанимать человека, который знает что с таким делать - либо начинать НИОКР: давать время команде для изучения вопроса и экспериментов (без гарантии выхода годного вообще).
LifeHackMan
21.12.2023 09:10Во многих сферах бизнеса простые задачи уже давно решены, и чтоб заработать дополнительных денег, нужно решать задачи, для которых нет готовых алгоритмов, дающих нужное качество
Конечно, разработка стала гораздо более высокоуровневой, но и задачи тоже, и проще они от этого не стали
kost_tr
21.12.2023 09:10Всё это похоже на некий мозговой штурм, очень много статей вышло про эту тему (и не только на хабре)
Накину немного своего взгляда
Необходимо разделять оценку задач по степеням готовности
Согласен с автором что потребность в оценке может исходить от ТОП менеджмента
Дополню автора, от конкретного разработчика она так же может исходить (хороший специалист ценит своё время, и даёт некую оценку, а очень хороший специалист в неё укладывается - важно понимать, что он закладывает время размышлений и поиска решения, даже если решение ему известно)
-
Предложу так же разграничить уровень оценки по этапам жизненного цикла конкретного проекта/продукта:
Обсуждение идеи - одна оценка (цель останется, но вот подход может измениться)
Первичная проработка архитектуры - другая оценка (определяет границы, но содержание может меняться)
Декомпозиция по итерациям - третья оценка (определяется набор функций, но и он может меняться)
Согласование условий оплаты и сроков - четвертая оценка (хочешь быстро и качественно плати много)
Есть жизненный цикл разработки, там свои этапы и способы оценки
Есть жизненный цикл поддержки со своей спецификой
Задача на самом деле комплексная и многогранная, для себя давно решил, что лучший способ - это адаптация под правила компании с применением здравого смысла, участники процесса должны понимать откуда взялась та или иная оценка и иметь возможность на неё повлиять, при условии понятного обоснования
dimas846
Оценка времени на выполнения задачи важна не только как KPI эффективности, но и для планирования в целом. Без estimations все бы развалилось
CorwinH
Непонятно, за что минус. Оценка времени выполнения задач нужна и важна.
1) Руководителю нужно планировать работу подразделения. Какой бы приблизительной не была эта оценка, "5 задач на 80 часов" всё равно лучше, чем "5 задач". Тем более, что каждый конкретный руководитель конкретного подразделения вырабатывает для себя эмпирические правила типа "40 часов задач - это две человеко-недели рабочего времени".
2) На основе таких оценок можно принимать не только "стратегические", но и "тактические" решения. Например, если уже готово к работе задач на 100500 часов, то можно отменить еженедельное совещание по разбору и оценке новых задач.
3) Если кто-то уже четвёртый день работает над задачей, оцененной в 8 условных часов, это повод разобраться в причинах. Возможно, он бьётся над задачей "не по рангу" вместо того, чтобы обратиться за советом к более опытному сотруднику.
4) Если у вас решение задачи заняло сильно больше времени, чем запланировано, то стоит задуматься и самому себе честно ответить на вопрос "почему?". Не обязательно делиться ответом с коллегами.
LifeHackMan
2) А ещё можно изначально не ставить еженедельное совещание по разбору и оценке новых задач
А ставить разовые встречи, когда эти новые задачи действительно накопились и стоит их разгрести, или если прилетело что-то срочное, что стоит обсудить
zolroman
Есть ощущение, что оценка задачи и сроки - не одно и то же.
если задача оценена в 2 дня, это не значит что через 2дня она будет готова.