Comments 78
Есть менеджеры, которые используют оценки для того что бы потом по ним предъявлять претензии к разработчикам. Такие оценки всегда вредны. Часто "эффективные менеджеры" доводят это до абсурда. Мне пришлось работать с одним руководителем который требовал точной почасовой оценки исследовательских математико-лингвистических задач. При этом не упуская возможности при каждом удобном случае унижать и высмеивать команду, сравнивая с командой фронтенд разработчиков, которые оценивали свою работу в часах и достаточно хорошо придерживались этих сроков.
На практике, в типовых задачах корпоративной разработки, декомпозиция и оценка задач чаще всего бывает крайне полезна (если использовать его без кнута). Допустим, если разработчик говорит неделя, то в процессе декомпозиции на более мелкие задачи (например 4-8 часов), часто выясняется что упускают мелкие задачи и срок выростает с недели до двух. Кроме того, при декомпозиции с тимлидом, часто выясняется, что изначально задача была неправильно понята и разработчик мог сильно усложнить логику какой-нибудь небольшой подзадачи. Т.е. тут главный профит не в том что разработчик потратит меньше времени, а в том что код будет проще, без ненужной/неиспользуемой запутанной логики.
Владельцы/руководители считают деньги и всегда хотят знать сколько денег уйдет на разработку и когда смогут запустить продукт. Плохой менеджер просто транслирует цифры наверх, и потом винит разработчиков. Грамотный менеджер или тимлид использует оценку не для того, что бы потом предъявлять претензии за эти сроки, а для того что бы встроить оценку в налаживание коммуникации и обмен опытом внутри команды и сам дает окончательную оценку руководству, в зависимости от состояния/квалификации команды и ответственность за обозначенные оценки берет на себя.
Одна из основных проблем при оценке, когда руководитель давит на разработчиков или берет на слабо, в стиле "а вот ХХХ сделает это в 2 раза быстрее". В итоге разработчик соглашается, чтобы не потерять лицо, а в итоге не успевает. И на словах получается виноват разработчик, а на деле руководитель, который не использует адекватную систему оценки, например на основе исторических данных, по трем точкам или с дополнительной оценкой рисков. Проще говоря, проблема в не совсем корректной организации процесса оценки.
Иногда удается применить комбинированный подход, например, начать работать с фиксированными бюджетами, а потом, по мере роста доверия заказчика к вам, перейти на работу по фактически затраченному времени. У меня есть знакомые, у которых так получалось.
Главный минус оценок для меня — они многими, почти всеми, включая самих разработчиков, воспринимаются как обязательство.
Сначала менеджер говорит дай хоть что-то, а потом почему не сделал как сказал
Спасибо за статью. Я разработчик, но сейчас прохожу менеджерский курс на курсере, где в том числе обсуждаетсят планирование бюджета и сроков проекта.
Все, что описано в статье — далеко не новость для менеджеров (с образованием конечно, а не самоучек). Более того, есть решения всех этих проблем, проверенные временем. Когда брать оценки, кого к этому привлекать, делать ли какие-то допущения по оценкам или нет и на каком этапе их делать, что вообще означает невыполнение оценки, кто несёт ответственность если несёт, есть ли какой-то резервный бюджет на случай если оценки профакапились, и если есть — то на каком уровне, и кто может его вскрывать — все эти вопросы весьма четко обсуждаются в менеджерских курсах по PMBOK.
Разработчикам надо просто чуть поменьше думать не о своих проблемах. Имхо это вообще проф деформация программистов, когда они начинают думать обо всем на свете, залезая не в области своей компетенции.
Все сказанное, конечно, относится только к командной работе, где есть project manager с образованием.
Ну так это красный флаг для того, чтобы в принципе бежать из компании, а не пытаться заново изобрести велосипед в области менеджмента.
Вы же предя к некомпетентному врачу просто уйдёте от него, как только это поймёте, а не будете пытаться изобрести метод лечения за него. Поэтому я и называю это профдеформацией. Это свойственно разработчикам думать всегда немного шире своей зоны ответственности. Надо уметь себя останавливать, я считаю
А можно сказать, что в ваших "нормальных" компаниях некомпетентное руководство, раз игнорирует компетенции программистов, которые у них должны быть согласно образовательным и профессиональным стандартам. Ну или программисты некомпетентные, только код и умеют писать по готовым ТЗ или спецификациям, и менеджер вынужден сам заниматься составлением тех же спецификаций.
Более того, есть решения всех этих проблем, проверенные временем. Когда брать оценки, кого к этому привлекать, делать ли какие-то допущения по оценкам или нет и на каком этапе их делать, что вообще означает невыполнение оценки, кто несёт ответственность если несёт, есть ли какой-то резервный бюджет на случай если оценки профакапились, и если есть — то на каком уровне, и кто может его вскрывать — все эти вопросы весьма четко обсуждаются в менеджерских курсах по PMBOK.
В теории, нет разницы между теорией и практикой
На практике — она есть
Или вы думаете, что во всех компаниях одни дураки сидят, а тут вы
Во-вторых, я подозреваю, что во многих компаниях IT-менеджеры — это программисты, которые не очень хорошо программируют, но хорошо «болтают языком». Поэтому они стали подниматься по этой лесенке. При этом по какой-то причине они не получают нормального менеджерского образования, и от этого, возможно, начинают изобретать велосипеды, которые иногда никуда не едут. А потом от этого появляются статьи, подобные этой, где программисты начинают советовать свои велосипеды.
Надо для начала читать теорию (не вам, менеджерам). Вот и я вся моя мысль.
Полностью согласен, что для внедрения хорошей системы управления, в том числе, оценок, приближенных к действительности, нужно, для начала понимать, что такое система управления и как она, организуется и работает.
Плюс вам от меня! Могу только на словах пока…
Я также считаю и вижу что в разработке ПО именно повальный непрофессионализм и рождает все эти айтишные "алхимии", "астрологии" и "метафизики". Причины для меня очевидны — дикое желание сэкономить сверху и дикое желание "кушать" снизу, а поверх всего отсутствие требовательного рынка. Подавляющее количество ПО не является жизненно-критичным, кое-как да справляется с поставленными задачами. А как следствие рынок вполне устраивает положение дел.
Потому что дедлайн каждый день?
здесь речь идет о Continuous Delivery и регулярной выкладке готовых результатов в прод небольшими порциями. Это вовсе не то же самое, что «дедлайн каждый день»
Как рассказывал Вадим Макишвили из Яндекса:
"В молодости мне поручили один проект, и я прикинул, за сколько дней смогу его выполнить. Когда я показал свои прикидки начальнику, он зачеркнул мои выкладки и написал новый срок — мое время, умноженное на Пи пополам плюс 2 недели. Я спросил, почему. Он ответил:
- Послушай, в жизни не бывает прямых путей. К любой цели ты начинаешь двигаться в обход, по дуге окружности. Поэтому и надо умножить на Пи пополам.
- Ого, понятно. Ну, а две недели-то почему?
- Так если даже за Пи пополам ты не успеешь закончить, то уж за две недели-то хоть что-то на коленке накидать сможешь! :)"
Добавив 2 недели к положенному по графику сроку на непредвиденные задержки, добавьте еще 2 недели на непредвиденность самих непредвиденных задержек.
Следствие №2 к "Закону прикладной неразберихи" (из "Законов Мерфи")
Оценки это хорошо.
Оба утверждения правильные. Вопрос контекста и кто делает.
В начале статьи автор пишет о том что скрам требует в спринт вкладывать не больше чем команда унесет. У этого правила есть много вариантов толкования и исполнения. Есть те которые приводят к дичи и проблемам. Есть те которые приводят к прогнозируемости и снижению рисков.
Заставь дурака богу молиться — он себе лоб расшибет.
Тоже самое с оценками в разработке.
Оценки бывают полезны, в ситуации когда клиенту, инвестору или руководству нужно понять инвестировать в задачу/проект или нет. Например если задача стоит пол года и 1 млн долларов то да, а если 12 месяцев и 4 млн долларов то нет.
Ну или чтобы понять что мы можем успеть к 1 января, а что нет? Что отбросить? А на чем фокусировать силы команды?
Другой момент когда «эффективные менеджеры» начинают оценивать сроки по задачам. Типа вот у нас 100 задач и каждой задаче надо поставить срок. А потом прививать «комплекс вины» разработчикам и заставлять их через манипуляции работать в выходные.
Ну или есть 1000 других вариантов разбить себе лоб и ушатать команду. Делая оценки сроков без смысла и понимания.
О сроках(датах) в такой постановке не может быть и речи.
Ну и при таком потоке нейронку можно натренировать оценивать задачи :)
Много спорных моментов. Особенно про управление командой и приоритезации.
Есть супер книга про оценки, там всё разжевано и в сухом остатке, покрывает, вероятно, всё что написано в статье и описывает много больше – https://www.amazon.com/Predicting-Unpredictable-Pragmatic-Approaches-Estimating-ebook/dp/B00ZL05FYA.
Если коротко, мое мнение – оценка это лишь догадка, и не обязательство. Нужно её уточнять, и воспринимать как один из факторов для приоритезации работы, чтобы команда не стояла без работы. И оценки менее важны чем фактический результат – итеративно показывайте положительные результаты, и мало кто будет спрашивать оценки (за своими исключениями).
Надо для начала определить, что сроки нужны — менеджерам и заказчику продукта. Программистам же — они до лампочки в большинстве своём.
А вообще я до сих пор недоумеваю — ведь с точки зрения Agile методологий вообще странно предполагать наличие сроков и дедлайнов. Ведь один из основополагающих принципов Agile методологий — каждую итерацию поставлять рабочий продукт. Дедлайны — это же реликт с водопадной модели. У меня всегда складывалось впечатление, что "манагеры" — недочитали эту часть Agile и взяли кусок старой парадигмы — в новую методологию. Потому что "ай-ай-ай, но мы же должны знать когда?! Нам же продавать!" Очень часто хочется ответить "манагерам": "каждые две недели есть готовый продукт — продавайте на здоровье"
Им нужно знать, что будет входить в этот готовый продукт, чтобы знать, что продавать.
Ну на момент получения продукта они точно знают — что туда уже вошло.
Подготовка рекламы фичи, например, должна проходить до релиза фичи
И как это будет выглядеть? Месяц пилить фичу, потом месяц делать рекламу, в которой будет говориться: "А теперь торжественно объявляем, что месяц назад мы выпустили новую версию, в которой вы можете X"?
Да и что там в рекламе делать месяц? Ролик? Материалы?
Да, если это сложная рекламная кампания, то может и дольше быть.
Почему нельзя подготовить это, а пустить онлайн, когда с фичей закончат?
Если это конкурентный бизнес, то важно не только быстро разработать фичу, но и быстро продать ее. Соответственно, с последовательным подходом вы можете проиграть конкуренту, который пилит ту же фичу с той же скоростью, только параллельно еще и рекламную кампанию делает.
К тому же, какой-то релиз может быть запланирован к определенному событию – конференция, выставка и т.д. И тогда команде маркетологов важно знать, что к этому событию готовить, какие фичи будут уже выпущены.
Ну тогда в чём удивление если в результате обгадились со сроками?
Т.е. я к тому, что если есть назревшая тема "программисты не умеют прогнозировать сроки", а манагеры продолжают планировать дедлайны (на основании чего, кстати?), несмотря на то, что их в Н-ный раз нарушают, при этом совокупляя мозг и нервы всем сопутствующим и себе в том числе — то может стоит поменять парадигму мышления?
У меня вообще есть устоявшееся мнение, что в провале сроков — виноваты манагеры. ВСЕГДА. Почему? Потому что обычно, когда манагеры обсуждают контракты и сроки сдачи продукта — мнение программистов зачастую просто не спрашивается. Манагеры же типа "белая кость", в костюмах и "делают деньги компании"- разве там есть место бородатому хмырю в безрукавке, который начинает задавать неудобные вопросы и рассуждать на тему архитектуры? К программисту в лучшем случае прийдут ПОСЛЕ переговоров и то, будут намекать, что "а не прихренел ли ты со своими 1.5 года, потому что мы через 3 месяца уже релиз обещали и деньги уже получили?"
У меня вообще есть устоявшееся мнение, что в провале сроков — виноваты манагеры. ВСЕГДА. Почему? Потому что обычно, когда манагеры обсуждают контракты и сроки сдачи продукта — мнение программистов зачастую просто не спрашивается.
К счастью, хоть и "обычно", но не всегда. В компании, где я сейчас работаю, жесткий дедлайн "сверху" приходит, только если иначе никак – например, требование законодательства "к такому-то сроку должно работать вот так". В остальных случаях сроки называет команда, и в обсуждении участвуют все. И тут уже девелопер должен, имхо, разделять ответственность, если все сроки завалили.
Смешно слышать про "разделение ответственности" в случае если девелопер обвиняется в неумении определить сроки априори, а зачастую — эти сроки ему в принципе навязываются менеджером.
Т.е. предлагается разделять ЧУЖУЮ ответственность, на которую разработчик влияет чуть менее чем никак.
на которую разработчик влияет чуть менее чем никак.
Я же написал, "в остальных случаях сроки называет команда, и в обсуждении участвуют все." Что значит не влияет? Я не за всех говорю, а только за компанию, в которой работаю, и тут именно девелопер больше всех влияет на заявленный срок (опять же, исключая ситуации с "по закону надо сделать до числа X" – но что делать в таких случаях, тема для отдельного обсуждения, таких ситуаций не так уж и много). Не умеет – пусть учится, палкой его все-таки никто не бьет за просроченную задачу. А senior developer должен уметь давать адекватную оценку.
Можно делать, но менее эффективно. Проще говоря, деньги, вложенные в разработку, будут заморожены
А вообще я до сих пор недоумеваю — ведь с точки зрения Agile методологий вообще странно предполагать наличие сроков и дедлайнов. Ведь один из основополагающих принципов Agile методологий — каждую итерацию поставлять рабочий продукт.В первом предложении вы отрицаете сроки и дедлайны в Agile, а вторым утверждаете, что дедлайн известен ещё до появления требований — конец очередного спринта.
Agile это про деятельность с жёстким сроком, жёстким бюджетом, но с гибким объёмом работ. То есть срок и работоспособность к этому сроку гарантируются, но объём выполненных работ к этому сроку — нет.
Нам же продавать!Да, это так. Причём продажа часто происходит до начала спринта: клиентам, совету директоров или акционерам. И у менеджера есть инструмент решения данной объективной потребности бизнеса — выставление задачам по проданному функционалу высокого приоритета помещением таких задач в начало бэклога продукта. Ответственность за разруливание возникающих при этом конфликтов между продавцами на Владельце продукта.
Ключевое слово – итерация.
Итерации в Agile не обязательны. Можно работать по Канбану без итераций, в потоке задач, и поставлять рабочий продукт без итераций – набрали задач от фичи из беклога и вперед за работу. Причем в отличии от Скрама, в Канбане можно заводить задачи по ходу работы.
В Скраме наоборот, итерации важны, насколько я понимаю, потому что там нужна оценка производительности команды, которая достигается через понимание сколько задач какого веса были решены за фиксированное количество времени. Если итераций или дедлайнов нет, это уже не Скрам, это Канбан.
Поэтому всё что вы сказали верно по-своему.
Есть и реликт с водопадной модели, где по Скраму сначала определяем обьем работы, выясняем требования, ставим срок, формируем задачи (и изменить их нельзя, за некоторыми исключениями), и вперед, и получается та же каскадная (водопадная) модель (требования -> разработка -> тесты -> и так далее) в рамках каждой итерации.
Есть и Канбан, где ни итераций (как вариант), ни сроков.
Всё вышесказанное субьективно – я не мастер методологий, это лишь образ как это работает из опыта и книг.
Формально говоря, в скраме вроде оценка производительности команды формальная не обязательна. Главное — достигать поставленных в итерации(спринте) целей, пока ПО и вообще заинтересованных лиц процесс устраивает. "Игры" в метрики и оценки начинаются часто когда цели хронически не достигаются, или у кого-то влиятельного появляется ощущение, что цели слишком лёгкие, что заметную часть спринта команда бездействует.
Как без оценки производительности можно спланировать спринт (Скрам), если менять задачи нельзя?
Насколько я понимаю, сначала берется скорость команды (сколько поинтов реально может сделать команда за спринт), и на этой базе планируется список задач на спринт.
Выходит, что нужны или оценки по задачам без весов (обычные, часы), либо нужна оценка производительности команды. Иначе спланировать спринт, вероятно, не получится.
Делать оценки можно разве что очень приблизительно — день, неделя, месяц. Когда начинают требовать точные сроки — это лишь добавляет работы (считать сроки это тоже работа) и нервотрепки (ой-ой не успеваем в сроки).
Единственный вариант, который как-то на практике помогает в таких ситуациях — это, во первых, предупреждать, что считать сроки — тоже работа, и тоже требует времени, а во вторых, считая, не забывать доносить о том, что «На подсчет сроков такой-то задачи ушло 2 дня». Чтобы руководство знало, что 2 дня программист не код писал, а декомпозировал задачу на самые элементарные подзадачи, прикидывал время на их выполнение, закрывал все неточности в ТЗ.
Ну а самое забавное, это когда на исправление бага требуют обозначить сроки. Особенно, в чужом коде — откуда программист может заранее сказать, решится ли ошибка изменением одной строчки, за 30 минут, или там половину проекта придется переписывать.
P.S.
Самый главный обман, в который попадает офисный разработчик, когда от него требуют четких сроков, и четкого соблюдения сроков — это то, что зарплату он получает за часы работы, а требуют от него уже фактического выполнения задач. Оплата за выполненные задачи — это вообще-то из другой области (там, где не нужно сидеть о офисе, там, где исполнитель сам решает когда и сколько сегодня он будет работать, там, где сделал задачу и свободен).
А так получается, что программист честно отрабатывает свои 40 часов в неделю (а иногда еще и больше), и при этом чувствует себя виноватым. WTF?
Самый главный обман, в который попадает офисный разработчик, когда от него требуют четких сроков, и четкого соблюдения сроков — это то, что зарплату он получает за часы работы, а требуют от него уже фактического выполнения задач. Оплата за выполненные задачи — это вообще-то из другой области
Интересная мысль… Не задумывался о ней.
Если провести какие-то параллели с прошлым, глубоким прошлым человечества, то почасовую/посменную оплату труда получали люди, чей труд был линеен и легко измерим — шахтеры, ткачи, ну и так далее. Условному художнику или строителю моста вроде как платили гонорар за всю работу.
Т.е. задачи делятся на 2 типа
1 производственные
2 исследовательские
Производственные легко считаются, так как описаны кем либо где либо и т.д. (чужой код не учитываю)
исследовательские «мне надо 3 дня, чтобы дать оценку между вилкой 100-1000 часов»
А эффективность разработчика не оценивается в затраченных им часах на работе. Если он полезен бизнесу, то получает больше денег. Вот в этот момент начинается движение на встречу работника и работодателя, подключаются софт скиллы, хард скиллы и деньги со стороны работодателя.
Но тут есть одно но. Производственные оценки обычно уже известны менеджерам или тимлидам, нет смысла ими напрягать линейного разраба.
Если вы в своей жизни сделали 50 одинаковых фич в разных проектах, то знаете сколько времени это занимает.
Проект проекту рознь. Даже в рамках одной платформы время на реализацию фичи может отличаться на порядок исключительно из-за архитектурных особенностей проекта.
Это и называется «риски».
Они бывают скрытыми и явными (в очень упрощенном виде). Если у вас оценка зависит от проекта или его тех устройства, то это явный риск и его можно учесть. Если проект ваш, то архитектура известна (либо у вас будут вопросы к тех персоналу), если проект чужой, то основные архитектуры описаны и это можно учесть, но «фактор» говнокода всегда присутствует.
Поэтому при оценке будет x часов архитектура 1, y часов архитектура 2, риски такие то, и это приемлемо.
Чем чаще вы спрашиваете вашу команду об оценках, тем сильнее вы замедляете ее работу.
Собственно так и есть, время же уходит на сам анализ.
Основная проблема заключается в том, что оценивание сроков должно помогать менеджерам планировать время на работу, чтобы бизнес мог рассчитывать свои траты и получать результаты.
Но слишком часто это оценивание приводится к тому, что все хотят не проанализировать, а непременно
Ускорить можно другими способами — введением автоматизации, наймом дополнительных людей, покупкой дополнительных ресурсов (вычислительных и не только). Опытный менеджер может попробовать поменять методологию разработки. Но к сожалению, редко когда бывает правильно.
Именно поэтому грамотный менеджер не набирает команду разработчиков с которыми сразу в agile и пилить богатому клиенту что-то быстренько, а срабатывается с командой, чтобы примерно представлять их производительность, и обсуждает дедлайны с заказчиком, пользуясь оценкой специалистов.
Agile это вообще не про то, чтобы работать без дедлайнов. Agile это как variable bitrate — общий дедлайн должен быть, а внутри срока какая-то задача выполняется дольше, какая-то меньше, какая-то разбивается на несколько сроков, но это все об управлении людьми, чтобы уменьшить простои.
Люди постоянно спрашивают оценки на первоначальную разработку, но мало кто интересуется оценками на последующую поддержку решения. И это большая проблема, поддержка — это очень серьезно. Поддержка может занимать до 60-80% всех затрат на проект.
Еще задолго до появления PMBOK, SCRUM и ХР, в книгах В.В.Липаева приводилась такая разбивка — первоначальная разработка занимает — 25%, а последующая отладка (тогда это так называлось) еще 75%.
Почему бы, как метод повышения точности оценки не использовать увеличение декомпозиции, например — разработка структуры классов, разработка интерфейсов, разработка GUI, модульное тестирование. Пусть будет чуть побольше оценок, но мы получим следующие результаты:
— уже в ходе оценки разработчик будет думать над реализацией, а не давать прогноз на основе исторических данных;
— получим дополнительные точки контроля, например если первая оценка будет просрочена, это заставит усомниться и в следующих и перепланировать всю работу заново, не дожидаясь провала сроков по итогу;
— получим, то что Вы описывали, как возможность поработать над задачей а потом планировать сроки ее завершения;
— оценочное время разработки фичи. От него зависит стоимость для клиента
— реальная дата, в которую фича будет готова уйти в релиз
Эти два срока в реальной жизни между собой не связаны почти никак. Если это в компании все понимают, то сразу все становится намного проще
Вроде около год назад на хабре был пост, где также, как и здесь, обсуждалась тема оценки сроков задач. Так вот, из одного из комментариев мне заполнилась следующая мысль: "Когда меня спрашивают срок, я всегда сначала рассчитываю ожидаемый срок X с маленьким запасом, а по итогу называю срок X * 2,5", я проверял на себе это много раз и ни разу не ошибся. Многие наверно решат, что это не со всеми работает и я с ними соглашусь, это работает почти всегда только с людьми, которые идут брать новые задачи, как только заканчиваются предыдущие. Для такого человека назвать срок 2.5X не страшно, т.к если он уложится в срок X, то просто пойдет и попросит другую задачу, тем самым опережая сроки еще и покажется себя очень расторопным.
В статье должно было быть хоть что-то об оценке с помощью story points, если коротко то это одна из agile практик, когда оценивается время + сложность + то насколько понятны требования. Главное тут порядок величин, обычно оценка даётся в степени цифры 2 (1/2/4/8/16/32). Первые несколько спринтов оценки просто записываются, а потом становится примерно понятно сколько story points команда делает в среднем за один спринт и уже можно планировать объем работы.
Такой подход позволяет избежать многие проблемы, которые указаны в статье и на моем опыте оценки получаются точнее.
Обычно даётся в числах Фибоначчи: 1,2,3,5,8,13,21...
Из личного опыта добавлю, что нередко в задачи для оценки попадает какая-нибудь полная хрень, которая делается за 5-15 минут, но ей дают 1 сторипоинт, раз уж притащили.
Об оценках сроков в разработке ПО