Я в тестировании 12 лет, работал в Naumen и Яндексе. Сейчас руковожу отделом тестирования из 150 человек в Контуре и продолжаю работать тестировщиком в одной из команд.
После полугодовых performance review менеджеры из разных команд рассказали, какие цели поставили своим тестировщикам. У каждого пятого была такая: «Научиться оценивать сроки на тестирование задач». Часто такой «оценки сроков» хотят не только от тестировщиков, но и от разработчиков.
Оценка сроков в 95 % случаев. Спасибо, xkcd.
Я считаю абсолютно вредной практику, когда исполнитель оценивает сроки на выполнение отдельной задачи. Это напрямую связано с отсутствием системного образования и низкими требованиями к менеджерам.
Сейчас объясню, как это работает.
О трудах классиков
Максим Дорофеев — Эффект выпрямления сроков
Цитирую по книжке «Джедайские техники», хотя можно было и закон Паркинсона процитировать:
К нам приходит человек, ставит задачу и спрашивает, сколько времени может занять ее выполнение. Оценивая задачу, мы, конечно же, хотим назвать тот срок, к которому точно успеем, а так как многое может случиться (и мы подозреваем, что что-то наверняка случится), мы закладываем в оценку некий запас времени.
Вместо того чтобы сразу же приступить к выполнению задачи, мы «разбираемся со срочным», так как «эта задача пока не горит» — у нас же есть вышеупомянутый запас.
Задача начинает «дымиться», и мы приступаем к ней. Если ничего не случилось, то мы успеваем вовремя, а вот если что-то случилось… Резерв мы на это «что-то» уже потратили и в итоге опаздываем.
В итоге любой названный в качестве дедлайна срок становится сроком, раньше которого задача выполнена не будет. К особо неприятным последствиям это приводит при командной работе, когда для выполнения одной задачи или проекта требуется сотрудничество разных специалистов и разных отделов.
Человек как выпрямитель (и диод) — иллюстрация из «Джедайских техник». Видео тоже есть.
Том Демарко — Человеческий фактор
В пятой части первой главы есть ссылки на исследования о зависимости производительности от того, кто выполнял оценку сроков.
Коротко: сам факт оценки влияет на сроки в худшую сторону примерно на 40 %.
Рекомендую прочесть. Все факторы, перечисленные в пятой главе, релевантны до сих пор.
Деминг и Нив — Эксперимент с красными бусинами
За последний год я дважды слышал от менеджеров: «Мы научились выдерживать сроки по оценкам задач, теперь такой-то программист или тестировщик совсем не нарушает сроки, которые назвал».
Я считаю, это крайне серьезная проблема, так как это означает, что этот программист или тестировщик системно и сознательно завышает сроки, работает на расслабоне и лжет менеджеру. В мире присутствуют вариации и ненарушение оценок конкретных задач означает, что оценка такого человека всегда правее кривой распределения фактического срока работы.
Упомянутые в заголовке авторы говорят, что единственно верный способ оценки сроков — статистический. Должен оцениваться пакет типовых задач. «У нас все задачи разные»? Это ложь. На промежутке в год будет уже не очень много разных задач. Как правило, такое заявление является признаком отсутствия рефлексии над процессом и невыполнения упражнений: декомпозиция, MVP, прототипы, стандартизация.
О заказчиках, которые требуют сроки
Во-первых, надо заметить, что чаще всего — и это само по себе забавно — от ответа исполнителя не зависит ничего, потому что сроки уже есть. Менеджер интересуется не сколько времени мы будем делать задачу, а успеем ли мы к заданному сроку и что именно успеем. Это разные вопросы и отвечать на них нужно по-разному.
Как правило, ответом на вопрос «успеем ли мы к заданному сроку» является аналитика и MVP, качественная инфраструктура разработки и размер технического долга, а именно сложность проведения рефакторинга и наличие автоматических тестов на регрессию.
Ещё раз: оценка сроков мешает исполнителю успеть к дедлайну.
Во-вторых, есть серия упражнений в разработке. Не все из них простые. Они напрямую не дают ответ на вопрос «когда фича будет готова». Однако они уменьшают размер поставки, снижают сложность разработки и тестирования и в итоге уменьшают вариативность сроков.
- MVP
- декомпозиция задачи
- ограничение недоделанной работы (программист не берёт новые задачи, пока не вышли старые)
- раздельные релизы рефакторинга и последующих фич
- раздельный релиз бэкенда, фронтенда и других частей продукта
- канареечные релизы
- использование фича-флагов
- умение тестировщиков отделять важные дефекты от неважных
- умение команды релизить с неважными дефектами
Если команда выполняет эти упражнения, а менеджер квалифицирован, то для ответа заказчикам ему не нужно требовать от исполнителей назвать срок. Если упражнения не выполняются, то скорее всего любой названный менеджером срок будет ложью.
О некомпетентных менеджерах
Очень легко перепутать оценку сроков (когда задача будет сделана) и оценку трудозатрат (сколько нужно времени, чтобы разработать фичу). Оценка сроков, как мы уже разобрались, если не вредна, то по крайней мере бессмысленна. А вот оценка трудозатрат — довольно полезное упражнение.
Необходимость оценить трудозатраты, когда задача будет сделана, заставляет делать перечисленные выше полезные упражнения: главным образом, декомпозицию этой задачи.
Но надо помнить, что оценка трудозатрат в команде с некомпетентным менеджером очень легко превращается в оценку сроков. Тут замешан миллион когнитивных искажений и непонимание, как устроены цепочки производства.
Пример из жизни:
— Сколько времени ты потратишь на эту фичу?
— Полторы недели буду писать и дня три фиксить баги.
— То есть через 3-4 недели будет готово?
То есть разница между «я потрачу на эту задачу день» и «задача будет готова через день» многократна и принципиальна.
Ты учишь жизни, а чего добился сам?
Да, давайте поговорим обо мне и моей команде. Некоторые из перечисленных упражнений мы успешно делаем, какие-то учимся делать. Какие-то нет, и это печально.
Думаю, что мы научились ограничивать недоделанную работу, делать предварительные релизы рефакторинга и отделять важные баги от неважных.
Оценку сроков на тестирование мы делаем так. Делим задачи на мелкие, большие и остальные. Мелких задач примерно половина, их делает дежурный тестировщик в свободное время. Мелкая задача помечена в YouTrack тегом «на час» и делается за один подход (от получаса до двух часов), если не возникли осложнения.
Большие задачи помечены тегом «проект», и по ним сразу понятно, что просто не будет. У каждой большой задачи есть фича-лид, задача которого — сделать так, чтоб были проделаны упражнения из списка выше.
Остальные задачи никак не помечены. Упражнения из списка начинают проделываться, если время работы над ней превышает произвольно выбранную и варьируемую границу в 2 недели.
Если в очередь попала срочная задача, надо всё бросить и делать её. Оценивать не нужно. Впрочем, будет полезно уточнить дедлайн, чтобы понять, с какими дефектами и недоработками можно будет выпустить. Таких срочных задач — меньше десяти процентов.
В последний раз я задерживался на работе по просьбе менеджера, чтобы выпустить срочную задачу, больше двух лет назад. До этого пару раз, в 2015 и в 2016 году.
P.S. Один из наиболее важных навыков в нашей работе — не делать ненужной херни. В том числе не заниматься «оценкой сроков» и самообманом. Чего и вам желаю.
(Подпишитесь на наш канал в Телеграме, там неплохо.)
Комментарии (158)
Codenamed
27.03.2019 10:55-1На месте руководителей Контура я бы поставил вопрос о снятии автора с должности за профнепригодность :)
Когда в нормальной команде от разработчика (тестировщика) требуют оценки сроков выполнения задачи, от него ждут двух вещей:
1. Тщательного осознания задачи, ее декомпозиции при необходимости и описания будущего решения (плана тестирования) в тикете. Такой детальный разбор задачи на этапе планирования делается не индивидуально, а в команде. Он позволяет не делать фигни и заодно получить реалистичную оценку сроков выполнения (которая фиксируется в том же тикете).
2. Взятия на себя ответственности за заявленные сроки. Когда задача уже разобрана и решение понятно описано, команда и отдельный разработчик с открытыми глазами берет на себя ответственность за сроки. Это порождает совсем другое отношение к работе, чем спускаемые сверху непонятные, а иногда и безумные сроки от «менеджеров».
Потом из таких качественно предобработанных задач легко собираются управляемые итерации скрама.
Именно такие граждане сначала не требуют от разработчиков оценки задач, перевешивают ее на менеджеров, у которых должны быть совсем другие компетенции, а потом жалуются, что у них «скрам не работает».
Пишу как человек, полтора года руливший невероятно бодрой командой разработки из бывших сотрудников Контура, которая с этим подходом запилила качественный продукт и всегда соблюдала сроки поставки. Не сдержался :)
kentastik
27.03.2019 11:04+1Кажется, автор разделяет понятия сроков и времени выполнения задачи, не очень понял в чем вы видите противоречия?
Codenamed
27.03.2019 13:28Если бы автор работал в заказной разработке, где бюджет может быть важнее сроков, а время выполнения задачи переводится не только в сроки, но и в деньги, это противопоставление имело бы смысл. Иногда заказчику выгоднее делать дольше, но дешевле.
Но автора работает в продуктовой разработке, где единственная цель определения временных затрат на задачу — оценить сроки выпуска очередной функциональности. Речь всегда идет об управлении сроками.
Поэтому противопоставление оценки сроков и оценки трудозатрат в часах — это неловкая манипуляция со стороны автора.
SirEdvin
27.03.2019 13:51Но автора работает в продуктовой разработке, где единственная цель определения временных затрат на задачу — оценить сроки выпуска очередной функциональности. Речь всегда идет об управлении сроками.
И автор утверждает — что оценивать сроки нет никакого смысла. Потому что как только задача начинает отличается от стандартной, начинается гадание на кофейной гуще, когда оценка сильно накручивается, в нее закладываются все возможные риски, а потом еще и ко всему этому совершается ошибка "техасского снайпера".
В продуктовой среде, мне казалось, очень часто сроки ставятся или свыше к какой-то дате, или "чем раньше, тем лучше".
Codenamed
27.03.2019 14:10Без оценки сроков бизнес просто умрет. Попробуйте, например, сказать маркетологам, что вы понятия не имеете, к какому сроку нужно подготовить и запустить многомиллионную рекламную кампанию или пообещать выпустить фичу к текущему пику отчетности, а выпустить через неделю после этого :)
Автор говорит совсем другое — сроки должны оценивать не специалисты, которые своими руками будут делать работу, а какой-то «менеджер» на белом коне, который, даже будучи в прошлом техническим специалистом, конкретных деталей реализации и многотонных подводных камней [уже] не знает.
И главная претензия к автору в том, что он как руководитель целого, по сути, направления, хочет полностью снять ответственность за сроки поставки с команды, лишив ее, пожалуй, самого главного мотивирующего фактора — commitment'а, личной ответственности и участия в жизни продукта.SirEdvin
27.03.2019 14:20Без оценки сроков бизнес просто умрет.
Особенно без оценки сроков на "поменяй тестовку". Мне кажется, у довольно большого количества задач дедлайн, к которому они должны быть реально сделаны — очень и очень мягкий.
А если вы говорите про какие-то крупные "проекты" в духе переделки сайта или создания новой сложной фичи, то обычно дедлайны спускают сверху, как мне казалось.
Codenamed
27.03.2019 14:47Если вы не успеете сделать «до конца недели» всего одну из десятка задач «поменяй текстовку» просто потому, что плохо спланировались, вы можете запросто слить рекламный бюджет в несколько своих месячных зарплат просто потому, что дорогой лид пришел на страницу, где он не увидел отражения своей потребности. И ушел :)
В крупных проектах сроки могут сколько угодно спускаться сверху, но физику не обманешь и бизнесу лучше узнать горькую правду о том, что в эти сроки можно сделать только 1/3 требуемого до того, как он подпишет контракт с серьезными неустойками за срыв сроков)
green_hippo
27.03.2019 15:12Автор говорит совсем другое — сроки должны оценивать не специалисты, которые своими руками будут делать работу, а какой-то «менеджер» на белом коне, который, даже будучи в прошлом техническим специалистом, конкретных деталей реализации и многотонных подводных камней [уже] не знает.
И главная претензия к автору в том, что он как руководитель целого, по сути, направления, хочет полностью снять ответственность за сроки поставки с команды, лишив ее, пожалуй, самого главного мотивирующего фактора — commitment'а, личной ответственности и участия в жизни продукта.Я прочитал статью несколько раз, но категорически не вижу, где Wolonter утверждает хоть что-то из цитаты. Александр, как же так? :)
Codenamed
27.03.2019 15:18Так вот же, Игорь! :)
Если команда выполняет эти упражнения, а менеджер квалифицирован, то для ответа заказчикам ему не нужно требовать от исполнителей назвать срок.
green_hippo
27.03.2019 15:26Мне очень неудобно такое говорить, но сразу после этой фразы в статье идут три абзаца, которые расставляют точки над ijk.
Codenamed
27.03.2019 16:52В следующих трех абзацах абсолютно искусственно противопоставляются вещи, которые для разработчика с точки зрения оценки не отличаются: «я потрачу на эту задачу день» превращается в «эта задача будет готова через день» в тот момент, когда разработчик начинает над ней работать.
Автор ниоткуда вытаскивает мысль, что, якобы, разработчик будет закладывать себе резерв времени если его спросить о конкретном времени завершения (что верно), и не будет, если его просто попросить оценить количество часов, которые ему потребуются с момента старта работы над задачей (что неверно).
Потому что разработчик знает, что команда будет одинаково его порицать за безответственность при любом из способов срыва сроков :)Wolonter Автор
27.03.2019 17:30Автор совсем не такой, как вы описываете… Автор специально привел ссылки на источники в начале, где есть объяснения. В частности перезакладывания.
Кажется, я чем то задел ваши эмоции и этим вызвал кучу толкований меня и достаточно резких высказываний.
Думаю, конструктивно не получится, а жаль.
Codenamed
27.03.2019 20:03+1Автор оправдывает атмосферу расслабленности и вялости, и пропагандирует подход, не раз лишавший активных разработчиков мотивации у меня на глазах. А я очень страдаю, когда такое вижу :)
Возможно, именно из-за такого подхода Контур за последние 5+ лет не выпустил ни одного заметного нового продукта при таком безумном количестве разработчиков (и 150(!) тестировщиках) ;(Wolonter Автор
27.03.2019 20:19+2Автор оправдывает атмосферу расслабленности и вялости
А я видел, как демотивирует и замедляет разработку ваш подход и тоже страдаю, когда вижу спринтеров с горящими жопамии, не умеющими играть дольше, чем в год.
Александр, наш спор на уровне мировоззрений и ни к чему не приведет. Аргументы вида «вот оно так потому что вы демотивируете!»
Вы будете оценивать сроки и считать свои команды крутыми и успешными. Я оценивать сроки не буду и тоже буду считать свои команды крутыми и успешными. Чистый эксперимент поставить не получится. Зрители повеселятся.
А контур, конечно да, ничего не создал и ничего не запустил и вообще на ладан дышит. Скорее всего из-за такого подхода. Всё плохо.
julie
27.03.2019 22:59+4Ребята у вас обоих сильные аргументы! Спасибо за интересную дискуссию, мне в разные периоды жизни нравятся перегибы в разные стороны)) И для компаний/подразделений бывает подходят режимы «завод с налаженными процесами» или «драйв когда все бегут — разработчики пишут код как ошпаренные»)))
Codenamed
28.03.2019 14:56-1Аааа! Только сейчас увидел.
Когда у ваших разработчиков во время спринта горят жопы, значит вы что-то совсем не то с ними делаете!
У разработчиков в состоянии драйва должны гореть глаза! Глаза!
Eugene-k
28.03.2019 15:11А контур, конечно да, ничего не создал и ничего не запустил
Уже лет 5 ждем API для Контур.Бухгалтерии — теперь понятно почему
VolCh
28.03.2019 08:04+1Ну вот у нас сейчас требуют оценку трудозатрат по разработке. Никаких порицаний на тему сроков или неверных оценок нет (они если есть, то на тему общей производительности). Менеджмент сам составляет календарные планы, в том числе планы взаимодействия R&D подразделения с другими (обучение поддержки прежде всего — у нас без неё никуда, анонсы для клиентов и т. п.)
Wolonter Автор
27.03.2019 17:26+2"Без оценки сроков бизнес просто умрет."
Что же вы пишете про все бизнесы сразу? Жил, живет и будет жить бизнес и без оценки сроков. И речь не только про контур.
Дальше вы делаете ряд заявлений и претензий, отвечая на которые я буду доказывать, что я не верблюд.
Ответственность с разработки я снимать не предлагаю. Предлагаю перестать обманывать. Себя в первую очередь.
Wolonter Автор
27.03.2019 11:07А вы прочитали статью или только заголовок? Может как-то более предметно и аргументированно пообщаемся?
Codenamed
27.03.2019 14:38Максим, я прочитал статью и не на один раз. И мы можем предметно и аргументированно пообщаться, хотя я и очень зол на вас за такое отношение к мотивации команд в моем все еще любимом Контуре :)
Если суммировать:
1. Противопоставление сроков поставки и оценки сложности задач в часах — абсолютно искусственное именно в продуктовой разработке. Это изоморфные вещи. В заказной разработке человекочасы переводятся еще и в деньги, но в вашем случае это чистая манипуляция. Вместо того, чтобы спросить: «Ты же обещал к четвергу, а сегодня пятница. Где?!» — владелец продукта спросит: «Ты же обещал сделать за 9.5 календарных часов и начал позавчера. Где?!».
2. Завышение оценок специалистами. Такая проблема есть, но решается она не отказом от оценки, а методами коллективной оценки, когда завышенная оценка не проходит дизайн-ревью, и ежедневных летучек, которые в нормально мотивированной команде не дают зря проедать временной бюджет.
3. Негативное влияние оценки на производительность. Если я правильно помню, ДеМарко писал об этом в контексте травли команд. Правильная оценка задач, как вы и сами пишете ниже, позволяет достаточно детализировать задачу, привлечь коллективное знание всей команды, чтобы не допустить большей части возможных дорогостоящих ошибок, которые один человек допустил бы, не допустить чрезмерного раздувания оценки — и получить достаточно надежные оценки, чтобы с высокой точностью планировать выпуски.
4. Самое главное. Предлагаемый вами подход убивает мотивацию сотрудников, потому что убивает вовлеченность в жизнь своего продукта и в принятие решений. Чувство сопричастности судьбе своего продукта и чувство личной ответственности за качество и за собственноручную оценку сроков — важнейшие мотиваторы разработчиков. Когда работа разработчика превращается в смену у конвеера с тасками, а сверху на него валятся взятые с потолка кем-то сроки, даже самая мотивированная команда необратимо превращается в болото. Что вы, к сожалению, вероятно, нередко видите вокруг :)Wolonter Автор
27.03.2019 17:36Еще и еще раз. Я говорю о том, что нужно спрашивать не срок, а упражнения из списка. Они полезны. Срок ложь.
По поводу мотивации, убитой сроками оценки — и опять не так. В моей и не только команде с мотивацией все ок. И она не зависит от коммита в дату. Зачем вы безапелляционно обобщаете? Прямо как я в заголовке. А еще я знаю команды, демотивированные необходимостью играть в сроки.
И да. Контур я тоже люблю.Codenamed
27.03.2019 19:33+1Ну вот я полтора года напряженной работы выдавал вместе с командой (а без команды и не смог бы) точные сроки на периоды от двухнедельной итерации до полугодового релиз-плана. И выдавал обоснованно и точно. А вы мне (и всем присутствующим) объясняете, что сроки — ложь :)
А откуда бизнесу брать реальные оценки сроков вы и вовсе тактично умалчиваете.
На практике из-за такого отношения к срокам почти десять лет может потребоваться, чтобы убрать баклажанный цвет с одной единственной страницы, если вы понимаете, о чем я ;(
Calc
28.03.2019 14:22+1«Ты же обещал сделать за 9.5 календарных часов и начал позавчера. Где?!».
вот я тоже в статье увидел эту манипуляцию, хотелось бы услышать от вас ответ, нам показалось или вы неправильно выразились?
Вы описываете оценки, но не описываете понятие как трафик. Грамотный ПМ спокойно клиенту объяснит что такое трафик и куда идет дедлайн (хотелки клиента).
VolCh
28.03.2019 08:30+1Манипуляцию (классическую для менеджмента в ИТ) я вижу в ваших вопросах. «Ты же обещал сделать за 9.5 часов и начал позавчера. Где?!» — это манипуляция, если я не обещал, а дал оценку своих трудозатрат. Вот из-за таких манипуляций и возникают завышения.
Давать оценки — профессиональный навык разработчика, а воспринимать их как обещания и порицать за неисполнение — неадекватность менеджмента. Оно может и работает на коротких дистанциях, когда разработчики, чтобы выполнить обещание добровольно и бесплатно перерабатывают, но при длительной работе или будете получать неадекватно завышенные сроки (разработчики будут закладывать в них риски, хотя риск-менеджменту их обычно не обучают, поэтому закладывание будет неадекватным), или людибудут демотивированы в ноль или даже минус.
Работа менеджера — взять оценку и заложив в неё риски ошибок оценщика («статистика показывает, что этот разработчик в 50% случаев работает над задачей на 90% времени больше, чем давал оценку — закладываем 45%») выдать наверх сроки (если сверху этого требуют).
Работа разработчика, тестировщика и т. п. — давать оценки (кроме всего прочего, конечно). Менеджмент должен поощрять точность оценок, мотивируя прокачку этого навыка, но именно точность, а не непревышение. «Ты дал неадекватно низкую оценку», а не «ты неадекватно превысил оценку». Плохой оценщик, а не плохой выполнятель обещаний.
Исключение навскидку — скрамообразные процессы, где выделенная роль менеджера отсутствует, и по сути вся команда выступает коллективным менеджером самой себя и даёт обязательства владельцу продукта за срок спринта выдать некоторый скоуп фич/багфиксов.Codenamed
28.03.2019 09:07-3Это не манипуляция, а экономика:
Клиент завязался на обязательства Компании поставить фичу в срок, Компания завязалась на обязательство Разработчика выпустить эту фичу в срок. Разработчик не выдержал сроки, Клиент потерял деньги, Компания потеряла Клиента, Разработчик потерял работу.
Не надо считать разработчиков единороговыми понями в вакууме, их работа и их косяки имеют реальный экономический эффект, который прилетает к ним бумерангом так или иначе.
Проблема завышения сроков при этом действительно существует, и работа менеджера и руководства — найти такой баланс пряника и кнута, при котором система устойчиво работает.
Одним из лучших решений для создания такого непростого баланса как раз являются «скрамообразные процессы», которые позволяют и контролировать сроки, и не скатываться в завышение оценок, и сохранять хороший моральный климат.VolCh
28.03.2019 11:55+1Не предполагается по сути работы разработчика давать обязательства что-то выпустить в срок. Я бы даже сказал по сути почти любой работы. Экономический эффект, конечно, есть. Но разработчик работает по трудовому договору суть которого «ты работаешь, а мы платим деньги за отработанные часы, риски того, что что-то пойдёт не так мы берём на себя и прибыль от твоей работы тоже себе забираем». Если работа предполагает обязательства «я сделаю фичу не позже чем за две недели», то и оплата должна быть за фичу, а не за часы.
Codenamed
28.03.2019 12:12Умение оценивать сроки и укладываться в них — крайне востребованный навык на рынке труда.
JustDont
28.03.2019 13:08+5Умение за еду выдавать код, продающийся на миллиарды — тоже крайне востребованный навык. Вот только есть маленькая проблемка… ;)
Реальность, данная нам в ощущениях, пока что в среднем такова, что если перекладывание ответственности на разработчика происходит (как правило в той самой форме «ты обещал, но не сделал», оценки рассматриваются как базис для дедлайнов) — то происходит оно абсолютно бесплатно для разработчика. Если какой-нибудь скрам или подобное начинает существенно добавлять задач на управление в жизнь разработчиков — это тоже происходит бесплатно для разработчиков. Вообще, в среднем рвение превратить разработчиков в псевдо-партнёров (когда они за продукт типа должны душой болеть, но получать при этом всё равно только зарплату за время) — встречается довольно часто. Угадайте, почему многим разработчикам такое рвение не нравится.
VolCh
28.03.2019 13:12+2В 90% интересных мне вакансий не упоминается, а в 10% остальных предлагаются те же деньги, что и без него, а то и меньше. Это больше похоже на хотелку «на халяву», а не на востребованность. Или у вас есть другие сведения? На какую прибавку к рынку в процентах можно рассчитывать, обладая этими навыками? Особенно вторым. 100%, 200%? Хотя бы 50?
Codenamed
28.03.2019 14:35Думаю, с таким скиллом вы можете рассчитывать на +20% к рынку и/или действительно интересные задачи и драйв на работе. Но увы, компаний, которые умеют нанимать таких разработчиков и грамотно управлять ими и вправду, похоже, очень немного. Зато работа там — это будет experience of a lifetime.
VolCh
28.03.2019 16:04Действительно интересные задачи — частично исследовательские, ну или хотя бы знакомые чисто в теории. Если уже делал на практике, то что интересного? А если не делал, то как вообще можешь дать достоверную оценку? Или дают исследовательские задачи вместо премии за точные оценки?
Codenamed
28.03.2019 16:10-1Кажется, вы относитесь к числу тех разработчиков, которым интересны задачи, но безразличны продукт и пользователи. Для вас рецепта счастья и у меня, к сожалению, нет.
mamokino
29.03.2019 13:22Думаю, с таким скиллом вы можете рассчитывать на +20% к рынку и/или действительно интересные задачи и драйв на работе. Но увы, компаний, которые умеют нанимать таких разработчиков и грамотно управлять ими и вправду, похоже, очень немного. Зато работа там — это будет experience of a lifetime.
С таким скиллом, войдя в число основателей компании, вы можете рассчитывать на много большее.
Как рядовому разработчику — ни на что рассчитывать сверх тут не приходится.
Другое дело, что более точные оценки дает/лучше разруливает ситуации по ошибкам оценок более квалифицированный разработчик. Который и получает больше.
Но платят ему +20% не столько и не только за скилл «точных оценок», а за всю совокупность профессиональных навыков.
24twelve
27.03.2019 11:12+2Тщательного осознания задачи, ее декомпозиции при необходимости и описания будущего решения (плана тестирования) в тикете.
Вот это ценный кусок работы над задачей. Можно его и требовать. Даже без сроков, уже поможет задачке быстрее и качественнее зарелизиться.Codenamed
27.03.2019 14:58Человеческий мозг разумно ленив. И требование дать оценку в часах — один из трюков, чтобы заставить его поверить, что все серьезно и надо поработать над решением, а не дать формальную отписку.
24twelve
27.03.2019 15:15+1Манипуляции это неприятно и бесит.
Мой опыт: обычно попросить с человека план работ и поревьюить его, задать вопросы.Codenamed
27.03.2019 15:22Это из тех манипуляций, которые люди добровольно на себе практикуют :)
Ваш вариант, на самом деле, эквивалентен, потому что при наличии такого плана работ и дать оценку сроков — уже не проблема.24twelve
27.03.2019 15:42Вполне себе проблема. Учесть непредвиденное, заложитб запас в оценке… ну а далее Максим в статье написал, к чему это приводит.
Codenamed
27.03.2019 17:06-2Максим написал, к чему это приводит, если не управлять процессом оценки.
И не написал, что бывает, когда бизнес заложился на оценку взятую менеджером с потолка, а не от специалистов, которые глубоко в теме и хорошо подумали.
И еще Максим не написал, что бывает, когда эта «спотолочная» оценка спускается менеджером самим разработчикам, а они вполне обоснованно относятся к ней и к этому менеджеру по принципу «ты ковбой, ты и прыгай».24twelve
27.03.2019 17:40Так все же логично. Сроки по отдельным задачам не нужно оценивать ни исполнителям, ни менеджеру :)
Про задачи с дедлайнами мне близка эта мысль из статьи:
Если в очередь попала срочная задача, надо всё бросить и делать её. Оценивать не нужно. Впрочем, будет полезно уточнить дедлайн, чтобы понять, с какими дефектами и недоработками можно будет выпустить. Таких срочных задач — меньше десяти процентов.
Тоже никаких оценок.Codenamed
27.03.2019 19:35А как вы ответите на вопрос «сколько осталось до релиза вот этой фичи?»
24twelve
27.03.2019 22:47+3Для задачи с дедлайнами обычно отвечаем, что зарелизим в срок, но с кучей трейдоффов.
Для несрочной — зачем отвечать? :)Codenamed
28.03.2019 08:10Ну тогда я попрошу список трейд-оффов, которые вы сможете порешать до конца этой недели, а какие решите в течение следующей :)
Тут надо понимать, что либо вы работаете в динамично развивающемся продукте, где каждая новая возможность — это счастье или уход пользователей и часто целые новые пласты клиентов, ресурсов не хватает, а впереди маячит вкусный приз, либо в проекте, где ничего от релиза вашей фичи не поменяется, по большому счету, и срок ее релиза вообще не имеет значения.
Во втором случае заморачиваться вопросами сроков и эффективности нет никакого смысла. А в первом случае в работе не бывает задач без дедлайнов :)24twelve
28.03.2019 08:35-3Во-первых, вы хамите. Зачем?
Во-вторых.
Я почти не работал в мире, где все задачи с дедлайнами. Вы мне расскажите, как там?
На берегу, мне кажется что ставить дедлайны по всем задачам — это самообман. Все равно команда разработки не сможет сделать больше Х задачек в месяц. Еще придется устраивать адски сложные планирования в стиле «надо приоритизировать и оценить сроки для 40 входящих задач, а также посмотреть на 30 задачек, что сейчас в разработке». Вы в другой ветке писали, что на планирование уходило по 2 дня из 10 (=двухнедельный спринт). Я пока не увидел плюсов у таких гигантских трудозатрат.
Еще интересно, были ли в вашем мире овертаймы у команды разработки. Если да, то как часто и как плохо?Codenamed
28.03.2019 09:27Я прошу прощения, конечно, но при тщательном перечитывании комментария не увидел ровно никакого хамства.
Живущие в мире дедлайнов разработчики получают именно то, за чем пришли в профессию: они видят, как на глазах развивается продукт, как клиенты начинают использовать новые возможности, принимают непосредственное участие в определении судьбы продукта и живут в состоянии драйва.
По поводу гигантских трудозатрат на планирование. Во время планирования находятся и описываются решения всех попавших в планирование задач. В оставшиеся дни итерации остается только написать код, потому что все решения уже приняты и почти все головоломки решены.
Оверхед возникает из-за того, что оценивание задач обязательно проводится коллективно.
Во-первых, в достаточно большом проекте не все одинаково владеют всеми кусками кода, и более компетентные в какой-то части функциональности разработчики помогают сразу принимать правильные решения.
Во-вторых, коллективная оценка не позволяет скатиться в завышение и, что не менее важно, в занижение оценки задачи.
С овертаймами — тут уж у кого как. Если команда адекватная и не позволяет занижать оценку, кранчи бывают редко и, как правило, компенсируются периодом расслабленности после очередного релиза.
WebMonet
27.03.2019 11:14+2В одной компании был я единственным разработчиком, а вокруг меня была куча менеджеров/руководителей.
Так вот, в вопросе оценке сроков я понял, что менеджерам моя оценка нужна только для отчета перед руководством и для прикрытия своей ж… в случае срыва-переноса сроков. В большинстве случаев получалось что-то типа «ты сказал, ты и делай».
В моем понимании сроки должно определять руководство (вот к этому дню нам нужен вот такой функционал), а менеджеры должны обеспечить все необходимое для реализации функционала разработчиками.
ssurrokk
27.03.2019 11:39абсолютно верно, есть такие менеджеры которым вообще пофигу что за задача, насколько сложная, что и как, вот ты дай мне срок и всё, и отвечать тоже ты за него будешь. А я получается только озвучу его руководству. Замечательно, блин. Ладно бы такой менеджер хоть как то пытался помочь, вникнуть в проблемы, так нет же! Так и хочется ответить таким манагерам — пошли вы в Ж...!
alatushkin
27.03.2019 19:25+2Вы так категорично рассуждаете о единственно верном подходе для абсолютно любых ситуаций, скажите, Судья Дред не ваш родственник?
Codenamed
28.03.2019 09:46-1Как вы узнали?! :)
А если серьезно, то я написал про конкретную ситуацию в Контуре, где много сотен разработчиков, которые могли бы сделать десятки продуктов. Причем, я знаю, очень качественных продуктов.
И эти сотни разработчиков делали бы крутые штуки в состоянии драйва. Причем у Контура есть такой опыт.
А тут менеджер всех тестировщиков, по сути, призывает сидеть в теплом липком болотце безрезультатного комфорта :)Wolonter Автор
28.03.2019 09:57Хамите, Александр, нехорошо.
Наверное хорошо, что теперь эти сотни разработчиков вместе с тестировщиками делают крутые штуки с драйвом, но без вас.Codenamed
28.03.2019 10:07Я бы сказал, что достаточно резко выражаюсь, но хамством это не назвал бы.
И буду очень признателен, Максим, если вы покажете мне эти крутые штуки на kontur.ru. А то вдруг я просто не ЦА и пропустил какие-то анонсы :)Wolonter Автор
28.03.2019 10:18Маркет начался после вас. Ритейл начался до, но зажег уже после вашего ухода.
Команды офигенные, работают бодро. Спорить о степени крутости и обсуждать мощь продуктов я не буду.
Кстати, чем похвастаете вы?Codenamed
28.03.2019 11:13А сколько процентов разработчиков и тестировщиков Контура работают в этих двух продуктах? :)
Я могу только очень скромно похвастаться трехкратным ростом за прошлый год моего маленького продута с десятками клиентов. Но я и делал его на свои, у меня нет 12-14 миллиардов рублей выручки в год =)
Codenamed
28.03.2019 14:42Кстати, о хамстве. Если вы внимательно перечитаете все мои комментарии, вы увидите, что я нигде не касаюсь ваших личных качеств. Только того, что вы написали и должности, от имени которой вы это сделали.
А обижаться на то, что комментарии по этому поводу жесткие, с вашей стороны странно, ведь вы в своем тексте в агрессивной форме обесцениваете лично мои профессиональные достижения и достижения еще многих и многих людей, что неприятно :)
alatushkin
30.03.2019 22:02А тут менеджер всех тестировщиков, по сути, призывает сидеть в теплом липком болотце безрезультатного комфорта :)
Если вы так для себя поняли написанное в статье и это стало триггером для таких категоричных суждений, то, возможно, вам будет интересно узнать, что я в статье такого не увидел :)
Я в статье увидел некие мысли по поводу «вредности оценок сроков» и того, как они обустроили процесс по-другому в своей части общей работы. С «чем-то» я согласен, с «чем-то» — нет, «что-то» «работает» только по стечению конкретных обстоятельств, «что-то» вообще не влияет на итоговый результат. Но призыва сидеть в болтце — не увидел.
P.S. Со временем и Судья Дред и Виталик Бутерин кое-что всё же поняли :)
Codenamed
31.03.2019 14:18— Ты когда-нибудь слышал о смягчающих обстоятельствах?
— Все, что только можно.
Смотрите.
Я бы хотел, чтобы разработчики (и в целом команды) Контура создавали новые крутые проекты. Именно за этим идут в разработку ПО. Это вводная.
Практика доказывает, что крутые проекты могут делать только крайне мотивированные команды голодных разработчиков с горящими глазами, которые безостановочно изучают клиента, пробуют новые гипотезы и не останавливаются, пока не нащупают облик реального продукта. Это идеальная команда по Бруксу и Листеру.
Если в ходе этого поиска сроки решения задач не ограничивать, команда теряет фокус и начинает делать всякую ненужную побочную фигню, и проект заболачивается, а потом и умирает.
Но если команду и ее разработчиков начать подгонять сверху и спускать какие-то сроки, это создаст у разработчиков понимание, что конечный результат от них не зависит, и вместо пылающих глаз мы получим горящие пуканы и, опять же, торможение и гибель проекта. Это один из идеальных сценариев «травли команд» по Бруксу и Листеру. Именно в таких условиях разработчики начинают раздувать сроки и бездельничать, сделав переоцененную задачу — им нужно прикрыть задницу, а не построить вместе с командой крутой продукт.
Тонкая грань максимальной эффективности команды — это режим, в котором команда полностью вовлечена и все участники чувствуют, что результат зависит только от них, берут на себя личную ответственность за результат. При этом темп поддерживается максимально высокий, сроки поставки фич и проверки гипотез остаются управляемыми. Нужно, чтобы команда оценивала сроки работы над задачами, чтобы она по-честному могла взять на себя ответственность за обоснованные сроки поставки.
Таким образом, автор, по сути, призывает к тому, чтобы команды Контура работали расслабленно, без огонька. А значит и без шансов сделать что-то действительно крутое.
В чем и виновен :)Wolonter Автор
31.03.2019 15:01Если в ходе этого поиска сроки решения задач не ограничивать, команда теряет фокус
Только потому, что вы так считаете?
Нужно, чтобы команда оценивала сроки работы над задачами, чтобы она по-честному могла взять на себя ответственность за обоснованные сроки поставки.
Без сроков нельзя брать ответственность?
Mabusius
27.03.2019 12:46+1Случай из моей жизни. Перебрасывают меня на новый проект. Тут же собирается совещание. И самый главный главнюк жестко начинает требовать с меня сроки по выполнению очень важной фичи. Я еще не видел проект, не работал с этим фреймворком и даже от самой фичи знаю только название и общее описание в двух словах. Честно говорю, что не знаю, я вообще только пришел, но начальнику все равно, он
достал свой член и стал им трястинастаивал, чтобы я назвал сроки. В итоге я выпалил рандомные «две недели». Фичу запилил за два дня, остальное время ковырял в носу и читал хабр. Э — эффективный менеджмент.
D_E_S
27.03.2019 13:17Повезло. У меня была аналогичная ситуации только всё с сгущалось тем чтобы я не назвал срок сдачи уже установили и некого не волновало, что мне может понадобится больше времени.
alatushkin
27.03.2019 19:28Да уж. Офисный мачизм, как он есть.
Почему все же решил остаться?
Mabusius
28.03.2019 14:27Так я и не остался :). Ушел я правда не из-за этого, а из-за того, что трактор прогрелся. Главный главнюк мне был даже не начальник, просто он был поставлен главным над всей затеей. Поэтому я особо из-за того случая не переживал, просто среди офисного планктона такое откровенно самцовое поведение встретил впервые.
D_E_S
27.03.2019 13:22Приходит как-то ко мне менеджер и заявляет у тебя 2 дня на реализацию отчёта в это системе. Я как-так 2 дня я даже систему не знаю и что должно быть в отчёте. А он мне ничего не знаю в вашем отделе другой программист в другой системе делал какой-то другой отчёт за 2 дня. А начальство да-да ты что хуже. Так что как не оценивай, что не называй ты в любом случаи не прав и крайней. Но это зависит от адекватности компании ;-)
VolCh
28.03.2019 08:37Крайность она разная бывает, одно дело если тебя назначили крайним за срыв сроков особо тебя не спрашивая, а совсем другое — если ты сам себя назначил, сам себя сделал ответственным за срыв. и особо не важно «я плохой — медленно решал задачу» или «я плохой — согласился или даже сам озвучил нереальный срок».
eefadeev
27.03.2019 13:29Не очень понял бурления в комментариях. Автор совершенно прав (даже если кому-то не нравится).
akhalat
27.03.2019 13:53+2Мелкая задача помечена в YouTrack тегом «на час
делается за один подход (от получаса до двух часов)
Просто прекрасно :)
Nestrik
27.03.2019 16:51а что не так? )
тестирование достаточно непредсказуемо, что бы можно было тестировать результаты недели работы разработчика за пол часа, а одну строчку кода — две недели :)
Автору — спасибо! я бы почитал еще более подробные примеры применения «упражнений» — и возможно даже какой-то опыт не очень успешного применения тех или иных практик: кажется, что к данной статье привел достаточно большой опыт и пул знаний, а не только желание «побомбить» на менеджеров, которые не различают «нужен день» и «через день — готово».
Dimes
27.03.2019 16:56+1ну это же тег а не эстимейт
akhalat
27.03.2019 21:12+1Если по-честному, то я сперва прочитал «от полутора до двух часов» :)
Но и в оригинальном виде некоторая ирония есть, на контрасте с содержанием статьи.
И, да, понятно, что это тег и прочее, но всё равно: в каждой шутке есть дуля шутки.
RenatSh
27.03.2019 16:52#NoEstimates (Allen Holub), предлагает измерять скорость (количество фич за период времени) вместо оценки сроков.
potemkinz
27.03.2019 16:53Чутка анализа статьи, какая-то она не однозначная.
Вот в целом какая цель у оценки? С точки зрения управленца, и это говорится во многих книгах, необходимо понимать когда, примерно, будет выпущена та или иная фича. Для чего? Очевидно, что есть процессы помимо разработки и тестирования и было бы круто выполнять их параллельно. Для этого надо понимать когда будет выполнена та или иная часть работы. Нередко бывает что руководитель говорит — “Надо через три дня, успеешь?”. Тут да, менеджер из него так себе (правда иногда такое бывает и с хорошими менеджерами). В такой ситуации, конечно, появляется чувство, что тебя прижали к стенке.
“Я считаю абсолютно вредной практику, когда исполнитель оценивает сроки на выполнение отдельной задачи.”
Во-первых, получается, что он считает оценку фичи полезной, раз не сказано обратного. Речь только о задачах, как я понял. Это же следует и из названия статьи. Во-вторых, он считает вредной практику оценки задач исполнителем, получается оценка задач менеджером, тимлидом, коллегой с другого проекта или командой уже не вредная, как минимум. А вот если доколупаться до Васи с вопросом сколько он потратит на задачу к которой приступает, это да, это вредно. Можно возразить, что это мои придирки, но все остальное будет просто мнением, основанным на ваших мыслях, которые могут не соответствовать мыслям автора.
“Это напрямую связано с отсутствием системного образования и низкими требованиями к менеджерам.”
Так, погодите, отсутствие системного образования у кого, у менеджера или того, кто будет оценивать? Это важно. Отсутствие системного образования (при чем здесь это вообще?) у менеджера может привести к ожиданию, что задача будет выполнена через Х часов с момента начала работы над ней. А у исполнителя, может создастся ощущение, что есть некий дедлайн и выход за его рамки приведет к ухудшению мнения о нем как о разработчике/тестировщике. Здесь важнее общее понимание оценки обеими сторонами и того, что может произойти при нарушении договоренности. Вторая часть предложения про низкие требования к менеджерам — это вообще о чем? Не, ну правда, не нравится менеджер и его методы, поговори с ним, объясни, что не так. Менеджеры не телепаты, им тоже нужна обратная связь, если он адекватный человек, то будет благодарен за фидбэк. Если не зашло, иди к директору, проси сменить менеджера, в чем проблема?
“К нам приходит человек, ставит задачу и спрашивает, сколько времени может занять ее выполнение. Оценивая задачу, мы, конечно же, хотим назвать тот срок, к которому точно успеем, а так как многое может случиться (и мы подозреваем, что что-то наверняка случится), мы закладываем в оценку некий запас времени.
В итоге любой названный в качестве дедлайна срок становится сроком, раньше которого задача выполнена не будет. К особо неприятным последствиям это приводит при командной работе, когда для выполнения одной задачи или проекта требуется сотрудничество разных специалистов и разных отделов.”
Логично и правдиво, но! Заметили ли вы логическую ошибку? По отдельности я согласен с каждым этим абзацем, а вот вместе нет. В одном речь про оценку, а во втором про срок! Это же разные понятия… Это к вопросу про системность образования. Абзацы вырваны из контекста и совмещены. Будь я чуточку менее внимателен, то проглотил бы это. Это же Макс Дорофеев написал! КЛАССИК! Интересно знает ли он сам про это? Оценка, это “За час, в течении недели”, а срок “Будет через час”.
“В пятой части первой главы есть ссылки на исследования о зависимости производительности от того, кто выполнял оценку сроков.”
Ну давайте почитаем эту часть вместе и добавим цитаты с небольшими комментариями:
“В 1954 году англичанин Сирил Паркинсон выразил мнение, что работа раст?т, заполняя любое отвед?нное под не? время. Сейчас это мнение известно как закон Паркинсона”
“Даже руководители, не знающие вообще ничего о менеджменте, цепляются за эту аксиоматическую истину – закон Паркинсона, руководящую людьми и их отношением к работе. Он да?т им крайнюю убежд?нность в том, что единственный способ добиться выполнения работы – это установить невозможно оптимистические сроки е? сдачи.”
Смотрите ка, опять про сроки, а не про оценку…
Книга, судя по пятой части первой главы, интересная. Что я вынес из прочтения этого отрывка. Во-первых, исследование на которое ссылается автор книги датирована 1985 годом. Скрам и аджаил в целом, а именно они возникают у меня в голове при слове “оценка”, был сформирован в 2000-ых. И подход к оценке был изменен. Можно почитать “Мифический человеко-месяц” (1975), что-то мне подсказывает, что есть на эту тему информация. Оценка в скраме несет приблизительный характер (попугайчики), а размер спринта зависит от среднего объема выполняемого командой за некоторое количество предыдущих спринтов. Кроме того, оценка производится коллективно, а не непосредственно исполнителем.
Продолжим разбор статьи.
“За последний год я дважды слышал от менеджеров: «Мы научились выдерживать сроки по оценкам задач, теперь такой-то программист или тестировщик совсем не нарушает сроки, которые назвал».
Я считаю, это крайне серьезная проблема, так как это означает, что этот программист или тестировщик системно и сознательно завышает сроки, работает на расслабоне и лжет менеджеру.”
И что? Менеджер доволен, у него не срываются другие процессы из-за разработки/тестирования. Программист/тестировщик тоже, у него нет чувства горящей пятой точки. А если возникает ощущение, что оценка завышена, то можно делать это коллективно и брать среднее значение оценки. Ничего нового, просто немного понимания скрама. Если какой-то сотрудник сильно отстает по производительности, то это повод к выяснению причин.
“Упомянутые в заголовке авторы говорят, что единственно верный способ оценки сроков — статистический. Должен оцениваться пакет типовых задач. «У нас все задачи разные»? Это ложь. На промежутке в год будет уже не очень много разных задач. Как правило, такое заявление является признаком отсутствия рефлексии над процессом и не выполнения упражнений: декомпозиция, MVP, прототипы, стандартизация.”
Бррр, да это же опровергает все что было написано автором до этого, нет? Лично у меня этот абзац не вызывает чувства отрицания сам по себе, но автору-то он зачем?
“О заказчиках, которые требуют сроки
Во-первых, надо заметить, что чаще всего — и это само по себе забавно — от ответа исполнителя не зависит ничего, потому что сроки уже есть. Менеджер интересуется не сколько времени мы будем делать задачу, а успеем ли мы к заданному сроку и что именно успеем. Это разные вопросы и отвечать на них нужно по-разному.
Как правило, ответом на вопрос «успеем ли мы к заданному сроку» является аналитика и MVP, качественная инфраструктура разработки и размер технического долга, а именно сложность проведения рефакторинга и наличие автоматических тестов на регрессию.”
Как? Как из этих двух абзацев следует вывод — “Ещё раз: оценка сроков мешает исполнителю успеть к дедлайну.” Я могу что-то с этим придумать, конечно, сделать какие-то домыслы, но это не то, что я ожидал от статьи.
Далее приводится список упражнений (среди которых MVP), которые рекомендуются к выполнению для повышения точности сроков и вывод:
“Если упражнения не выполняются, то скорее всего любой названный менеджером срок будет ложью.”
Ну как так-то? Вот представим ситуацию. Приходит заказчик и приносит требования, просит оценить сроки выполнения и бюджет. А мы ему такие: “Так, товарищ, надо запилить MVP и выпустить его канареечными релизами! Если вам нужна более точная оценка оценка, то в этом нам поможет раздельный релиз бэкэнда, фронтенда и прочего… и канарейки. И не забудьте про фича-флаги!”. И как нам это поможет?
“О некомпетентных менеджерах
Очень легко перепутать оценку сроков (когда задача будет сделана) и оценку трудозатрат (сколько нужно времени, чтобы разработать фичу). Оценка сроков, как мы уже разобрались, если не вредна, то по крайней мере бессмысленна. А вот оценка трудозатрат — довольно полезное упражнение.”
Зачем? Ну что кому даст оценка трудозатрат сама по себе? Разумеется она нужна, но, только в контексте оценки сроков. И эти две оценки очень тесно связаны. Просто надо добавить еще один параметр — количество выполняемого труда командой проекта. И тогда все встает на свои места. Оценили трудозатраты, знаем производительность команды, следовательно, можем получить оценку сроков. Если что-то меняется в требованиях, то происходит изменение оценки.
“Пример из жизни:
— Сколько времени ты потратишь на эту фичу?
— Полторы недели буду писать и дня три фиксить баги.
— То есть через 3-4 недели будет готово?”
А где продолжение? Ну ответил — “да” и сделал, у него же не лапки. Или ответил — “У меня сейчас большая загруженность. Давай посмотрим бэклог и подумаем над приоритетом этой фичи (посмотрели — вставили в бэклог — сделали)”. Где интрига-то?
“P.S. Один из наиболее важных навыков в нашей работе — не делать ненужной херни. В том числе не заниматься «оценкой сроков» и самообманом. Чего и вам желаю.”
Про самообман хорошо сказал…
Lexicon
27.03.2019 17:25+1В планировании времени исполнителем мне нравится одна вещь — осознание ответственности.
В планировании времени исполнителем мне не нравится другая вещь — исполнителям обычно не платят деньги и не выделяют временной ресурс на рациональное планирование, и несение ответственности.
Codenamed
27.03.2019 20:22При хорошей организации работы мы выделяли на планирование первые 1-2 дня двухнедельной итерации. Это и прекрасно работало, и прекрасно воспринималось, потому что любому, пришедшему на такое планирование, было очевидно, что это крайне напряженный рабочий процесс.
triton
27.03.2019 18:11+1это означает, что этот программист или тестировщик системно и сознательно завышает сроки, работает на расслабоне и лжет менеджеру
Нет, совсем не так!
На каких-то задачах он может и расслабиться, зато если не учел в своих расчетах какую-то трудоемкую часть, то будет напрягаться и работать напряженне обычно, да еще и будет задерживаться на работе чтобы не выйти из сроков.
Часто наблюдал как неопытные коллеги (да и сам поначалу) ошибались в сроках в меньшую сторону и пытались самоотверженно это исправить ударным и сверхурочным трудом. Итоговый результат, обычно получался не очень хорошим: или код был написан без нормальной проработки «на костылях» или сам сотрудник уставал от такого режима…
Требование оценки сроков выполнения от бизнеса вполне понятные, и если такие требования есть, то они автоматически подразумевают, что опытные разработчики будут закладывать в эти сроки запас времени. Так же понятно, что если есть сроки, то, как правило, выполнение задачи займет все заявленные сроки. Это должно быть понятно и менеджерам и бизнесу, чудес не бывает и никакого вранья здесь — нет. Бизнес может сформировать избыточную команду разработчиков и иметь гарантированные (ну, почти) сроки выполнения и неплохую прогнозируемость по срокам.
Другое дело, если команда разработчиков небольшая и важно иметь высокую эффективность работы, в этом случае, если руководство доверяет тимлиду, то команда может работать без оценки сроков в своей нормальной производительности. Т.е. есть определенный объем работ и есть команда разработчиков, которые эту работу последовательно выполняют.
За то чтобы все работали в нормальном режиме следит сам тимлид, он может примерно оценить сроки выполнения задачи каждым разработчиком, да и авторитет у него должен быть, чтобы сами разработчики не пытались отлынивать. В этом режиме задачи будут выполнены в минимальные сроки (без перенапряжения команды), если попадется сложная задача, то или будет попытка ее упростить (по согласованию с заказчиком) или на нее будет потрачено все необходимое время. Тимлид также следит, за качеством кода и за тем чтобы кто-то не занялся оверинжинирингом.
vlsinitsyn
27.03.2019 21:34+4Меня, как программиста, такая постановка вопроса, когда нужно выдать сроки и подпись поставить, давно не смущает. Если менеджер туп, то что поделать. Я вбиваю такой срок, на котором мне будет спокойно — хорошее такое резервирование, многократное ;-). А если появится свободное время, его всегда можно с пользой и интересно потратить на вылизывание кода. Качество результата от этого только повышается.
Если начальник свой человек и понимает, что программирование — не укладка кирпичей, а скорее, бурение, то да, при доверительных отношениях все делается очень быстро и эффективно. Но это только в случае, если есть доверительные отношение и я могу рассчитывать на понимание именно как специалиста. Потому что дело здесь даже не в прикрытии жопы, а в том, что есть разница между «затянул по дурости или неопытности» и «наткнулся на реальную проблему, потратил время, но решил». Если начальник не в состоянии оценить разницу, мне работать с ним доверительно будет трудно.
kreo_OL
28.03.2019 03:32+1Вы вот все серьёзно?
То есть тут многие не понимают почему "делать день, но готово будет через месяц?".
"эффективный менеджер" из комментариев выше даже не смог отличить трудозатраты от сроков.
Вот поэтому в большинстве компаниях и болото.DrPass
28.03.2019 04:12Чем отличаются трудозатраты от сроков, как раз понятно всем. Совершенно непонятно, зачем одно противопоставлять другому, если эти величины взаимосвязаны, и одна выводится из другой?
mad_nazgul
28.03.2019 07:23Не совсем. Сроки — это дата (точка). Трудозатраты это время (вектор).
Работа обычно состоит из суммы трудозатрат (векторов).
Причем разнонаправленных. И вполне может оказаться, что фича которая делается за пару часов, будет сделана только за месяц.
DrPass
28.03.2019 13:46Что-то вы совсем запутали совершенно простые понятия. Во-первых, трудозатраты — скалярная величина, и никакого направления у неё в принципе нет. Время всегда течёт в одну сторону, и рассматривать как вектор его бессмысленно. Даже отклонения от плана, хотя интуитивно имеют два направления, все равно обычный скаляр.
Во-вторых, трудозатраты и сроки — это два представления одного и того же показателя, временной шкалы проекта. Абсолютное значение на ней, это сроки. Расстояние между значениями (при необходимости помноженное на количество участвующих в задаче людей) — трудозатраты. Только и всего.mad_nazgul
28.03.2019 14:06-1Вот вы только что подтвердили, что трудозатраты это вектор.
Т.к. они имеют направленность (время) и размерность (скаляр) ;-)
Сроки это точка (конкретная дата) их сдвинуть проблематично.
И сроки можно сказать не складываются.
Например фича А будет готова к дате D1, а фича B будет готова готова к дате D2 (D1 < D2).
Т.о. обе фичи будут готовы к D2!
А вот если говорить в трудозатратах, то фича A делается N1 часов, а фича B делается N2 часов.
Когда будет готовы обе фичи (дата)?
Фиг его знает. Но точно не к D(ткущая дата) + N1 + N2.
Тут надо учитывать рабочее время (не более 8 часов), выходные и праздничные дни, разные второстепенные факторы (совещания, болезнь, настроение и прочее).
Поэтому с программистов нужно спрашивать не срок, а время сколько в часах он сделает фичу (трудозатраты).
А дальше идет сложная математика с элементами теории вероятности с выставлением сроков (даты), когда обе фичи будут сделаны.
DrPass
28.03.2019 14:40-1Вот вы только что подтвердили, что трудозатраты это вектор.
Т.к. они имеют направленность (время) и размерность (скаляр) ;-)
По вашей логике, так и температура — вектор, и вес — тоже вектор. Т.к. температура имеет направленность (ползет, зараза, куда-то) и размерность (градусы). И вес, так же как и время, имеет направленность (всё время вниз падает, а если пнуть, то влево полетит), и размерность :)
Время — это скалярная величина, у неё направленность появится только тогда, когда вы изобретёте машину времени или хотя бы сможете находить червоточины в пространственно-временном континууме.
Фиг его знает. Но точно не к D(ткущая дата) + N1 + N2.
Вы не путайте точность планирования и методику планирования. Фичи будут точно готовы к D(ткущая дата) + N1 + N2, при условии, что N1 и N2 — реальные трудозатраты, а проект выполняется, а не лежит на полке.
Если у вас нет реальных трудозатрат, а есть оценочные, то в вашем плане точно так же оценочный срок будет N1 + N2.mad_nazgul
28.03.2019 15:25-1При чем тут температура?!
Насчет веса… Вес имеет смысл только при существовании ускорения.
Т.е. он изменяется в зависимости от. Т.е. вес это сумма векторов ускорения.
N1 и N2 это реальные трудозатраты.
Т.е. если берем программиста стоим над душой за секундомером и мерим сколько времени он затратил на создание фичь.
Считая на «подумать», набора кода и т.д.
Но пока программисты плохо заганяются в потогонную систему.
Поэтому нельзя сложить N1+N2 и получить время когда будут готовы обе фичи.
В лучшем нижнюю границу.
eefadeev
28.03.2019 16:08+1По вашей логике, так и температура — вектор, и вес — тоже вектор
Э-э-э… Вес-то — действительно вектор. Я ещё из школьного курса физики помню что «Вес — это сила, с которой тело действует на опору или подвес». А сила — величина векторная.
VolCh
28.03.2019 16:07+1Трудозатраты и сроки — это не два представления одного и того же показателя. Даже при абсолютно точной оценки трудозатрат сроки могут быть нарушены, например, потому что переключили на другую задачу, или не были выполнены блокирующие задачи, или просто не было электричества/интернета.
DrPass
28.03.2019 16:19Мы же про планирование говорим. Если вы переключаетесь на другую задачу, вы не нарушаете сроки, а меняете их в соответствии с новым планом.
VolCh
28.03.2019 16:26+1Нет нового плана. Составитель плана не знает, что вы переключились на новую задачу. Или знает, но игнорирует это в планах. И сроки утверждены документально и вы за них ответственный, если не сдали задачу, то вы сорвали сроки, причины могут быть уважительные, но факта срыва это не меняет.
DrPass
29.03.2019 10:58Мы о разном говорим. Во временной шкале проекта нет никаких «срывов сроков». Вы рассчитали трудозатраты, вывели сроки. Или наоборот, установили сроки, под них рассчитали трудозатраты. У вас при этом нет никаких там «новых задач», «отключений электроэнергии» и т.д.
А срывы сроков, изменение загрузки исполнителя и т.д. — это всё уже факт, выполнение проекта. При таком форс-мажоре вы вносите изменения в текущий график, пересчитываете его. Или не вносите, если подробное проектное управление вам не нужно. Но это совершенно другой процесс и другие цифры.
kreo_OL
28.03.2019 17:09У вас была очень занимательная беседа ниже)) (или выше^^)
Я возможно тоже не сильно правильно понял посыл статьи, но вот комментарий более менее совпадает с моим виденьем вопроса, и в 80% случаев моя команда сдает спринт\проект вовремя. Оставшиеся 20% это как раз совершенно не типичные задачи, но и тут изза того что сам разработчик не полностью участвует в сроках, мы заранее договариваемся о сдвигание сроков или уменьшение "фич листа".
И вот мои менеджеры этого не понимают, поэтому если менеджерить приходится им, а не мне, то все летит к Летову. В большенстве случаев начинает тратится половина времени только на оценки, согласования и тд и тп.
KoldunOne
28.03.2019 06:59+3Сейчас руковожу отделом тестирования из 150 человек в Контуре
Если не секрет, то сколько в Контуре разработчиков?green_hippo
28.03.2019 12:31+2Привет, я из Контура :) Сейчас у нас примерно 1100 человек в продуктовых командах, из них 700 разработчиков, 150 тестировщиков, 140 системных аналитиков, 40 продуктовых дизайнеров, 20 юзабилистов, 60 менеджеров. У нас примерно 80 продуктовых команд, часто распределённых, и 9 городов с офисами разработки.
Понятно, что разработчики разные: бэкенд на различных платформах (C#, Java, Go, Node.js), фронтенд (TypeScript, JavaScript+Flow), мобилки (Kotlin, Swift, Xamarin), data science (Python, R, Scala). Кажется, что по числу .NET-разработчиков мы продуктовая компания № 1 в России. Если узнаю, что у кого-нибудь больше — сильно удивлюсь :)
Недавно «Мой круг» ещё что-то писал о нас на Хабре. Или я могу что-нибудь рассказать, если интересно.
Newbilius
28.03.2019 07:37+1В отличии от Максима я не знаком со всеми проектами Контура, успел поработать только над 5-6, с большей частью — на стадии MVP (по пол года или меньше). Поэтому прокомментирую исключительно на базе собственного опыта и того, что я слышу, общаясь с коллегами из других проектов.
1) Изменения в немалом числе проектов Контура нередко завязаны на изменения законодательства, читай у нас есть «внешние дедлайны». И оценивать сроки, чтобы понять «начать переделывать вот эту отчётность сейчас или через месяц» необходимо.
2) Сроки мы конечно же оцениваем, регулярно и активно. Но
а) это оценка поверхностная, вида «X дней / недель», мы не тратим на оцени недели, дни или часы
б) оценка каждым специалистом ведёт только в своей области компетенции — разработчик оценивает время разработки, тестер — тестрования и так далее. А вот задача менеджера разработки — свести эти оценки воедино и помочь с планированием деятельности проекта в целом. От остальных оценки сроков всей задачи в Контуре не требуют.
в) оценка нужна для планирования деятельности других людей, чтобы отвечать на вопросы вида «пора начинать рисовать баннеры с рекламой для этой фичи и писать текст в блог?»
г) оценка нужна для расстановки приоритет между задачами (тут задача на 2 дня, тут на 2 недели, такой то разработчик через неделю в отпуск, какую задачу ему дать, а такой то заканчивает такую то задачу когда то)
д) когда задача уже взята в работу — делается поверхностая декомпозиция, и там может быть пересмотр сроков или даже откладывания задачи и взятие в работу другую
3) Типовых задач в работе таки довольно много, и там оценки промахиваются не так уже сильно — и это не «обман и работа на расслабоне», а банальный опыт
4) В чисто исследовательских задачах нет сроков со стороны разработчика — но есть срок вида «сколько максимум мы можем выделить на эту деятельность учитывая такие то факторы». И тут от задачи зависит, разработчик может и до упора это время потратить, и до конца срока справиться, и даже до начала сказать «этого точно не хватит, давайте в исследование чего-нибудь другое возьмём»
5) И просто в отрыве — небольшой момент из практики: каждое утро на летучке отмечать, сколько уже часов потратил на такую то подзадачу такой то задачи. Если «оценка» и «затраты» начались расходиться — то сразу видно, что пора разбираться, может быть разработчику нужна помощь, или там возникли объективные трудности и нам нужно перепланировать другую деятельность. Без предварительной примерной оценки есть шанс «закопаться», и этот момент может пройти не замеченным столь явно. А вот «я тут потратил на задачу 15 часов из 5 запланированных» замечается сразу ;-)
truthfinder
28.03.2019 09:17Я так понимаю ключевой посыл статьи состоит в том, что оценка сроков оценивается из опыта выполнения аналогичных задач.
mad_nazgul
28.03.2019 14:07Основной посыл, что каждый должен заниматься своим делом.
Программисты программировать, менеджеры проектов управлять проектом. :-)
teemour
28.03.2019 09:28+2ну а как вы строите порядок задач чтобы люди друг друга не блокировали? сколько у вас человек? вы что-то создаёте или просто поддерживаете, дописывая фички?
в целом, статья по стилю и содержанию, вредна для брендаgreen_hippo
28.03.2019 12:43+1Привет, я из Контура. Могу о-о-очень кратко рассказать, что знаю сам: у Максима Wolonter в продуктовой команде 30 человек, из них половина — разработчики. Работают по канбаноподобному процессу. Продукту несколько лет, но идёт бурный рост, так что задачи разные.
valis
28.03.2019 11:13+2Сам замечал на сколько увлекательным занятием для меня является декомпозиция задачи и оценка трудозатрат. Это очень полезное упражнение, которое позволяет лучше понять задачу.
И каким нелепым и угнетающим занятием является простановка срока исполнения задачи.mad_nazgul
28.03.2019 14:09Так без декомпозиции задачи, вообще нельзя ничего сказать.
Т.е. когда спрашивают срок на создании фичи и при этом не дают время на «подумать» (оценить задачу/сделать декомпозицию), то получают ответ в стиле «потом, когда-нибудь»
ApeCoder
28.03.2019 11:48+2https://martinfowler.com/bliki/PurposeOfEstimation.html
So whenever you're thinking of asking for an estimate, you should always clarify what decision that estimate is informing. If you can't find one, or the decision isn't very significant, then that's a signal that an estimate is wasteful. When you do find a decision then knowing it focuses the estimate because the decision provides context. It should also clarify the desired precision and accuracy.
Timpo
28.03.2019 13:26+2Я честно говоря не понял, объясните пожалуйста
Почти всю статью автор рассказывает, что оценка сроков не нужна
Затем заявляет «Оценка сроков, если не вредна, то по крайней мере бессмысленна. А вот оценка трудозатрат — довольно полезное упражнение»
Я всю жизнь думал что оценка срока это и есть оценка трудозатрат, то есть сколько тебе нужно времени, чтобы запилить эту фичу?
Я вот вообще в шоке, в чем отличие то принципиальное? Почему одно не нужно, а другое очень полезно?mad_nazgul
28.03.2019 14:11Нет. Срок — это дата. Трудозатраты — часы.
Вы можете установить любой срок и при этом с вероятностью стремящейся к еденице можете быть уверены что к этому сроку фича не будет сделана.
С трудозатратами наоборот, есть не нулевая вероятность, что фича будет сделана за меньшее время.Calc
28.03.2019 16:15Ну так сроки и ставятся на основании трудозатрат, точнее берется трафик, берутся трудозатраты, берется текучка и вычисляется срок. MIcrosoft project и подобные ПО умеют делать всё это. Тот же гант нормально используется.
VolCh
28.03.2019 16:14+1«Сделаю через месяц» и «это займёт 168 часов работы» — разные вещи, равные только в каких-то идеальных условиях. Даже без форс-мажоров, без переключения на другие задачи, без совещаний, без составления отчётов бывают месяцы с разным количеством дней, с разным количеством выходных и праздников. Скажете «сделаю через месяц», имея в виду 168 часов, 1 февраля вечером и от вас будут ждать готового результата утром 1 марта (в лучшем случае), а рабочих часов у вас будет только 152, например. 16 часов где хотите там и ищите.
Codenamed
28.03.2019 16:24Это как раз просто лечится. Задача с оценкой больше 8 календарных часов (одного рабочего дня) — это исключение, которое должно быть обосновано.
Если задача получается больше 1 рабочего дня, почти всегда она может и должна быть декомпозирована, оценена на уровне подзадач и, очень часто, еще и распараллелена.VolCh
28.03.2019 16:27+1А это суммарная оценка подзадач, каждая из которых не имеет смысла. Общая трудоемкость фичи 168 часов (21 задача по 8 часов). Увидели сумму и назвали срок.
Codenamed
28.03.2019 16:33Нет. Набрали задач в итерацию, оставив оговоренный запас для непредвиденных задач (багов) и на случай ошибок в оценках. И уже тогда огласили какие-то сроки.
Оценка каждой задачи — необходимый источник данных, чтобы назвать конечный срок, но никто в здравом уме не суммирует их механически. И команда никогда не подпишется под такой оценкой. И автор поста тоже пишет, что так делают только неадекватные менеджеры.VolCh
28.03.2019 18:07Команду и не спросят про сроки. Она сама уже дала оценки.
Codenamed
28.03.2019 18:19Опять нет. Команда сама называет сроки — такие, под которыми готова подписаться. И в таком режиме она максимально ответственна и мотивирована.
Разумеется, при этом команда может обосновать эти сроки заказчику, либо уже заслужила его доверие.
Если заказчик так работать не может, то все скатывается к сценариям, описанным автором поста, с соответствующим отношением к неадекватному заказчику.VolCh
28.03.2019 20:09Выглядит как перекладывание обязанностей менеджера на команду. Ну или как какое-то подобие скрама, вывернутое по одному из измерений (вместо скоупа работ в фиксированный спринт команда выбирает «размер спринта» для фиксированного скоупа).
Codenamed
28.03.2019 20:42Вы все правильно понимаете, это скрам и есть.
Спринт обычный, фиксированный. Сроки оцениваются не для спринта, а для фич, которые бывают разными и могут делаться в несколько спринтов или просто уезжать вперед из-за нехватки времени в текущем или следующем.
То, что команда сама выполняет функции менеджера — дает огромный буст к мотивации и чувство драйва. То есть, счастливы и заказчики, и команда. Именно это невозможно при подходе, описанном автором оригинального поста.
eefadeev
29.03.2019 17:21+1Скажу больше: «это займёт Х часов работы» — тоже оценка приблизительная. Потому что в одном случае (человек сидит и Х часов занимается только этой задачей) это действительно займёт Х часов, а в другом (когда ему приходится N раз переключаться на другие задачи) это может занять произвольное количество часов, вплоть до бесконечности. Поэтому любые оценки адекватно работают только для очень коротких временных интервалов (именно отсюда стремление к коротким спринтам в agile). Но тут есть небольшой обман — управляемость улучшается, а результативность — вовсе не обязательно.
evgenpm
28.03.2019 16:21+1Раз идет речь о мотивации и сроках, есть опыт одной дизайн студии.Как мы понимаем это на 20%творчество и 80% «отрисовки» (в данной ситуации 3D моделей), что очень похоже на разработку новых продуктов в IT. Сотрудникам давали конкретные сроки на выполнение задачи и очень жестко спрашивали с них.Но порядок выполнения был 2-3 недели, а не часы или дни.Сроки брались из опыта работы студии.
Основная фишка была очень банальна, но давала высокий результат.Сотрудники могли выполнять работу когда им вздумается и никто в течении этого времени у них ничего не спрашивал и не требовал предварительный результат.Члены команды приходили иногда в воскресенье после обеда на работу, кто любил поспать мог работать с 13-14 и сидел до поздней ночи просто потому что ему так было лучше, а иногда и вообще не приходил так как вчера перебрал в пабе))Результат всегда был отличный и очень креативный. Если же дедлайн был близок, то никто не поливал грязью начальство, так как оно всегда виновато по определению, а просто пахал круглые сутки и был счастлив.
Погорив по душам с некоторыми этими сотрудниками я для себя определил так:
— людям нравиться когда им доверяют и считают их профессионалами.
— всем нравиться самостоятельность ( хотя она мнимая, но все же...). Ты вроде как сам себе начальник.
— возможность решать личные вопросы и не быть привязанным к рабочему времени.
Думаю некоторые из этих практик можно применять и в разработке, хотя и с большой осторожностью. Но там где нужен креатив, а не конвейер по-другому очень сложно. Особенно долгосрочно.
polarnik
30.03.2019 00:45Как правило, ответом на вопрос «успеем ли мы к заданному сроку» является аналитика и MVP, качественная инфраструктура разработки и размер технического долга, а именно сложность проведения рефакторинга и наличие автоматических тестов на регрессию.
Сколько тысяч автоматических тестов на поддержке сейчас? И сколько человек из 150 заняты этой задачей? Мигают ли они, сколько там технического долга?
Это вопросы с продолжением. Продолжение в том, что инфраструктура и автотесты не даются бесплатно. Если они работают всегда, без долгов, возможно, кто-то из команды с работы не выходит24twelve
30.03.2019 06:34+1150 тестеров — это всего в Контуре, в разных командах разработки.
Я работаю в команде, про которую в конце статьи пишут. Могу рассказать что-нибудь :)
3000 тестов UI с поднятием приложения, 3000 API тестов с поднятием приложения, 10000 юнит-тестов. В прогоне из-за нестабильностей падает 0-7 тестов.
У нас 6 тестировщиков и регрессия покрыта тестами полностью. Это верно, что мы тратим много сил на это. Но без овертаймов. Если бы не тратили, у нас было бы больше тестеров(16?), потому что ручной регресии было бы очень много. Кажется, в нашей ситуации 6 тестеров и автоматическая регрессия выходят дешевле, чем 16 тестеров и «какие-то» автотесты.polarnik
30.03.2019 10:16Спасибо за ответ. Ощущение, что в статье что-то не рассказано, уменьшилось.
Здорово, что тесты не мигают. Важна история, что тестов много и на их поддержку уходит много времени. Как понимаю, это основная работа, значит команда — команда автоматизаторов. Редкая.
Также важны люди. Фактором успеха может быть конкретная команда из 6-ти человек, которая достаточно квалифицирована, слажена, стабильна, дружна. И в такой команде любой метод работы, особенно тот, где полное доверие и нет микроменеджмента даст просто прекрасный результат.
И если две такие команды встретятся и начнут обсуждать, что важнее в их работе. Одна будет говорить: «У нас нет сроков», — а вторая отвечать: «А у нас есть сроки, и всё просто замечательно». И обе правду говорят :). Значит критерий оценки не самый точный.
Работаю в команде, про которую ещё статей не написано. Команды гибкие. Ближе всего к команде из трёх человек. Мы просто делаем работу, делаем хорошо. Иногда мы обсуждаем сроки и приоритеты. Но это в те моменты, когда работы свалилось по 10+ задач на человека. А когда горизонт планирования 1-2 задачи на человека, а все остальные пока не важны, то обсуждения приоритетов нет.24twelve
30.03.2019 11:53Хочу уточнить, что наша основная работа — это искать баги в задачках всеми доступными средствами и способствовать быстрым релизам.
А автотесты пишем и поддерживаем всей командой разработки (разработчики, аналитики, тестировщики). Потому и обходимся без отдельных автоматизаторов.
Про критерии выбора тоже хочу добавить. Можно выбирать по полезности, эффективности и такому вот. Есть еще один: личный комфорт. Мне очень стремно делать оценки по отдельным задачам:
- Это само по себе сложно, неточно и все время ошибаешься. Ошибаться раздражает.
- Кроме этого, на твои оценки неявно начинают полагаться другие люди. А когда ты в оценки не попадаешь, они ощущают негатив по отношению к тебе. Это портит отношения.
- Даже если за ошибки не ругают, то раздражает, когда при непопадении в оценку какой-то другой человек приходит «разбираться, а что пошло не так». Это тоже психологическое давление, как бы его ни оправдывали :)
И пока я не вижу значимых плюсов оценки сроков по отдельным задачам, мне неясно, зачем впускать вот это все в мою жизнь. Я уже так работал и больше не хочу.
DrPass
Всё это хорошая теория, но она несколько расходится с жизненными потребностями. Оценка сроков нужна не для того, чтобы задолбать программиста и снизить его производительность. Она нужна для того, чтобы планировать бюджеты, чтобы давать ориентиры смежным подразделениям и организациям и т.д. Даже если она не будет точной даже на 50%, это все равно нормально, это просто веха, по которой будет идти проект. И абсолютно нормально, что в процессе работы оно будет уточняться и корректироваться в соответствии с реальностью. И абсолютно нормально, что кто-то её завышает. А другие её наоборот, занижают. Опытный менеджер это сведёт к более-менее реальным срокам. А неопытный, по крайней мере, на этом будет учиться.
Wolonter Автор
Точность в плюс-минус 50% это трехкратная разница, о каком планировании может идти речь?
DrPass
Ну так а куда от этого деться? В любом проекте могут быть такие задачи, по которым большая ошибка с планированием. Суммарно, кстати, они обычно друг друга частично компенсируют, так что итоговая погрешность наоборот, уменьшается. Главное, чтобы при планировании не было систематического занижения или наоборот, завышения.
Wolonter Автор
Мы тоже не шашкой махали, думали, пробовали. Если совсем насмерть сократить мысль статьи, то между «с оценкой сроков» и «без оценки сроков, но вдвое быстрее, чем если бы оценивали» мы — в продуктовой разработке — выбрали второе. Самая важная часть статьи, на мой взгляд, после слов «серия упражнений в разработке».
DrPass
Не знаю, может быть, это особенность именно вашей команды. Я не могу сказать по своему опыту и опыту коллег, что оценка сроков так существенно влияет на производительность, или отнимает много времени сама по себе.
i360u
С увеличением сложности проекта и увеличением роли R&D — адекватность оценки сроков снижается до полной бесполезности. Если проекты типовые — и процесс налажен — оценивать можно.
DrPass
Нередко да. Но без хоть какой оценки сроков и стоимости вам проект все равно никто не профинансирует.
yvm
Это следствие распространенной ментальной ловушки.
vanxant
Да, но что есть то есть. Если вы умеете объяснить заказчику, что у него в голове ментальные ловушки, вам надо в экстрасенсы.
yvm
Успеха добиваются только те кто понял, что разработка это процесс и не надо пытаться купить его, как продукт.
AllexIn
Да, никто не профинансирует. Ну и называются в итоге сроке от балды.
i360u
Вы слишком категоричны. Часто выделяют бюджет на команду а со сроками разбираются на уровне менеджмента. В продуктовой разработке именно этот подход позволяет более-менее адекватно планировать расходы.
DrPass
Да ну, почти во всех таких случаях есть хотя бы предварительная оценка сроков и как следствие стоимости. Как вы можете браться за проект, если у вас нет прогноза, сколько он будет стоить, и сколько денег принесёт? Просто так, «вот вам зарплата, а теперь подумаем, чем бы вас занять», поступают только в очень уж богатых компаниях, которые сидят на денежной трубе из комиссионных доходов за счет облаков или процентов от чужих продаж.
i360u
Большинство стартапов с треском провалилось. И у большинства был красивый график роста доходности и срок окупаемости на старте. Большинство инвесторов, с высшим экономическим образованием и портфелем успешных проектов, понимающе кивало глядя на эти графики. Что это говорит нам о предварительных оценках? Что это говорит нам о окупаемости инвестиций в сами предварительные оценки? Тут хорошо подходит аналогия с предсказанием погоды: на 1-2 дня вы можете предсказать ее достаточно точно. На пару недель — уже врядли. Однако, вы четко знаете, что зимой холодно а летом — тепло. Именно это знание, но уже в конкретной предметной области и требуется менеджеру проекта, о чем и пишет автор статьи. Оно приходит с опытом наблюдений и не зависит от магических ритуалов в виде проставления эстимейтов задачам со стороны разработчиков.
DrPass
Это вообще ничего не говорит. Бизнес — это всегда риск. Те, кто успешен, рисуют такие же графики и делают такие же оценки. Оценка вам хотя бы даст ответ на изначальный вопрос: стоит ли вообще рисковать.
i360u
То есть то, что рисование графиков никак не коррелирует с итоговым результатом вообще ничего нам не говорит? Ну ок.
DrPass
А что вас тут смущает? Может, график был хорошим, а плохим был программист, дизайнер или маркетолог. Или конкуренты были быстрее, или инвестиций хватило только для старта, а следующий раунд не получился. Или проект изначально был венчурным, и никто не обещал успеха с высокой вероятностью. Есть стопицот причин, почему стартапы не взлетают, и ошибка планирования тут далеко не главная. И уж точно не повод от планирования отказываться, даже если кто-то планирует неправильно. В любой работе бывает хороший результат, бывает лажа.
i360u
Как график может быть хорошим, если он не отражает плохого программиста и стопицот других рисков? Риск-менеджмент не должен быть частью планирования? И кто вообще говорит, что от планирования нужно отказываться? Речь идёт о том, что манки-бизнес — это НЕ планирование. Это лишь способ кормить себя и инвесторов иллюзиями.
DrPass
Риск менеджмент — это не про кадровый подбор. Если у вас специалисты оказались не специалистами, это не уже риск, а жопа проекту.
Я уже не знаю, о чем идёт речь, если честно. Мой изначальный тезис, с которым вы спорили, был о том, что планы необходимы для определения необходимости финансирования проекта. Когда это вдруг переросло в обсуждение манки-бизнеса, непонятно. Я не писал нигде конкретно про изначально тухлые проекты, создаваемые только для съема бабла (которые по-хорошему не нужны вообще, ни с планированием, ни без).
ApeCoder
Как вы посчитали, что оно не кореллирует, какие данные вы использовали?
Source
Сложность проекта чаще растёт из-за накопленного технического долга, а не из-за R&D. Если не накапливать кучу этого долга, то всё достаточно просто:
1) выделяется время под R&D
2) результаты анализируются, если они перспективны, но сыроваты, то итерация повторяется ещё раз
3) полученные результаты R&D позволяют весьма точно оценить объёмы и сроки дальнейших работ
Само собой, глупо оценивать задачу, требующую R&D, до проведения этого самого R&D. Справедливости ради, таких задач меньшинство даже на самых сложных проектах.
В большинстве случаев достаточно банальной декомпозиции, чтобы оценить с точностью ±20%.
i360u
В большинстве действительно сложных случаев, для того, чтобы выяснить, что именно на что в итоге декомпозировать нужно сделать не менее 60% всей работы. А технический долг со сложностью имеет весьма непрямое отношение: долг еще нужно накопить, а сложность и R&D — вот они, уже на старте. И сколько циклов R&D понадобится известно только самому R&D, ибо на то оно и R&D, что никакие результаты не гарантированы ни на одном из промежуточных этапов. В оценки таких проектов с точностью 20% я не верю абсолютно, ибо еще ни разу в моей практике такие оценщики не попадали в диапазон с кратностью меньше двух. Ну либо трудозатраты на такую оценку становятся сравнимы со стоимостью проекта. В большинстве случаев, все эти оценки — это тыканье пальцем в небо с мыслью "авось успеем", а попадание в срок в итоге определяется количеством компромиссов.
Source
R&D естественно делается без оценки, просто итерационно с подведением промежуточных результатов. Однако, фаза R&D всё равно должна проходить достаточно бодро, бизнес не может ждать пока вы там 2 года исследованиями будете заниматься, особенно на старте проекта. В конце концов, сам проект можно декомпозировать и выделить пресловутый MVP.
Короче, давно уже есть работающие практики, как выстраивать работу с приемлемой точностью эстимейтов. Можно зашориться и их не замечать, но бизнес всё равно будет у вас спрашивать сроки. Очень часто тут имеет место ситуация, что если задача слишком объёмная, то её тупо не выгодно даже начинать. Именно для этого нужна оценка в нулевом приближении — понять начинать вообще задачу делать или нет. Если да, то оценка уточняется более детально.
60% по сложности — крайне редко, но теоретически может быть, но по объёму (а соответственно и по временным затратам) 80% работы — это мартышкин труд на любом проекте.
Ну что тут сказать, набирайтесь опыта. Оценивание — это такой же навык, как и другие, он вполне себе тренируется. Но если вы будете себя ограничивать убеждением, что это невозможно, то для вас это и останется невозможным.
i360u
Оставьте свой менторский тон, мы ентого опыта наелись вдоволь. И про бизнес свои рассуждения тоже не экстраполируйте и не формулируйте столь категорично, у нас ведь тоже тут не благотворительная организация. По моему, вы просто не совсем понимаете что такое R&D, возможно просто не сталкивались с проектами на старте которых бывает вопросов больше чем ответов но в целом все участники согласны, что все выполнимо в некоей «среднесрочной перспективе».
Source
Вот уже 8 лет только с проектами такого рода и работаю. Для крупных проектов, которые длятся много лет, оценка сроков выстраивается по принципу: какой функционал можно успеть реализовать в ближайшие 3 месяца, месяц, 2 недели.
Само собой, никто не оценивает подобный проект целиком, хотя бы потому что требования к нему поменяются 100 раз в процессе разработки и дальнейшей эксплуатации. Однако ваш начальный тезис "С увеличением сложности проекта и увеличением роли R&D — адекватность оценки сроков снижается до полной бесполезности" в корне неверен. Полезные оценки можно давать для проектов любой сложности. Да, это сложнее, чем для типовых. Да, нужен навык и хорошее понимание как предметной области проекта, так и возможностей членов команды разработки. Но тем не менее, это вполне возможно.
i360u
Вы начинаете юлить. То есть, мы, конечно, знаем, что условная операция «открытие крышки ноутбука» занимает 2 секунды, а за месяц мы ее откроем 24 раза. Вот и часть эстимейтов у нас в кармане, да? А дальше начинается:
Ну так об этом я и пишу изначально. Разве нет? А вы утверждаете, что оцениваете такое с точностью 20% в обе стороны.
Source
Если вы не заметили статья про "оценку сроков на разработку и тестирование задач". Про оценку проектов целиком тут никто не говорил. Оценка проекта — это тупо оксюморон, потому что нормальные проекты живут и развиваются, а не сдаются "под ключ".
Вы же пишете, что нельзя оценить ничего с приемлемой точностью на проектах, требующих R&D. И это неверно.
stanislavkulikov
Всё-таки не понятно, как у вас без оценок бюджет рассчитывают.
green_hippo
У нас в Контуре продуктовая разработка, поэтому «бюджет» скорее зависит от команды продукта, нежели от запланированных к выпуску фич.
fracturizer
Поражает насколько порой тратится усилий на процесс оценки, при этом вообще не принимая во внимания _что_ мы оцениваем. Если в задаче заложена неопределенность (а если ничего не предпринимать то она всегда там заложена), то неважно какой метод оценки вы возьмете — все равно будете пролетать и на 50 и на 100, и на 1000%. Только снижением неопределенности можно внести уверенную стабильность в сроки выполнения работ.
i86com
Не все начальники/заказчики разбираются в ИТ. Приведу почти реальный пример с фриланса:
Спрашивает меня заказчик интернет-магазина:
— А сколько займёт времени сделать, чтобы пользователь вводит в поиск, например, «желтый холодильник» и ему выдаются все желтые холодильники? (Часто такое ещё спрашивают в форме «Можно ли» или «Сколько будет стоить»)
И вот он реально не знает — может, там просто галочку в нужном месте поставить. И когда я называю реальный план работ и сроки (какими бы примерными они ни были), у него сразу возникнет понимание, что ему это не нужно на данном этапе.
Плюс, в оценке сроков для нетиповых задач я всегда отвечаю в таком ключе:
«Выглядит, как задача на 2 недели. Более точно смогу сказать через 3 дня работы.»
То есть и примерный срок назвал, и не соврал (выглядит — факт), и не пообещал невозможного, и пообещал возможное. При работе с нормальным/опытным заказчиком, это было бы то же самое, что сказать просто «2 недели», но не все такие, и иногда приходится напоминать, откуда берутся эти ответы и что под ними подразумевается.
eugene_bx
Для этого есть специальный термин SWAG (scientific wild-ass guess) адекватно описывающий точность оценки и правильно воспринимаемый другой стороной.
Calc
При планировании, где числа идут 10, 100 и 1000 разница в 3 раза это норма. Как вы сами написали задачи у нас одинаковые, статистически их можно оценить, но всегда есть подводные камни, поэтому +-50% это хорошо. Вы же чувствуете разницу для планирования где может быть 15 и 50 (10 и 100 +-50%). Ну и самое главное, оценку должен давать не разработчик (любой), а тот, у кого есть статистика по задачам (например тим-лид)
romkavt
Автор верно отмечает разницу между оценкой трудозатрат и планом реализации.
Проблемы начинаются тогда, когда оценка трудозатрат автоматически становится дедлайном.
Оценки и планирование нужны хотя бы для того чтобы получить необходимые ресурсы для проекта.