Комментарии 14
Очень классная, а главное полезная статья
Статья полезная, особенно для тех, кто часто сталкивается с проблемой дедлайнов
Хорошо раскрыта психология обещаний и советы по управлению сроками и ожиданиями
Про ретроспективы и буферное время особенно актуально)
Автору спасибо
Классная статья, спасибо! У меня есть проблемы с дедлайнами, вечно какой-то аврал. Искала как раз такие статьи) Попробую применять советы, особенно буферное время
Со стороны разработчика могу сказать, что часто прилетают "пятиминутные" правки, на которые ты тратишь до получаса, потому что: 5-10 минут обсудить правку с ПМ-ом, внести правку, а потом сконцентрироваться и вернуться к предыдущей задаче, которую ты делал, когда тебя отвлекли. А если бы эти пятиминутные правки за неделю собрали бы в одну отдельную задачу, то за те же полчаса можно было внести 15 таких правок. Но клиент считает, что это двухминутная задачка и не займёт времени, а ПМ потом удивляется, почему за неделю было сделано на 3-4 часа меньше работ и тумаки летят на "нерадивого разработчика", который не справился с поставленной задачей в срок.
+ разработчик также страдает от того, что может назвать оценку меньше фактической, потому что не хочет расстраивать ПМ-а, руководителя, не выставлять себя "некомпетентным", что за, казалось бы, простую задачу, просит чуть больше времени, чем он мог бы затратить.
Хорошо, если все будут соблюдать правила, описанные в статье, на всех уровнях и, может быть, когда-нибудь дедлайны не будут вызывать у нас нервный тик.
Полностью согласен. Проблема заниженных оценок и сорванных дедлайно ложится не только на ПМа, но и на разраба. Хотя возможные косяки в оценке разработчика теоретически должны обрабатываться ПМом в виде дополнительной итерации оценки, выделение дополнительного времени на риски и т.д. Но это не значит, что мы как разработчики не должны учитывать озвученные в статье идеи при оценке чего бы то ни было.
С "пятиминутными" правками же разработчик (увы) сделать ничего не может, поэтому, по моему мнению, на старте проекта нужно обсудить регламент этих правок. То есть не когда заказчик уже пришел со словами "а вот у нас тут правочка небольшая", а в момент заключения договора указать (хотя бы примерно) какие изменения в сроках/стоимости такие правочки повлекут)
Хорошо, если все будут соблюдать правила, описанные в статье, на всех уровнях и, может быть, когда-нибудь дедлайны не будут вызывать у нас нервный тик.
Найдутся другие способы пролюбить дедлайн) Мы ж опытные люди все тут)))))
Идея с использованием «взвешенного обещания» ничего так, хотя и не новая, но ощутимое преимущество в планировании дает. Было бы здорово добавить, что наличие в команде опытного лида или даже нескольких - необходимость для ПМа. Причем тоже грамотного в отношении планирования. В разработке хватает своих "тараканов".
Взаимодействие со смежными командами, нетривиальные задачи (нужно какое-то время на ресерч).
Но все же, как вы и сказали, всё не предусмотришь и идеальная стратегия планирования выглядит так: "Заглянуть в будущее". Да, это невозможно.
Слушай, реально классно)
По своему опыту могу сказать, что всё что тут написано я ощутил на своём примере и я на 100% согласен с автором)
Часто руководители манипулирую в дедлайнах. Под давлением просят прикинуть сроки завершение проекта, сами дают оговорку « это, конечно, все не точно и если нужно-подвинем». Сначала говорят, что дед-лайн «резиновый», но как только к дате приближаешься-все резко становится иначе… Спасибо за статью, желаю всем не вестись на провокации руководства и работать без горящих ж***)
Вот про то, как бороться с бесконечными правками - бывает анриал, это я вам как человек, который работал на стороне клиента, точно говорю:)) Особенно если клиент крупный и ему безразличны твои процессы, сроки и траты..., а надо небольшой сайт просто сделать, просто так.
У клиента, как правило, находится ответ на все. Обсудить сначала детали? - А нет у меня деталей, мы сейчас с начальником отдела, директором департамента, замом генерального, секретаршей собственника и его начальником охраны назначили совещание на пару часов: согласуем кого и в какой позе фоткать, потом как именно их подписать и т.п., а вы пока просто на своем сайте "квадратики" под наши фотки оставьте, что сложно что ли? Вы что не профессионалы что ли? А за что я вам плачу? Кто такой этот ваш Agile? Он мне вообще не авторитет!
Ну и так далее.
Ну и правило не работать с м**аками тут не всегда применимо - м**даки могут быть крупными и важными для вашего бизнеса.
Отличная статья! Действительно порой хочется побыстрее все, а потом времени не остается, паника и тревожность. Советы хорошие, буду использовать!
Про буферы в каждой задаче (да и в целом - в оценках), имхо, хорошо у Голдратта в "Критической цепи" написано. Закон Паркинсона, к сожалению, не врёт.
Про "пятиминутки" и их реальную трудозатратность - прямо в точку, дельный совет собрать их в импровизированный "тех долг" и раз в период решать. Правда контекст может немного из оперативной памяти уже уйти, но переключение между несколькими задачами всё равно выглядит более трудоёмким, чем вспомнить и быстро поправить.
Но бывают проекты (больше похожие на тех поддержку, конечно) когда требуется моментально внести. Видел условия на уровне договора - ограничение на количество задач с повышенной срочностью, или повышение стоимости таких правок.
Про обещания и манипуляции, коллеги-разработчики говорят, хорошо написано в "Идеальном программисте" Мартина. Если кратко - не надо вестись, не надо обещать пустого :)
Ну и главное - надо помнить, что ПМ и разработчики - одна команда. И вместе должны решать возникающие проблемы. А если и заказчик понимает, что он часть команды проекта - то риски понижаются, а шансы на успех повышаются.
В комментарии ботов нагнали? А по теме, я делаю столько, сколько займёт и ничего не обещаю. Как сделаю, так напишу. Ждите.
Отличная статья. Очередное подтверждение и разъяснение, что в основе практически каждого нарушения дедлайна лежит психология, отсутствие внятного ТЗ и предварительного анализа
Как не обещать лишнего и сдать проект вовремя: спасаем дедлайны и проекты