Comments 186
Всё это хорошая теория, но она несколько расходится с жизненными потребностями. Оценка сроков нужна не для того, чтобы задолбать программиста и снизить его производительность. Она нужна для того, чтобы планировать бюджеты, чтобы давать ориентиры смежным подразделениям и организациям и т.д. Даже если она не будет точной даже на 50%, это все равно нормально, это просто веха, по которой будет идти проект. И абсолютно нормально, что в процессе работы оно будет уточняться и корректироваться в соответствии с реальностью. И абсолютно нормально, что кто-то её завышает. А другие её наоборот, занижают. Опытный менеджер это сведёт к более-менее реальным срокам. А неопытный, по крайней мере, на этом будет учиться.
Точность в плюс-минус 50% это трехкратная разница, о каком планировании может идти речь?
Ну так а куда от этого деться? В любом проекте могут быть такие задачи, по которым большая ошибка с планированием. Суммарно, кстати, они обычно друг друга частично компенсируют, так что итоговая погрешность наоборот, уменьшается. Главное, чтобы при планировании не было систематического занижения или наоборот, завышения.
Мы тоже не шашкой махали, думали, пробовали. Если совсем насмерть сократить мысль статьи, то между «с оценкой сроков» и «без оценки сроков, но вдвое быстрее, чем если бы оценивали» мы — в продуктовой разработке — выбрали второе. Самая важная часть статьи, на мой взгляд, после слов «серия упражнений в разработке».
Не знаю, может быть, это особенность именно вашей команды. Я не могу сказать по своему опыту и опыту коллег, что оценка сроков так существенно влияет на производительность, или отнимает много времени сама по себе.
С увеличением сложности проекта и увеличением роли R&D — адекватность оценки сроков снижается до полной бесполезности. Если проекты типовые — и процесс налажен — оценивать можно.
С увеличением сложности проекта и увеличением роли R&D — адекватность оценки сроков снижается до полной бесполезности
Нередко да. Но без хоть какой оценки сроков и стоимости вам проект все равно никто не профинансирует.
Это следствие распространенной ментальной ловушки.
Да, никто не профинансирует. Ну и называются в итоге сроке от балды.
Вы слишком категоричны. Часто выделяют бюджет на команду а со сроками разбираются на уровне менеджмента. В продуктовой разработке именно этот подход позволяет более-менее адекватно планировать расходы.
Да ну, почти во всех таких случаях есть хотя бы предварительная оценка сроков и как следствие стоимости. Как вы можете браться за проект, если у вас нет прогноза, сколько он будет стоить, и сколько денег принесёт? Просто так, «вот вам зарплата, а теперь подумаем, чем бы вас занять», поступают только в очень уж богатых компаниях, которые сидят на денежной трубе из комиссионных доходов за счет облаков или процентов от чужих продаж.
Большинство стартапов с треском провалилось. И у большинства был красивый график роста доходности и срок окупаемости на старте. Большинство инвесторов, с высшим экономическим образованием и портфелем успешных проектов, понимающе кивало глядя на эти графики. Что это говорит нам о предварительных оценках? Что это говорит нам о окупаемости инвестиций в сами предварительные оценки? Тут хорошо подходит аналогия с предсказанием погоды: на 1-2 дня вы можете предсказать ее достаточно точно. На пару недель — уже врядли. Однако, вы четко знаете, что зимой холодно а летом — тепло. Именно это знание, но уже в конкретной предметной области и требуется менеджеру проекта, о чем и пишет автор статьи. Оно приходит с опытом наблюдений и не зависит от магических ритуалов в виде проставления эстимейтов задачам со стороны разработчиков.
Это вообще ничего не говорит. Бизнес — это всегда риск. Те, кто успешен, рисуют такие же графики и делают такие же оценки. Оценка вам хотя бы даст ответ на изначальный вопрос: стоит ли вообще рисковать.
То есть то, что рисование графиков никак не коррелирует с итоговым результатом вообще ничего нам не говорит? Ну ок.
А что вас тут смущает? Может, график был хорошим, а плохим был программист, дизайнер или маркетолог. Или конкуренты были быстрее, или инвестиций хватило только для старта, а следующий раунд не получился. Или проект изначально был венчурным, и никто не обещал успеха с высокой вероятностью. Есть стопицот причин, почему стартапы не взлетают, и ошибка планирования тут далеко не главная. И уж точно не повод от планирования отказываться, даже если кто-то планирует неправильно. В любой работе бывает хороший результат, бывает лажа.
Как график может быть хорошим, если он не отражает плохого программиста и стопицот других рисков? Риск-менеджмент не должен быть частью планирования? И кто вообще говорит, что от планирования нужно отказываться? Речь идёт о том, что манки-бизнес — это НЕ планирование. Это лишь способ кормить себя и инвесторов иллюзиями.
Риск-менеджмент не должен быть частью планирования?
Риск менеджмент — это не про кадровый подбор. Если у вас специалисты оказались не специалистами, это не уже риск, а жопа проекту.
Речь идёт о том, что манки-бизнес — это НЕ планирование.
Я уже не знаю, о чем идёт речь, если честно. Мой изначальный тезис, с которым вы спорили, был о том, что планы необходимы для определения необходимости финансирования проекта. Когда это вдруг переросло в обсуждение манки-бизнеса, непонятно. Я не писал нигде конкретно про изначально тухлые проекты, создаваемые только для съема бабла (которые по-хорошему не нужны вообще, ни с планированием, ни без).
Как вы посчитали, что оно не кореллирует, какие данные вы использовали?
Сложность проекта чаще растёт из-за накопленного технического долга, а не из-за 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, возможно просто не сталкивались с проектами на старте которых бывает вопросов больше чем ответов но в целом все участники согласны, что все выполнимо в некоей «среднесрочной перспективе».
По моему, вы просто не совсем понимаете что такое R&D, возможно просто не сталкивались с проектами на старте которых бывает вопросов больше чем ответов но в целом все участники согласны, что все выполнимо в некоей «среднесрочной перспективе».
Вот уже 8 лет только с проектами такого рода и работаю. Для крупных проектов, которые длятся много лет, оценка сроков выстраивается по принципу: какой функционал можно успеть реализовать в ближайшие 3 месяца, месяц, 2 недели.
Само собой, никто не оценивает подобный проект целиком, хотя бы потому что требования к нему поменяются 100 раз в процессе разработки и дальнейшей эксплуатации. Однако ваш начальный тезис "С увеличением сложности проекта и увеличением роли R&D — адекватность оценки сроков снижается до полной бесполезности" в корне неверен. Полезные оценки можно давать для проектов любой сложности. Да, это сложнее, чем для типовых. Да, нужен навык и хорошее понимание как предметной области проекта, так и возможностей членов команды разработки. Но тем не менее, это вполне возможно.
Вы начинаете юлить. То есть, мы, конечно, знаем, что условная операция «открытие крышки ноутбука» занимает 2 секунды, а за месяц мы ее откроем 24 раза. Вот и часть эстимейтов у нас в кармане, да? А дальше начинается:
Ну так об этом я и пишу изначально. Разве нет? А вы утверждаете, что оцениваете такое с точностью 20% в обе стороны.
Само собой, никто не оценивает подобный проект целиком
Ну так об этом я и пишу изначально. Разве нет? А вы утверждаете, что оцениваете такое с точностью 20% в обе стороны.
Если вы не заметили статья про "оценку сроков на разработку и тестирование задач". Про оценку проектов целиком тут никто не говорил. Оценка проекта — это тупо оксюморон, потому что нормальные проекты живут и развиваются, а не сдаются "под ключ".
Вы же пишете, что нельзя оценить ничего с приемлемой точностью на проектах, требующих R&D. И это неверно.
Всё-таки не понятно, как у вас без оценок бюджет рассчитывают.
Поражает насколько порой тратится усилий на процесс оценки, при этом вообще не принимая во внимания _что_ мы оцениваем. Если в задаче заложена неопределенность (а если ничего не предпринимать то она всегда там заложена), то неважно какой метод оценки вы возьмете — все равно будете пролетать и на 50 и на 100, и на 1000%. Только снижением неопределенности можно внести уверенную стабильность в сроки выполнения работ.
Точность в плюс-минус 50% это трехкратная разница, о каком планировании может идти речь?
Не все начальники/заказчики разбираются в ИТ. Приведу почти реальный пример с фриланса:
Спрашивает меня заказчик интернет-магазина:
— А сколько займёт времени сделать, чтобы пользователь вводит в поиск, например, «желтый холодильник» и ему выдаются все желтые холодильники? (Часто такое ещё спрашивают в форме «Можно ли» или «Сколько будет стоить»)
И вот он реально не знает — может, там просто галочку в нужном месте поставить. И когда я называю реальный план работ и сроки (какими бы примерными они ни были), у него сразу возникнет понимание, что ему это не нужно на данном этапе.
Плюс, в оценке сроков для нетиповых задач я всегда отвечаю в таком ключе:
«Выглядит, как задача на 2 недели. Более точно смогу сказать через 3 дня работы.»
То есть и примерный срок назвал, и не соврал (выглядит — факт), и не пообещал невозможного, и пообещал возможное. При работе с нормальным/опытным заказчиком, это было бы то же самое, что сказать просто «2 недели», но не все такие, и иногда приходится напоминать, откуда берутся эти ответы и что под ними подразумевается.
UFO just landed and posted this here
При планировании, где числа идут 10, 100 и 1000 разница в 3 раза это норма. Как вы сами написали задачи у нас одинаковые, статистически их можно оценить, но всегда есть подводные камни, поэтому +-50% это хорошо. Вы же чувствуете разницу для планирования где может быть 15 и 50 (10 и 100 +-50%). Ну и самое главное, оценку должен давать не разработчик (любой), а тот, у кого есть статистика по задачам (например тим-лид)
Автор верно отмечает разницу между оценкой трудозатрат и планом реализации.
Проблемы начинаются тогда, когда оценка трудозатрат автоматически становится дедлайном.
Оценки и планирование нужны хотя бы для того чтобы получить необходимые ресурсы для проекта.
Проблемы начинаются тогда, когда оценка трудозатрат автоматически становится дедлайном.
Оценки и планирование нужны хотя бы для того чтобы получить необходимые ресурсы для проекта.
На месте руководителей Контура я бы поставил вопрос о снятии автора с должности за профнепригодность :)
Когда в нормальной команде от разработчика (тестировщика) требуют оценки сроков выполнения задачи, от него ждут двух вещей:
1. Тщательного осознания задачи, ее декомпозиции при необходимости и описания будущего решения (плана тестирования) в тикете. Такой детальный разбор задачи на этапе планирования делается не индивидуально, а в команде. Он позволяет не делать фигни и заодно получить реалистичную оценку сроков выполнения (которая фиксируется в том же тикете).
2. Взятия на себя ответственности за заявленные сроки. Когда задача уже разобрана и решение понятно описано, команда и отдельный разработчик с открытыми глазами берет на себя ответственность за сроки. Это порождает совсем другое отношение к работе, чем спускаемые сверху непонятные, а иногда и безумные сроки от «менеджеров».
Потом из таких качественно предобработанных задач легко собираются управляемые итерации скрама.
Именно такие граждане сначала не требуют от разработчиков оценки задач, перевешивают ее на менеджеров, у которых должны быть совсем другие компетенции, а потом жалуются, что у них «скрам не работает».
Пишу как человек, полтора года руливший невероятно бодрой командой разработки из бывших сотрудников Контура, которая с этим подходом запилила качественный продукт и всегда соблюдала сроки поставки. Не сдержался :)
Когда в нормальной команде от разработчика (тестировщика) требуют оценки сроков выполнения задачи, от него ждут двух вещей:
1. Тщательного осознания задачи, ее декомпозиции при необходимости и описания будущего решения (плана тестирования) в тикете. Такой детальный разбор задачи на этапе планирования делается не индивидуально, а в команде. Он позволяет не делать фигни и заодно получить реалистичную оценку сроков выполнения (которая фиксируется в том же тикете).
2. Взятия на себя ответственности за заявленные сроки. Когда задача уже разобрана и решение понятно описано, команда и отдельный разработчик с открытыми глазами берет на себя ответственность за сроки. Это порождает совсем другое отношение к работе, чем спускаемые сверху непонятные, а иногда и безумные сроки от «менеджеров».
Потом из таких качественно предобработанных задач легко собираются управляемые итерации скрама.
Именно такие граждане сначала не требуют от разработчиков оценки задач, перевешивают ее на менеджеров, у которых должны быть совсем другие компетенции, а потом жалуются, что у них «скрам не работает».
Пишу как человек, полтора года руливший невероятно бодрой командой разработки из бывших сотрудников Контура, которая с этим подходом запилила качественный продукт и всегда соблюдала сроки поставки. Не сдержался :)
Кажется, автор разделяет понятия сроков и времени выполнения задачи, не очень понял в чем вы видите противоречия?
Если бы автор работал в заказной разработке, где бюджет может быть важнее сроков, а время выполнения задачи переводится не только в сроки, но и в деньги, это противопоставление имело бы смысл. Иногда заказчику выгоднее делать дольше, но дешевле.
Но автора работает в продуктовой разработке, где единственная цель определения временных затрат на задачу — оценить сроки выпуска очередной функциональности. Речь всегда идет об управлении сроками.
Поэтому противопоставление оценки сроков и оценки трудозатрат в часах — это неловкая манипуляция со стороны автора.
Но автора работает в продуктовой разработке, где единственная цель определения временных затрат на задачу — оценить сроки выпуска очередной функциональности. Речь всегда идет об управлении сроками.
Поэтому противопоставление оценки сроков и оценки трудозатрат в часах — это неловкая манипуляция со стороны автора.
Но автора работает в продуктовой разработке, где единственная цель определения временных затрат на задачу — оценить сроки выпуска очередной функциональности. Речь всегда идет об управлении сроками.
И автор утверждает — что оценивать сроки нет никакого смысла. Потому что как только задача начинает отличается от стандартной, начинается гадание на кофейной гуще, когда оценка сильно накручивается, в нее закладываются все возможные риски, а потом еще и ко всему этому совершается ошибка "техасского снайпера".
В продуктовой среде, мне казалось, очень часто сроки ставятся или свыше к какой-то дате, или "чем раньше, тем лучше".
Без оценки сроков бизнес просто умрет. Попробуйте, например, сказать маркетологам, что вы понятия не имеете, к какому сроку нужно подготовить и запустить многомиллионную рекламную кампанию или пообещать выпустить фичу к текущему пику отчетности, а выпустить через неделю после этого :)
Автор говорит совсем другое — сроки должны оценивать не специалисты, которые своими руками будут делать работу, а какой-то «менеджер» на белом коне, который, даже будучи в прошлом техническим специалистом, конкретных деталей реализации и многотонных подводных камней [уже] не знает.
И главная претензия к автору в том, что он как руководитель целого, по сути, направления, хочет полностью снять ответственность за сроки поставки с команды, лишив ее, пожалуй, самого главного мотивирующего фактора — commitment'а, личной ответственности и участия в жизни продукта.
Автор говорит совсем другое — сроки должны оценивать не специалисты, которые своими руками будут делать работу, а какой-то «менеджер» на белом коне, который, даже будучи в прошлом техническим специалистом, конкретных деталей реализации и многотонных подводных камней [уже] не знает.
И главная претензия к автору в том, что он как руководитель целого, по сути, направления, хочет полностью снять ответственность за сроки поставки с команды, лишив ее, пожалуй, самого главного мотивирующего фактора — commitment'а, личной ответственности и участия в жизни продукта.
Без оценки сроков бизнес просто умрет.
Особенно без оценки сроков на "поменяй тестовку". Мне кажется, у довольно большого количества задач дедлайн, к которому они должны быть реально сделаны — очень и очень мягкий.
А если вы говорите про какие-то крупные "проекты" в духе переделки сайта или создания новой сложной фичи, то обычно дедлайны спускают сверху, как мне казалось.
Если вы не успеете сделать «до конца недели» всего одну из десятка задач «поменяй текстовку» просто потому, что плохо спланировались, вы можете запросто слить рекламный бюджет в несколько своих месячных зарплат просто потому, что дорогой лид пришел на страницу, где он не увидел отражения своей потребности. И ушел :)
В крупных проектах сроки могут сколько угодно спускаться сверху, но физику не обманешь и бизнесу лучше узнать горькую правду о том, что в эти сроки можно сделать только 1/3 требуемого до того, как он подпишет контракт с серьезными неустойками за срыв сроков)
В крупных проектах сроки могут сколько угодно спускаться сверху, но физику не обманешь и бизнесу лучше узнать горькую правду о том, что в эти сроки можно сделать только 1/3 требуемого до того, как он подпишет контракт с серьезными неустойками за срыв сроков)
Автор говорит совсем другое — сроки должны оценивать не специалисты, которые своими руками будут делать работу, а какой-то «менеджер» на белом коне, который, даже будучи в прошлом техническим специалистом, конкретных деталей реализации и многотонных подводных камней [уже] не знает.
И главная претензия к автору в том, что он как руководитель целого, по сути, направления, хочет полностью снять ответственность за сроки поставки с команды, лишив ее, пожалуй, самого главного мотивирующего фактора — commitment'а, личной ответственности и участия в жизни продукта.
Я прочитал статью несколько раз, но категорически не вижу, где Wolonter утверждает хоть что-то из цитаты. Александр, как же так? :)
Так вот же, Игорь! :)
Если команда выполняет эти упражнения, а менеджер квалифицирован, то для ответа заказчикам ему не нужно требовать от исполнителей назвать срок.
Мне очень неудобно такое говорить, но сразу после этой фразы в статье идут три абзаца, которые расставляют точки над ijk.
В следующих трех абзацах абсолютно искусственно противопоставляются вещи, которые для разработчика с точки зрения оценки не отличаются: «я потрачу на эту задачу день» превращается в «эта задача будет готова через день» в тот момент, когда разработчик начинает над ней работать.
Автор ниоткуда вытаскивает мысль, что, якобы, разработчик будет закладывать себе резерв времени если его спросить о конкретном времени завершения (что верно), и не будет, если его просто попросить оценить количество часов, которые ему потребуются с момента старта работы над задачей (что неверно).
Потому что разработчик знает, что команда будет одинаково его порицать за безответственность при любом из способов срыва сроков :)
Автор ниоткуда вытаскивает мысль, что, якобы, разработчик будет закладывать себе резерв времени если его спросить о конкретном времени завершения (что верно), и не будет, если его просто попросить оценить количество часов, которые ему потребуются с момента старта работы над задачей (что неверно).
Потому что разработчик знает, что команда будет одинаково его порицать за безответственность при любом из способов срыва сроков :)
Автор совсем не такой, как вы описываете… Автор специально привел ссылки на источники в начале, где есть объяснения. В частности перезакладывания.
Кажется, я чем то задел ваши эмоции и этим вызвал кучу толкований меня и достаточно резких высказываний.
Думаю, конструктивно не получится, а жаль.
Автор оправдывает атмосферу расслабленности и вялости, и пропагандирует подход, не раз лишавший активных разработчиков мотивации у меня на глазах. А я очень страдаю, когда такое вижу :)
Возможно, именно из-за такого подхода Контур за последние 5+ лет не выпустил ни одного заметного нового продукта при таком безумном количестве разработчиков (и 150(!) тестировщиках) ;(
Возможно, именно из-за такого подхода Контур за последние 5+ лет не выпустил ни одного заметного нового продукта при таком безумном количестве разработчиков (и 150(!) тестировщиках) ;(
Автор оправдывает атмосферу расслабленности и вялости
А я видел, как демотивирует и замедляет разработку ваш подход и тоже страдаю, когда вижу спринтеров с горящими жопамии, не умеющими играть дольше, чем в год.
Александр, наш спор на уровне мировоззрений и ни к чему не приведет. Аргументы вида «вот оно так потому что вы демотивируете!»
Вы будете оценивать сроки и считать свои команды крутыми и успешными. Я оценивать сроки не буду и тоже буду считать свои команды крутыми и успешными. Чистый эксперимент поставить не получится. Зрители повеселятся.
А контур, конечно да, ничего не создал и ничего не запустил и вообще на ладан дышит. Скорее всего из-за такого подхода. Всё плохо.
Ребята у вас обоих сильные аргументы! Спасибо за интересную дискуссию, мне в разные периоды жизни нравятся перегибы в разные стороны)) И для компаний/подразделений бывает подходят режимы «завод с налаженными процесами» или «драйв когда все бегут — разработчики пишут код как ошпаренные»)))
Аааа! Только сейчас увидел.
Когда у ваших разработчиков во время спринта горят жопы, значит вы что-то совсем не то с ними делаете!
У разработчиков в состоянии драйва должны гореть глаза! Глаза!
Когда у ваших разработчиков во время спринта горят жопы, значит вы что-то совсем не то с ними делаете!
У разработчиков в состоянии драйва должны гореть глаза! Глаза!
А контур, конечно да, ничего не создал и ничего не запустил
Уже лет 5 ждем API для Контур.Бухгалтерии — теперь понятно почему
Ну вот у нас сейчас требуют оценку трудозатрат по разработке. Никаких порицаний на тему сроков или неверных оценок нет (они если есть, то на тему общей производительности). Менеджмент сам составляет календарные планы, в том числе планы взаимодействия R&D подразделения с другими (обучение поддержки прежде всего — у нас без неё никуда, анонсы для клиентов и т. п.)
"Без оценки сроков бизнес просто умрет."
Что же вы пишете про все бизнесы сразу? Жил, живет и будет жить бизнес и без оценки сроков. И речь не только про контур.
Дальше вы делаете ряд заявлений и претензий, отвечая на которые я буду доказывать, что я не верблюд.
Ответственность с разработки я снимать не предлагаю. Предлагаю перестать обманывать. Себя в первую очередь.
А вы прочитали статью или только заголовок? Может как-то более предметно и аргументированно пообщаемся?
Максим, я прочитал статью и не на один раз. И мы можем предметно и аргументированно пообщаться, хотя я и очень зол на вас за такое отношение к мотивации команд в моем все еще любимом Контуре :)
Если суммировать:
1. Противопоставление сроков поставки и оценки сложности задач в часах — абсолютно искусственное именно в продуктовой разработке. Это изоморфные вещи. В заказной разработке человекочасы переводятся еще и в деньги, но в вашем случае это чистая манипуляция. Вместо того, чтобы спросить: «Ты же обещал к четвергу, а сегодня пятница. Где?!» — владелец продукта спросит: «Ты же обещал сделать за 9.5 календарных часов и начал позавчера. Где?!».
2. Завышение оценок специалистами. Такая проблема есть, но решается она не отказом от оценки, а методами коллективной оценки, когда завышенная оценка не проходит дизайн-ревью, и ежедневных летучек, которые в нормально мотивированной команде не дают зря проедать временной бюджет.
3. Негативное влияние оценки на производительность. Если я правильно помню, ДеМарко писал об этом в контексте травли команд. Правильная оценка задач, как вы и сами пишете ниже, позволяет достаточно детализировать задачу, привлечь коллективное знание всей команды, чтобы не допустить большей части возможных дорогостоящих ошибок, которые один человек допустил бы, не допустить чрезмерного раздувания оценки — и получить достаточно надежные оценки, чтобы с высокой точностью планировать выпуски.
4. Самое главное. Предлагаемый вами подход убивает мотивацию сотрудников, потому что убивает вовлеченность в жизнь своего продукта и в принятие решений. Чувство сопричастности судьбе своего продукта и чувство личной ответственности за качество и за собственноручную оценку сроков — важнейшие мотиваторы разработчиков. Когда работа разработчика превращается в смену у конвеера с тасками, а сверху на него валятся взятые с потолка кем-то сроки, даже самая мотивированная команда необратимо превращается в болото. Что вы, к сожалению, вероятно, нередко видите вокруг :)
Если суммировать:
1. Противопоставление сроков поставки и оценки сложности задач в часах — абсолютно искусственное именно в продуктовой разработке. Это изоморфные вещи. В заказной разработке человекочасы переводятся еще и в деньги, но в вашем случае это чистая манипуляция. Вместо того, чтобы спросить: «Ты же обещал к четвергу, а сегодня пятница. Где?!» — владелец продукта спросит: «Ты же обещал сделать за 9.5 календарных часов и начал позавчера. Где?!».
2. Завышение оценок специалистами. Такая проблема есть, но решается она не отказом от оценки, а методами коллективной оценки, когда завышенная оценка не проходит дизайн-ревью, и ежедневных летучек, которые в нормально мотивированной команде не дают зря проедать временной бюджет.
3. Негативное влияние оценки на производительность. Если я правильно помню, ДеМарко писал об этом в контексте травли команд. Правильная оценка задач, как вы и сами пишете ниже, позволяет достаточно детализировать задачу, привлечь коллективное знание всей команды, чтобы не допустить большей части возможных дорогостоящих ошибок, которые один человек допустил бы, не допустить чрезмерного раздувания оценки — и получить достаточно надежные оценки, чтобы с высокой точностью планировать выпуски.
4. Самое главное. Предлагаемый вами подход убивает мотивацию сотрудников, потому что убивает вовлеченность в жизнь своего продукта и в принятие решений. Чувство сопричастности судьбе своего продукта и чувство личной ответственности за качество и за собственноручную оценку сроков — важнейшие мотиваторы разработчиков. Когда работа разработчика превращается в смену у конвеера с тасками, а сверху на него валятся взятые с потолка кем-то сроки, даже самая мотивированная команда необратимо превращается в болото. Что вы, к сожалению, вероятно, нередко видите вокруг :)
Еще и еще раз. Я говорю о том, что нужно спрашивать не срок, а упражнения из списка. Они полезны. Срок ложь.
По поводу мотивации, убитой сроками оценки — и опять не так. В моей и не только команде с мотивацией все ок. И она не зависит от коммита в дату. Зачем вы безапелляционно обобщаете? Прямо как я в заголовке. А еще я знаю команды, демотивированные необходимостью играть в сроки.
И да. Контур я тоже люблю.
Ну вот я полтора года напряженной работы выдавал вместе с командой (а без команды и не смог бы) точные сроки на периоды от двухнедельной итерации до полугодового релиз-плана. И выдавал обоснованно и точно. А вы мне (и всем присутствующим) объясняете, что сроки — ложь :)
А откуда бизнесу брать реальные оценки сроков вы и вовсе тактично умалчиваете.
На практике из-за такого отношения к срокам почти десять лет может потребоваться, чтобы убрать баклажанный цвет с одной единственной страницы, если вы понимаете, о чем я ;(
А откуда бизнесу брать реальные оценки сроков вы и вовсе тактично умалчиваете.
На практике из-за такого отношения к срокам почти десять лет может потребоваться, чтобы убрать баклажанный цвет с одной единственной страницы, если вы понимаете, о чем я ;(
«Ты же обещал сделать за 9.5 календарных часов и начал позавчера. Где?!».
вот я тоже в статье увидел эту манипуляцию, хотелось бы услышать от вас ответ, нам показалось или вы неправильно выразились?
Вы описываете оценки, но не описываете понятие как трафик. Грамотный ПМ спокойно клиенту объяснит что такое трафик и куда идет дедлайн (хотелки клиента).
Манипуляцию (классическую для менеджмента в ИТ) я вижу в ваших вопросах. «Ты же обещал сделать за 9.5 часов и начал позавчера. Где?!» — это манипуляция, если я не обещал, а дал оценку своих трудозатрат. Вот из-за таких манипуляций и возникают завышения.
Давать оценки — профессиональный навык разработчика, а воспринимать их как обещания и порицать за неисполнение — неадекватность менеджмента. Оно может и работает на коротких дистанциях, когда разработчики, чтобы выполнить обещание добровольно и бесплатно перерабатывают, но при длительной работе или будете получать неадекватно завышенные сроки (разработчики будут закладывать в них риски, хотя риск-менеджменту их обычно не обучают, поэтому закладывание будет неадекватным), или людибудут демотивированы в ноль или даже минус.
Работа менеджера — взять оценку и заложив в неё риски ошибок оценщика («статистика показывает, что этот разработчик в 50% случаев работает над задачей на 90% времени больше, чем давал оценку — закладываем 45%») выдать наверх сроки (если сверху этого требуют).
Работа разработчика, тестировщика и т. п. — давать оценки (кроме всего прочего, конечно). Менеджмент должен поощрять точность оценок, мотивируя прокачку этого навыка, но именно точность, а не непревышение. «Ты дал неадекватно низкую оценку», а не «ты неадекватно превысил оценку». Плохой оценщик, а не плохой выполнятель обещаний.
Исключение навскидку — скрамообразные процессы, где выделенная роль менеджера отсутствует, и по сути вся команда выступает коллективным менеджером самой себя и даёт обязательства владельцу продукта за срок спринта выдать некоторый скоуп фич/багфиксов.
Давать оценки — профессиональный навык разработчика, а воспринимать их как обещания и порицать за неисполнение — неадекватность менеджмента. Оно может и работает на коротких дистанциях, когда разработчики, чтобы выполнить обещание добровольно и бесплатно перерабатывают, но при длительной работе или будете получать неадекватно завышенные сроки (разработчики будут закладывать в них риски, хотя риск-менеджменту их обычно не обучают, поэтому закладывание будет неадекватным), или людибудут демотивированы в ноль или даже минус.
Работа менеджера — взять оценку и заложив в неё риски ошибок оценщика («статистика показывает, что этот разработчик в 50% случаев работает над задачей на 90% времени больше, чем давал оценку — закладываем 45%») выдать наверх сроки (если сверху этого требуют).
Работа разработчика, тестировщика и т. п. — давать оценки (кроме всего прочего, конечно). Менеджмент должен поощрять точность оценок, мотивируя прокачку этого навыка, но именно точность, а не непревышение. «Ты дал неадекватно низкую оценку», а не «ты неадекватно превысил оценку». Плохой оценщик, а не плохой выполнятель обещаний.
Исключение навскидку — скрамообразные процессы, где выделенная роль менеджера отсутствует, и по сути вся команда выступает коллективным менеджером самой себя и даёт обязательства владельцу продукта за срок спринта выдать некоторый скоуп фич/багфиксов.
Это не манипуляция, а экономика:
Клиент завязался на обязательства Компании поставить фичу в срок, Компания завязалась на обязательство Разработчика выпустить эту фичу в срок. Разработчик не выдержал сроки, Клиент потерял деньги, Компания потеряла Клиента, Разработчик потерял работу.
Не надо считать разработчиков единороговыми понями в вакууме, их работа и их косяки имеют реальный экономический эффект, который прилетает к ним бумерангом так или иначе.
Проблема завышения сроков при этом действительно существует, и работа менеджера и руководства — найти такой баланс пряника и кнута, при котором система устойчиво работает.
Одним из лучших решений для создания такого непростого баланса как раз являются «скрамообразные процессы», которые позволяют и контролировать сроки, и не скатываться в завышение оценок, и сохранять хороший моральный климат.
Клиент завязался на обязательства Компании поставить фичу в срок, Компания завязалась на обязательство Разработчика выпустить эту фичу в срок. Разработчик не выдержал сроки, Клиент потерял деньги, Компания потеряла Клиента, Разработчик потерял работу.
Не надо считать разработчиков единороговыми понями в вакууме, их работа и их косяки имеют реальный экономический эффект, который прилетает к ним бумерангом так или иначе.
Проблема завышения сроков при этом действительно существует, и работа менеджера и руководства — найти такой баланс пряника и кнута, при котором система устойчиво работает.
Одним из лучших решений для создания такого непростого баланса как раз являются «скрамообразные процессы», которые позволяют и контролировать сроки, и не скатываться в завышение оценок, и сохранять хороший моральный климат.
Не предполагается по сути работы разработчика давать обязательства что-то выпустить в срок. Я бы даже сказал по сути почти любой работы. Экономический эффект, конечно, есть. Но разработчик работает по трудовому договору суть которого «ты работаешь, а мы платим деньги за отработанные часы, риски того, что что-то пойдёт не так мы берём на себя и прибыль от твоей работы тоже себе забираем». Если работа предполагает обязательства «я сделаю фичу не позже чем за две недели», то и оплата должна быть за фичу, а не за часы.
Умение оценивать сроки и укладываться в них — крайне востребованный навык на рынке труда.
Умение за еду выдавать код, продающийся на миллиарды — тоже крайне востребованный навык. Вот только есть маленькая проблемка… ;)
Реальность, данная нам в ощущениях, пока что в среднем такова, что если перекладывание ответственности на разработчика происходит (как правило в той самой форме «ты обещал, но не сделал», оценки рассматриваются как базис для дедлайнов) — то происходит оно абсолютно бесплатно для разработчика. Если какой-нибудь скрам или подобное начинает существенно добавлять задач на управление в жизнь разработчиков — это тоже происходит бесплатно для разработчиков. Вообще, в среднем рвение превратить разработчиков в псевдо-партнёров (когда они за продукт типа должны душой болеть, но получать при этом всё равно только зарплату за время) — встречается довольно часто. Угадайте, почему многим разработчикам такое рвение не нравится.
Реальность, данная нам в ощущениях, пока что в среднем такова, что если перекладывание ответственности на разработчика происходит (как правило в той самой форме «ты обещал, но не сделал», оценки рассматриваются как базис для дедлайнов) — то происходит оно абсолютно бесплатно для разработчика. Если какой-нибудь скрам или подобное начинает существенно добавлять задач на управление в жизнь разработчиков — это тоже происходит бесплатно для разработчиков. Вообще, в среднем рвение превратить разработчиков в псевдо-партнёров (когда они за продукт типа должны душой болеть, но получать при этом всё равно только зарплату за время) — встречается довольно часто. Угадайте, почему многим разработчикам такое рвение не нравится.
В 90% интересных мне вакансий не упоминается, а в 10% остальных предлагаются те же деньги, что и без него, а то и меньше. Это больше похоже на хотелку «на халяву», а не на востребованность. Или у вас есть другие сведения? На какую прибавку к рынку в процентах можно рассчитывать, обладая этими навыками? Особенно вторым. 100%, 200%? Хотя бы 50?
Думаю, с таким скиллом вы можете рассчитывать на +20% к рынку и/или действительно интересные задачи и драйв на работе. Но увы, компаний, которые умеют нанимать таких разработчиков и грамотно управлять ими и вправду, похоже, очень немного. Зато работа там — это будет experience of a lifetime.
Действительно интересные задачи — частично исследовательские, ну или хотя бы знакомые чисто в теории. Если уже делал на практике, то что интересного? А если не делал, то как вообще можешь дать достоверную оценку? Или дают исследовательские задачи вместо премии за точные оценки?
Думаю, с таким скиллом вы можете рассчитывать на +20% к рынку и/или действительно интересные задачи и драйв на работе. Но увы, компаний, которые умеют нанимать таких разработчиков и грамотно управлять ими и вправду, похоже, очень немного. Зато работа там — это будет experience of a lifetime.
С таким скиллом, войдя в число основателей компании, вы можете рассчитывать на много большее.
Как рядовому разработчику — ни на что рассчитывать сверх тут не приходится.
Другое дело, что более точные оценки дает/лучше разруливает ситуации по ошибкам оценок более квалифицированный разработчик. Который и получает больше.
Но платят ему +20% не столько и не только за скилл «точных оценок», а за всю совокупность профессиональных навыков.
Тщательного осознания задачи, ее декомпозиции при необходимости и описания будущего решения (плана тестирования) в тикете.
Вот это ценный кусок работы над задачей. Можно его и требовать. Даже без сроков, уже поможет задачке быстрее и качественнее зарелизиться.
Человеческий мозг разумно ленив. И требование дать оценку в часах — один из трюков, чтобы заставить его поверить, что все серьезно и надо поработать над решением, а не дать формальную отписку.
Манипуляции это неприятно и бесит.
Мой опыт: обычно попросить с человека план работ и поревьюить его, задать вопросы.
fix *обычно достаточно
Это из тех манипуляций, которые люди добровольно на себе практикуют :)
Ваш вариант, на самом деле, эквивалентен, потому что при наличии такого плана работ и дать оценку сроков — уже не проблема.
Ваш вариант, на самом деле, эквивалентен, потому что при наличии такого плана работ и дать оценку сроков — уже не проблема.
Вполне себе проблема. Учесть непредвиденное, заложитб запас в оценке… ну а далее Максим в статье написал, к чему это приводит.
Максим написал, к чему это приводит, если не управлять процессом оценки.
И не написал, что бывает, когда бизнес заложился на оценку взятую менеджером с потолка, а не от специалистов, которые глубоко в теме и хорошо подумали.
И еще Максим не написал, что бывает, когда эта «спотолочная» оценка спускается менеджером самим разработчикам, а они вполне обоснованно относятся к ней и к этому менеджеру по принципу «ты ковбой, ты и прыгай».
И не написал, что бывает, когда бизнес заложился на оценку взятую менеджером с потолка, а не от специалистов, которые глубоко в теме и хорошо подумали.
И еще Максим не написал, что бывает, когда эта «спотолочная» оценка спускается менеджером самим разработчикам, а они вполне обоснованно относятся к ней и к этому менеджеру по принципу «ты ковбой, ты и прыгай».
Так все же логично. Сроки по отдельным задачам не нужно оценивать ни исполнителям, ни менеджеру :)
Про задачи с дедлайнами мне близка эта мысль из статьи:
Тоже никаких оценок.
Про задачи с дедлайнами мне близка эта мысль из статьи:
Если в очередь попала срочная задача, надо всё бросить и делать её. Оценивать не нужно. Впрочем, будет полезно уточнить дедлайн, чтобы понять, с какими дефектами и недоработками можно будет выпустить. Таких срочных задач — меньше десяти процентов.
Тоже никаких оценок.
А как вы ответите на вопрос «сколько осталось до релиза вот этой фичи?»
Для задачи с дедлайнами обычно отвечаем, что зарелизим в срок, но с кучей трейдоффов.
Для несрочной — зачем отвечать? :)
Для несрочной — зачем отвечать? :)
Ну тогда я попрошу список трейд-оффов, которые вы сможете порешать до конца этой недели, а какие решите в течение следующей :)
Тут надо понимать, что либо вы работаете в динамично развивающемся продукте, где каждая новая возможность — это счастье или уход пользователей и часто целые новые пласты клиентов, ресурсов не хватает, а впереди маячит вкусный приз, либо в проекте, где ничего от релиза вашей фичи не поменяется, по большому счету, и срок ее релиза вообще не имеет значения.
Во втором случае заморачиваться вопросами сроков и эффективности нет никакого смысла. А в первом случае в работе не бывает задач без дедлайнов :)
Тут надо понимать, что либо вы работаете в динамично развивающемся продукте, где каждая новая возможность — это счастье или уход пользователей и часто целые новые пласты клиентов, ресурсов не хватает, а впереди маячит вкусный приз, либо в проекте, где ничего от релиза вашей фичи не поменяется, по большому счету, и срок ее релиза вообще не имеет значения.
Во втором случае заморачиваться вопросами сроков и эффективности нет никакого смысла. А в первом случае в работе не бывает задач без дедлайнов :)
Во-первых, вы хамите. Зачем?
Во-вторых.
Я почти не работал в мире, где все задачи с дедлайнами. Вы мне расскажите, как там?
На берегу, мне кажется что ставить дедлайны по всем задачам — это самообман. Все равно команда разработки не сможет сделать больше Х задачек в месяц. Еще придется устраивать адски сложные планирования в стиле «надо приоритизировать и оценить сроки для 40 входящих задач, а также посмотреть на 30 задачек, что сейчас в разработке». Вы в другой ветке писали, что на планирование уходило по 2 дня из 10 (=двухнедельный спринт). Я пока не увидел плюсов у таких гигантских трудозатрат.
Еще интересно, были ли в вашем мире овертаймы у команды разработки. Если да, то как часто и как плохо?
Во-вторых.
Я почти не работал в мире, где все задачи с дедлайнами. Вы мне расскажите, как там?
На берегу, мне кажется что ставить дедлайны по всем задачам — это самообман. Все равно команда разработки не сможет сделать больше Х задачек в месяц. Еще придется устраивать адски сложные планирования в стиле «надо приоритизировать и оценить сроки для 40 входящих задач, а также посмотреть на 30 задачек, что сейчас в разработке». Вы в другой ветке писали, что на планирование уходило по 2 дня из 10 (=двухнедельный спринт). Я пока не увидел плюсов у таких гигантских трудозатрат.
Еще интересно, были ли в вашем мире овертаймы у команды разработки. Если да, то как часто и как плохо?
Я прошу прощения, конечно, но при тщательном перечитывании комментария не увидел ровно никакого хамства.
Живущие в мире дедлайнов разработчики получают именно то, за чем пришли в профессию: они видят, как на глазах развивается продукт, как клиенты начинают использовать новые возможности, принимают непосредственное участие в определении судьбы продукта и живут в состоянии драйва.
По поводу гигантских трудозатрат на планирование. Во время планирования находятся и описываются решения всех попавших в планирование задач. В оставшиеся дни итерации остается только написать код, потому что все решения уже приняты и почти все головоломки решены.
Оверхед возникает из-за того, что оценивание задач обязательно проводится коллективно.
Во-первых, в достаточно большом проекте не все одинаково владеют всеми кусками кода, и более компетентные в какой-то части функциональности разработчики помогают сразу принимать правильные решения.
Во-вторых, коллективная оценка не позволяет скатиться в завышение и, что не менее важно, в занижение оценки задачи.
С овертаймами — тут уж у кого как. Если команда адекватная и не позволяет занижать оценку, кранчи бывают редко и, как правило, компенсируются периодом расслабленности после очередного релиза.
Живущие в мире дедлайнов разработчики получают именно то, за чем пришли в профессию: они видят, как на глазах развивается продукт, как клиенты начинают использовать новые возможности, принимают непосредственное участие в определении судьбы продукта и живут в состоянии драйва.
По поводу гигантских трудозатрат на планирование. Во время планирования находятся и описываются решения всех попавших в планирование задач. В оставшиеся дни итерации остается только написать код, потому что все решения уже приняты и почти все головоломки решены.
Оверхед возникает из-за того, что оценивание задач обязательно проводится коллективно.
Во-первых, в достаточно большом проекте не все одинаково владеют всеми кусками кода, и более компетентные в какой-то части функциональности разработчики помогают сразу принимать правильные решения.
Во-вторых, коллективная оценка не позволяет скатиться в завышение и, что не менее важно, в занижение оценки задачи.
С овертаймами — тут уж у кого как. Если команда адекватная и не позволяет занижать оценку, кранчи бывают редко и, как правило, компенсируются периодом расслабленности после очередного релиза.
В одной компании был я единственным разработчиком, а вокруг меня была куча менеджеров/руководителей.
Так вот, в вопросе оценке сроков я понял, что менеджерам моя оценка нужна только для отчета перед руководством и для прикрытия своей ж… в случае срыва-переноса сроков. В большинстве случаев получалось что-то типа «ты сказал, ты и делай».
В моем понимании сроки должно определять руководство (вот к этому дню нам нужен вот такой функционал), а менеджеры должны обеспечить все необходимое для реализации функционала разработчиками.
Так вот, в вопросе оценке сроков я понял, что менеджерам моя оценка нужна только для отчета перед руководством и для прикрытия своей ж… в случае срыва-переноса сроков. В большинстве случаев получалось что-то типа «ты сказал, ты и делай».
В моем понимании сроки должно определять руководство (вот к этому дню нам нужен вот такой функционал), а менеджеры должны обеспечить все необходимое для реализации функционала разработчиками.
абсолютно верно, есть такие менеджеры которым вообще пофигу что за задача, насколько сложная, что и как, вот ты дай мне срок и всё, и отвечать тоже ты за него будешь. А я получается только озвучу его руководству. Замечательно, блин. Ладно бы такой менеджер хоть как то пытался помочь, вникнуть в проблемы, так нет же! Так и хочется ответить таким манагерам — пошли вы в Ж...!
Вы так категорично рассуждаете о единственно верном подходе для абсолютно любых ситуаций, скажите, Судья Дред не ваш родственник?
Как вы узнали?! :)
А если серьезно, то я написал про конкретную ситуацию в Контуре, где много сотен разработчиков, которые могли бы сделать десятки продуктов. Причем, я знаю, очень качественных продуктов.
И эти сотни разработчиков делали бы крутые штуки в состоянии драйва. Причем у Контура есть такой опыт.
А тут менеджер всех тестировщиков, по сути, призывает сидеть в теплом липком болотце безрезультатного комфорта :)
А если серьезно, то я написал про конкретную ситуацию в Контуре, где много сотен разработчиков, которые могли бы сделать десятки продуктов. Причем, я знаю, очень качественных продуктов.
И эти сотни разработчиков делали бы крутые штуки в состоянии драйва. Причем у Контура есть такой опыт.
А тут менеджер всех тестировщиков, по сути, призывает сидеть в теплом липком болотце безрезультатного комфорта :)
Хамите, Александр, нехорошо.
Наверное хорошо, что теперь эти сотни разработчиков вместе с тестировщиками делают крутые штуки с драйвом, но без вас.
Наверное хорошо, что теперь эти сотни разработчиков вместе с тестировщиками делают крутые штуки с драйвом, но без вас.
Я бы сказал, что достаточно резко выражаюсь, но хамством это не назвал бы.
И буду очень признателен, Максим, если вы покажете мне эти крутые штуки на kontur.ru. А то вдруг я просто не ЦА и пропустил какие-то анонсы :)
И буду очень признателен, Максим, если вы покажете мне эти крутые штуки на kontur.ru. А то вдруг я просто не ЦА и пропустил какие-то анонсы :)
Кстати, о хамстве. Если вы внимательно перечитаете все мои комментарии, вы увидите, что я нигде не касаюсь ваших личных качеств. Только того, что вы написали и должности, от имени которой вы это сделали.
А обижаться на то, что комментарии по этому поводу жесткие, с вашей стороны странно, ведь вы в своем тексте в агрессивной форме обесцениваете лично мои профессиональные достижения и достижения еще многих и многих людей, что неприятно :)
А обижаться на то, что комментарии по этому поводу жесткие, с вашей стороны странно, ведь вы в своем тексте в агрессивной форме обесцениваете лично мои профессиональные достижения и достижения еще многих и многих людей, что неприятно :)
А тут менеджер всех тестировщиков, по сути, призывает сидеть в теплом липком болотце безрезультатного комфорта :)
Если вы так для себя поняли написанное в статье и это стало триггером для таких категоричных суждений, то, возможно, вам будет интересно узнать, что я в статье такого не увидел :)
Я в статье увидел некие мысли по поводу «вредности оценок сроков» и того, как они обустроили процесс по-другому в своей части общей работы. С «чем-то» я согласен, с «чем-то» — нет, «что-то» «работает» только по стечению конкретных обстоятельств, «что-то» вообще не влияет на итоговый результат. Но призыва сидеть в болтце — не увидел.
P.S. Со временем и Судья Дред и Виталик Бутерин кое-что всё же поняли :)
— Ты когда-нибудь слышал о смягчающих обстоятельствах?
— Все, что только можно.
Смотрите.
Я бы хотел, чтобы разработчики (и в целом команды) Контура создавали новые крутые проекты. Именно за этим идут в разработку ПО. Это вводная.
Практика доказывает, что крутые проекты могут делать только крайне мотивированные команды голодных разработчиков с горящими глазами, которые безостановочно изучают клиента, пробуют новые гипотезы и не останавливаются, пока не нащупают облик реального продукта. Это идеальная команда по Бруксу и Листеру.
Если в ходе этого поиска сроки решения задач не ограничивать, команда теряет фокус и начинает делать всякую ненужную побочную фигню, и проект заболачивается, а потом и умирает.
Но если команду и ее разработчиков начать подгонять сверху и спускать какие-то сроки, это создаст у разработчиков понимание, что конечный результат от них не зависит, и вместо пылающих глаз мы получим горящие пуканы и, опять же, торможение и гибель проекта. Это один из идеальных сценариев «травли команд» по Бруксу и Листеру. Именно в таких условиях разработчики начинают раздувать сроки и бездельничать, сделав переоцененную задачу — им нужно прикрыть задницу, а не построить вместе с командой крутой продукт.
Тонкая грань максимальной эффективности команды — это режим, в котором команда полностью вовлечена и все участники чувствуют, что результат зависит только от них, берут на себя личную ответственность за результат. При этом темп поддерживается максимально высокий, сроки поставки фич и проверки гипотез остаются управляемыми. Нужно, чтобы команда оценивала сроки работы над задачами, чтобы она по-честному могла взять на себя ответственность за обоснованные сроки поставки.
Таким образом, автор, по сути, призывает к тому, чтобы команды Контура работали расслабленно, без огонька. А значит и без шансов сделать что-то действительно крутое.
В чем и виновен :)
Если в ходе этого поиска сроки решения задач не ограничивать, команда теряет фокус
Только потому, что вы так считаете?
Нужно, чтобы команда оценивала сроки работы над задачами, чтобы она по-честному могла взять на себя ответственность за обоснованные сроки поставки.
Без сроков нельзя брать ответственность?
Только потому, что вы так считаете?
Вы тоже так считаете. Не зря же вы писали, что работа стремится занять все отведенное под нее время. А представьте себе, что время вообще не ограничено. Немедленно случится паралич перфекционизма, или решение задачи в общем виде, или написание целого фреймворка — под функцию, которой клиенты, может, вообще не будут никогда пользоваться.
Без сроков нельзя брать ответственность?
Можно. Но бизнесу/владельцу продукта нужны сроки. Если их спускают сверху, команда переходит в режим прикрытия задницы и теряет продуктивность. А дать собственную обоснованную оценку команда может, только оценивая свои задачи. А когда команда такую оценку дает, она получает серьезную мотивацию в нее уложиться. Тут хотите — поверьте моему опыту, не хотите — попробуйте сами)
А когда команда такую оценку дает, она получает серьезную мотивацию в нее уложиться.
Вопрос, за счет чего она будет в него укладываться...
Ну, вроде бы, кроме ответственного отношения к работе больше ничего не требуется :)
Вот где перход от оценки к мотивации? Нам вот говорят, что как можно более точная оценка менеджменту нужна, но это мотивирует не больше чем очередняа геймификация: «я крут, я верно оценил сколько эта задача у меня займёт» или «я лузер, ошибся в три раза». Мотивации уложиться в оценку нет, вся мотивация кончается после дачи оценки и только после нажатия кнопки «done» смотри угадал ты или нет пару месяцев назад, давая оценку.
Если оценил задачу, то хочется успеть в срок, соответственно предпринимаешь усилия, чтобы это сделать.
Правда, некоторые считают, что обычно это приводит к спешке, которая вредит качеству.
Правда, некоторые считают, что обычно это приводит к спешке, которая вредит качеству.
А если не хочется? Особенно если сроков не называл, а давал оценку трудоемкости, в которые ни риски не закладывал, ни времени на переключение контекста, ни чего-то ещё. Или даже приступил планово, но на половине задачи понял что не успеваешь. ну или вообще к тому времени когда приступил уже и забыл какую оценку давал.
В любом случае убеждён, что оценки трудоёмкости не должны ограничивать работу по времени, мотивировать успеть в них уложиться. Развивать нужно навык точной оценки, а не навык умудряться укладываться в сроки.
В любом случае убеждён, что оценки трудоёмкости не должны ограничивать работу по времени, мотивировать успеть в них уложиться. Развивать нужно навык точной оценки, а не навык умудряться укладываться в сроки.
Вопрос не только в том, что должно и что не должно, а в том, как это работает реально на большинстве людей в конкретной культуре. Я наблюдаю что это стимулирует спешку.
Причем, судя по тому, что некоторые призывы оценивать задачи в условных единицах а не во временных мотивируются так же (чтобы не стимулировать спешку), это наблюдаю не только я.
Причем, судя по тому, что некоторые призывы оценивать задачи в условных единицах а не во временных мотивируются так же (чтобы не стимулировать спешку), это наблюдаю не только я.
Есть мнение, что без спешки разрабатывается только ПО, которое заведомо никому не нужно.
Даже если у вас нет наступающих на пятки конкурентов, кучи пользователей с запросами, маркетологов, которые требуют фич для новых классов клиентов, вас все равно подгоняет как минимум ограничения бюджета/контракта/объема инвестиций/терпения внешнего или внутреннего инвестора.
А умение делать быстро, но без ущерба качеству — это и есть искусство разработки ПО, индивидуальное и командное.
Даже если у вас нет наступающих на пятки конкурентов, кучи пользователей с запросами, маркетологов, которые требуют фич для новых классов клиентов, вас все равно подгоняет как минимум ограничения бюджета/контракта/объема инвестиций/терпения внешнего или внутреннего инвестора.
А умение делать быстро, но без ущерба качеству — это и есть искусство разработки ПО, индивидуальное и командное.
Есть мнение, что со спешкой, в целом, медленнее (баги отнимают больше ресурсов на последующих этапах)
Если при запуске нового продукта делать все не спеша, последующих этапов, как правило, не бывает — по причине прекращения продукта.
При запуске, ага. Это инженерный долг — если его берешь, надо учитывать, что отдавать придется с процентами. «Всегда брать», «никогда не брать» — слишком примитивные стратегии.
«без спешки разрабатывается только ПО, которое заведомо никому не нужно.» — тоже слишком примитивно — каждое ПО разрабатывается со спешкой и без спешки в разные моменты времени.
«без спешки разрабатывается только ПО, которое заведомо никому не нужно.» — тоже слишком примитивно — каждое ПО разрабатывается со спешкой и без спешки в разные моменты времени.
Ваши замечания справедливы.
Просто чтобы донести основную мысль, иногда приходится утрировать. Иначе, если доносить главную мысль со всеми должными уточнениями и оговорками, она ускользает от внимания в потоке слов :)
Вообще, с хорошей командой и торопиться можно не спеша, без перегибов, и технический долг оставлять минимальный. Но расслабленного отношения к работе создания нового продукта не прощает.
Просто чтобы донести основную мысль, иногда приходится утрировать. Иначе, если доносить главную мысль со всеми должными уточнениями и оговорками, она ускользает от внимания в потоке слов :)
Вообще, с хорошей командой и торопиться можно не спеша, без перегибов, и технический долг оставлять минимальный. Но расслабленного отношения к работе создания нового продукта не прощает.
А зачем вы давали оценку трудоемкости?
Чтобы менеджмент составлял планы. Насколько я знаю, используют статистику по точности оценок каждого разработчика. То есть по сути важны не конкретные цифры оценки, а их корреляция с фактами из прошлого.
Здоровая мотивация начинается там, где вы (в составе команды), а не менеджмент, управляете своим процессом разработки. И сами назначаете сроки.
Менеджмент приходит к вам с набором feature requests и спрашивает, что и когда вы можете сделать.
Вы все декомпозируете, оцениваете, и предлагаете менеджменту несколько вариантов, как можно раскидать его запросы по порядку реализации и вы вместе исходя из приоритетов формируете план разработки.
И это ваш план, ваш процесс, ваши оценки и только от вас зависит результат.
И уж где-где, а в Контуре точно возможен такой процесс)
Менеджмент приходит к вам с набором feature requests и спрашивает, что и когда вы можете сделать.
Вы все декомпозируете, оцениваете, и предлагаете менеджменту несколько вариантов, как можно раскидать его запросы по порядку реализации и вы вместе исходя из приоритетов формируете план разработки.
И это ваш план, ваш процесс, ваши оценки и только от вас зависит результат.
И уж где-где, а в Контуре точно возможен такой процесс)
Вот зачем нам самих себя загонять в ограничения сроков? Тем более, что угадать их точно мы можем только случайно, не имея никакого понятия о теории и практики управления рисками. Не так ли начинается выгорание, когда чувствуешь себя всюду обязаным и плохо справляющимся с этими обязанностями?
Банально, заболел человек, который должен был делать ключевую задачу спринта, блокирующий половину если не больших остальных. Хорошо если команда реально кроссфункциональная и каждый легко может его подменить. Просто чтобы спринт закрыть надо будет по 9-10 часов работать, а не 8. За теже деньги, конечно, да, у нас же мотивация и ответственность за сроки. А он лежит более и думает какой он редиска, команду подвёл. А если команда не совсем кроссфункциональная, если чтобы в задачу въехать только неделя нужна, и то при условии постоянных консультаций с заболевшим?
Банально, заболел человек, который должен был делать ключевую задачу спринта, блокирующий половину если не больших остальных. Хорошо если команда реально кроссфункциональная и каждый легко может его подменить. Просто чтобы спринт закрыть надо будет по 9-10 часов работать, а не 8. За теже деньги, конечно, да, у нас же мотивация и ответственность за сроки. А он лежит более и думает какой он редиска, команду подвёл. А если команда не совсем кроссфункциональная, если чтобы в задачу въехать только неделя нужна, и то при условии постоянных консультаций с заболевшим?
Я понял. У вас был травмирующий опыт, ситуация, когда недобросовестное руководство манипулировало разработчиками через их чрезмерно развитое чувство ответственности.
И теперь вы противопоставляете себя коллегам и руководству, вместо того, чтобы считать всех одной командой единомышленников, где все друг друга поддерживают.
Даже не знаю, как теперь помочь вам поверить, что это не норма, и так бывает далеко не всегда :(
И теперь вы противопоставляете себя коллегам и руководству, вместо того, чтобы считать всех одной командой единомышленников, где все друг друга поддерживают.
Даже не знаю, как теперь помочь вам поверить, что это не норма, и так бывает далеко не всегда :(
Разный опыт был.
И где я про противопоставление говорю? Наоборот, работая над продуктом каждый занят своим делом, разработчики разрабатывают, менеджеры управляют на основании данных от разработчиков явных (оценки, статусы) и неявных (статистика по прошлым задачам). Управление рисками — это (с вики) процесс принятия и выполнения управленческих решений. Если разработчик берёт на себя ответственность управленца, то возникает два вопроса: что взамен и зачем ему менеджмент нужен? ну и вдогонку, а в чём ответственность конкретно заключается?
С менеджментом понятно, он редко работает за оклад, а явно или не очень участвует в прибылях. Его ответственность — лишение премий и бонусов за успешную работу, составляющих заметную часть его дохода. А разработчик на окладе? К тому же с профессиональными навыками находить дыры в системах, в том числе административных типа "сдашь задачу тобою же оцененную досрочно — получишь премию" и "не сдашь задачу в названные тоою сроки — уволим". Как говорится "и тут мне карта как попёрла", нет?
1. Вот прямо в этом комментарии и противопоставляете менеджеров разработчикам.
2. Менеджмент в вашей модели мира — это какие-то полубоги с долей в прибыли, а на самом деле 99% менеджеров точно такие же наемные сотрудники, тем более в больших компаниях.
3. Просто представьте себе ситуацию, когда вы и ваш менеджер разработки делаете все, чтобы помочь друг другу в работе: менеджер добивается у своего руководства обязательного бюджета на рефакторинг, хорошего железа, пары больших мониторов и дивана в офис, чтобы не спать после обеда лицом в клавиатуре. А вы помогаете менеджеру в его работе: помогаете ему оценить сроки, не подводите его без необходимости, сразу сообщаете о проблемах, конструктивно помогаете ему увидеть ошибки. Приятно было бы работать в таких условиях?
2. Менеджмент в вашей модели мира — это какие-то полубоги с долей в прибыли, а на самом деле 99% менеджеров точно такие же наемные сотрудники, тем более в больших компаниях.
3. Просто представьте себе ситуацию, когда вы и ваш менеджер разработки делаете все, чтобы помочь друг другу в работе: менеджер добивается у своего руководства обязательного бюджета на рефакторинг, хорошего железа, пары больших мониторов и дивана в офис, чтобы не спать после обеда лицом в клавиатуре. А вы помогаете менеджеру в его работе: помогаете ему оценить сроки, не подводите его без необходимости, сразу сообщаете о проблемах, конструктивно помогаете ему увидеть ошибки. Приятно было бы работать в таких условиях?
1. Не противопоставляю, а дополняю. Без них продукт не получится и без нас не получится. И если наши усилия будут разнонаправлены, то тоже не получится.
2. Ну вот так получилось, что в моей практике если не доля в прибыли, то приличный бонус за успешное завершения проекта они получали. Как я понимаю немалая часть этого успеха заключалась в грамотном управлении рисками. Ну или они взяли наши оценки, сложили и выдали заказчику без каких-либо поправок и резервов, а мы сильно трудозатраты переоценили, интуитивно заложив не только прямые трудозатраты, технологические риски, но и время совещаний, время переключения контекстов, время перекуров и опозданий, ожиданий обратной связи и т. п.
3. Так я и помогаю менеджерам оценить сроки, давая оценку трудозатрат и список видимых технологических рисков из-за которых трудозатраты могут увеличиться.
2. Ну вот так получилось, что в моей практике если не доля в прибыли, то приличный бонус за успешное завершения проекта они получали. Как я понимаю немалая часть этого успеха заключалась в грамотном управлении рисками. Ну или они взяли наши оценки, сложили и выдали заказчику без каких-либо поправок и резервов, а мы сильно трудозатраты переоценили, интуитивно заложив не только прямые трудозатраты, технологические риски, но и время совещаний, время переключения контекстов, время перекуров и опозданий, ожиданий обратной связи и т. п.
3. Так я и помогаю менеджерам оценить сроки, давая оценку трудозатрат и список видимых технологических рисков из-за которых трудозатраты могут увеличиться.
Здоровая мотивация начинается там, где все делают свое дело (то что им больше всего нравиться).
Программист должен отвечать за «качество» кода.
Менеджер проекта должен контролировать время.
Программист должен отвечать за «качество» кода.
Менеджер проекта должен контролировать время.
Случай из моей жизни. Перебрасывают меня на новый проект. Тут же собирается совещание. И самый главный главнюк жестко начинает требовать с меня сроки по выполнению очень важной фичи. Я еще не видел проект, не работал с этим фреймворком и даже от самой фичи знаю только название и общее описание в двух словах. Честно говорю, что не знаю, я вообще только пришел, но начальнику все равно, он достал свой член и стал им трясти настаивал, чтобы я назвал сроки. В итоге я выпалил рандомные «две недели». Фичу запилил за два дня, остальное время ковырял в носу и читал хабр. Э — эффективный менеджмент.
Повезло. У меня была аналогичная ситуации только всё с сгущалось тем чтобы я не назвал срок сдачи уже установили и некого не волновало, что мне может понадобится больше времени.
Да уж. Офисный мачизм, как он есть.
Почему все же решил остаться?
Так я и не остался :). Ушел я правда не из-за этого, а из-за того, что трактор прогрелся. Главный главнюк мне был даже не начальник, просто он был поставлен главным над всей затеей. Поэтому я особо из-за того случая не переживал, просто среди офисного планктона такое откровенно самцовое поведение встретил впервые.
Приходит как-то ко мне менеджер и заявляет у тебя 2 дня на реализацию отчёта в это системе. Я как-так 2 дня я даже систему не знаю и что должно быть в отчёте. А он мне ничего не знаю в вашем отделе другой программист в другой системе делал какой-то другой отчёт за 2 дня. А начальство да-да ты что хуже. Так что как не оценивай, что не называй ты в любом случаи не прав и крайней. Но это зависит от адекватности компании ;-)
Крайность она разная бывает, одно дело если тебя назначили крайним за срыв сроков особо тебя не спрашивая, а совсем другое — если ты сам себя назначил, сам себя сделал ответственным за срыв. и особо не важно «я плохой — медленно решал задачу» или «я плохой — согласился или даже сам озвучил нереальный срок».
Не очень понял бурления в комментариях. Автор совершенно прав (даже если кому-то не нравится).
Мелкая задача помечена в YouTrack тегом «на час
делается за один подход (от получаса до двух часов)
Просто прекрасно :)
а что не так? )
тестирование достаточно непредсказуемо, что бы можно было тестировать результаты недели работы разработчика за пол часа, а одну строчку кода — две недели :)
Автору — спасибо! я бы почитал еще более подробные примеры применения «упражнений» — и возможно даже какой-то опыт не очень успешного применения тех или иных практик: кажется, что к данной статье привел достаточно большой опыт и пул знаний, а не только желание «побомбить» на менеджеров, которые не различают «нужен день» и «через день — готово».
тестирование достаточно непредсказуемо, что бы можно было тестировать результаты недели работы разработчика за пол часа, а одну строчку кода — две недели :)
Автору — спасибо! я бы почитал еще более подробные примеры применения «упражнений» — и возможно даже какой-то опыт не очень успешного применения тех или иных практик: кажется, что к данной статье привел достаточно большой опыт и пул знаний, а не только желание «побомбить» на менеджеров, которые не различают «нужен день» и «через день — готово».
ну это же тег а не эстимейт
#NoEstimates (Allen Holub), предлагает измерять скорость (количество фич за период времени) вместо оценки сроков.
Чутка анализа статьи, какая-то она не однозначная.
Вот в целом какая цель у оценки? С точки зрения управленца, и это говорится во многих книгах, необходимо понимать когда, примерно, будет выпущена та или иная фича. Для чего? Очевидно, что есть процессы помимо разработки и тестирования и было бы круто выполнять их параллельно. Для этого надо понимать когда будет выполнена та или иная часть работы. Нередко бывает что руководитель говорит — “Надо через три дня, успеешь?”. Тут да, менеджер из него так себе (правда иногда такое бывает и с хорошими менеджерами). В такой ситуации, конечно, появляется чувство, что тебя прижали к стенке.
“Я считаю абсолютно вредной практику, когда исполнитель оценивает сроки на выполнение отдельной задачи.”
Во-первых, получается, что он считает оценку фичи полезной, раз не сказано обратного. Речь только о задачах, как я понял. Это же следует и из названия статьи. Во-вторых, он считает вредной практику оценки задач исполнителем, получается оценка задач менеджером, тимлидом, коллегой с другого проекта или командой уже не вредная, как минимум. А вот если доколупаться до Васи с вопросом сколько он потратит на задачу к которой приступает, это да, это вредно. Можно возразить, что это мои придирки, но все остальное будет просто мнением, основанным на ваших мыслях, которые могут не соответствовать мыслям автора.
“Это напрямую связано с отсутствием системного образования и низкими требованиями к менеджерам.”
Так, погодите, отсутствие системного образования у кого, у менеджера или того, кто будет оценивать? Это важно. Отсутствие системного образования (при чем здесь это вообще?) у менеджера может привести к ожиданию, что задача будет выполнена через Х часов с момента начала работы над ней. А у исполнителя, может создастся ощущение, что есть некий дедлайн и выход за его рамки приведет к ухудшению мнения о нем как о разработчике/тестировщике. Здесь важнее общее понимание оценки обеими сторонами и того, что может произойти при нарушении договоренности. Вторая часть предложения про низкие требования к менеджерам — это вообще о чем? Не, ну правда, не нравится менеджер и его методы, поговори с ним, объясни, что не так. Менеджеры не телепаты, им тоже нужна обратная связь, если он адекватный человек, то будет благодарен за фидбэк. Если не зашло, иди к директору, проси сменить менеджера, в чем проблема?
“К нам приходит человек, ставит задачу и спрашивает, сколько времени может занять ее выполнение. Оценивая задачу, мы, конечно же, хотим назвать тот срок, к которому точно успеем, а так как многое может случиться (и мы подозреваем, что что-то наверняка случится), мы закладываем в оценку некий запас времени.
В итоге любой названный в качестве дедлайна срок становится сроком, раньше которого задача выполнена не будет. К особо неприятным последствиям это приводит при командной работе, когда для выполнения одной задачи или проекта требуется сотрудничество разных специалистов и разных отделов.”
Логично и правдиво, но! Заметили ли вы логическую ошибку? По отдельности я согласен с каждым этим абзацем, а вот вместе нет. В одном речь про оценку, а во втором про срок! Это же разные понятия… Это к вопросу про системность образования. Абзацы вырваны из контекста и совмещены. Будь я чуточку менее внимателен, то проглотил бы это. Это же Макс Дорофеев написал! КЛАССИК! Интересно знает ли он сам про это? Оценка, это “За час, в течении недели”, а срок “Будет через час”.
“В пятой части первой главы есть ссылки на исследования о зависимости производительности от того, кто выполнял оценку сроков.”
Ну давайте почитаем эту часть вместе и добавим цитаты с небольшими комментариями:
“В 1954 году англичанин Сирил Паркинсон выразил мнение, что работа растѐт, заполняя любое отведѐнное под неѐ время. Сейчас это мнение известно как закон Паркинсона”
“Даже руководители, не знающие вообще ничего о менеджменте, цепляются за эту аксиоматическую истину – закон Паркинсона, руководящую людьми и их отношением к работе. Он даѐт им крайнюю убеждѐнность в том, что единственный способ добиться выполнения работы – это установить невозможно оптимистические сроки еѐ сдачи.”
Смотрите ка, опять про сроки, а не про оценку…
Книга, судя по пятой части первой главы, интересная. Что я вынес из прочтения этого отрывка. Во-первых, исследование на которое ссылается автор книги датирована 1985 годом. Скрам и аджаил в целом, а именно они возникают у меня в голове при слове “оценка”, был сформирован в 2000-ых. И подход к оценке был изменен. Можно почитать “Мифический человеко-месяц” (1975), что-то мне подсказывает, что есть на эту тему информация. Оценка в скраме несет приблизительный характер (попугайчики), а размер спринта зависит от среднего объема выполняемого командой за некоторое количество предыдущих спринтов. Кроме того, оценка производится коллективно, а не непосредственно исполнителем.
Продолжим разбор статьи.
“За последний год я дважды слышал от менеджеров: «Мы научились выдерживать сроки по оценкам задач, теперь такой-то программист или тестировщик совсем не нарушает сроки, которые назвал».
Я считаю, это крайне серьезная проблема, так как это означает, что этот программист или тестировщик системно и сознательно завышает сроки, работает на расслабоне и лжет менеджеру.”
И что? Менеджер доволен, у него не срываются другие процессы из-за разработки/тестирования. Программист/тестировщик тоже, у него нет чувства горящей пятой точки. А если возникает ощущение, что оценка завышена, то можно делать это коллективно и брать среднее значение оценки. Ничего нового, просто немного понимания скрама. Если какой-то сотрудник сильно отстает по производительности, то это повод к выяснению причин.
“Упомянутые в заголовке авторы говорят, что единственно верный способ оценки сроков — статистический. Должен оцениваться пакет типовых задач. «У нас все задачи разные»? Это ложь. На промежутке в год будет уже не очень много разных задач. Как правило, такое заявление является признаком отсутствия рефлексии над процессом и не выполнения упражнений: декомпозиция, MVP, прототипы, стандартизация.”
Бррр, да это же опровергает все что было написано автором до этого, нет? Лично у меня этот абзац не вызывает чувства отрицания сам по себе, но автору-то он зачем?
“О заказчиках, которые требуют сроки
Во-первых, надо заметить, что чаще всего — и это само по себе забавно — от ответа исполнителя не зависит ничего, потому что сроки уже есть. Менеджер интересуется не сколько времени мы будем делать задачу, а успеем ли мы к заданному сроку и что именно успеем. Это разные вопросы и отвечать на них нужно по-разному.
Как правило, ответом на вопрос «успеем ли мы к заданному сроку» является аналитика и MVP, качественная инфраструктура разработки и размер технического долга, а именно сложность проведения рефакторинга и наличие автоматических тестов на регрессию.”
Как? Как из этих двух абзацев следует вывод — “Ещё раз: оценка сроков мешает исполнителю успеть к дедлайну.” Я могу что-то с этим придумать, конечно, сделать какие-то домыслы, но это не то, что я ожидал от статьи.
Далее приводится список упражнений (среди которых MVP), которые рекомендуются к выполнению для повышения точности сроков и вывод:
“Если упражнения не выполняются, то скорее всего любой названный менеджером срок будет ложью.”
Ну как так-то? Вот представим ситуацию. Приходит заказчик и приносит требования, просит оценить сроки выполнения и бюджет. А мы ему такие: “Так, товарищ, надо запилить MVP и выпустить его канареечными релизами! Если вам нужна более точная оценка оценка, то в этом нам поможет раздельный релиз бэкэнда, фронтенда и прочего… и канарейки. И не забудьте про фича-флаги!”. И как нам это поможет?
“О некомпетентных менеджерах
Очень легко перепутать оценку сроков (когда задача будет сделана) и оценку трудозатрат (сколько нужно времени, чтобы разработать фичу). Оценка сроков, как мы уже разобрались, если не вредна, то по крайней мере бессмысленна. А вот оценка трудозатрат — довольно полезное упражнение.”
Зачем? Ну что кому даст оценка трудозатрат сама по себе? Разумеется она нужна, но, только в контексте оценки сроков. И эти две оценки очень тесно связаны. Просто надо добавить еще один параметр — количество выполняемого труда командой проекта. И тогда все встает на свои места. Оценили трудозатраты, знаем производительность команды, следовательно, можем получить оценку сроков. Если что-то меняется в требованиях, то происходит изменение оценки.
“Пример из жизни:
— Сколько времени ты потратишь на эту фичу?
— Полторы недели буду писать и дня три фиксить баги.
— То есть через 3-4 недели будет готово?”
А где продолжение? Ну ответил — “да” и сделал, у него же не лапки. Или ответил — “У меня сейчас большая загруженность. Давай посмотрим бэклог и подумаем над приоритетом этой фичи (посмотрели — вставили в бэклог — сделали)”. Где интрига-то?
“P.S. Один из наиболее важных навыков в нашей работе — не делать ненужной херни. В том числе не заниматься «оценкой сроков» и самообманом. Чего и вам желаю.”
Про самообман хорошо сказал…
Вот в целом какая цель у оценки? С точки зрения управленца, и это говорится во многих книгах, необходимо понимать когда, примерно, будет выпущена та или иная фича. Для чего? Очевидно, что есть процессы помимо разработки и тестирования и было бы круто выполнять их параллельно. Для этого надо понимать когда будет выполнена та или иная часть работы. Нередко бывает что руководитель говорит — “Надо через три дня, успеешь?”. Тут да, менеджер из него так себе (правда иногда такое бывает и с хорошими менеджерами). В такой ситуации, конечно, появляется чувство, что тебя прижали к стенке.
“Я считаю абсолютно вредной практику, когда исполнитель оценивает сроки на выполнение отдельной задачи.”
Во-первых, получается, что он считает оценку фичи полезной, раз не сказано обратного. Речь только о задачах, как я понял. Это же следует и из названия статьи. Во-вторых, он считает вредной практику оценки задач исполнителем, получается оценка задач менеджером, тимлидом, коллегой с другого проекта или командой уже не вредная, как минимум. А вот если доколупаться до Васи с вопросом сколько он потратит на задачу к которой приступает, это да, это вредно. Можно возразить, что это мои придирки, но все остальное будет просто мнением, основанным на ваших мыслях, которые могут не соответствовать мыслям автора.
“Это напрямую связано с отсутствием системного образования и низкими требованиями к менеджерам.”
Так, погодите, отсутствие системного образования у кого, у менеджера или того, кто будет оценивать? Это важно. Отсутствие системного образования (при чем здесь это вообще?) у менеджера может привести к ожиданию, что задача будет выполнена через Х часов с момента начала работы над ней. А у исполнителя, может создастся ощущение, что есть некий дедлайн и выход за его рамки приведет к ухудшению мнения о нем как о разработчике/тестировщике. Здесь важнее общее понимание оценки обеими сторонами и того, что может произойти при нарушении договоренности. Вторая часть предложения про низкие требования к менеджерам — это вообще о чем? Не, ну правда, не нравится менеджер и его методы, поговори с ним, объясни, что не так. Менеджеры не телепаты, им тоже нужна обратная связь, если он адекватный человек, то будет благодарен за фидбэк. Если не зашло, иди к директору, проси сменить менеджера, в чем проблема?
“К нам приходит человек, ставит задачу и спрашивает, сколько времени может занять ее выполнение. Оценивая задачу, мы, конечно же, хотим назвать тот срок, к которому точно успеем, а так как многое может случиться (и мы подозреваем, что что-то наверняка случится), мы закладываем в оценку некий запас времени.
В итоге любой названный в качестве дедлайна срок становится сроком, раньше которого задача выполнена не будет. К особо неприятным последствиям это приводит при командной работе, когда для выполнения одной задачи или проекта требуется сотрудничество разных специалистов и разных отделов.”
Логично и правдиво, но! Заметили ли вы логическую ошибку? По отдельности я согласен с каждым этим абзацем, а вот вместе нет. В одном речь про оценку, а во втором про срок! Это же разные понятия… Это к вопросу про системность образования. Абзацы вырваны из контекста и совмещены. Будь я чуточку менее внимателен, то проглотил бы это. Это же Макс Дорофеев написал! КЛАССИК! Интересно знает ли он сам про это? Оценка, это “За час, в течении недели”, а срок “Будет через час”.
“В пятой части первой главы есть ссылки на исследования о зависимости производительности от того, кто выполнял оценку сроков.”
Ну давайте почитаем эту часть вместе и добавим цитаты с небольшими комментариями:
“В 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 часов), выходные и праздничные дни, разные второстепенные факторы (совещания, болезнь, настроение и прочее).
Поэтому с программистов нужно спрашивать не срок, а время сколько в часах он сделает фичу (трудозатраты).
А дальше идет сложная математика с элементами теории вероятности с выставлением сроков (даты), когда обе фичи будут сделаны.
Т.к. они имеют направленность (время) и размерность (скаляр) ;-)
Сроки это точка (конкретная дата) их сдвинуть проблематично.
И сроки можно сказать не складываются.
Например фича А будет готова к дате 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 и получить время когда будут готовы обе фичи.
В лучшем нижнюю границу.
Насчет веса… Вес имеет смысл только при существовании ускорения.
Т.е. он изменяется в зависимости от. Т.е. вес это сумма векторов ускорения.
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 в России. Если узнаю, что у кого-нибудь больше — сильно удивлюсь :)
Недавно «Мой круг» ещё что-то писал о нас на Хабре. Или я могу что-нибудь рассказать, если интересно.
В отличии от Максима я не знаком со всеми проектами Контура, успел поработать только над 5-6, с большей частью — на стадии MVP (по пол года или меньше). Поэтому прокомментирую исключительно на базе собственного опыта и того, что я слышу, общаясь с коллегами из других проектов.
1) Изменения в немалом числе проектов Контура нередко завязаны на изменения законодательства, читай у нас есть «внешние дедлайны». И оценивать сроки, чтобы понять «начать переделывать вот эту отчётность сейчас или через месяц» необходимо.
2) Сроки мы конечно же оцениваем, регулярно и активно. Но
а) это оценка поверхностная, вида «X дней / недель», мы не тратим на оцени недели, дни или часы
б) оценка каждым специалистом ведёт только в своей области компетенции — разработчик оценивает время разработки, тестер — тестрования и так далее. А вот задача менеджера разработки — свести эти оценки воедино и помочь с планированием деятельности проекта в целом. От остальных оценки сроков всей задачи в Контуре не требуют.
в) оценка нужна для планирования деятельности других людей, чтобы отвечать на вопросы вида «пора начинать рисовать баннеры с рекламой для этой фичи и писать текст в блог?»
г) оценка нужна для расстановки приоритет между задачами (тут задача на 2 дня, тут на 2 недели, такой то разработчик через неделю в отпуск, какую задачу ему дать, а такой то заканчивает такую то задачу когда то)
д) когда задача уже взята в работу — делается поверхностая декомпозиция, и там может быть пересмотр сроков или даже откладывания задачи и взятие в работу другую
3) Типовых задач в работе таки довольно много, и там оценки промахиваются не так уже сильно — и это не «обман и работа на расслабоне», а банальный опыт
4) В чисто исследовательских задачах нет сроков со стороны разработчика — но есть срок вида «сколько максимум мы можем выделить на эту деятельность учитывая такие то факторы». И тут от задачи зависит, разработчик может и до упора это время потратить, и до конца срока справиться, и даже до начала сказать «этого точно не хватит, давайте в исследование чего-нибудь другое возьмём»
5) И просто в отрыве — небольшой момент из практики: каждое утро на летучке отмечать, сколько уже часов потратил на такую то подзадачу такой то задачи. Если «оценка» и «затраты» начались расходиться — то сразу видно, что пора разбираться, может быть разработчику нужна помощь, или там возникли объективные трудности и нам нужно перепланировать другую деятельность. Без предварительной примерной оценки есть шанс «закопаться», и этот момент может пройти не замеченным столь явно. А вот «я тут потратил на задачу 15 часов из 5 запланированных» замечается сразу ;-)
1) Изменения в немалом числе проектов Контура нередко завязаны на изменения законодательства, читай у нас есть «внешние дедлайны». И оценивать сроки, чтобы понять «начать переделывать вот эту отчётность сейчас или через месяц» необходимо.
2) Сроки мы конечно же оцениваем, регулярно и активно. Но
а) это оценка поверхностная, вида «X дней / недель», мы не тратим на оцени недели, дни или часы
б) оценка каждым специалистом ведёт только в своей области компетенции — разработчик оценивает время разработки, тестер — тестрования и так далее. А вот задача менеджера разработки — свести эти оценки воедино и помочь с планированием деятельности проекта в целом. От остальных оценки сроков всей задачи в Контуре не требуют.
в) оценка нужна для планирования деятельности других людей, чтобы отвечать на вопросы вида «пора начинать рисовать баннеры с рекламой для этой фичи и писать текст в блог?»
г) оценка нужна для расстановки приоритет между задачами (тут задача на 2 дня, тут на 2 недели, такой то разработчик через неделю в отпуск, какую задачу ему дать, а такой то заканчивает такую то задачу когда то)
д) когда задача уже взята в работу — делается поверхностая декомпозиция, и там может быть пересмотр сроков или даже откладывания задачи и взятие в работу другую
3) Типовых задач в работе таки довольно много, и там оценки промахиваются не так уже сильно — и это не «обман и работа на расслабоне», а банальный опыт
4) В чисто исследовательских задачах нет сроков со стороны разработчика — но есть срок вида «сколько максимум мы можем выделить на эту деятельность учитывая такие то факторы». И тут от задачи зависит, разработчик может и до упора это время потратить, и до конца срока справиться, и даже до начала сказать «этого точно не хватит, давайте в исследование чего-нибудь другое возьмём»
5) И просто в отрыве — небольшой момент из практики: каждое утро на летучке отмечать, сколько уже часов потратил на такую то подзадачу такой то задачи. Если «оценка» и «затраты» начались расходиться — то сразу видно, что пора разбираться, может быть разработчику нужна помощь, или там возникли объективные трудности и нам нужно перепланировать другую деятельность. Без предварительной примерной оценки есть шанс «закопаться», и этот момент может пройти не замеченным столь явно. А вот «я тут потратил на задачу 15 часов из 5 запланированных» замечается сразу ;-)
Самое смешное что в нашей сфере здравоохранения абсолютно такая же ситуация.
Хм… а мне говорили что известно только 3 задачи, не поддающиеся алгоритмизации…
А их, оказывается, намного больше…
А их, оказывается, намного больше…
Я так понимаю ключевой посыл статьи состоит в том, что оценка сроков оценивается из опыта выполнения аналогичных задач.
ну а как вы строите порядок задач чтобы люди друг друга не блокировали? сколько у вас человек? вы что-то создаёте или просто поддерживаете, дописывая фички?
в целом, статья по стилю и содержанию, вредна для бренда
в целом, статья по стилю и содержанию, вредна для бренда
Привет, я из Контура. Могу о-о-очень кратко рассказать, что знаю сам: у Максима Wolonter в продуктовой команде 30 человек, из них половина — разработчики. Работают по канбаноподобному процессу. Продукту несколько лет, но идёт бурный рост, так что задачи разные.
Fixed: wrong branch.
Сам замечал на сколько увлекательным занятием для меня является декомпозиция задачи и оценка трудозатрат. Это очень полезное упражнение, которое позволяет лучше понять задачу.
И каким нелепым и угнетающим занятием является простановка срока исполнения задачи.
И каким нелепым и угнетающим занятием является простановка срока исполнения задачи.
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.
Я честно говоря не понял, объясните пожалуйста
Почти всю статью автор рассказывает, что оценка сроков не нужна
Затем заявляет «Оценка сроков, если не вредна, то по крайней мере бессмысленна. А вот оценка трудозатрат — довольно полезное упражнение»
Я всю жизнь думал что оценка срока это и есть оценка трудозатрат, то есть сколько тебе нужно времени, чтобы запилить эту фичу?
Я вот вообще в шоке, в чем отличие то принципиальное? Почему одно не нужно, а другое очень полезно?
Почти всю статью автор рассказывает, что оценка сроков не нужна
Затем заявляет «Оценка сроков, если не вредна, то по крайней мере бессмысленна. А вот оценка трудозатрат — довольно полезное упражнение»
Я всю жизнь думал что оценка срока это и есть оценка трудозатрат, то есть сколько тебе нужно времени, чтобы запилить эту фичу?
Я вот вообще в шоке, в чем отличие то принципиальное? Почему одно не нужно, а другое очень полезно?
Нет. Срок — это дата. Трудозатраты — часы.
Вы можете установить любой срок и при этом с вероятностью стремящейся к еденице можете быть уверены что к этому сроку фича не будет сделана.
С трудозатратами наоборот, есть не нулевая вероятность, что фича будет сделана за меньшее время.
Вы можете установить любой срок и при этом с вероятностью стремящейся к еденице можете быть уверены что к этому сроку фича не будет сделана.
С трудозатратами наоборот, есть не нулевая вероятность, что фича будет сделана за меньшее время.
«Сделаю через месяц» и «это займёт 168 часов работы» — разные вещи, равные только в каких-то идеальных условиях. Даже без форс-мажоров, без переключения на другие задачи, без совещаний, без составления отчётов бывают месяцы с разным количеством дней, с разным количеством выходных и праздников. Скажете «сделаю через месяц», имея в виду 168 часов, 1 февраля вечером и от вас будут ждать готового результата утром 1 марта (в лучшем случае), а рабочих часов у вас будет только 152, например. 16 часов где хотите там и ищите.
Это как раз просто лечится. Задача с оценкой больше 8 календарных часов (одного рабочего дня) — это исключение, которое должно быть обосновано.
Если задача получается больше 1 рабочего дня, почти всегда она может и должна быть декомпозирована, оценена на уровне подзадач и, очень часто, еще и распараллелена.
Если задача получается больше 1 рабочего дня, почти всегда она может и должна быть декомпозирована, оценена на уровне подзадач и, очень часто, еще и распараллелена.
А это суммарная оценка подзадач, каждая из которых не имеет смысла. Общая трудоемкость фичи 168 часов (21 задача по 8 часов). Увидели сумму и назвали срок.
Нет. Набрали задач в итерацию, оставив оговоренный запас для непредвиденных задач (багов) и на случай ошибок в оценках. И уже тогда огласили какие-то сроки.
Оценка каждой задачи — необходимый источник данных, чтобы назвать конечный срок, но никто в здравом уме не суммирует их механически. И команда никогда не подпишется под такой оценкой. И автор поста тоже пишет, что так делают только неадекватные менеджеры.
Оценка каждой задачи — необходимый источник данных, чтобы назвать конечный срок, но никто в здравом уме не суммирует их механически. И команда никогда не подпишется под такой оценкой. И автор поста тоже пишет, что так делают только неадекватные менеджеры.
Команду и не спросят про сроки. Она сама уже дала оценки.
Опять нет. Команда сама называет сроки — такие, под которыми готова подписаться. И в таком режиме она максимально ответственна и мотивирована.
Разумеется, при этом команда может обосновать эти сроки заказчику, либо уже заслужила его доверие.
Если заказчик так работать не может, то все скатывается к сценариям, описанным автором поста, с соответствующим отношением к неадекватному заказчику.
Разумеется, при этом команда может обосновать эти сроки заказчику, либо уже заслужила его доверие.
Если заказчик так работать не может, то все скатывается к сценариям, описанным автором поста, с соответствующим отношением к неадекватному заказчику.
Выглядит как перекладывание обязанностей менеджера на команду. Ну или как какое-то подобие скрама, вывернутое по одному из измерений (вместо скоупа работ в фиксированный спринт команда выбирает «размер спринта» для фиксированного скоупа).
Вы все правильно понимаете, это скрам и есть.
Спринт обычный, фиксированный. Сроки оцениваются не для спринта, а для фич, которые бывают разными и могут делаться в несколько спринтов или просто уезжать вперед из-за нехватки времени в текущем или следующем.
То, что команда сама выполняет функции менеджера — дает огромный буст к мотивации и чувство драйва. То есть, счастливы и заказчики, и команда. Именно это невозможно при подходе, описанном автором оригинального поста.
Спринт обычный, фиксированный. Сроки оцениваются не для спринта, а для фич, которые бывают разными и могут делаться в несколько спринтов или просто уезжать вперед из-за нехватки времени в текущем или следующем.
То, что команда сама выполняет функции менеджера — дает огромный буст к мотивации и чувство драйва. То есть, счастливы и заказчики, и команда. Именно это невозможно при подходе, описанном автором оригинального поста.
Скажу больше: «это займёт Х часов работы» — тоже оценка приблизительная. Потому что в одном случае (человек сидит и Х часов занимается только этой задачей) это действительно займёт Х часов, а в другом (когда ему приходится N раз переключаться на другие задачи) это может занять произвольное количество часов, вплоть до бесконечности. Поэтому любые оценки адекватно работают только для очень коротких временных интервалов (именно отсюда стремление к коротким спринтам в agile). Но тут есть небольшой обман — управляемость улучшается, а результативность — вовсе не обязательно.
Раз идет речь о мотивации и сроках, есть опыт одной дизайн студии.Как мы понимаем это на 20%творчество и 80% «отрисовки» (в данной ситуации 3D моделей), что очень похоже на разработку новых продуктов в IT. Сотрудникам давали конкретные сроки на выполнение задачи и очень жестко спрашивали с них.Но порядок выполнения был 2-3 недели, а не часы или дни.Сроки брались из опыта работы студии.
Основная фишка была очень банальна, но давала высокий результат.Сотрудники могли выполнять работу когда им вздумается и никто в течении этого времени у них ничего не спрашивал и не требовал предварительный результат.Члены команды приходили иногда в воскресенье после обеда на работу, кто любил поспать мог работать с 13-14 и сидел до поздней ночи просто потому что ему так было лучше, а иногда и вообще не приходил так как вчера перебрал в пабе))Результат всегда был отличный и очень креативный. Если же дедлайн был близок, то никто не поливал грязью начальство, так как оно всегда виновато по определению, а просто пахал круглые сутки и был счастлив.
Погорив по душам с некоторыми этими сотрудниками я для себя определил так:
— людям нравиться когда им доверяют и считают их профессионалами.
— всем нравиться самостоятельность ( хотя она мнимая, но все же...). Ты вроде как сам себе начальник.
— возможность решать личные вопросы и не быть привязанным к рабочему времени.
Думаю некоторые из этих практик можно применять и в разработке, хотя и с большой осторожностью. Но там где нужен креатив, а не конвейер по-другому очень сложно. Особенно долгосрочно.
Основная фишка была очень банальна, но давала высокий результат.Сотрудники могли выполнять работу когда им вздумается и никто в течении этого времени у них ничего не спрашивал и не требовал предварительный результат.Члены команды приходили иногда в воскресенье после обеда на работу, кто любил поспать мог работать с 13-14 и сидел до поздней ночи просто потому что ему так было лучше, а иногда и вообще не приходил так как вчера перебрал в пабе))Результат всегда был отличный и очень креативный. Если же дедлайн был близок, то никто не поливал грязью начальство, так как оно всегда виновато по определению, а просто пахал круглые сутки и был счастлив.
Погорив по душам с некоторыми этими сотрудниками я для себя определил так:
— людям нравиться когда им доверяют и считают их профессионалами.
— всем нравиться самостоятельность ( хотя она мнимая, но все же...). Ты вроде как сам себе начальник.
— возможность решать личные вопросы и не быть привязанным к рабочему времени.
Думаю некоторые из этих практик можно применять и в разработке, хотя и с большой осторожностью. Но там где нужен креатив, а не конвейер по-другому очень сложно. Особенно долгосрочно.
Как правило, ответом на вопрос «успеем ли мы к заданному сроку» является аналитика и MVP, качественная инфраструктура разработки и размер технического долга, а именно сложность проведения рефакторинга и наличие автоматических тестов на регрессию.
Сколько тысяч автоматических тестов на поддержке сейчас? И сколько человек из 150 заняты этой задачей? Мигают ли они, сколько там технического долга?
Это вопросы с продолжением. Продолжение в том, что инфраструктура и автотесты не даются бесплатно. Если они работают всегда, без долгов, возможно, кто-то из команды с работы не выходит
150 тестеров — это всего в Контуре, в разных командах разработки.
Я работаю в команде, про которую в конце статьи пишут. Могу рассказать что-нибудь :)
3000 тестов UI с поднятием приложения, 3000 API тестов с поднятием приложения, 10000 юнит-тестов. В прогоне из-за нестабильностей падает 0-7 тестов.
У нас 6 тестировщиков и регрессия покрыта тестами полностью. Это верно, что мы тратим много сил на это. Но без овертаймов. Если бы не тратили, у нас было бы больше тестеров(16?), потому что ручной регресии было бы очень много. Кажется, в нашей ситуации 6 тестеров и автоматическая регрессия выходят дешевле, чем 16 тестеров и «какие-то» автотесты.
Я работаю в команде, про которую в конце статьи пишут. Могу рассказать что-нибудь :)
3000 тестов UI с поднятием приложения, 3000 API тестов с поднятием приложения, 10000 юнит-тестов. В прогоне из-за нестабильностей падает 0-7 тестов.
У нас 6 тестировщиков и регрессия покрыта тестами полностью. Это верно, что мы тратим много сил на это. Но без овертаймов. Если бы не тратили, у нас было бы больше тестеров(16?), потому что ручной регресии было бы очень много. Кажется, в нашей ситуации 6 тестеров и автоматическая регрессия выходят дешевле, чем 16 тестеров и «какие-то» автотесты.
Спасибо за ответ. Ощущение, что в статье что-то не рассказано, уменьшилось.
Здорово, что тесты не мигают. Важна история, что тестов много и на их поддержку уходит много времени. Как понимаю, это основная работа, значит команда — команда автоматизаторов. Редкая.
Также важны люди. Фактором успеха может быть конкретная команда из 6-ти человек, которая достаточно квалифицирована, слажена, стабильна, дружна. И в такой команде любой метод работы, особенно тот, где полное доверие и нет микроменеджмента даст просто прекрасный результат.
И если две такие команды встретятся и начнут обсуждать, что важнее в их работе. Одна будет говорить: «У нас нет сроков», — а вторая отвечать: «А у нас есть сроки, и всё просто замечательно». И обе правду говорят :). Значит критерий оценки не самый точный.
Работаю в команде, про которую ещё статей не написано. Команды гибкие. Ближе всего к команде из трёх человек. Мы просто делаем работу, делаем хорошо. Иногда мы обсуждаем сроки и приоритеты. Но это в те моменты, когда работы свалилось по 10+ задач на человека. А когда горизонт планирования 1-2 задачи на человека, а все остальные пока не важны, то обсуждения приоритетов нет.
Здорово, что тесты не мигают. Важна история, что тестов много и на их поддержку уходит много времени. Как понимаю, это основная работа, значит команда — команда автоматизаторов. Редкая.
Также важны люди. Фактором успеха может быть конкретная команда из 6-ти человек, которая достаточно квалифицирована, слажена, стабильна, дружна. И в такой команде любой метод работы, особенно тот, где полное доверие и нет микроменеджмента даст просто прекрасный результат.
И если две такие команды встретятся и начнут обсуждать, что важнее в их работе. Одна будет говорить: «У нас нет сроков», — а вторая отвечать: «А у нас есть сроки, и всё просто замечательно». И обе правду говорят :). Значит критерий оценки не самый точный.
Работаю в команде, про которую ещё статей не написано. Команды гибкие. Ближе всего к команде из трёх человек. Мы просто делаем работу, делаем хорошо. Иногда мы обсуждаем сроки и приоритеты. Но это в те моменты, когда работы свалилось по 10+ задач на человека. А когда горизонт планирования 1-2 задачи на человека, а все остальные пока не важны, то обсуждения приоритетов нет.
Хочу уточнить, что наша основная работа — это искать баги в задачках всеми доступными средствами и способствовать быстрым релизам.
А автотесты пишем и поддерживаем всей командой разработки (разработчики, аналитики, тестировщики). Потому и обходимся без отдельных автоматизаторов.
Про критерии выбора тоже хочу добавить. Можно выбирать по полезности, эффективности и такому вот. Есть еще один: личный комфорт. Мне очень стремно делать оценки по отдельным задачам:
И пока я не вижу значимых плюсов оценки сроков по отдельным задачам, мне неясно, зачем впускать вот это все в мою жизнь. Я уже так работал и больше не хочу.
А автотесты пишем и поддерживаем всей командой разработки (разработчики, аналитики, тестировщики). Потому и обходимся без отдельных автоматизаторов.
Про критерии выбора тоже хочу добавить. Можно выбирать по полезности, эффективности и такому вот. Есть еще один: личный комфорт. Мне очень стремно делать оценки по отдельным задачам:
- Это само по себе сложно, неточно и все время ошибаешься. Ошибаться раздражает.
- Кроме этого, на твои оценки неявно начинают полагаться другие люди. А когда ты в оценки не попадаешь, они ощущают негатив по отношению к тебе. Это портит отношения.
- Даже если за ошибки не ругают, то раздражает, когда при непопадении в оценку какой-то другой человек приходит «разбираться, а что пошло не так». Это тоже психологическое давление, как бы его ни оправдывали :)
И пока я не вижу значимых плюсов оценки сроков по отдельным задачам, мне неясно, зачем впускать вот это все в мою жизнь. Я уже так работал и больше не хочу.
Sign up to leave a comment.
Оценка сроков на разработку и тестирование задачи (не нужна)