Comments 30
Картинка просто огонь! :) Статья тоже, спасибо
-Фича нужна бизнесу в продакшне раньше чем due date?
-Разработчик «срезает» углы, чтобы успеть в due date?
Так мы пытаемся избежать ситуации коллективной ответственности: ведь если за что-то отвечают все, значит, де-факто не отвечает никто.
Я не совсем согласен с этим правилом, считаю (надеюсь) оно устарело.
У него есть и обратная сторона — если за задачу ответственен только один человек, то все проблемы этой задачи — только его проблемы. У других и СВОИ задачи есть. Мне кажется это негативно сказывается на командном взаимодействии.
Мне видится более эффективным (хоть и редким, но мне случалось) командная ответственность. Речь идет, конечно, о стабильных и кроссфункциональных командах размером 5-7 человек.
Спасибо.
Пойдем по пунктам.
1) Как быть, если «Фича нужна бизнесу в продакшне раньше чем due date?». Due date это в первую очередь бизнесовый показатель. Если фича нужна раньше, чем Due date, это значит что Due date = раньше :). Понятно что бывает так, что бизнес требует почти невозможного. Но если задуматься, то все что мы делаем, нужно в первую очередь именно бизнесу. И если получилось так, что мы должны к определенному сроку дать какой-то продукт, то надо выложиться по полной, но сделать. Мы нередко делаем MVP-продукт. Это когда мы компромиссным путем в кратчайшие сроки даем на выход результат, который позволяет прощупать концепт. И если он «летит», то полируем фичу дальше.
2) Во-первых, надо регулярно с менеджером проверять результат на промежуточных этапах, а во-вторых, если мы делаем прагматично и полезно бизнесу, то это не всегда означает что мы делаем плохо, верно? Может быть оно с архитектурной точки зрения не всегда оптимально, но нашим пользователям зачастую наплевать как оно сделано изнутри. Если фича сделана так, что ее можно «продать» пользователю, значит она сделана «на отлично». При этом мы сразу делаем оговорку, что возможно в будущем надо будет делать рефакторинг, или даже полную переделку — это все технический долг.
3) По поводу коллективной ответственности, и «устаревшего правила» — я даже рад что бывают альтернативные мнения. С другой стороны, есть зарекомендовавший себя подход и правила, а есть мода. И если автомат Калашникова работает, несмотря на то что он «устарел», может это значит что он не так уж и плохо сделан?
Спасибо за ваше мнение!
Какие цели могут быть у обычного человека, даже если учитывать, что средний IQ в нашей отрасли высокий? Заработать денег и уехать на Бали, купить квартиру, накопить на старость, выплатить кредит, купить гитару Gibson, уйти пораньше с работы, сходить вечером в кино и познакомиться с симпатичной соседкой.
То есть никаких целей, связанных с работой, нет совсем?
Судя по тому, что вы пишете после этой фразы, это очевидно не так. Для людей есть смысл в работе, и это важно не менее зарплаты.
Ну мне кажется, что Вы придираетесь. Там была и такая фраза:
"поскольку речь об айтишниках, накинем ещё: разобрать беклог на работе, воспроизвести надоевший баг...".
И даже такая:
"Разумеется, есть отличные ребята, которые «болеют за проект» и «понимают бизнес», – ведь мы вместе работаем над общим делом.".
Да и это явно не является суть статьи. :)
Если вы обратили внимание, я даже сделал оговорку о том, что я намеренно утрирую и «сгущаю краски» при приведении примеров. Reductio ad absurdum — это специальный полемический прием, позволяющий наиболее красочно показать те или иные аспекты обсуждаемой проблемы.
Разумеется у разных людей цели разные. И я очень рад, что есть ребята, которых просто драйвит делать крутые вещи. Это прикольно и здорово мотивирует. Моя же цель в том, чтобы сделать процесс, работающий в большинстве случаев. Даже тогда, когда у людей внутренней мотивации не вполне достаточно.
Удачи!
Здравствуйте, Илья!
Вот тут наши позиции расходятся. На мой взгляд, основа не процессы, а обстановка, которая позволяет раскрываться способностям людей, делает их работу осмысленной, люди получают от неё удовольствие. Очень надеюсь, что у меня получается двигаться в этом направлении.
Вам тоже удачи!
В статье я намеренно упоминаю инженерную культуру, в это широкое понятие входит и обстановка тоже. Когда работаешь в окружении крутых ребят, чувствуешь себя мотивированным делать крутые вещи.
И частью своей работы и работы других менеджеров считаю как раз воспитание инженерной культуры и взращивание той самой обстановки, в которой людям драйвово работать. Процессы — один из механизмов, позволяющих эту самую культуру развивать.
ой не льстите айтищникам.
Статья дельная. Обсуждая цели компании и работника, то задача менеджмента поставить «правильного» человека в «правильное» место, как пазл в картинке. Правильность заключается в том, чтобы обязанности позиции совпадали с личным интересом человека на текущий момент и осуществлять над этим контроль.
Из личного примера, очень непросто найти даже хорошую уборщицу — человека который любит чистоту и порядок, а главное ему нравится приводить помещение в порядок. Так и с программистами и со всемы остальными.
то у сотрудников цель противоположная: сделать как можно меньше и получить за это как можно больше
O'RLY? Смею предположить, что это, мягко говоря, не так. Особенно если в вашей компании толковые разработчики.
Спасибо за ваш комментарий.
В нашей компании разработчики очень толковые. А в вашей?
It depends. Иными словами, не все. Наша основная проблема в том, что многие утверждают "задача выполнена", когда на деле — нет. классическая такая "Developer calls it done".
Лично меня разбирает сарказм, когда в попытке угодить менеджменту и срокам сверху разработчики упускают слишком много дефектов.
Я борюсь за Scrum's "done-done-done". Чаще всего, это требует замедления команды. И как правило, это воспринимают это как элементарное "сделать как можно меньше и получить за это как можно больше", а не как профессионализм и борьбу за Качество.
Так яснее?
Да, между "готово" у разработчика и "принято" у кастомэра ещё целая уйма задач, разработчика особо не касающихся и это проблемы продукт оунера/менеджера. Но в статье как-то акцентируется внимание на том, что разработчик несёт за всё ответственность, хотя вовремя сделанная разработчиками фича может не попасть в продакшн по целому ряду других причин. Pipeline сломат, QE несогласны, т.к. напрограммировали по одним требованиям, а тестируют по другим, performance просел, не дали времени на внятную валидацию и многое другое.
уйма задач, разработчика особо не касающихся:
"Pipeline сломат" — это моя проблема.
"QA несогласны" — это моя проблема.
"performance просел" — это моя проблема.
"не дали времени на..." — это проблема либо моя (плохо сигнализирую "красные флаги"), но чаще — менеджмента с "датой наперед" в голове плюс с пресловутым "и так сойдет".
За pipeline должны отвечать всякие release инженегры.
За то, что QA тестирует по требованиям, которых разработчики не видели, последние ответственность нести не должны, я это специально оговорил.
Если требований по performance также не было, то это тоже не проблемы разработчиков.
В противном случае разработчик превращается в человек-оркестр, обязанный всем и вся, а также обязанный предугадать, сколько миитингов запланирует ему менеджер отняв у него время, когда он заболеет, сколько необходимой ему документации отсутствует — только чтобы оценить не очень нужный ему дъю дэйт. И такой разработчик довольно быстро уйдёт из Badoo. А разработчик ресурс ценный и на дороге не валяется, это чтоб ваш бизнес знал (а он таки знает). По моим наблюдениям все срывы сроков происходят по большей части из-за организационного бардака в компаниях и некомпетентности менеджеров, у которых 7 пятниц на неделе и 8 митингов. Почему-то современные методологии уходят от понятия физического времени, заменяя их story pointами. И задача менеджеров конвертировать story points в физическое время и даты, разработчика это парить вообще не должно.
Я так и ожидал, что будет ответ вроде «по-разному бывает». Это нормально, именно для того мы правила задаем и процессы создаем, чтобы в коллективе могли работать и приносить пользу компании практически все. И понимающие и не понимающие. И согласные и не согласные.
И здорово, если в компании все разработчики толковые и понимающие. Но что если не все? Или как вновь прибывших внедрять и воспитывать правильно?
Многие из моих утверждений в статье спорные. Это сделано намеренно, чтобы читатель задумался, задал себе вопрос «какого фига?». А может и в комментариях со мной подискутировал :)
Честно говоря, много текста, содержащего лишь банальность, которая, кроме прочего ещё и разбивается при первом же столкновении с реальностью. Работники внезапно берут дэйоффы по срочным делам, заболевают, кто-то отключает электричество в лабе, интернет и ещё более 9000 причин мелких помех. Дъю дэйт хорошо подходит для фичи, над которой работает как минимум несколько чедовек, чтобы неизбежно возникающие ауты сглаживались в предсказуемую статистику, среднюю температуру по больнице. Спрашивать дъю дэйт с каждого одного человека не слишком корректно и попахивает карательным микроменеджментом.
Очень интересная методология, жаль ничего не понял(
Вот у вас есть некий похапе разработчик Вася и вы пытаетесь внедрить ему ответственность и kpi. И есть Петя из компании ХХивПрод.
- Вася, когда эта фича будет готова на проде?
Ну 31 февраля (через X дней) — это наш DueDate
- Петя, сколько делать эту фиговину (декомпозицию задачи мы не умеем)?
- Ну, наверное, дней X — это некая оценка сложность задачи
В чем между ними разница? Если только Вася все X дней не занимается ничем другим, кроме своей задачи (у Пети X дней спринта "заняты" или просто менеджер понимает, что такой вот расход ресурса). Вариант с Васей разве лучше для вашего бизнеса?
Должны ли оценки Пети и Васи отличаться? Может быть Вася должен продумать что-то еще помимо "накину еще n дней на всякий случай", которых вы хотите избегать?
Нужна ли эта дата бизнесу? Судя по вашему комментарию, нет — не нужна. У вас там MVP, "если бизнесу надо — бизнес сам дату придумает". Если у бизнеса нет даты, то ему надо "чем быстрее, тем лучше", но быстрее чем будет готово оно все равно не появится.
Будут ли различия в части депремирования для Пети, не угадавшего время реализации и Васи, не угадавшего дату "на проде"? Похоже, что Вася не пострадает — он же дал оптимистичный прогноз. Просто у него коэф. к премии немного ухудшится (kpi жи).
Каким образом наличие due date дает «ответственность разработчика» за результат тоже не понятно. И чем эта ответственность отличается от ответственности Пети за результат?
Если Вася еще и "типаменеджер" своей задачки, то может ли он что-то требовать (соблюдения сроков от тестировщиков, перерисовки макета от дизайнера, изменений в логике и т.д.)? если это все надо согласовывать с настоящим менеджером, то это прям ответственная ответственность.
В примере вот есть — Вася не осилил дизайн, завалил сроки. Надо рисовать гайдлайны. А кто рисовать то будет? Вася или дизайнер? и кто поставит этому художнику задачу?
В итоге я умудрился в статье прочитать, что вы придумали некую никому не нужную дату, которая должна внедрять инжЫнерный подход у хороших разработчиков (а плохих вгонять в стресс "ой не успею" или перезакладываться, но таких, слава богу, в баде нет)
С точки зрения дат, ситуация Васи и Пети не отличается ничем. А вот с точки зрения ответственности, отличается. В чем преимущество Васи? В том, что он — «пушер». Он «драйвер» и двигатель всех процессов. Может ли он что-то требовать? Может, если это ему поможет сделать задачу эффективнее. Он может просить, убеждать, требовать, взывать к помощи менеджера — не важно.
Если задачу во время не сделал Петя, то ничего страшного. Ну не сделал, и не сделал. А вот для Васи любой исход означает вопрос: «как сделать быстрее»? Его не оштрафуют. Но его обязательно спросят, как быть быстрее в следующий раз.
Про пример с гайдлайнами и вопросом кто будет рисовать — это неважно. Пушить процесс будет Вася. Если он нарисует лучше чем дизайнер, то хорошо. Но скорее всего, дизайнет нарисует лучше. А вот прийти к дизайнеру и направить его на путь истинный должен Вася. Если он прийдет к дизайнеру и тому некогда, то Вася может заказать дизайн на стороне (я сейчас совсем-совсем утрирую, но надеюсь, суть понятна).
Не важно кто и что делает, у кого хватает ресурсов и у кого есть желание что-то делать. Главное — результат. И для его достижения нужна какая-то цель. Такой «универсальной целью» во многих ситуациях и выступает Due date.
Конечно, Володе не хочется знать ни про какие дедлайны, не хочется общаться с продакт-менеджером, дизайнерами, бухгалтерами – ему хочется сесть и погрузиться в свою интересную задачу (и чтобы никто не мешал). И в этих условиях сроки, планы, заказчики, конкуренты – это суровая реальность, с которой Володя вынужден мириться, но не часть стратегической цели, как в случае с продакт-менеджером.
Прямо с болью в сердце читаю. Т.е. Володя все-таки должен общаться с продакт-менеджером, дизайнерами, бухгалтерами (?!)?
Разработчик устанавливает срок задачи в виде Due date. Это срок, когда задача окажется на продакшене.
Технический менеджер должен подтвердить срок Due date. Хорошо бы, чтобы он сделал это, предварительно самостоятельно изучив проект, и сразу указал на факторы, способные повлиять на сроки в будущем. Коучить нужно начинать уже на этом этапе.
С определённой периодичностью, оговорённой заранее, менеджер должен проверять статус вместе с разработчиком: рассматривать проблемы, которые уже могли возникнуть, и процессы, которые уже можно ускорить. Пример: «Почему ревью трёх строк кода заняло три дня?»
После завершения проекта в любом случае нужно делать ретроспективу и ставить вопрос: как в следующий раз сделать быстрее?
Я вот читаю, что у меня и у технического менеджера должно быть много свободного времени.
А что если каждая новая задача является для меня и моего технического менеджера новой? В общем и целом, мы не сомневаемся, что ее можно решить, но сколько займет ее выполнение — никто адекватно сказать не в силах. При этом мы оба находимся в середине другого проекта. А ответ по оценке сроков нам надо дать на следующий день. И мы даем. Естественно, обманывая, а потом накидываем n дней. Раза 3-4.
А потом в середине уже этого проекта, когда уже понятно, что не вывозим, я, находясь в глубокой отладке, я не буду (из комментария выше)
просить, убеждать, требовать, взывать к помощи менеджера
Во-первых, он занят более глобальными задачами, которые перед ним ставит бизнес и суровая реальность. Видели бы вы тоску в его глазах, когда я очередной раз появляюсь на пороге…
Во-вторых, какую помощь он может дать? Дать людей? Допустим, люди есть, но все упирается в то, что мне надо отвлечься от своей отладки и выдумать такую декомпозицию, которая помогла бы часть работы передать другому разработчику. При этом время уйдет на потери взаимодействия, а еще этот другой разработчик, скорее всего попросит какие-нибудь API-заглушки, чтобы он смог поставленную задачу решить за один присест, не возвращаясь к ней по мере реализации функционала с моей стороны. И мне надо будет написать все заглушки, а потом мы вместе будем заниматься соединением одного с другим, поскольку у него ни времени, ни желания сильно погружаться в мои замыслы нет, ему надо задачу в треккере закрыть. В общем, после пяти минут таких сомнений я иду не за помощью, а за кофе и яблочным пирогом.
Конечно, это все следствие моей некомпетентности, ряда ошибок в организации работы, бла-бла-бла, но вот так, что поделать, надо жить дальше. И я не думаю, что это редкость. Я думаю, наоборот, многие команды (точнее, их руководства) берутся за проекты, о которых не имеют исчерпывающего представления. А потом будет другой, еще менее понятный на этапе оценки сроков, и вся предыдущая ретроспектива окажется просто трепом.
Еще из комментария выше:
А вот прийти к дизайнеру и направить его на путь истинный должен Вася. Если он прийдет к дизайнеру и тому некогда, то Вася может заказать дизайн на стороне (я сейчас совсем-совсем утрирую, но надеюсь, суть понятна).
Нет, вообще не понятна суть. Я не могу на стороне. Нет никакой стороны, есть NDA с заказчиком. Мы, скорее всего вместе с техническим менеджером пойдем к руководству с призывом надавить на дизайнера. Дизайнер — хороший человек, занятой, ценю и уважаю, но…
Т.е. Володя все-таки должен общаться с продакт-менеджером, дизайнерами, бухгалтерами
Угу. Если Родина требует, то куда деваться?
Я вот читаю, что у меня и у технического менеджера должно быть много свободного времени.
А я считаю что я не должен ходить на работу. Но иногда все-таки нужно, верно?
Видели бы вы тоску в его глазах, когда я очередной раз появляюсь на пороге…
Видел, и много раз. Но есть «хочу», а есть «нужно».
какую помощь он может дать? Дать людей?
Очень сильно зависит от. Увеличить людей — самый простой способ. Утверждаю что есть еще масса вещей, которые стоит попробовать. Главное — результат. А как каждый конкретный Володя его добьется — дело десятое. За это мы Володь и ценим.
Нет, вообще не понятна суть. Я не могу на стороне.
И это прекрасно. Значит у вас нет иного выхода, кроме как «задолбать» своего дизайнера, чтобы он сделал как надо. В этом и суть. У нас нет задачи сделать вам комфортно (уж извините, при всем уважении). У нас задача — дать результат. Следовательно мы пушим всех, и вас в том числе (в данном примере), действовать на результат, выводя вас из зоны комфорта.
очень сомнительная фраза
для кого важнее? и цель у компании одна — получение прибыли
так что думаю, точнее сказать так:
цель (прибыль) компании единственное важное для нее, все остальное только рычаги получения прибыли, включая желания отдельных людей, их неосведомленность, ответственность, энтузиазм и т.д.
Не увидел только рецептов работы с одним из возможных подтипов разработчиков, а именно
людей не способных в принципе даже угадывать срок окончания разработки, и нет, не потому что не понимают проблему или не обладают достаточным уровнем квалификации, а просто вот человек «оптимист» или хуже «спорадический оптимист».
Если, в еще более «устаревшей» классической схеме, ПМ как то смог бы сгладить его due date, исходя из опыта работы и имеющегося персонального для разработчика фактора, то кто и как делает это в вашем случае.
Только не говорите что вы его обучите, здесь речь о существенной части наших коллег которые не способны на это, при всех их заслугах как профессионала.
Due date как компонента ответственности в процессе разработки