Комментарии 186
С увеличением сложности проекта и увеличением роли R&D — адекватность оценки сроков снижается до полной бесполезности. Если проекты типовые — и процесс налажен — оценивать можно.
С увеличением сложности проекта и увеличением роли R&D — адекватность оценки сроков снижается до полной бесполезности
Нередко да. Но без хоть какой оценки сроков и стоимости вам проект все равно никто не профинансирует.
Вы слишком категоричны. Часто выделяют бюджет на команду а со сроками разбираются на уровне менеджмента. В продуктовой разработке именно этот подход позволяет более-менее адекватно планировать расходы.
Как график может быть хорошим, если он не отражает плохого программиста и стопицот других рисков? Риск-менеджмент не должен быть частью планирования? И кто вообще говорит, что от планирования нужно отказываться? Речь идёт о том, что манки-бизнес — это НЕ планирование. Это лишь способ кормить себя и инвесторов иллюзиями.
Риск-менеджмент не должен быть частью планирования?
Риск менеджмент — это не про кадровый подбор. Если у вас специалисты оказались не специалистами, это не уже риск, а жопа проекту.
Речь идёт о том, что манки-бизнес — это НЕ планирование.
Я уже не знаю, о чем идёт речь, если честно. Мой изначальный тезис, с которым вы спорили, был о том, что планы необходимы для определения необходимости финансирования проекта. Когда это вдруг переросло в обсуждение манки-бизнеса, непонятно. Я не писал нигде конкретно про изначально тухлые проекты, создаваемые только для съема бабла (которые по-хорошему не нужны вообще, ни с планированием, ни без).
Сложность проекта чаще растёт из-за накопленного технического долга, а не из-за R&D. Если не накапливать кучу этого долга, то всё достаточно просто:
1) выделяется время под R&D
2) результаты анализируются, если они перспективны, но сыроваты, то итерация повторяется ещё раз
3) полученные результаты R&D позволяют весьма точно оценить объёмы и сроки дальнейших работ
Само собой, глупо оценивать задачу, требующую R&D, до проведения этого самого R&D. Справедливости ради, таких задач меньшинство даже на самых сложных проектах.
В большинстве случаев достаточно банальной декомпозиции, чтобы оценить с точностью ±20%.
В большинстве действительно сложных случаев, для того, чтобы выяснить, что именно на что в итоге декомпозировать нужно сделать не менее 60% всей работы. А технический долг со сложностью имеет весьма непрямое отношение: долг еще нужно накопить, а сложность и R&D — вот они, уже на старте. И сколько циклов R&D понадобится известно только самому R&D, ибо на то оно и R&D, что никакие результаты не гарантированы ни на одном из промежуточных этапов. В оценки таких проектов с точностью 20% я не верю абсолютно, ибо еще ни разу в моей практике такие оценщики не попадали в диапазон с кратностью меньше двух. Ну либо трудозатраты на такую оценку становятся сравнимы со стоимостью проекта. В большинстве случаев, все эти оценки — это тыканье пальцем в небо с мыслью "авось успеем", а попадание в срок в итоге определяется количеством компромиссов.
R&D естественно делается без оценки, просто итерационно с подведением промежуточных результатов. Однако, фаза R&D всё равно должна проходить достаточно бодро, бизнес не может ждать пока вы там 2 года исследованиями будете заниматься, особенно на старте проекта. В конце концов, сам проект можно декомпозировать и выделить пресловутый MVP.
Короче, давно уже есть работающие практики, как выстраивать работу с приемлемой точностью эстимейтов. Можно зашориться и их не замечать, но бизнес всё равно будет у вас спрашивать сроки. Очень часто тут имеет место ситуация, что если задача слишком объёмная, то её тупо не выгодно даже начинать. Именно для этого нужна оценка в нулевом приближении — понять начинать вообще задачу делать или нет. Если да, то оценка уточняется более детально.
чтобы выяснить, что именно на что в итоге декомпозировать нужно сделать не менее 60% всей работы.
60% по сложности — крайне редко, но теоретически может быть, но по объёму (а соответственно и по временным затратам) 80% работы — это мартышкин труд на любом проекте.
В оценки таких проектов с точностью 20% я не верю абсолютно, ибо еще ни разу в моей практике такие оценщики не попадали в диапазон с кратностью меньше двух.
Ну что тут сказать, набирайтесь опыта. Оценивание — это такой же навык, как и другие, он вполне себе тренируется. Но если вы будете себя ограничивать убеждением, что это невозможно, то для вас это и останется невозможным.
По моему, вы просто не совсем понимаете что такое R&D, возможно просто не сталкивались с проектами на старте которых бывает вопросов больше чем ответов но в целом все участники согласны, что все выполнимо в некоей «среднесрочной перспективе».
Вот уже 8 лет только с проектами такого рода и работаю. Для крупных проектов, которые длятся много лет, оценка сроков выстраивается по принципу: какой функционал можно успеть реализовать в ближайшие 3 месяца, месяц, 2 недели.
Само собой, никто не оценивает подобный проект целиком, хотя бы потому что требования к нему поменяются 100 раз в процессе разработки и дальнейшей эксплуатации. Однако ваш начальный тезис "С увеличением сложности проекта и увеличением роли R&D — адекватность оценки сроков снижается до полной бесполезности" в корне неверен. Полезные оценки можно давать для проектов любой сложности. Да, это сложнее, чем для типовых. Да, нужен навык и хорошее понимание как предметной области проекта, так и возможностей членов команды разработки. Но тем не менее, это вполне возможно.
Само собой, никто не оценивает подобный проект целиком
Ну так об этом я и пишу изначально. Разве нет? А вы утверждаете, что оцениваете такое с точностью 20% в обе стороны.
Если вы не заметили статья про "оценку сроков на разработку и тестирование задач". Про оценку проектов целиком тут никто не говорил. Оценка проекта — это тупо оксюморон, потому что нормальные проекты живут и развиваются, а не сдаются "под ключ".
Вы же пишете, что нельзя оценить ничего с приемлемой точностью на проектах, требующих R&D. И это неверно.
Точность в плюс-минус 50% это трехкратная разница, о каком планировании может идти речь?
Не все начальники/заказчики разбираются в ИТ. Приведу почти реальный пример с фриланса:
Спрашивает меня заказчик интернет-магазина:
— А сколько займёт времени сделать, чтобы пользователь вводит в поиск, например, «желтый холодильник» и ему выдаются все желтые холодильники? (Часто такое ещё спрашивают в форме «Можно ли» или «Сколько будет стоить»)
И вот он реально не знает — может, там просто галочку в нужном месте поставить. И когда я называю реальный план работ и сроки (какими бы примерными они ни были), у него сразу возникнет понимание, что ему это не нужно на данном этапе.
Плюс, в оценке сроков для нетиповых задач я всегда отвечаю в таком ключе:
«Выглядит, как задача на 2 недели. Более точно смогу сказать через 3 дня работы.»
То есть и примерный срок назвал, и не соврал (выглядит — факт), и не пообещал невозможного, и пообещал возможное. При работе с нормальным/опытным заказчиком, это было бы то же самое, что сказать просто «2 недели», но не все такие, и иногда приходится напоминать, откуда берутся эти ответы и что под ними подразумевается.
Проблемы начинаются тогда, когда оценка трудозатрат автоматически становится дедлайном.
Оценки и планирование нужны хотя бы для того чтобы получить необходимые ресурсы для проекта.
Когда в нормальной команде от разработчика (тестировщика) требуют оценки сроков выполнения задачи, от него ждут двух вещей:
1. Тщательного осознания задачи, ее декомпозиции при необходимости и описания будущего решения (плана тестирования) в тикете. Такой детальный разбор задачи на этапе планирования делается не индивидуально, а в команде. Он позволяет не делать фигни и заодно получить реалистичную оценку сроков выполнения (которая фиксируется в том же тикете).
2. Взятия на себя ответственности за заявленные сроки. Когда задача уже разобрана и решение понятно описано, команда и отдельный разработчик с открытыми глазами берет на себя ответственность за сроки. Это порождает совсем другое отношение к работе, чем спускаемые сверху непонятные, а иногда и безумные сроки от «менеджеров».
Потом из таких качественно предобработанных задач легко собираются управляемые итерации скрама.
Именно такие граждане сначала не требуют от разработчиков оценки задач, перевешивают ее на менеджеров, у которых должны быть совсем другие компетенции, а потом жалуются, что у них «скрам не работает».
Пишу как человек, полтора года руливший невероятно бодрой командой разработки из бывших сотрудников Контура, которая с этим подходом запилила качественный продукт и всегда соблюдала сроки поставки. Не сдержался :)
Но автора работает в продуктовой разработке, где единственная цель определения временных затрат на задачу — оценить сроки выпуска очередной функциональности. Речь всегда идет об управлении сроками.
Поэтому противопоставление оценки сроков и оценки трудозатрат в часах — это неловкая манипуляция со стороны автора.
Но автора работает в продуктовой разработке, где единственная цель определения временных затрат на задачу — оценить сроки выпуска очередной функциональности. Речь всегда идет об управлении сроками.
И автор утверждает — что оценивать сроки нет никакого смысла. Потому что как только задача начинает отличается от стандартной, начинается гадание на кофейной гуще, когда оценка сильно накручивается, в нее закладываются все возможные риски, а потом еще и ко всему этому совершается ошибка "техасского снайпера".
В продуктовой среде, мне казалось, очень часто сроки ставятся или свыше к какой-то дате, или "чем раньше, тем лучше".
Автор говорит совсем другое — сроки должны оценивать не специалисты, которые своими руками будут делать работу, а какой-то «менеджер» на белом коне, который, даже будучи в прошлом техническим специалистом, конкретных деталей реализации и многотонных подводных камней [уже] не знает.
И главная претензия к автору в том, что он как руководитель целого, по сути, направления, хочет полностью снять ответственность за сроки поставки с команды, лишив ее, пожалуй, самого главного мотивирующего фактора — commitment'а, личной ответственности и участия в жизни продукта.
Без оценки сроков бизнес просто умрет.
Особенно без оценки сроков на "поменяй тестовку". Мне кажется, у довольно большого количества задач дедлайн, к которому они должны быть реально сделаны — очень и очень мягкий.
А если вы говорите про какие-то крупные "проекты" в духе переделки сайта или создания новой сложной фичи, то обычно дедлайны спускают сверху, как мне казалось.
В крупных проектах сроки могут сколько угодно спускаться сверху, но физику не обманешь и бизнесу лучше узнать горькую правду о том, что в эти сроки можно сделать только 1/3 требуемого до того, как он подпишет контракт с серьезными неустойками за срыв сроков)
Автор говорит совсем другое — сроки должны оценивать не специалисты, которые своими руками будут делать работу, а какой-то «менеджер» на белом коне, который, даже будучи в прошлом техническим специалистом, конкретных деталей реализации и многотонных подводных камней [уже] не знает.
И главная претензия к автору в том, что он как руководитель целого, по сути, направления, хочет полностью снять ответственность за сроки поставки с команды, лишив ее, пожалуй, самого главного мотивирующего фактора — commitment'а, личной ответственности и участия в жизни продукта.
Я прочитал статью несколько раз, но категорически не вижу, где Wolonter утверждает хоть что-то из цитаты. Александр, как же так? :)
Если команда выполняет эти упражнения, а менеджер квалифицирован, то для ответа заказчикам ему не нужно требовать от исполнителей назвать срок.
Автор ниоткуда вытаскивает мысль, что, якобы, разработчик будет закладывать себе резерв времени если его спросить о конкретном времени завершения (что верно), и не будет, если его просто попросить оценить количество часов, которые ему потребуются с момента старта работы над задачей (что неверно).
Потому что разработчик знает, что команда будет одинаково его порицать за безответственность при любом из способов срыва сроков :)
Автор совсем не такой, как вы описываете… Автор специально привел ссылки на источники в начале, где есть объяснения. В частности перезакладывания.
Кажется, я чем то задел ваши эмоции и этим вызвал кучу толкований меня и достаточно резких высказываний.
Думаю, конструктивно не получится, а жаль.
Возможно, именно из-за такого подхода Контур за последние 5+ лет не выпустил ни одного заметного нового продукта при таком безумном количестве разработчиков (и 150(!) тестировщиках) ;(
Автор оправдывает атмосферу расслабленности и вялости
А я видел, как демотивирует и замедляет разработку ваш подход и тоже страдаю, когда вижу спринтеров с горящими жопамии, не умеющими играть дольше, чем в год.
Александр, наш спор на уровне мировоззрений и ни к чему не приведет. Аргументы вида «вот оно так потому что вы демотивируете!»
Вы будете оценивать сроки и считать свои команды крутыми и успешными. Я оценивать сроки не буду и тоже буду считать свои команды крутыми и успешными. Чистый эксперимент поставить не получится. Зрители повеселятся.
А контур, конечно да, ничего не создал и ничего не запустил и вообще на ладан дышит. Скорее всего из-за такого подхода. Всё плохо.
Когда у ваших разработчиков во время спринта горят жопы, значит вы что-то совсем не то с ними делаете!
У разработчиков в состоянии драйва должны гореть глаза! Глаза!
А контур, конечно да, ничего не создал и ничего не запустил
Уже лет 5 ждем API для Контур.Бухгалтерии — теперь понятно почему
"Без оценки сроков бизнес просто умрет."
Что же вы пишете про все бизнесы сразу? Жил, живет и будет жить бизнес и без оценки сроков. И речь не только про контур.
Дальше вы делаете ряд заявлений и претензий, отвечая на которые я буду доказывать, что я не верблюд.
Ответственность с разработки я снимать не предлагаю. Предлагаю перестать обманывать. Себя в первую очередь.
Если суммировать:
1. Противопоставление сроков поставки и оценки сложности задач в часах — абсолютно искусственное именно в продуктовой разработке. Это изоморфные вещи. В заказной разработке человекочасы переводятся еще и в деньги, но в вашем случае это чистая манипуляция. Вместо того, чтобы спросить: «Ты же обещал к четвергу, а сегодня пятница. Где?!» — владелец продукта спросит: «Ты же обещал сделать за 9.5 календарных часов и начал позавчера. Где?!».
2. Завышение оценок специалистами. Такая проблема есть, но решается она не отказом от оценки, а методами коллективной оценки, когда завышенная оценка не проходит дизайн-ревью, и ежедневных летучек, которые в нормально мотивированной команде не дают зря проедать временной бюджет.
3. Негативное влияние оценки на производительность. Если я правильно помню, ДеМарко писал об этом в контексте травли команд. Правильная оценка задач, как вы и сами пишете ниже, позволяет достаточно детализировать задачу, привлечь коллективное знание всей команды, чтобы не допустить большей части возможных дорогостоящих ошибок, которые один человек допустил бы, не допустить чрезмерного раздувания оценки — и получить достаточно надежные оценки, чтобы с высокой точностью планировать выпуски.
4. Самое главное. Предлагаемый вами подход убивает мотивацию сотрудников, потому что убивает вовлеченность в жизнь своего продукта и в принятие решений. Чувство сопричастности судьбе своего продукта и чувство личной ответственности за качество и за собственноручную оценку сроков — важнейшие мотиваторы разработчиков. Когда работа разработчика превращается в смену у конвеера с тасками, а сверху на него валятся взятые с потолка кем-то сроки, даже самая мотивированная команда необратимо превращается в болото. Что вы, к сожалению, вероятно, нередко видите вокруг :)
Еще и еще раз. Я говорю о том, что нужно спрашивать не срок, а упражнения из списка. Они полезны. Срок ложь.
По поводу мотивации, убитой сроками оценки — и опять не так. В моей и не только команде с мотивацией все ок. И она не зависит от коммита в дату. Зачем вы безапелляционно обобщаете? Прямо как я в заголовке. А еще я знаю команды, демотивированные необходимостью играть в сроки.
И да. Контур я тоже люблю.
А откуда бизнесу брать реальные оценки сроков вы и вовсе тактично умалчиваете.
На практике из-за такого отношения к срокам почти десять лет может потребоваться, чтобы убрать баклажанный цвет с одной единственной страницы, если вы понимаете, о чем я ;(
«Ты же обещал сделать за 9.5 календарных часов и начал позавчера. Где?!».
вот я тоже в статье увидел эту манипуляцию, хотелось бы услышать от вас ответ, нам показалось или вы неправильно выразились?
Вы описываете оценки, но не описываете понятие как трафик. Грамотный ПМ спокойно клиенту объяснит что такое трафик и куда идет дедлайн (хотелки клиента).
Давать оценки — профессиональный навык разработчика, а воспринимать их как обещания и порицать за неисполнение — неадекватность менеджмента. Оно может и работает на коротких дистанциях, когда разработчики, чтобы выполнить обещание добровольно и бесплатно перерабатывают, но при длительной работе или будете получать неадекватно завышенные сроки (разработчики будут закладывать в них риски, хотя риск-менеджменту их обычно не обучают, поэтому закладывание будет неадекватным), или людибудут демотивированы в ноль или даже минус.
Работа менеджера — взять оценку и заложив в неё риски ошибок оценщика («статистика показывает, что этот разработчик в 50% случаев работает над задачей на 90% времени больше, чем давал оценку — закладываем 45%») выдать наверх сроки (если сверху этого требуют).
Работа разработчика, тестировщика и т. п. — давать оценки (кроме всего прочего, конечно). Менеджмент должен поощрять точность оценок, мотивируя прокачку этого навыка, но именно точность, а не непревышение. «Ты дал неадекватно низкую оценку», а не «ты неадекватно превысил оценку». Плохой оценщик, а не плохой выполнятель обещаний.
Исключение навскидку — скрамообразные процессы, где выделенная роль менеджера отсутствует, и по сути вся команда выступает коллективным менеджером самой себя и даёт обязательства владельцу продукта за срок спринта выдать некоторый скоуп фич/багфиксов.
Клиент завязался на обязательства Компании поставить фичу в срок, Компания завязалась на обязательство Разработчика выпустить эту фичу в срок. Разработчик не выдержал сроки, Клиент потерял деньги, Компания потеряла Клиента, Разработчик потерял работу.
Не надо считать разработчиков единороговыми понями в вакууме, их работа и их косяки имеют реальный экономический эффект, который прилетает к ним бумерангом так или иначе.
Проблема завышения сроков при этом действительно существует, и работа менеджера и руководства — найти такой баланс пряника и кнута, при котором система устойчиво работает.
Одним из лучших решений для создания такого непростого баланса как раз являются «скрамообразные процессы», которые позволяют и контролировать сроки, и не скатываться в завышение оценок, и сохранять хороший моральный климат.
Реальность, данная нам в ощущениях, пока что в среднем такова, что если перекладывание ответственности на разработчика происходит (как правило в той самой форме «ты обещал, но не сделал», оценки рассматриваются как базис для дедлайнов) — то происходит оно абсолютно бесплатно для разработчика. Если какой-нибудь скрам или подобное начинает существенно добавлять задач на управление в жизнь разработчиков — это тоже происходит бесплатно для разработчиков. Вообще, в среднем рвение превратить разработчиков в псевдо-партнёров (когда они за продукт типа должны душой болеть, но получать при этом всё равно только зарплату за время) — встречается довольно часто. Угадайте, почему многим разработчикам такое рвение не нравится.
Думаю, с таким скиллом вы можете рассчитывать на +20% к рынку и/или действительно интересные задачи и драйв на работе. Но увы, компаний, которые умеют нанимать таких разработчиков и грамотно управлять ими и вправду, похоже, очень немного. Зато работа там — это будет experience of a lifetime.
С таким скиллом, войдя в число основателей компании, вы можете рассчитывать на много большее.
Как рядовому разработчику — ни на что рассчитывать сверх тут не приходится.
Другое дело, что более точные оценки дает/лучше разруливает ситуации по ошибкам оценок более квалифицированный разработчик. Который и получает больше.
Но платят ему +20% не столько и не только за скилл «точных оценок», а за всю совокупность профессиональных навыков.
Ваш вариант, на самом деле, эквивалентен, потому что при наличии такого плана работ и дать оценку сроков — уже не проблема.
И не написал, что бывает, когда бизнес заложился на оценку взятую менеджером с потолка, а не от специалистов, которые глубоко в теме и хорошо подумали.
И еще Максим не написал, что бывает, когда эта «спотолочная» оценка спускается менеджером самим разработчикам, а они вполне обоснованно относятся к ней и к этому менеджеру по принципу «ты ковбой, ты и прыгай».
Тут надо понимать, что либо вы работаете в динамично развивающемся продукте, где каждая новая возможность — это счастье или уход пользователей и часто целые новые пласты клиентов, ресурсов не хватает, а впереди маячит вкусный приз, либо в проекте, где ничего от релиза вашей фичи не поменяется, по большому счету, и срок ее релиза вообще не имеет значения.
Во втором случае заморачиваться вопросами сроков и эффективности нет никакого смысла. А в первом случае в работе не бывает задач без дедлайнов :)
Живущие в мире дедлайнов разработчики получают именно то, за чем пришли в профессию: они видят, как на глазах развивается продукт, как клиенты начинают использовать новые возможности, принимают непосредственное участие в определении судьбы продукта и живут в состоянии драйва.
По поводу гигантских трудозатрат на планирование. Во время планирования находятся и описываются решения всех попавших в планирование задач. В оставшиеся дни итерации остается только написать код, потому что все решения уже приняты и почти все головоломки решены.
Оверхед возникает из-за того, что оценивание задач обязательно проводится коллективно.
Во-первых, в достаточно большом проекте не все одинаково владеют всеми кусками кода, и более компетентные в какой-то части функциональности разработчики помогают сразу принимать правильные решения.
Во-вторых, коллективная оценка не позволяет скатиться в завышение и, что не менее важно, в занижение оценки задачи.
С овертаймами — тут уж у кого как. Если команда адекватная и не позволяет занижать оценку, кранчи бывают редко и, как правило, компенсируются периодом расслабленности после очередного релиза.
Так вот, в вопросе оценке сроков я понял, что менеджерам моя оценка нужна только для отчета перед руководством и для прикрытия своей ж… в случае срыва-переноса сроков. В большинстве случаев получалось что-то типа «ты сказал, ты и делай».
В моем понимании сроки должно определять руководство (вот к этому дню нам нужен вот такой функционал), а менеджеры должны обеспечить все необходимое для реализации функционала разработчиками.
абсолютно верно, есть такие менеджеры которым вообще пофигу что за задача, насколько сложная, что и как, вот ты дай мне срок и всё, и отвечать тоже ты за него будешь. А я получается только озвучу его руководству. Замечательно, блин. Ладно бы такой менеджер хоть как то пытался помочь, вникнуть в проблемы, так нет же! Так и хочется ответить таким манагерам — пошли вы в Ж...!
Вы так категорично рассуждаете о единственно верном подходе для абсолютно любых ситуаций, скажите, Судья Дред не ваш родственник?
А если серьезно, то я написал про конкретную ситуацию в Контуре, где много сотен разработчиков, которые могли бы сделать десятки продуктов. Причем, я знаю, очень качественных продуктов.
И эти сотни разработчиков делали бы крутые штуки в состоянии драйва. Причем у Контура есть такой опыт.
А тут менеджер всех тестировщиков, по сути, призывает сидеть в теплом липком болотце безрезультатного комфорта :)
Наверное хорошо, что теперь эти сотни разработчиков вместе с тестировщиками делают крутые штуки с драйвом, но без вас.
И буду очень признателен, Максим, если вы покажете мне эти крутые штуки на kontur.ru. А то вдруг я просто не ЦА и пропустил какие-то анонсы :)
Команды офигенные, работают бодро. Спорить о степени крутости и обсуждать мощь продуктов я не буду.
Кстати, чем похвастаете вы?
А обижаться на то, что комментарии по этому поводу жесткие, с вашей стороны странно, ведь вы в своем тексте в агрессивной форме обесцениваете лично мои профессиональные достижения и достижения еще многих и многих людей, что неприятно :)
А тут менеджер всех тестировщиков, по сути, призывает сидеть в теплом липком болотце безрезультатного комфорта :)
Если вы так для себя поняли написанное в статье и это стало триггером для таких категоричных суждений, то, возможно, вам будет интересно узнать, что я в статье такого не увидел :)
Я в статье увидел некие мысли по поводу «вредности оценок сроков» и того, как они обустроили процесс по-другому в своей части общей работы. С «чем-то» я согласен, с «чем-то» — нет, «что-то» «работает» только по стечению конкретных обстоятельств, «что-то» вообще не влияет на итоговый результат. Но призыва сидеть в болтце — не увидел.
P.S. Со временем и Судья Дред и Виталик Бутерин кое-что всё же поняли :)
— Ты когда-нибудь слышал о смягчающих обстоятельствах?
— Все, что только можно.
Смотрите.
Я бы хотел, чтобы разработчики (и в целом команды) Контура создавали новые крутые проекты. Именно за этим идут в разработку ПО. Это вводная.
Практика доказывает, что крутые проекты могут делать только крайне мотивированные команды голодных разработчиков с горящими глазами, которые безостановочно изучают клиента, пробуют новые гипотезы и не останавливаются, пока не нащупают облик реального продукта. Это идеальная команда по Бруксу и Листеру.
Если в ходе этого поиска сроки решения задач не ограничивать, команда теряет фокус и начинает делать всякую ненужную побочную фигню, и проект заболачивается, а потом и умирает.
Но если команду и ее разработчиков начать подгонять сверху и спускать какие-то сроки, это создаст у разработчиков понимание, что конечный результат от них не зависит, и вместо пылающих глаз мы получим горящие пуканы и, опять же, торможение и гибель проекта. Это один из идеальных сценариев «травли команд» по Бруксу и Листеру. Именно в таких условиях разработчики начинают раздувать сроки и бездельничать, сделав переоцененную задачу — им нужно прикрыть задницу, а не построить вместе с командой крутой продукт.
Тонкая грань максимальной эффективности команды — это режим, в котором команда полностью вовлечена и все участники чувствуют, что результат зависит только от них, берут на себя личную ответственность за результат. При этом темп поддерживается максимально высокий, сроки поставки фич и проверки гипотез остаются управляемыми. Нужно, чтобы команда оценивала сроки работы над задачами, чтобы она по-честному могла взять на себя ответственность за обоснованные сроки поставки.
Таким образом, автор, по сути, призывает к тому, чтобы команды Контура работали расслабленно, без огонька. А значит и без шансов сделать что-то действительно крутое.
В чем и виновен :)
Если в ходе этого поиска сроки решения задач не ограничивать, команда теряет фокус
Только потому, что вы так считаете?
Нужно, чтобы команда оценивала сроки работы над задачами, чтобы она по-честному могла взять на себя ответственность за обоснованные сроки поставки.
Без сроков нельзя брать ответственность?
Только потому, что вы так считаете?
Вы тоже так считаете. Не зря же вы писали, что работа стремится занять все отведенное под нее время. А представьте себе, что время вообще не ограничено. Немедленно случится паралич перфекционизма, или решение задачи в общем виде, или написание целого фреймворка — под функцию, которой клиенты, может, вообще не будут никогда пользоваться.
Без сроков нельзя брать ответственность?
Можно. Но бизнесу/владельцу продукта нужны сроки. Если их спускают сверху, команда переходит в режим прикрытия задницы и теряет продуктивность. А дать собственную обоснованную оценку команда может, только оценивая свои задачи. А когда команда такую оценку дает, она получает серьезную мотивацию в нее уложиться. Тут хотите — поверьте моему опыту, не хотите — попробуйте сами)
А когда команда такую оценку дает, она получает серьезную мотивацию в нее уложиться.
Вопрос, за счет чего она будет в него укладываться...
Правда, некоторые считают, что обычно это приводит к спешке, которая вредит качеству.
В любом случае убеждён, что оценки трудоёмкости не должны ограничивать работу по времени, мотивировать успеть в них уложиться. Развивать нужно навык точной оценки, а не навык умудряться укладываться в сроки.
Причем, судя по тому, что некоторые призывы оценивать задачи в условных единицах а не во временных мотивируются так же (чтобы не стимулировать спешку), это наблюдаю не только я.
Даже если у вас нет наступающих на пятки конкурентов, кучи пользователей с запросами, маркетологов, которые требуют фич для новых классов клиентов, вас все равно подгоняет как минимум ограничения бюджета/контракта/объема инвестиций/терпения внешнего или внутреннего инвестора.
А умение делать быстро, но без ущерба качеству — это и есть искусство разработки ПО, индивидуальное и командное.
«без спешки разрабатывается только ПО, которое заведомо никому не нужно.» — тоже слишком примитивно — каждое ПО разрабатывается со спешкой и без спешки в разные моменты времени.
Просто чтобы донести основную мысль, иногда приходится утрировать. Иначе, если доносить главную мысль со всеми должными уточнениями и оговорками, она ускользает от внимания в потоке слов :)
Вообще, с хорошей командой и торопиться можно не спеша, без перегибов, и технический долг оставлять минимальный. Но расслабленного отношения к работе создания нового продукта не прощает.
Менеджмент приходит к вам с набором feature requests и спрашивает, что и когда вы можете сделать.
Вы все декомпозируете, оцениваете, и предлагаете менеджменту несколько вариантов, как можно раскидать его запросы по порядку реализации и вы вместе исходя из приоритетов формируете план разработки.
И это ваш план, ваш процесс, ваши оценки и только от вас зависит результат.
И уж где-где, а в Контуре точно возможен такой процесс)
Банально, заболел человек, который должен был делать ключевую задачу спринта, блокирующий половину если не больших остальных. Хорошо если команда реально кроссфункциональная и каждый легко может его подменить. Просто чтобы спринт закрыть надо будет по 9-10 часов работать, а не 8. За теже деньги, конечно, да, у нас же мотивация и ответственность за сроки. А он лежит более и думает какой он редиска, команду подвёл. А если команда не совсем кроссфункциональная, если чтобы в задачу въехать только неделя нужна, и то при условии постоянных консультаций с заболевшим?
И теперь вы противопоставляете себя коллегам и руководству, вместо того, чтобы считать всех одной командой единомышленников, где все друг друга поддерживают.
Даже не знаю, как теперь помочь вам поверить, что это не норма, и так бывает далеко не всегда :(
Разный опыт был.
И где я про противопоставление говорю? Наоборот, работая над продуктом каждый занят своим делом, разработчики разрабатывают, менеджеры управляют на основании данных от разработчиков явных (оценки, статусы) и неявных (статистика по прошлым задачам). Управление рисками — это (с вики) процесс принятия и выполнения управленческих решений. Если разработчик берёт на себя ответственность управленца, то возникает два вопроса: что взамен и зачем ему менеджмент нужен? ну и вдогонку, а в чём ответственность конкретно заключается?
С менеджментом понятно, он редко работает за оклад, а явно или не очень участвует в прибылях. Его ответственность — лишение премий и бонусов за успешную работу, составляющих заметную часть его дохода. А разработчик на окладе? К тому же с профессиональными навыками находить дыры в системах, в том числе административных типа "сдашь задачу тобою же оцененную досрочно — получишь премию" и "не сдашь задачу в названные тоою сроки — уволим". Как говорится "и тут мне карта как попёрла", нет?
2. Менеджмент в вашей модели мира — это какие-то полубоги с долей в прибыли, а на самом деле 99% менеджеров точно такие же наемные сотрудники, тем более в больших компаниях.
3. Просто представьте себе ситуацию, когда вы и ваш менеджер разработки делаете все, чтобы помочь друг другу в работе: менеджер добивается у своего руководства обязательного бюджета на рефакторинг, хорошего железа, пары больших мониторов и дивана в офис, чтобы не спать после обеда лицом в клавиатуре. А вы помогаете менеджеру в его работе: помогаете ему оценить сроки, не подводите его без необходимости, сразу сообщаете о проблемах, конструктивно помогаете ему увидеть ошибки. Приятно было бы работать в таких условиях?
2. Ну вот так получилось, что в моей практике если не доля в прибыли, то приличный бонус за успешное завершения проекта они получали. Как я понимаю немалая часть этого успеха заключалась в грамотном управлении рисками. Ну или они взяли наши оценки, сложили и выдали заказчику без каких-либо поправок и резервов, а мы сильно трудозатраты переоценили, интуитивно заложив не только прямые трудозатраты, технологические риски, но и время совещаний, время переключения контекстов, время перекуров и опозданий, ожиданий обратной связи и т. п.
3. Так я и помогаю менеджерам оценить сроки, давая оценку трудозатрат и список видимых технологических рисков из-за которых трудозатраты могут увеличиться.
Программист должен отвечать за «качество» кода.
Менеджер проекта должен контролировать время.
Да уж. Офисный мачизм, как он есть.
Почему все же решил остаться?
Мелкая задача помечена в YouTrack тегом «на час
делается за один подход (от получаса до двух часов)
Просто прекрасно :)
тестирование достаточно непредсказуемо, что бы можно было тестировать результаты недели работы разработчика за пол часа, а одну строчку кода — две недели :)
Автору — спасибо! я бы почитал еще более подробные примеры применения «упражнений» — и возможно даже какой-то опыт не очень успешного применения тех или иных практик: кажется, что к данной статье привел достаточно большой опыт и пул знаний, а не только желание «побомбить» на менеджеров, которые не различают «нужен день» и «через день — готово».
Вот в целом какая цель у оценки? С точки зрения управленца, и это говорится во многих книгах, необходимо понимать когда, примерно, будет выпущена та или иная фича. Для чего? Очевидно, что есть процессы помимо разработки и тестирования и было бы круто выполнять их параллельно. Для этого надо понимать когда будет выполнена та или иная часть работы. Нередко бывает что руководитель говорит — “Надо через три дня, успеешь?”. Тут да, менеджер из него так себе (правда иногда такое бывает и с хорошими менеджерами). В такой ситуации, конечно, появляется чувство, что тебя прижали к стенке.
“Я считаю абсолютно вредной практику, когда исполнитель оценивает сроки на выполнение отдельной задачи.”
Во-первых, получается, что он считает оценку фичи полезной, раз не сказано обратного. Речь только о задачах, как я понял. Это же следует и из названия статьи. Во-вторых, он считает вредной практику оценки задач исполнителем, получается оценка задач менеджером, тимлидом, коллегой с другого проекта или командой уже не вредная, как минимум. А вот если доколупаться до Васи с вопросом сколько он потратит на задачу к которой приступает, это да, это вредно. Можно возразить, что это мои придирки, но все остальное будет просто мнением, основанным на ваших мыслях, которые могут не соответствовать мыслям автора.
“Это напрямую связано с отсутствием системного образования и низкими требованиями к менеджерам.”
Так, погодите, отсутствие системного образования у кого, у менеджера или того, кто будет оценивать? Это важно. Отсутствие системного образования (при чем здесь это вообще?) у менеджера может привести к ожиданию, что задача будет выполнена через Х часов с момента начала работы над ней. А у исполнителя, может создастся ощущение, что есть некий дедлайн и выход за его рамки приведет к ухудшению мнения о нем как о разработчике/тестировщике. Здесь важнее общее понимание оценки обеими сторонами и того, что может произойти при нарушении договоренности. Вторая часть предложения про низкие требования к менеджерам — это вообще о чем? Не, ну правда, не нравится менеджер и его методы, поговори с ним, объясни, что не так. Менеджеры не телепаты, им тоже нужна обратная связь, если он адекватный человек, то будет благодарен за фидбэк. Если не зашло, иди к директору, проси сменить менеджера, в чем проблема?
“К нам приходит человек, ставит задачу и спрашивает, сколько времени может занять ее выполнение. Оценивая задачу, мы, конечно же, хотим назвать тот срок, к которому точно успеем, а так как многое может случиться (и мы подозреваем, что что-то наверняка случится), мы закладываем в оценку некий запас времени.
В итоге любой названный в качестве дедлайна срок становится сроком, раньше которого задача выполнена не будет. К особо неприятным последствиям это приводит при командной работе, когда для выполнения одной задачи или проекта требуется сотрудничество разных специалистов и разных отделов.”
Логично и правдиво, но! Заметили ли вы логическую ошибку? По отдельности я согласен с каждым этим абзацем, а вот вместе нет. В одном речь про оценку, а во втором про срок! Это же разные понятия… Это к вопросу про системность образования. Абзацы вырваны из контекста и совмещены. Будь я чуточку менее внимателен, то проглотил бы это. Это же Макс Дорофеев написал! КЛАССИК! Интересно знает ли он сам про это? Оценка, это “За час, в течении недели”, а срок “Будет через час”.
“В пятой части первой главы есть ссылки на исследования о зависимости производительности от того, кто выполнял оценку сроков.”
Ну давайте почитаем эту часть вместе и добавим цитаты с небольшими комментариями:
“В 1954 году англичанин Сирил Паркинсон выразил мнение, что работа растѐт, заполняя любое отведѐнное под неѐ время. Сейчас это мнение известно как закон Паркинсона”
“Даже руководители, не знающие вообще ничего о менеджменте, цепляются за эту аксиоматическую истину – закон Паркинсона, руководящую людьми и их отношением к работе. Он даѐт им крайнюю убеждѐнность в том, что единственный способ добиться выполнения работы – это установить невозможно оптимистические сроки еѐ сдачи.”
Смотрите ка, опять про сроки, а не про оценку…
Книга, судя по пятой части первой главы, интересная. Что я вынес из прочтения этого отрывка. Во-первых, исследование на которое ссылается автор книги датирована 1985 годом. Скрам и аджаил в целом, а именно они возникают у меня в голове при слове “оценка”, был сформирован в 2000-ых. И подход к оценке был изменен. Можно почитать “Мифический человеко-месяц” (1975), что-то мне подсказывает, что есть на эту тему информация. Оценка в скраме несет приблизительный характер (попугайчики), а размер спринта зависит от среднего объема выполняемого командой за некоторое количество предыдущих спринтов. Кроме того, оценка производится коллективно, а не непосредственно исполнителем.
Продолжим разбор статьи.
“За последний год я дважды слышал от менеджеров: «Мы научились выдерживать сроки по оценкам задач, теперь такой-то программист или тестировщик совсем не нарушает сроки, которые назвал».
Я считаю, это крайне серьезная проблема, так как это означает, что этот программист или тестировщик системно и сознательно завышает сроки, работает на расслабоне и лжет менеджеру.”
И что? Менеджер доволен, у него не срываются другие процессы из-за разработки/тестирования. Программист/тестировщик тоже, у него нет чувства горящей пятой точки. А если возникает ощущение, что оценка завышена, то можно делать это коллективно и брать среднее значение оценки. Ничего нового, просто немного понимания скрама. Если какой-то сотрудник сильно отстает по производительности, то это повод к выяснению причин.
“Упомянутые в заголовке авторы говорят, что единственно верный способ оценки сроков — статистический. Должен оцениваться пакет типовых задач. «У нас все задачи разные»? Это ложь. На промежутке в год будет уже не очень много разных задач. Как правило, такое заявление является признаком отсутствия рефлексии над процессом и не выполнения упражнений: декомпозиция, MVP, прототипы, стандартизация.”
Бррр, да это же опровергает все что было написано автором до этого, нет? Лично у меня этот абзац не вызывает чувства отрицания сам по себе, но автору-то он зачем?
“О заказчиках, которые требуют сроки
Во-первых, надо заметить, что чаще всего — и это само по себе забавно — от ответа исполнителя не зависит ничего, потому что сроки уже есть. Менеджер интересуется не сколько времени мы будем делать задачу, а успеем ли мы к заданному сроку и что именно успеем. Это разные вопросы и отвечать на них нужно по-разному.
Как правило, ответом на вопрос «успеем ли мы к заданному сроку» является аналитика и MVP, качественная инфраструктура разработки и размер технического долга, а именно сложность проведения рефакторинга и наличие автоматических тестов на регрессию.”
Как? Как из этих двух абзацев следует вывод — “Ещё раз: оценка сроков мешает исполнителю успеть к дедлайну.” Я могу что-то с этим придумать, конечно, сделать какие-то домыслы, но это не то, что я ожидал от статьи.
Далее приводится список упражнений (среди которых MVP), которые рекомендуются к выполнению для повышения точности сроков и вывод:
“Если упражнения не выполняются, то скорее всего любой названный менеджером срок будет ложью.”
Ну как так-то? Вот представим ситуацию. Приходит заказчик и приносит требования, просит оценить сроки выполнения и бюджет. А мы ему такие: “Так, товарищ, надо запилить MVP и выпустить его канареечными релизами! Если вам нужна более точная оценка оценка, то в этом нам поможет раздельный релиз бэкэнда, фронтенда и прочего… и канарейки. И не забудьте про фича-флаги!”. И как нам это поможет?
“О некомпетентных менеджерах
Очень легко перепутать оценку сроков (когда задача будет сделана) и оценку трудозатрат (сколько нужно времени, чтобы разработать фичу). Оценка сроков, как мы уже разобрались, если не вредна, то по крайней мере бессмысленна. А вот оценка трудозатрат — довольно полезное упражнение.”
Зачем? Ну что кому даст оценка трудозатрат сама по себе? Разумеется она нужна, но, только в контексте оценки сроков. И эти две оценки очень тесно связаны. Просто надо добавить еще один параметр — количество выполняемого труда командой проекта. И тогда все встает на свои места. Оценили трудозатраты, знаем производительность команды, следовательно, можем получить оценку сроков. Если что-то меняется в требованиях, то происходит изменение оценки.
“Пример из жизни:
— Сколько времени ты потратишь на эту фичу?
— Полторы недели буду писать и дня три фиксить баги.
— То есть через 3-4 недели будет готово?”
А где продолжение? Ну ответил — “да” и сделал, у него же не лапки. Или ответил — “У меня сейчас большая загруженность. Давай посмотрим бэклог и подумаем над приоритетом этой фичи (посмотрели — вставили в бэклог — сделали)”. Где интрига-то?
“P.S. Один из наиболее важных навыков в нашей работе — не делать ненужной херни. В том числе не заниматься «оценкой сроков» и самообманом. Чего и вам желаю.”
Про самообман хорошо сказал…
В планировании времени исполнителем мне нравится одна вещь — осознание ответственности.
В планировании времени исполнителем мне не нравится другая вещь — исполнителям обычно не платят деньги и не выделяют временной ресурс на рациональное планирование, и несение ответственности.
это означает, что этот программист или тестировщик системно и сознательно завышает сроки, работает на расслабоне и лжет менеджеру
Нет, совсем не так!
На каких-то задачах он может и расслабиться, зато если не учел в своих расчетах какую-то трудоемкую часть, то будет напрягаться и работать напряженне обычно, да еще и будет задерживаться на работе чтобы не выйти из сроков.
Часто наблюдал как неопытные коллеги (да и сам поначалу) ошибались в сроках в меньшую сторону и пытались самоотверженно это исправить ударным и сверхурочным трудом. Итоговый результат, обычно получался не очень хорошим: или код был написан без нормальной проработки «на костылях» или сам сотрудник уставал от такого режима…
Требование оценки сроков выполнения от бизнеса вполне понятные, и если такие требования есть, то они автоматически подразумевают, что опытные разработчики будут закладывать в эти сроки запас времени. Так же понятно, что если есть сроки, то, как правило, выполнение задачи займет все заявленные сроки. Это должно быть понятно и менеджерам и бизнесу, чудес не бывает и никакого вранья здесь — нет. Бизнес может сформировать избыточную команду разработчиков и иметь гарантированные (ну, почти) сроки выполнения и неплохую прогнозируемость по срокам.
Другое дело, если команда разработчиков небольшая и важно иметь высокую эффективность работы, в этом случае, если руководство доверяет тимлиду, то команда может работать без оценки сроков в своей нормальной производительности. Т.е. есть определенный объем работ и есть команда разработчиков, которые эту работу последовательно выполняют.
За то чтобы все работали в нормальном режиме следит сам тимлид, он может примерно оценить сроки выполнения задачи каждым разработчиком, да и авторитет у него должен быть, чтобы сами разработчики не пытались отлынивать. В этом режиме задачи будут выполнены в минимальные сроки (без перенапряжения команды), если попадется сложная задача, то или будет попытка ее упростить (по согласованию с заказчиком) или на нее будет потрачено все необходимое время. Тимлид также следит, за качеством кода и за тем чтобы кто-то не занялся оверинжинирингом.
Если начальник свой человек и понимает, что программирование — не укладка кирпичей, а скорее, бурение, то да, при доверительных отношениях все делается очень быстро и эффективно. Но это только в случае, если есть доверительные отношение и я могу рассчитывать на понимание именно как специалиста. Потому что дело здесь даже не в прикрытии жопы, а в том, что есть разница между «затянул по дурости или неопытности» и «наткнулся на реальную проблему, потратил время, но решил». Если начальник не в состоянии оценить разницу, мне работать с ним доверительно будет трудно.
Вы вот все серьёзно?
То есть тут многие не понимают почему "делать день, но готово будет через месяц?".
"эффективный менеджер" из комментариев выше даже не смог отличить трудозатраты от сроков.
Вот поэтому в большинстве компаниях и болото.
Работа обычно состоит из суммы трудозатрат (векторов).
Причем разнонаправленных. И вполне может оказаться, что фича которая делается за пару часов, будет сделана только за месяц.
Во-вторых, трудозатраты и сроки — это два представления одного и того же показателя, временной шкалы проекта. Абсолютное значение на ней, это сроки. Расстояние между значениями (при необходимости помноженное на количество участвующих в задаче людей) — трудозатраты. Только и всего.
Т.к. они имеют направленность (время) и размерность (скаляр) ;-)
Сроки это точка (конкретная дата) их сдвинуть проблематично.
И сроки можно сказать не складываются.
Например фича А будет готова к дате D1, а фича B будет готова готова к дате D2 (D1 < D2).
Т.о. обе фичи будут готовы к D2!
А вот если говорить в трудозатратах, то фича A делается N1 часов, а фича B делается N2 часов.
Когда будет готовы обе фичи (дата)?
Фиг его знает. Но точно не к D(ткущая дата) + N1 + N2.
Тут надо учитывать рабочее время (не более 8 часов), выходные и праздничные дни, разные второстепенные факторы (совещания, болезнь, настроение и прочее).
Поэтому с программистов нужно спрашивать не срок, а время сколько в часах он сделает фичу (трудозатраты).
А дальше идет сложная математика с элементами теории вероятности с выставлением сроков (даты), когда обе фичи будут сделаны.
Вот вы только что подтвердили, что трудозатраты это вектор.
Т.к. они имеют направленность (время) и размерность (скаляр) ;-)
По вашей логике, так и температура — вектор, и вес — тоже вектор. Т.к. температура имеет направленность (ползет, зараза, куда-то) и размерность (градусы). И вес, так же как и время, имеет направленность (всё время вниз падает, а если пнуть, то влево полетит), и размерность :)
Время — это скалярная величина, у неё направленность появится только тогда, когда вы изобретёте машину времени или хотя бы сможете находить червоточины в пространственно-временном континууме.
Фиг его знает. Но точно не к D(ткущая дата) + N1 + N2.
Вы не путайте точность планирования и методику планирования. Фичи будут точно готовы к D(ткущая дата) + N1 + N2, при условии, что N1 и N2 — реальные трудозатраты, а проект выполняется, а не лежит на полке.
Если у вас нет реальных трудозатрат, а есть оценочные, то в вашем плане точно так же оценочный срок будет N1 + N2.
Насчет веса… Вес имеет смысл только при существовании ускорения.
Т.е. он изменяется в зависимости от. Т.е. вес это сумма векторов ускорения.
N1 и N2 это реальные трудозатраты.
Т.е. если берем программиста стоим над душой за секундомером и мерим сколько времени он затратил на создание фичь.
Считая на «подумать», набора кода и т.д.
Но пока программисты плохо заганяются в потогонную систему.
Поэтому нельзя сложить N1+N2 и получить время когда будут готовы обе фичи.
В лучшем нижнюю границу.
По вашей логике, так и температура — вектор, и вес — тоже вектор
Э-э-э… Вес-то — действительно вектор. Я ещё из школьного курса физики помню что «Вес — это сила, с которой тело действует на опору или подвес». А сила — величина векторная.
А срывы сроков, изменение загрузки исполнителя и т.д. — это всё уже факт, выполнение проекта. При таком форс-мажоре вы вносите изменения в текущий график, пересчитываете его. Или не вносите, если подробное проектное управление вам не нужно. Но это совершенно другой процесс и другие цифры.
У вас была очень занимательная беседа ниже)) (или выше^^)
Я возможно тоже не сильно правильно понял посыл статьи, но вот комментарий более менее совпадает с моим виденьем вопроса, и в 80% случаев моя команда сдает спринт\проект вовремя. Оставшиеся 20% это как раз совершенно не типичные задачи, но и тут изза того что сам разработчик не полностью участвует в сроках, мы заранее договариваемся о сдвигание сроков или уменьшение "фич листа".
И вот мои менеджеры этого не понимают, поэтому если менеджерить приходится им, а не мне, то все летит к Летову. В большенстве случаев начинает тратится половина времени только на оценки, согласования и тд и тп.
Сейчас руковожу отделом тестирования из 150 человек в Контуре
Если не секрет, то сколько в Контуре разработчиков?
Привет, я из Контура :) Сейчас у нас примерно 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 в России. Если узнаю, что у кого-нибудь больше — сильно удивлюсь :)
Недавно «Мой круг» ещё что-то писал о нас на Хабре. Или я могу что-нибудь рассказать, если интересно.
1) Изменения в немалом числе проектов Контура нередко завязаны на изменения законодательства, читай у нас есть «внешние дедлайны». И оценивать сроки, чтобы понять «начать переделывать вот эту отчётность сейчас или через месяц» необходимо.
2) Сроки мы конечно же оцениваем, регулярно и активно. Но
а) это оценка поверхностная, вида «X дней / недель», мы не тратим на оцени недели, дни или часы
б) оценка каждым специалистом ведёт только в своей области компетенции — разработчик оценивает время разработки, тестер — тестрования и так далее. А вот задача менеджера разработки — свести эти оценки воедино и помочь с планированием деятельности проекта в целом. От остальных оценки сроков всей задачи в Контуре не требуют.
в) оценка нужна для планирования деятельности других людей, чтобы отвечать на вопросы вида «пора начинать рисовать баннеры с рекламой для этой фичи и писать текст в блог?»
г) оценка нужна для расстановки приоритет между задачами (тут задача на 2 дня, тут на 2 недели, такой то разработчик через неделю в отпуск, какую задачу ему дать, а такой то заканчивает такую то задачу когда то)
д) когда задача уже взята в работу — делается поверхностая декомпозиция, и там может быть пересмотр сроков или даже откладывания задачи и взятие в работу другую
3) Типовых задач в работе таки довольно много, и там оценки промахиваются не так уже сильно — и это не «обман и работа на расслабоне», а банальный опыт
4) В чисто исследовательских задачах нет сроков со стороны разработчика — но есть срок вида «сколько максимум мы можем выделить на эту деятельность учитывая такие то факторы». И тут от задачи зависит, разработчик может и до упора это время потратить, и до конца срока справиться, и даже до начала сказать «этого точно не хватит, давайте в исследование чего-нибудь другое возьмём»
5) И просто в отрыве — небольшой момент из практики: каждое утро на летучке отмечать, сколько уже часов потратил на такую то подзадачу такой то задачи. Если «оценка» и «затраты» начались расходиться — то сразу видно, что пора разбираться, может быть разработчику нужна помощь, или там возникли объективные трудности и нам нужно перепланировать другую деятельность. Без предварительной примерной оценки есть шанс «закопаться», и этот момент может пройти не замеченным столь явно. А вот «я тут потратил на задачу 15 часов из 5 запланированных» замечается сразу ;-)
А их, оказывается, намного больше…
в целом, статья по стилю и содержанию, вредна для бренда
Привет, я из Контура. Могу о-о-очень кратко рассказать, что знаю сам: у Максима Wolonter в продуктовой команде 30 человек, из них половина — разработчики. Работают по канбаноподобному процессу. Продукту несколько лет, но идёт бурный рост, так что задачи разные.
И каким нелепым и угнетающим занятием является простановка срока исполнения задачи.
https://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.
Почти всю статью автор рассказывает, что оценка сроков не нужна
Затем заявляет «Оценка сроков, если не вредна, то по крайней мере бессмысленна. А вот оценка трудозатрат — довольно полезное упражнение»
Я всю жизнь думал что оценка срока это и есть оценка трудозатрат, то есть сколько тебе нужно времени, чтобы запилить эту фичу?
Я вот вообще в шоке, в чем отличие то принципиальное? Почему одно не нужно, а другое очень полезно?
Вы можете установить любой срок и при этом с вероятностью стремящейся к еденице можете быть уверены что к этому сроку фича не будет сделана.
С трудозатратами наоборот, есть не нулевая вероятность, что фича будет сделана за меньшее время.
Если задача получается больше 1 рабочего дня, почти всегда она может и должна быть декомпозирована, оценена на уровне подзадач и, очень часто, еще и распараллелена.
Оценка каждой задачи — необходимый источник данных, чтобы назвать конечный срок, но никто в здравом уме не суммирует их механически. И команда никогда не подпишется под такой оценкой. И автор поста тоже пишет, что так делают только неадекватные менеджеры.
Разумеется, при этом команда может обосновать эти сроки заказчику, либо уже заслужила его доверие.
Если заказчик так работать не может, то все скатывается к сценариям, описанным автором поста, с соответствующим отношением к неадекватному заказчику.
Спринт обычный, фиксированный. Сроки оцениваются не для спринта, а для фич, которые бывают разными и могут делаться в несколько спринтов или просто уезжать вперед из-за нехватки времени в текущем или следующем.
То, что команда сама выполняет функции менеджера — дает огромный буст к мотивации и чувство драйва. То есть, счастливы и заказчики, и команда. Именно это невозможно при подходе, описанном автором оригинального поста.
Основная фишка была очень банальна, но давала высокий результат.Сотрудники могли выполнять работу когда им вздумается и никто в течении этого времени у них ничего не спрашивал и не требовал предварительный результат.Члены команды приходили иногда в воскресенье после обеда на работу, кто любил поспать мог работать с 13-14 и сидел до поздней ночи просто потому что ему так было лучше, а иногда и вообще не приходил так как вчера перебрал в пабе))Результат всегда был отличный и очень креативный. Если же дедлайн был близок, то никто не поливал грязью начальство, так как оно всегда виновато по определению, а просто пахал круглые сутки и был счастлив.
Погорив по душам с некоторыми этими сотрудниками я для себя определил так:
— людям нравиться когда им доверяют и считают их профессионалами.
— всем нравиться самостоятельность ( хотя она мнимая, но все же...). Ты вроде как сам себе начальник.
— возможность решать личные вопросы и не быть привязанным к рабочему времени.
Думаю некоторые из этих практик можно применять и в разработке, хотя и с большой осторожностью. Но там где нужен креатив, а не конвейер по-другому очень сложно. Особенно долгосрочно.
Как правило, ответом на вопрос «успеем ли мы к заданному сроку» является аналитика и MVP, качественная инфраструктура разработки и размер технического долга, а именно сложность проведения рефакторинга и наличие автоматических тестов на регрессию.
Сколько тысяч автоматических тестов на поддержке сейчас? И сколько человек из 150 заняты этой задачей? Мигают ли они, сколько там технического долга?
Это вопросы с продолжением. Продолжение в том, что инфраструктура и автотесты не даются бесплатно. Если они работают всегда, без долгов, возможно, кто-то из команды с работы не выходит
Здорово, что тесты не мигают. Важна история, что тестов много и на их поддержку уходит много времени. Как понимаю, это основная работа, значит команда — команда автоматизаторов. Редкая.
Также важны люди. Фактором успеха может быть конкретная команда из 6-ти человек, которая достаточно квалифицирована, слажена, стабильна, дружна. И в такой команде любой метод работы, особенно тот, где полное доверие и нет микроменеджмента даст просто прекрасный результат.
И если две такие команды встретятся и начнут обсуждать, что важнее в их работе. Одна будет говорить: «У нас нет сроков», — а вторая отвечать: «А у нас есть сроки, и всё просто замечательно». И обе правду говорят :). Значит критерий оценки не самый точный.
Работаю в команде, про которую ещё статей не написано. Команды гибкие. Ближе всего к команде из трёх человек. Мы просто делаем работу, делаем хорошо. Иногда мы обсуждаем сроки и приоритеты. Но это в те моменты, когда работы свалилось по 10+ задач на человека. А когда горизонт планирования 1-2 задачи на человека, а все остальные пока не важны, то обсуждения приоритетов нет.
Оценка сроков на разработку и тестирование задачи (не нужна)