company_banner

Due date как компонента ответственности в процессе разработки


    В продуктовой разработке постоянно и довольно остро стоит вопрос эффективности. Как построить процесс так, чтобы он был оптимален с точки зрения бизнеса, роста сотрудников, изменяемости, прозрачности и многих других факторов? Где та самая «серебряная пуля», которая позволит решить сразу все проблемы и избавит вас как руководителя от головной боли?


    На звание этой «серебряной пули» по очереди претендуют модные (и не очень) методологии разработки: Scrum, Kanban, XP, RAD, FDD и т. п. Регулярно появляются новые способы и подходы, фреймворки и инструменты. Бизнес-консультанты приходят в компании и делятся своими ноу-хау за немалые деньги, рассказывая, как правильно. А при этом хорошо бы ещё и дёшево, не так ли?


    И здорово, если люди могут сформулировать потребности, которые они хотят удовлетворить с помощью того или иного процесса. Но часто бывает так, что без раздумий просто внедряется модный подход, что в итоге приводит к недовольству участников либо к неэффективности для бизнеса – в современном мире с его высокими темпами, со стартапами и высокой конкуренцией результат подобной неосмотрительности может быть плачевным.


    Давайте подумаем, что требуется от процесса, какие проблемы нужно решить и какие подходы для этого используют. А заодно я расскажу о том, как делаем мы в Badoo. Это уже третий мой пост подряд в нашем блоге на Хабре. Но на всякий случай представлюсь снова: я – Илья Агеев, руковожу QA в Badoo.


    Участники процесса


    Говоря о процессе, в основном говорят об участниках. Есть ещё условия, результат, ресурсы, цель и т. д. Но организация совместной работы таким образом, чтобы она была комфортной и эффективной в большинстве случаев, как раз и подразумевает процесс в фичевой разработке.


    Все работники компании, делающей продукт для пользователей, каждый день приходят в офис с разными целями. Хорошо если эти цели удаётся сбалансировать и совместными усилиями достигать хороших бизнес-показателей. Но очевидно, что у бизнеса и рядовых сотрудников цели и ценности изначально разные. Кто-то копит на жильё, новую машину, отпуск. Кому-то интересно живое общение и личностное развитие. Бизнес же зарабатывает деньги и воспринимает сотрудников как ресурсы, позволяющие достигать поставленных целей.


    Согласитесь, немногие компании существуют просто для того, чтобы платить зарплату сотрудникам, потому что они хорошие люди (если такие вообще есть). Цели другие, хоть и не всегда разделяемые работниками.


    И мне кажется, что в этом сложном симбиозе цели компании всё-таки важнее, чем цели отдельных сотрудников. Хорошая компания ценит и любит свои ресурсы, но с точки зрения бизнеса людей (как и многие другие ресурсы) всегда можно заменить (хоть иногда и очень сложно). А вот изменить глобальные цели – невозможно. Да и странно было бы ожидать это от бизнеса. «Давайте мы теперь вместо того, чтобы печь хлеб, будем давать музыкальные представления на детских утренниках!» Ради чего? Если ради большей прибыли и если это легко осуществить, давайте. Но менять направление бизнеса только потому, что пекарь Володя любит и хочет петь (иначе может уволиться), естественно, никто не станет.


    Следовательно, первым и самым важным участником производственного процесса является сам бизнес. Он, образно говоря, платит и поэтому заказывает музыку. Чего хочет бизнес? Цели очень разные. Начиная с благотворительности и заканчивая трудоустройством родственника (бывает и так). Но всё же в большинстве случаев главной целью является улучшение благосостояния собственников. И желательно с наименьшими затратами. «Как можно меньше потратить и как можно больше заработать» – это азбука рынка.


    В нашем производственном процессе разработки фич представителем бизнеса является продакт-менеджер. Он призван цели бизнеса понять, сформулировать, донести до разработчиков, если потребуется, «разжевать», найти компромисс и всё грамотно спланировать. А затем – проконтролировать процесс, проверить результат и отдать его в эксплуатацию.


    Какие у него цели? Это очевидно: за как можно меньший период времени получить как можно больше сделанной работы. Чтобы и эксперименты провести, проверить идеи на жизнеспособность, и возможные недочёты успеть исправить, и как можно скорее начать зарабатывать деньги на произведённом продукте (я намеренно не говорю о качестве, но подразумеваю его: некачественный товар никто приобретать не будет).


    Поэтому продакт-менеджер и требует постоянно данные о сроках, обзор текущей ситуации, давит на остальных участников процесса и, кажется, хочет всё и сразу. Он просто хочет понимать, как сделать максимально эффективно, а в идеале – как в следующий раз сделать ещё больше и ещё быстрее. Это нормально и с точки зрения бизнеса хорошо.


    Следовательно, нам необходимо важность целей продакт-менеджера донести до всех участников процесса, объяснить – и, возможно, тогда продакт-менеджеру не придётся бегать за разработчиком каждые полчаса, вопрошая: «Ну, когда уже будет готово?!», мешая ему и отвлекая от работы над задачей.


    У нас в Badoo планирование сроков является очень важной частью процесса разработки. Срок доставки новой фичи у нас появляется как можно раньше и называется Due date. Он представляет собой дату, когда фича должна оказаться на продакшне. Due date зависит от многих факторов – на него влияет практически всё в процессе разработки продукта, начиная от степени детализации в описании требуемых изменений и заканчивая методом доставки кода конечному юзеру. Декомпозиция задач, сложность дизайна интерфейсов, тестирование и его автоматизация, количество внешнего взаимодействия и архитектура кода – всё это может радикальным образом влиять на Due date. А учитывая, что на каждом этапе производства работают люди, влияние человеческого фактора на срок доставки колоссальное.


    Идеально было бы, если бы все члены команды понимали важность процесса, были хорошо мотивированы и аккуратны и всегда всё успевали. Возможно ли это? Не всегда. Особенно если говорить об объяснении и разделении общих ценностей. Но уверен, что всегда можно найти компромисс, если сделать так, чтобы последующие участники процесса сами стремились уложиться в срок, ориентируясь на какой-нибудь простой показатель и руководствуясь простыми правилами.


    В нашей компании таким показателем является Due date. Как мы при этом добиваемся, чтобы разработчики сами стремились к достижению целей бизнеса, я расскажу дальше.


    Кто у нас следующий участник процесса? Пекарь Володя. В нашем случае – программист. Какие цели могут быть у обычного человека, даже если учитывать, что средний IQ в нашей отрасли высокий? Заработать денег и уехать на Бали, купить квартиру, накопить на старость, выплатить кредит, купить гитару Gibson, уйти пораньше с работы, сходить вечером в кино и познакомиться с симпатичной соседкой. Так и быть, поскольку речь об айтишниках, накинем ещё: разобрать беклог на работе, воспроизвести надоевший баг и избавиться от придирок начальника, изучить Erlang, «пощупать» новый фреймворк для Python, выучить английский, собрать дрон на Raspberry Pi и дослушать подкаст про преимущества Kotlin.


    Разумеется, есть отличные ребята, которые «болеют за проект» и «понимают бизнес», – ведь мы вместе работаем над общим делом. Но попробуйте им несколько раз не заплатить зарплату (я не пытаюсь обидеть – я специально играю на контрастах, чтобы была понятна суть). Что получится в итоге? Они уйдут в Яндекс, Facebook, Google и любую другую компанию, где зарплаты немаленькие, кормят обедами, стригут и делают массаж и маникюр. И правильно сделают! Работа – это место, где бизнес покупает труд (и мозги) программистов за деньги, поэтому тут правят товарно-денежные отношения. И если у бизнеса цель – получить как можно больше работы за наименьшие деньги, то у сотрудников цель противоположная: сделать как можно меньше и получить за это как можно больше.


    Разумеется, в процессе есть и другие участники: дизайнеры, копирайтеры, переводчики, аналитики, тестировщики, релиз-инженеры, сисадмины. Но во-первых, их цели не сильно отличаются от целей пекаря Володи. А во-вторых, они часто выступают не на передовых ролях, а скорее прикрывают бойцов-разработчиков, пока те «идут в атаку». Кстати, таких сотрудников в компании вообще может не быть: их роли часто совмещаются с другими ролями. В продуктовой разработке все подобные роли выступают ресурсами для продактов и программистов, помогая им лучше делать свою работу, избавляя от рутины и т. д.


    Итак, основной участник процесса после продакт-менеджера, представляющего бизнес, – программист. Пекарь Володя может делать много, если ему интересно; он может ночами не спать, не есть, не выходить на улицу. Но задачи у бизнеса разные, и среди них немало неинтересных и рутинных. Так что, если Володя выполнил десять интересных для себя, но неактуальных для бизнеса задач и одну неинтересную, но очень важную для бизнеса – это равносильно тому, что он выполнил только одну задачу. Бизнесу важно, чтобы произведённый товар был ликвиден и конкурентоспособен, а какие технологии при этом использовались, как удачно Володя применил алгоритмы и паттерны хлебопечения – вопрос второстепенный.


    Конечно, Володе не хочется знать ни про какие дедлайны, не хочется общаться с продакт-менеджером, дизайнерами, бухгалтерами – ему хочется сесть и погрузиться в свою интересную задачу (и чтобы никто не мешал). И в этих условиях сроки, планы, заказчики, конкуренты – это суровая реальность, с которой Володя вынужден мириться, но не часть стратегической цели, как в случае с продакт-менеджером.


    Ответственность


    Как сделать так, чтобы цели компании, которые так далеки от целей пекаря Володи, всё-таки учитывались в процессе разработки? Чтобы на всех этапах при множестве подводных камней, проблем и неожиданностей, принимались такие решения, которые полезны в первую очередь компании? Чтобы Володе было необходимо соблюсти дедлайн и в идеале избежать при этом проблем с планированием архитектуры, оверинжинирингом и других, которые могут увести его в сторону от потребностей бизнеса?


    Мы в Badoo называем такой процесс «ответственностью разработчика» и всячески стимулируем и поощряем эту самую ответственность. Как я уже рассказывал, в наших процессах разработчик выступает в роли микропроджектменеджера проектов, над которыми он работает. Что это означает, как мы это стимулируем? Очень просто: за соблюдение срока (того самого Due date) отвечает разработчик.


    Это значит, что и устанавливать срок должен сам разработчик. Разумеется, он должен сделать это, тщательно изучив задачу и стараясь учесть как можно больше факторов при планировании. И разумеется, он должен стремиться этот срок соблюсти. Но при этом нужно быть готовым к тому, что разработчик может сорвать дедлайн. Суть в том, как мы поступаем дальше: мы рассматриваем каждый нюанс, который мешает нам уложиться в срок, и готовим ответ на него (как сделать так, чтобы в следующий раз подобная проблема не повторилась).


    Ответ надо требовать от разработчика, потому что он знает проект лучше всех. Он назвал срок в этот раз, и он назовёт его в будущем. Возможно, он снова ошибётся – это не страшно. Важно то, что такой подход совершенствует инженерную культуру и стимулирует рост разработчика и всей компании в целом. И очевидно, что решение о том, как избежать подобных проблем в будущем, должно быть надёжным. Не «постараться в следующий раз», а сделать так, чтобы это не повторилось, исключив по максимуму человеческий фактор.


    Хорошо бы, чтобы технический менеджер, получив срок на реализацию (Due date) и подтвердив его, не перестал обращать внимание на проект до наступления дедлайна – это рискованно и откладывает решение многих проблем на последний этап (проблем, которые проще, быстрее и дешевле решить сразу). Тут необходимо с определённой, заранее оговорённой периодичностью (чтобы это не отвлекало разработчика от работы) возвращаться к каждой задаче и уточнять ситуацию, корректировать сроки. Возможно, придётся принимать компромиссные решения, позволяющие уложиться в срок, но на перспективу оставляющие «полировку» и доработки функционала.


    Ну, и не лишним будет упомянуть, что просто накинуть n дней к сроку – не лучшее решение. Как это контролировать? Очень просто: задачи, выполненные раньше срока, тоже должны считаться неправильно спланированными. При этом «неправильно спланированные» не значит, что всё плохо и нужно наказать разработчика – это значит, что следует обратить на этот аспект внимание менеджера и обсудить проблемы, повлиявшие на срок (это могут быть, например, «творческий экстаз» и неожиданные находки в процессе разработки).


    Разумеется, не забываем про Закон Паркинсона, который гласит, что работа занимает всё отпущенное на неё время. Но во-первых, самый действенный способ этому противодействовать – сократить время выполнения задачи, сделав что-то полезное до срока её завершения, что замечательно вписывается в фичевую разработку, ведь мы делаем несколько проектов параллельно. Во-вторых, мы рассматриваем любое отклонение от срока как повод к ретроспективе и стимулированию выработки надёжного решения о том, как сделать более точный прогноз в будущем. А в-третьих, даже если мы уложились в сроки, нужно обязательно задать вопрос: как в следующий раз сделать быстрее?


    Очень важно уловить суть – мы не стремимся просто заставить всех соблюдать Due date. В фичевой разработке (в отличие от хлебопечения) слишком много неопределённостей. Очень немногие задачи похожи одна на другую – это не «универсальные» батоны хлеба. Если у пекаря «что-то пошло не так» со сроками, значит, либо случился форс-мажор (отключили электричество, вовремя не привезли муку и т. д.), либо он просто лентяй. В разработке же, напротив, редко удаётся уложиться в установленный срок, даже если очень стараться. И если разработчик в срок не уложился, это совсем не значит, что он где-то схалтурил. Суть тут в другом – мы смотрим на то, почему сроки не выдержаны и оцениваем причины (что повлияло на срок: ситуация, ресурсы, лень исполнителей или непонимание бизнес-целей). Разработчик может быть очень работоспособным, но без нацеленности на результат постоянно отвлекаться на несущественные мелочи, которые могут показаться ему важными (или, как вариант, на оказание помощи грузчику Васе, потому что у них приятельские отношения). В результате у разработчика есть масса причин, которые он искренне считает важными, но при этом отсутствует результат. Тут необходима постоянная поддержка и корректировка менеджера.


    Итак, подведём итог.


    1. Разработчик устанавливает срок задачи в виде Due date. Это срок, когда задача окажется на продакшене.
    2. Технический менеджер должен подтвердить срок Due date. Хорошо бы, чтобы он сделал это, предварительно самостоятельно изучив проект, и сразу указал на факторы, способные повлиять на сроки в будущем. Коучить нужно начинать уже на этом этапе.
    3. С определённой периодичностью, оговорённой заранее, менеджер должен проверять статус вместе с разработчиком: рассматривать проблемы, которые уже могли возникнуть, и процессы, которые уже можно ускорить. Пример: «Почему ревью трёх строк кода заняло три дня?»
    4. После завершения проекта в любом случае нужно делать ретроспективу и ставить вопрос: как в следующий раз сделать быстрее?

    Due date – это оптимистичный прогноз. В нашей компании все это понимают и знают, что разработчику нужна поддержка менеджера на всех этапах работы над проектом. И даже если предположить, что у разработчика остаётся небольшой запас времени, который помогает ему чувствовать себя спокойнее и увереннее, в этом нет ничего плохого. У нас цель – сделать эффективно и прагматично, а не «загнать лошадей насмерть», ведь нам ещё работать вместе и делать много крутых проектов.


    Примеры


    Следующие ситуации можно рассмотреть в качестве примеров, описывающих хорошие и не очень решения. Очевидно, что решения не единственно верные, но суть (я надеюсь) уловить позволяют.


    1. У задачи было слишком много переоткрытий, потому что тестировщики находили много багов, что привело к лишним временным затратам на всех смежных этапах: переключение контекста, ожидание задачи в очередях и т. д. Плохое решение: наорать на тестировщиков, уволить их, нанять новых. Хорошее решение: покрыть код юнит-тестами, чтобы в следующий раз фидбек о качестве кода получать быстрее; работать над методологиями и практиками по улучшению качества продукта.
    2. Дизайнер сделал слишком сложный дизайн новой фичи, кнопки приходилось буквально рисовать с нуля, это заняло больше времени. Плохое решение: попросить дизайнера больше так не делать. Хорошее решение: составить гайдлайны для вашего приложения и иметь стандартные компоненты, дать их дизайнерам и работать в соответствии с гайдлайнами.
    3. Разработчик решил новую фичу делать на новом модном фреймворке, это потянуло за собой изменения в других местах, пришлось переписать почти всё. Плохое решение: сказать всем, что фреймворк плохой, и больше никогда его не использовать. Хорошее решение: в задаче кода должно быть по минимуму – только чтобы решить эту конкретную задачу; новые подходы, фреймворки и т. д. должны идти отдельными задачами в рамках технического долга с инвестигейтом, плавным развёртыванием и т. д.
    4. В процессе работы над исправлением бага разработчик нашёл ещё один старый баг, стал его исправлять, закопался в старый код и отрефакторил половину проекта. Плохое решение: запретить исправлять баги и рефакторинг. Хорошее решение: в задаче кода должно быть по минимуму – только то, что касается исправления бага. Несмотря на то, что XP предполагает разработку через рефакторинг, необходимо несколько раз обдумать ситуацию, прежде чем пускаться в переделки всего и вся. Часто бывает так, что рефакторинг на данном этапе лучше отложить. На переднем плане должен быть прагматизм, а не красота кода и правильность архитектуры. Считаете, что надо рефакторить – обсудите это с менеджером и лишь после этого начинайте «лопатить» код.
    5. Сделали всё вовремя, но через два дня после раскладки обнаружили, что очень важный компонент системы был сломан новым кодом, пользователи не могли пользоваться продуктом, фичу пришлось откатить и исправлять. Плохое решение: оштрафовать разработчика и тестировщиков. Хорошее решение: начать вести мониторинг данного и других важных компонентов системы, покрыть их автотестами, новые фичи снабжать хотя бы минимальной статистикой о работоспособности и об основных бизнес-показателях.

    Ситуаций может быть великое множество – всё предусмотреть невозможно. Но разбираясь с проблемами, каждый раз мы стараемся решить сразу ряд подобных проблем в будущем. Такой подход не только улучшает весь проект в целом, но и заметно повышает уровень разработчика – ведь он стимулирует его смотреть на проблемы шире. Разработчик в этом случае получает архитекторскую, менеджерскую экспертизу и чувствует себя важной частью единого, развивающегося и постоянно совершенствующегося инженерного коллектива.


    И хорошо бы помнить о том, что ответственный должен быть один. Даже если над проектом работает несколько разработчиков, отвечать за координацию и сроки должен один из них, часто это самый опытный специалист. Так мы пытаемся избежать ситуации коллективной ответственности: ведь если за что-то отвечают все, значит, де-факто не отвечает никто.


    Мы в Badoo также практикуем подход, когда ответственным назначается не самый опытный, а молодой и «горячий» — для стимулирования его роста. При этом опытные разработчики наблюдают за всеми этапами проекта и всячески ему помогают, советуют, указывают на ошибки. И даже если при этом фичи будут делаться немного медленнее (хотя это вовсе не обязательно) и рисков будет больше, такой подход стратегически правилен, поскольку обеспечивает рост людей в команде.


    Заключение


    Создавая процесс, я стараюсь делать так, чтобы система сама себя оптимизировала. В теории решения изобретательских задач есть подход, который называется «идеальный конечный результат» (ИКР). Он предлагает при решении задачи представить себе идеальный образ решения, когда нужное действие совершается без каких-либо затрат, усложнений и нежелательных эффектов.


    В фичевой разработке часто случается так, что мы требуем от разработчика чего-то, пытаемся это контролировать, окружаем себя всё большим и большим количеством показателей, чтобы получить уверенность в том, что всё идёт по плану. Но чем больше людей, чем больше задач, чем больше показателей, тем этим становится всё сложнее и сложнее управлять. В результате можно прийти к ситуации, когда времени нет ни на что, кроме таблиц с показателями и бесед, а дела всё равно идут не очень.


    К тому же имеется масса факторов, влияющих на мотивацию разработчика, на стимуляцию его понимания и принятия целей бизнеса: перспективы бизнеса, понимание важности проекта для компании, стремление к беспроблемному внедрению и эксплуатации, субъективная удовлетворённость заказчиком и т. д. Но многое из этого трудно формализовать и измерить. А тем более сложно порой донести ценность до конкретного исполнителя. Часто даже очень хороший разработчик не улавливает изменение направления «продуктового ветра», и ему требуется какой-то понятный и простой механизм, указывающий верное направление.


    Соответственно, я рассматриваю Due date как один из основных инструментов стимулирования ИКР разработчика на всех этапах. Он проходит через весь процесс и заставляет изобретать решения, позволяющие избежать массу проблем в будущем. Он позволяет нам делегировать ответственность, не прибегая к многочисленным KPI. Он понятен и доступен практически всем. И он ведёт нас всех к главной цели бизнеса: сделать как можно быстрее как можно больше. А будет ли это ещё и дёшево, зависит от тех решений, которые мы будем использовать, а следовательно, от нас всех.


    А как делаете вы в своей компании?

    Badoo 257,44
    Big Dating
    Поделиться публикацией
    Похожие публикации
    Комментарии 30
    • +4

      Картинка просто огонь! :) Статья тоже, спасибо

      • +1
        Таким образом due date это такой lead time/эстимация привязанный к дате? Мне стало интересно, как быть тогда при следующих ситуациях:
        -Фича нужна бизнесу в продакшне раньше чем due date?
        -Разработчик «срезает» углы, чтобы успеть в due date?

        Так мы пытаемся избежать ситуации коллективной ответственности: ведь если за что-то отвечают все, значит, де-факто не отвечает никто.

        Я не совсем согласен с этим правилом, считаю (надеюсь) оно устарело.
        У него есть и обратная сторона — если за задачу ответственен только один человек, то все проблемы этой задачи — только его проблемы. У других и СВОИ задачи есть. Мне кажется это негативно сказывается на командном взаимодействии.
        Мне видится более эффективным (хоть и редким, но мне случалось) командная ответственность. Речь идет, конечно, о стабильных и кроссфункциональных командах размером 5-7 человек.

        Спасибо.
        • 0
          Привет, Александр!
          Пойдем по пунктам.
          1) Как быть, если «Фича нужна бизнесу в продакшне раньше чем due date?». Due date это в первую очередь бизнесовый показатель. Если фича нужна раньше, чем Due date, это значит что Due date = раньше :). Понятно что бывает так, что бизнес требует почти невозможного. Но если задуматься, то все что мы делаем, нужно в первую очередь именно бизнесу. И если получилось так, что мы должны к определенному сроку дать какой-то продукт, то надо выложиться по полной, но сделать. Мы нередко делаем MVP-продукт. Это когда мы компромиссным путем в кратчайшие сроки даем на выход результат, который позволяет прощупать концепт. И если он «летит», то полируем фичу дальше.
          2) Во-первых, надо регулярно с менеджером проверять результат на промежуточных этапах, а во-вторых, если мы делаем прагматично и полезно бизнесу, то это не всегда означает что мы делаем плохо, верно? Может быть оно с архитектурной точки зрения не всегда оптимально, но нашим пользователям зачастую наплевать как оно сделано изнутри. Если фича сделана так, что ее можно «продать» пользователю, значит она сделана «на отлично». При этом мы сразу делаем оговорку, что возможно в будущем надо будет делать рефакторинг, или даже полную переделку — это все технический долг.
          3) По поводу коллективной ответственности, и «устаревшего правила» — я даже рад что бывают альтернативные мнения. С другой стороны, есть зарекомендовавший себя подход и правила, а есть мода. И если автомат Калашникова работает, несмотря на то что он «устарел», может это значит что он не так уж и плохо сделан?

          Спасибо за ваше мнение!
        • +1
          Какие цели могут быть у обычного человека, даже если учитывать, что средний IQ в нашей отрасли высокий? Заработать денег и уехать на Бали, купить квартиру, накопить на старость, выплатить кредит, купить гитару Gibson, уйти пораньше с работы, сходить вечером в кино и познакомиться с симпатичной соседкой.

          То есть никаких целей, связанных с работой, нет совсем?
          Судя по тому, что вы пишете после этой фразы, это очевидно не так. Для людей есть смысл в работе, и это важно не менее зарплаты.
          • +1

            Ну мне кажется, что Вы придираетесь. Там была и такая фраза:


            "поскольку речь об айтишниках, накинем ещё: разобрать беклог на работе, воспроизвести надоевший баг...".


            И даже такая:


            "Разумеется, есть отличные ребята, которые «болеют за проект» и «понимают бизнес», – ведь мы вместе работаем над общим делом.".


            Да и это явно не является суть статьи. :)

            • +1

              Есть мнения, что именно это и является сутью результативной работы. Вкупе с возможностью принимать решения, отвечать за них и иметь широкие возможности консультирования.

            • 0
              Привет, Валентин!

              Если вы обратили внимание, я даже сделал оговорку о том, что я намеренно утрирую и «сгущаю краски» при приведении примеров. Reductio ad absurdum — это специальный полемический прием, позволяющий наиболее красочно показать те или иные аспекты обсуждаемой проблемы.

              Разумеется у разных людей цели разные. И я очень рад, что есть ребята, которых просто драйвит делать крутые вещи. Это прикольно и здорово мотивирует. Моя же цель в том, чтобы сделать процесс, работающий в большинстве случаев. Даже тогда, когда у людей внутренней мотивации не вполне достаточно.

              Удачи!
              • +1

                Здравствуйте, Илья!
                Вот тут наши позиции расходятся. На мой взгляд, основа не процессы, а обстановка, которая позволяет раскрываться способностям людей, делает их работу осмысленной, люди получают от неё удовольствие. Очень надеюсь, что у меня получается двигаться в этом направлении.
                Вам тоже удачи!

                • 0
                  Ну почему же расходятся? Я тоже считаю что обстановка очень важна. Но как ее формализовать? Хорошо если вы прийдя в компанию и поработав там, поймете хорошо там с этой самой обстановкой или нет. А если плохо? Уходить в другую компанию?

                  В статье я намеренно упоминаю инженерную культуру, в это широкое понятие входит и обстановка тоже. Когда работаешь в окружении крутых ребят, чувствуешь себя мотивированным делать крутые вещи.

                  И частью своей работы и работы других менеджеров считаю как раз воспитание инженерной культуры и взращивание той самой обстановки, в которой людям драйвово работать. Процессы — один из механизмов, позволяющих эту самую культуру развивать.
            • +1
              > даже если учитывать, что средний IQ в нашей отрасли высокий
              ой не льстите айтищникам.

              Статья дельная. Обсуждая цели компании и работника, то задача менеджмента поставить «правильного» человека в «правильное» место, как пазл в картинке. Правильность заключается в том, чтобы обязанности позиции совпадали с личным интересом человека на текущий момент и осуществлять над этим контроль.

              Из личного примера, очень непросто найти даже хорошую уборщицу — человека который любит чистоту и порядок, а главное ему нравится приводить помещение в порядок. Так и с программистами и со всемы остальными.
              • +1
                Спасибо за статью, очень понравились примеры. У нас тоже нередко бывает так, что разработчик получая в работу новую фичу стремится зарефакторить еще кучу всего рядом. Решаем эту проблему подробной декомпозицией + в конце спринта оставляем немного времени на тех. долг и прочие хотела разработчиков.
                • +1
                  то у сотрудников цель противоположная: сделать как можно меньше и получить за это как можно больше

                  O'RLY? Смею предположить, что это, мягко говоря, не так. Особенно если в вашей компании толковые разработчики.

                  • 0
                    Привет, Игорь.
                    Спасибо за ваш комментарий.

                    В нашей компании разработчики очень толковые. А в вашей?
                    • +2

                      It depends. Иными словами, не все. Наша основная проблема в том, что многие утверждают "задача выполнена", когда на деле — нет. классическая такая "Developer calls it done".


                      image


                      Лично меня разбирает сарказм, когда в попытке угодить менеджменту и срокам сверху разработчики упускают слишком много дефектов.


                      Я борюсь за Scrum's "done-done-done". Чаще всего, это требует замедления команды. И как правило, это воспринимают это как элементарное "сделать как можно меньше и получить за это как можно больше", а не как профессионализм и борьбу за Качество.


                      Так яснее?

                      • –3

                        Да, между "готово" у разработчика и "принято" у кастомэра ещё целая уйма задач, разработчика особо не касающихся и это проблемы продукт оунера/менеджера. Но в статье как-то акцентируется внимание на том, что разработчик несёт за всё ответственность, хотя вовремя сделанная разработчиками фича может не попасть в продакшн по целому ряду других причин. Pipeline сломат, QE несогласны, т.к. напрограммировали по одним требованиям, а тестируют по другим, performance просел, не дали времени на внятную валидацию и многое другое.

                        • +3
                          уйма задач, разработчика особо не касающихся:

                          "Pipeline сломат" — это моя проблема.


                          "QA несогласны" — это моя проблема.


                          "performance просел" — это моя проблема.


                          "не дали времени на..." — это проблема либо моя (плохо сигнализирую "красные флаги"), но чаще — менеджмента с "датой наперед" в голове плюс с пресловутым "и так сойдет".


                          image

                          • –1

                            За pipeline должны отвечать всякие release инженегры.
                            За то, что QA тестирует по требованиям, которых разработчики не видели, последние ответственность нести не должны, я это специально оговорил.
                            Если требований по performance также не было, то это тоже не проблемы разработчиков.
                            В противном случае разработчик превращается в человек-оркестр, обязанный всем и вся, а также обязанный предугадать, сколько миитингов запланирует ему менеджер отняв у него время, когда он заболеет, сколько необходимой ему документации отсутствует — только чтобы оценить не очень нужный ему дъю дэйт. И такой разработчик довольно быстро уйдёт из Badoo. А разработчик ресурс ценный и на дороге не валяется, это чтоб ваш бизнес знал (а он таки знает). По моим наблюдениям все срывы сроков происходят по большей части из-за организационного бардака в компаниях и некомпетентности менеджеров, у которых 7 пятниц на неделе и 8 митингов. Почему-то современные методологии уходят от понятия физического времени, заменяя их story pointами. И задача менеджеров конвертировать story points в физическое время и даты, разработчика это парить вообще не должно.

                            • +3
                              За pipeline должны отвечать всякие release инженегры.

                              В смысле, специальные люди отдельно под такую задачу?!
                              Мой мир теперь никогда не будет прежним…
                              • –2

                                Да, в более-менее крупных проектах/компаниях они есть, представьте

                                • +1

                                  В Amazon таких нет, представляете? Есть много команд, пилящих инфраструктуру (для пайплайнов в том числе). Но каждая сервисная команда сата содержит свои пайплайны — DevOps

                        • 0
                          Да, так яснее, спасибо.
                          Я так и ожидал, что будет ответ вроде «по-разному бывает». Это нормально, именно для того мы правила задаем и процессы создаем, чтобы в коллективе могли работать и приносить пользу компании практически все. И понимающие и не понимающие. И согласные и не согласные.
                          И здорово, если в компании все разработчики толковые и понимающие. Но что если не все? Или как вновь прибывших внедрять и воспитывать правильно?

                          Многие из моих утверждений в статье спорные. Это сделано намеренно, чтобы читатель задумался, задал себе вопрос «какого фига?». А может и в комментариях со мной подискутировал :)
                    • +3

                      Честно говоря, много текста, содержащего лишь банальность, которая, кроме прочего ещё и разбивается при первом же столкновении с реальностью. Работники внезапно берут дэйоффы по срочным делам, заболевают, кто-то отключает электричество в лабе, интернет и ещё более 9000 причин мелких помех. Дъю дэйт хорошо подходит для фичи, над которой работает как минимум несколько чедовек, чтобы неизбежно возникающие ауты сглаживались в предсказуемую статистику, среднюю температуру по больнице. Спрашивать дъю дэйт с каждого одного человека не слишком корректно и попахивает карательным микроменеджментом.

                      • –1
                        Толсто, Андрей.
                        Удачи!
                      • +1

                        Очень интересная методология, жаль ничего не понял(
                        Вот у вас есть некий похапе разработчик Вася и вы пытаетесь внедрить ему ответственность и kpi. И есть Петя из компании ХХивПрод.


                        • Вася, когда эта фича будет готова на проде?
                        • Ну 31 февраля (через X дней) — это наш DueDate


                        • Петя, сколько делать эту фиговину (декомпозицию задачи мы не умеем)?
                        • Ну, наверное, дней X — это некая оценка сложность задачи

                        В чем между ними разница? Если только Вася все X дней не занимается ничем другим, кроме своей задачи (у Пети X дней спринта "заняты" или просто менеджер понимает, что такой вот расход ресурса). Вариант с Васей разве лучше для вашего бизнеса?
                        Должны ли оценки Пети и Васи отличаться? Может быть Вася должен продумать что-то еще помимо "накину еще n дней на всякий случай", которых вы хотите избегать?


                        Нужна ли эта дата бизнесу? Судя по вашему комментарию, нет — не нужна. У вас там MVP, "если бизнесу надо — бизнес сам дату придумает". Если у бизнеса нет даты, то ему надо "чем быстрее, тем лучше", но быстрее чем будет готово оно все равно не появится.


                        Будут ли различия в части депремирования для Пети, не угадавшего время реализации и Васи, не угадавшего дату "на проде"? Похоже, что Вася не пострадает — он же дал оптимистичный прогноз. Просто у него коэф. к премии немного ухудшится (kpi жи).


                        Каким образом наличие due date дает «ответственность разработчика» за результат тоже не понятно. И чем эта ответственность отличается от ответственности Пети за результат?
                        Если Вася еще и "типаменеджер" своей задачки, то может ли он что-то требовать (соблюдения сроков от тестировщиков, перерисовки макета от дизайнера, изменений в логике и т.д.)? если это все надо согласовывать с настоящим менеджером, то это прям ответственная ответственность.
                        В примере вот есть — Вася не осилил дизайн, завалил сроки. Надо рисовать гайдлайны. А кто рисовать то будет? Вася или дизайнер? и кто поставит этому художнику задачу?


                        В итоге я умудрился в статье прочитать, что вы придумали некую никому не нужную дату, которая должна внедрять инжЫнерный подход у хороших разработчиков (а плохих вгонять в стресс "ой не успею" или перезакладываться, но таких, слава богу, в баде нет)

                        • 0
                          Ну смотрите, Андрей.
                          С точки зрения дат, ситуация Васи и Пети не отличается ничем. А вот с точки зрения ответственности, отличается. В чем преимущество Васи? В том, что он — «пушер». Он «драйвер» и двигатель всех процессов. Может ли он что-то требовать? Может, если это ему поможет сделать задачу эффективнее. Он может просить, убеждать, требовать, взывать к помощи менеджера — не важно.
                          Если задачу во время не сделал Петя, то ничего страшного. Ну не сделал, и не сделал. А вот для Васи любой исход означает вопрос: «как сделать быстрее»? Его не оштрафуют. Но его обязательно спросят, как быть быстрее в следующий раз.
                          Про пример с гайдлайнами и вопросом кто будет рисовать — это неважно. Пушить процесс будет Вася. Если он нарисует лучше чем дизайнер, то хорошо. Но скорее всего, дизайнет нарисует лучше. А вот прийти к дизайнеру и направить его на путь истинный должен Вася. Если он прийдет к дизайнеру и тому некогда, то Вася может заказать дизайн на стороне (я сейчас совсем-совсем утрирую, но надеюсь, суть понятна).

                          Не важно кто и что делает, у кого хватает ресурсов и у кого есть желание что-то делать. Главное — результат. И для его достижения нужна какая-то цель. Такой «универсальной целью» во многих ситуациях и выступает Due date.
                        • +1
                          Конечно, Володе не хочется знать ни про какие дедлайны, не хочется общаться с продакт-менеджером, дизайнерами, бухгалтерами – ему хочется сесть и погрузиться в свою интересную задачу (и чтобы никто не мешал). И в этих условиях сроки, планы, заказчики, конкуренты – это суровая реальность, с которой Володя вынужден мириться, но не часть стратегической цели, как в случае с продакт-менеджером.

                          Прямо с болью в сердце читаю. Т.е. Володя все-таки должен общаться с продакт-менеджером, дизайнерами, бухгалтерами (?!)?

                          Разработчик устанавливает срок задачи в виде Due date. Это срок, когда задача окажется на продакшене.
                          Технический менеджер должен подтвердить срок Due date. Хорошо бы, чтобы он сделал это, предварительно самостоятельно изучив проект, и сразу указал на факторы, способные повлиять на сроки в будущем. Коучить нужно начинать уже на этом этапе.
                          С определённой периодичностью, оговорённой заранее, менеджер должен проверять статус вместе с разработчиком: рассматривать проблемы, которые уже могли возникнуть, и процессы, которые уже можно ускорить. Пример: «Почему ревью трёх строк кода заняло три дня?»
                          После завершения проекта в любом случае нужно делать ретроспективу и ставить вопрос: как в следующий раз сделать быстрее?

                          Я вот читаю, что у меня и у технического менеджера должно быть много свободного времени.
                          А что если каждая новая задача является для меня и моего технического менеджера новой? В общем и целом, мы не сомневаемся, что ее можно решить, но сколько займет ее выполнение — никто адекватно сказать не в силах. При этом мы оба находимся в середине другого проекта. А ответ по оценке сроков нам надо дать на следующий день. И мы даем. Естественно, обманывая, а потом накидываем n дней. Раза 3-4.
                          А потом в середине уже этого проекта, когда уже понятно, что не вывозим, я, находясь в глубокой отладке, я не буду (из комментария выше)
                          просить, убеждать, требовать, взывать к помощи менеджера

                          Во-первых, он занят более глобальными задачами, которые перед ним ставит бизнес и суровая реальность. Видели бы вы тоску в его глазах, когда я очередной раз появляюсь на пороге…
                          Во-вторых, какую помощь он может дать? Дать людей? Допустим, люди есть, но все упирается в то, что мне надо отвлечься от своей отладки и выдумать такую декомпозицию, которая помогла бы часть работы передать другому разработчику. При этом время уйдет на потери взаимодействия, а еще этот другой разработчик, скорее всего попросит какие-нибудь API-заглушки, чтобы он смог поставленную задачу решить за один присест, не возвращаясь к ней по мере реализации функционала с моей стороны. И мне надо будет написать все заглушки, а потом мы вместе будем заниматься соединением одного с другим, поскольку у него ни времени, ни желания сильно погружаться в мои замыслы нет, ему надо задачу в треккере закрыть. В общем, после пяти минут таких сомнений я иду не за помощью, а за кофе и яблочным пирогом.
                          Конечно, это все следствие моей некомпетентности, ряда ошибок в организации работы, бла-бла-бла, но вот так, что поделать, надо жить дальше. И я не думаю, что это редкость. Я думаю, наоборот, многие команды (точнее, их руководства) берутся за проекты, о которых не имеют исчерпывающего представления. А потом будет другой, еще менее понятный на этапе оценки сроков, и вся предыдущая ретроспектива окажется просто трепом.

                          Еще из комментария выше:
                          А вот прийти к дизайнеру и направить его на путь истинный должен Вася. Если он прийдет к дизайнеру и тому некогда, то Вася может заказать дизайн на стороне (я сейчас совсем-совсем утрирую, но надеюсь, суть понятна).

                          Нет, вообще не понятна суть. Я не могу на стороне. Нет никакой стороны, есть NDA с заказчиком. Мы, скорее всего вместе с техническим менеджером пойдем к руководству с призывом надавить на дизайнера. Дизайнер — хороший человек, занятой, ценю и уважаю, но…
                          • 0
                            Т.е. Володя все-таки должен общаться с продакт-менеджером, дизайнерами, бухгалтерами

                            Угу. Если Родина требует, то куда деваться?

                            Я вот читаю, что у меня и у технического менеджера должно быть много свободного времени.

                            А я считаю что я не должен ходить на работу. Но иногда все-таки нужно, верно?

                            Видели бы вы тоску в его глазах, когда я очередной раз появляюсь на пороге…

                            Видел, и много раз. Но есть «хочу», а есть «нужно».

                            какую помощь он может дать? Дать людей?

                            Очень сильно зависит от. Увеличить людей — самый простой способ. Утверждаю что есть еще масса вещей, которые стоит попробовать. Главное — результат. А как каждый конкретный Володя его добьется — дело десятое. За это мы Володь и ценим.

                            Нет, вообще не понятна суть. Я не могу на стороне.

                            И это прекрасно. Значит у вас нет иного выхода, кроме как «задолбать» своего дизайнера, чтобы он сделал как надо. В этом и суть. У нас нет задачи сделать вам комфортно (уж извините, при всем уважении). У нас задача — дать результат. Следовательно мы пушим всех, и вас в том числе (в данном примере), действовать на результат, выводя вас из зоны комфорта.
                          • 0
                            >цели компании всё-таки важнее, чем цели отдельных сотрудников.

                            очень сомнительная фраза
                            для кого важнее? и цель у компании одна — получение прибыли

                            так что думаю, точнее сказать так:
                            цель (прибыль) компании единственное важное для нее, все остальное только рычаги получения прибыли, включая желания отдельных людей, их неосведомленность, ответственность, энтузиазм и т.д.
                            • 0
                              Классика не стареет.

                              Не увидел только рецептов работы с одним из возможных подтипов разработчиков, а именно
                              людей не способных в принципе даже угадывать срок окончания разработки, и нет, не потому что не понимают проблему или не обладают достаточным уровнем квалификации, а просто вот человек «оптимист» или хуже «спорадический оптимист».
                              Если, в еще более «устаревшей» классической схеме, ПМ как то смог бы сгладить его due date, исходя из опыта работы и имеющегося персонального для разработчика фактора, то кто и как делает это в вашем случае.
                              Только не говорите что вы его обучите, здесь речь о существенной части наших коллег которые не способны на это, при всех их заслугах как профессионала.

                              • 0
                                Due date разработчик выдает не в одно лицо, а как минимум, посоветовавшись с менеджером/техническим лидом. Научить все-таки пытаемся, но бывает всякое. Если совсем не получается — признаем что конкретный человек в фичевую разработку не подходит и расстаемся с ним. Это не обязательно означает увольнение. Может быть переход в нефичевую команду, например.

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое