Это как раз просто лечится. Задача с оценкой больше 8 календарных часов (одного рабочего дня) — это исключение, которое должно быть обосновано.
Если задача получается больше 1 рабочего дня, почти всегда она может и должна быть декомпозирована, оценена на уровне подзадач и, очень часто, еще и распараллелена.
Кажется, вы относитесь к числу тех разработчиков, которым интересны задачи, но безразличны продукт и пользователи. Для вас рецепта счастья и у меня, к сожалению, нет.
Кстати, о хамстве. Если вы внимательно перечитаете все мои комментарии, вы увидите, что я нигде не касаюсь ваших личных качеств. Только того, что вы написали и должности, от имени которой вы это сделали.
А обижаться на то, что комментарии по этому поводу жесткие, с вашей стороны странно, ведь вы в своем тексте в агрессивной форме обесцениваете лично мои профессиональные достижения и достижения еще многих и многих людей, что неприятно :)
Думаю, с таким скиллом вы можете рассчитывать на +20% к рынку и/или действительно интересные задачи и драйв на работе. Но увы, компаний, которые умеют нанимать таких разработчиков и грамотно управлять ими и вправду, похоже, очень немного. Зато работа там — это будет experience of a lifetime.
А сколько процентов разработчиков и тестировщиков Контура работают в этих двух продуктах? :)
Я могу только очень скромно похвастаться трехкратным ростом за прошлый год моего маленького продута с десятками клиентов. Но я и делал его на свои, у меня нет 12-14 миллиардов рублей выручки в год =)
А если серьезно, то я написал про конкретную ситуацию в Контуре, где много сотен разработчиков, которые могли бы сделать десятки продуктов. Причем, я знаю, очень качественных продуктов.
И эти сотни разработчиков делали бы крутые штуки в состоянии драйва. Причем у Контура есть такой опыт.
А тут менеджер всех тестировщиков, по сути, призывает сидеть в теплом липком болотце безрезультатного комфорта :)
Я прошу прощения, конечно, но при тщательном перечитывании комментария не увидел ровно никакого хамства.
Живущие в мире дедлайнов разработчики получают именно то, за чем пришли в профессию: они видят, как на глазах развивается продукт, как клиенты начинают использовать новые возможности, принимают непосредственное участие в определении судьбы продукта и живут в состоянии драйва.
По поводу гигантских трудозатрат на планирование. Во время планирования находятся и описываются решения всех попавших в планирование задач. В оставшиеся дни итерации остается только написать код, потому что все решения уже приняты и почти все головоломки решены.
Оверхед возникает из-за того, что оценивание задач обязательно проводится коллективно.
Во-первых, в достаточно большом проекте не все одинаково владеют всеми кусками кода, и более компетентные в какой-то части функциональности разработчики помогают сразу принимать правильные решения.
Во-вторых, коллективная оценка не позволяет скатиться в завышение и, что не менее важно, в занижение оценки задачи.
С овертаймами — тут уж у кого как. Если команда адекватная и не позволяет занижать оценку, кранчи бывают редко и, как правило, компенсируются периодом расслабленности после очередного релиза.
Клиент завязался на обязательства Компании поставить фичу в срок, Компания завязалась на обязательство Разработчика выпустить эту фичу в срок. Разработчик не выдержал сроки, Клиент потерял деньги, Компания потеряла Клиента, Разработчик потерял работу.
Не надо считать разработчиков единороговыми понями в вакууме, их работа и их косяки имеют реальный экономический эффект, который прилетает к ним бумерангом так или иначе.
Проблема завышения сроков при этом действительно существует, и работа менеджера и руководства — найти такой баланс пряника и кнута, при котором система устойчиво работает.
Одним из лучших решений для создания такого непростого баланса как раз являются «скрамообразные процессы», которые позволяют и контролировать сроки, и не скатываться в завышение оценок, и сохранять хороший моральный климат.
Ну тогда я попрошу список трейд-оффов, которые вы сможете порешать до конца этой недели, а какие решите в течение следующей :)
Тут надо понимать, что либо вы работаете в динамично развивающемся продукте, где каждая новая возможность — это счастье или уход пользователей и часто целые новые пласты клиентов, ресурсов не хватает, а впереди маячит вкусный приз, либо в проекте, где ничего от релиза вашей фичи не поменяется, по большому счету, и срок ее релиза вообще не имеет значения.
Во втором случае заморачиваться вопросами сроков и эффективности нет никакого смысла. А в первом случае в работе не бывает задач без дедлайнов :)
При хорошей организации работы мы выделяли на планирование первые 1-2 дня двухнедельной итерации. Это и прекрасно работало, и прекрасно воспринималось, потому что любому, пришедшему на такое планирование, было очевидно, что это крайне напряженный рабочий процесс.
Автор оправдывает атмосферу расслабленности и вялости, и пропагандирует подход, не раз лишавший активных разработчиков мотивации у меня на глазах. А я очень страдаю, когда такое вижу :)
Возможно, именно из-за такого подхода Контур за последние 5+ лет не выпустил ни одного заметного нового продукта при таком безумном количестве разработчиков (и 150(!) тестировщиках) ;(
Ну вот я полтора года напряженной работы выдавал вместе с командой (а без команды и не смог бы) точные сроки на периоды от двухнедельной итерации до полугодового релиз-плана. И выдавал обоснованно и точно. А вы мне (и всем присутствующим) объясняете, что сроки — ложь :)
А откуда бизнесу брать реальные оценки сроков вы и вовсе тактично умалчиваете.
На практике из-за такого отношения к срокам почти десять лет может потребоваться, чтобы убрать баклажанный цвет с одной единственной страницы, если вы понимаете, о чем я ;(
Максим написал, к чему это приводит, если не управлять процессом оценки.
И не написал, что бывает, когда бизнес заложился на оценку взятую менеджером с потолка, а не от специалистов, которые глубоко в теме и хорошо подумали.
И еще Максим не написал, что бывает, когда эта «спотолочная» оценка спускается менеджером самим разработчикам, а они вполне обоснованно относятся к ней и к этому менеджеру по принципу «ты ковбой, ты и прыгай».
В следующих трех абзацах абсолютно искусственно противопоставляются вещи, которые для разработчика с точки зрения оценки не отличаются: «я потрачу на эту задачу день» превращается в «эта задача будет готова через день» в тот момент, когда разработчик начинает над ней работать.
Автор ниоткуда вытаскивает мысль, что, якобы, разработчик будет закладывать себе резерв времени если его спросить о конкретном времени завершения (что верно), и не будет, если его просто попросить оценить количество часов, которые ему потребуются с момента старта работы над задачей (что неверно).
Потому что разработчик знает, что команда будет одинаково его порицать за безответственность при любом из способов срыва сроков :)
Если задача получается больше 1 рабочего дня, почти всегда она может и должна быть декомпозирована, оценена на уровне подзадач и, очень часто, еще и распараллелена.
Когда у ваших разработчиков во время спринта горят жопы, значит вы что-то совсем не то с ними делаете!
У разработчиков в состоянии драйва должны гореть глаза! Глаза!
А обижаться на то, что комментарии по этому поводу жесткие, с вашей стороны странно, ведь вы в своем тексте в агрессивной форме обесцениваете лично мои профессиональные достижения и достижения еще многих и многих людей, что неприятно :)
Я могу только очень скромно похвастаться трехкратным ростом за прошлый год моего маленького продута с десятками клиентов. Но я и делал его на свои, у меня нет 12-14 миллиардов рублей выручки в год =)
И буду очень признателен, Максим, если вы покажете мне эти крутые штуки на kontur.ru. А то вдруг я просто не ЦА и пропустил какие-то анонсы :)
А если серьезно, то я написал про конкретную ситуацию в Контуре, где много сотен разработчиков, которые могли бы сделать десятки продуктов. Причем, я знаю, очень качественных продуктов.
И эти сотни разработчиков делали бы крутые штуки в состоянии драйва. Причем у Контура есть такой опыт.
А тут менеджер всех тестировщиков, по сути, призывает сидеть в теплом липком болотце безрезультатного комфорта :)
Живущие в мире дедлайнов разработчики получают именно то, за чем пришли в профессию: они видят, как на глазах развивается продукт, как клиенты начинают использовать новые возможности, принимают непосредственное участие в определении судьбы продукта и живут в состоянии драйва.
По поводу гигантских трудозатрат на планирование. Во время планирования находятся и описываются решения всех попавших в планирование задач. В оставшиеся дни итерации остается только написать код, потому что все решения уже приняты и почти все головоломки решены.
Оверхед возникает из-за того, что оценивание задач обязательно проводится коллективно.
Во-первых, в достаточно большом проекте не все одинаково владеют всеми кусками кода, и более компетентные в какой-то части функциональности разработчики помогают сразу принимать правильные решения.
Во-вторых, коллективная оценка не позволяет скатиться в завышение и, что не менее важно, в занижение оценки задачи.
С овертаймами — тут уж у кого как. Если команда адекватная и не позволяет занижать оценку, кранчи бывают редко и, как правило, компенсируются периодом расслабленности после очередного релиза.
Клиент завязался на обязательства Компании поставить фичу в срок, Компания завязалась на обязательство Разработчика выпустить эту фичу в срок. Разработчик не выдержал сроки, Клиент потерял деньги, Компания потеряла Клиента, Разработчик потерял работу.
Не надо считать разработчиков единороговыми понями в вакууме, их работа и их косяки имеют реальный экономический эффект, который прилетает к ним бумерангом так или иначе.
Проблема завышения сроков при этом действительно существует, и работа менеджера и руководства — найти такой баланс пряника и кнута, при котором система устойчиво работает.
Одним из лучших решений для создания такого непростого баланса как раз являются «скрамообразные процессы», которые позволяют и контролировать сроки, и не скатываться в завышение оценок, и сохранять хороший моральный климат.
Тут надо понимать, что либо вы работаете в динамично развивающемся продукте, где каждая новая возможность — это счастье или уход пользователей и часто целые новые пласты клиентов, ресурсов не хватает, а впереди маячит вкусный приз, либо в проекте, где ничего от релиза вашей фичи не поменяется, по большому счету, и срок ее релиза вообще не имеет значения.
Во втором случае заморачиваться вопросами сроков и эффективности нет никакого смысла. А в первом случае в работе не бывает задач без дедлайнов :)
Возможно, именно из-за такого подхода Контур за последние 5+ лет не выпустил ни одного заметного нового продукта при таком безумном количестве разработчиков (и 150(!) тестировщиках) ;(
А откуда бизнесу брать реальные оценки сроков вы и вовсе тактично умалчиваете.
На практике из-за такого отношения к срокам почти десять лет может потребоваться, чтобы убрать баклажанный цвет с одной единственной страницы, если вы понимаете, о чем я ;(
И не написал, что бывает, когда бизнес заложился на оценку взятую менеджером с потолка, а не от специалистов, которые глубоко в теме и хорошо подумали.
И еще Максим не написал, что бывает, когда эта «спотолочная» оценка спускается менеджером самим разработчикам, а они вполне обоснованно относятся к ней и к этому менеджеру по принципу «ты ковбой, ты и прыгай».
Автор ниоткуда вытаскивает мысль, что, якобы, разработчик будет закладывать себе резерв времени если его спросить о конкретном времени завершения (что верно), и не будет, если его просто попросить оценить количество часов, которые ему потребуются с момента старта работы над задачей (что неверно).
Потому что разработчик знает, что команда будет одинаково его порицать за безответственность при любом из способов срыва сроков :)