Саша Раковский dan repost
Про творческий беспорядок в процессах
Я куда ни приду лидом, меня первое время все ругают за бардак в процессах. Мол, непонятно, кто чем занят, и где границы ответственности. И я всегда говорю: вы не поймите неправильно, я это специально, так было не всегда. Щас поясню.
Дело в том, что я всей душой верю в несколько идей, которые вместе собираются в такой внешне хаотичный стиль. Для начала расскажу сами принципы, потом про подводные камни. Я знаю, когда вы будете читать, у вас там в определённые моменты будут возражения. Так вот про них в самом конце будет.
1. Максимум делегирования
Тимлид, как и любой другой член команды, которого в команде всего одна штука - это самый первый кандидат на бутылочное горлышко и single point of failure. Поэтому его ключевая задача - всю работу скидывать с себя на кого-то другого. Этакий вариант поговорки "работа-работа, перейди на Федота". Load balancer от мира команд.
2. Замкнутые ответственности
Доведенное до максимума делегирование подразумевает, в том числе, делегирование и уже традиционно лидерских задач. А именно - самостоятельная расстановка приоритетов по задачам и самостоятельный контроль прода во всех смыслах. В идеале: в продуктовом и инфраструктурном смыслах тоже.
3. Минимум координационного взаимодействия
Недостаток коммуникации - один из самых главных источников проблем. Но и сама коммуникация совершенно не даётся бесплатно - все эти бесконечные созвоны и болтовня сами по себе работу не двигают. Поэтому с этой точки зрения самый эффективный вариант реализации чего-либо - это в одиночку. Тогда не надо ни с кем договариваться, спорить, никого ставить в известность и нести потери от того, что кто-то что-то неправильно понял, кому-то что-то не сказал или границы ответственности у людей расставлены с огромными дырами между ними. Но, разумеется, не всегда это возможно.
Отсюда как раз моё предпочтение наиболее широкой компетенции специалиста. Несмотря на свое бэкендерское происхождение, я уже много лет всем сердцем голосую за фуллстеков, а теперь уже - за продуктовых инженеров. Именно продуктовый инженер может замкнуть на себя наиболее широкую ответственность.
В то же время вижу, что многие фанатеют от идеи собрать себе колоду, как в кино, чтобы снайпер, сапёр, пулемётчик и медик. Типа чем больше узких ролей в команде, тем лучше. Для крутого боевика - это, конечно, идеально, но я все же фанат Рэмбо - универсального суперсолдата, который в одиночку затащит все.
4. Минимум процессов
Я в своей жизни насмотрелся на процессы ради процессов: дейлики, ретро, планирования. Обязательно списывайтесь, обязательно двигайте таску по трекеру, обязательно через ветку, через 2 ревью, 0 замечаний в сонаре, 80% покрытия, написать вики. Все обязательно. Человеко-дни работы команды сгорают каждую неделю на очень логичную и зачастую очень малополезную туфту.
Поэтому процессы у нас всегда строились так: если ничего не болит, то и процесса не надо. Если что-то болит, давайте найдём подходящий инструмент. Не достаёт коммуникации - давайте введем регулярные синки. Не хватает ревью кому-то - сажаем ему в пару человека. Ну и так далее. Чем меньше процесса, чем меньше людей в нём людей, тем лучше.
5. Доверие
Это прям любимая мантра аджилистов: зачем вы нанимаете людей, которым вы не доверяете.
Вот и я всегда предпочитал играть только с козырями в руке. Нанимаешь добросовестных умных людей, разделяющих твои ценности, обучаешь их, смотришь за ними и, если все ок, отпускаешь их в самостоятельное плавание.
6. Самоорганизация
Я в банке часто слышал вопрос-упрёк от нашего аналитика: "Я не понимаю границы своей ответственности, что конкретно от меня ожидают?!"
Я всегда отвечал ей так: "Ты знаешь цели и задачи нашей команды, у тебя есть нужные нам компетенции, которых нет ни у кого больше. Пожалуйста, помоги разработчикам выполнить цели и задачи команды."
Это звучало очень неконкретно и вроде бы не отвечало на вопрос. Но, в итоге, именно отсутствие чётких границ ответственности позволяло людям самостоятельно распределять работу между собой, превращаясь в полноценный слитный организм даже без чётких заранее прописанных рамок.
Результат
Совокупность этих принципов порождала естественный процесс, в котором человек отвечает не за задачу, а за то, чтобы на продукте все было зашибись. Исполнители имеют все компетенции, полномочия и доверие, чтобы выбирать способ достижения этого зашибись. После того, как процесс построен, лид в нём может не участвовать никак, команда работает сама по себе без вмешательства.
Про подводные камни
Ну и, как обещал, давайте разберём очевидные вопросы, которые у вас 100% возникли.
1. Максимум делегирования
Первый очевидный вопрос: если лид все делегировал, какова роль лидера в такой команде?
Ну, во-первых, защищать место от человека, который придёт и сломает классно работающий механизм. И это кстати не совсем шутка: после моего ухода из банка процессы начали разваливаться со скоростью света, хотя до этого преспокойно переживали весьма длительное невмешательство.
Другие роли: визионерство, коррекция курса и внезапные смены направления движения, раннее обнаружение проблем, разруливание ситуаций, подбор достойных и прочая текучка.
2. Замкнутые ответственности
Как доверить джуну постановку себе задач и полный контроль за продуктом? Никак. Либо не нанимайте джунов, либо сажайте их в пару к тому, кому готовы это доверить. Но будьте готовы: по джуну не всегда можно понять, сможет ли он вырасти во что-то большее, в конце концов.
3. Минимум координационного взаимодействия
Режим одиночки имеет 3 основных ограничения и, соответственно, возражения:
- Bus factor. Человек ушёл в отпуск - продукт стоит. Человек уволился - продукт сильно просел. Решается просто - всегда должен быть запасной человек, который либо работает вместе на продукте, либо когда-то на нём работал.
- Существует ли человек, способный закрыть все необходимые компетенции? Во-первых, в эпоху нейронок - скорее, да. Во-вторых, всегда можно иметь одного-двух профильных специалистов на множество одиночек и пар, к которому все будут обращаться.
- Некоторые продукты заколебешься делать в одного - нужна куда большая пропускная способность. Порой это даже десятки и сотни человек, да? Да, но можно ли разделить их работу на небольшие независящие друг от друга подпродукты, которые могут делать 1-2 человека? Почти всегда - да.
4. Минимум процессов
Все эти процессы придумали не просто так. Это очень стройная система: вот вы накидали задач в бэклог, вот вы из них отобрали самые важные и запланировали на спринт, вот аналитики проанализировали и отдали бэкендерам, беки закодили и отдали на ревью, после аппрува оно уехало к фронтам, потом снова ревью, после чего задача уехала в тестирование. Потом это все поехало в прод. Круто же?
Круто, пока не начинаешь находить проблемы: огромное количество времени на коммуникацию и проблемы из-за ее нехватки; одни в мыле, другие на расслабоне; немалая часть работы делается не потому что нужна, а потому что так надо по процессу.
Сама работа постоянно гуляет туда-сюда. Например, фронт начал делать и понял, что а аналитике есть проблемы - аналитику надо переделывать и, конечно же, бэк (и ревью снова). Тестировщик проверил и нашёл на бэке косяк: теперь бэк все переделывает, подходит ревью, фронт переделывает, проходит ревью, и задача снова уходит к тестеру, чтобы тот понял, что проблема была не в ошибке бэка, а вообще в аналитике.
5. Доверие.
Как довериться человеку, которого только нанял? Может, он балду пинает. К тому же, если ты его только что нанял, то он точно ещё долго будет въезжать, прежде чем станет действительно самостоятельным.
Ответ: нельзя довериться. Доверие нужно заслужить. Просто для этого надо не так много: дать ментора и чуть-чуть времени на вход. Уже довольно скоро будет видно, можно ли доверять или нет.
Что делать, если нельзя? В идеале - поговорить честно и разойтись по-хорошему. В реальности часто: оставить вечным подопечным на второстепенных ролях у кого-то, кто тащит.
6. Самоорганизация.
Как можно работать в процессах, где у тебя нет чётко сформированной ответственности? Ведь, тебя, получается, могут спросить вообще за все, что угодно?
Я куда ни приду лидом, меня первое время все ругают за бардак в процессах. Мол, непонятно, кто чем занят, и где границы ответственности. И я всегда говорю: вы не поймите неправильно, я это специально, так было не всегда. Щас поясню.
Дело в том, что я всей душой верю в несколько идей, которые вместе собираются в такой внешне хаотичный стиль. Для начала расскажу сами принципы, потом про подводные камни. Я знаю, когда вы будете читать, у вас там в определённые моменты будут возражения. Так вот про них в самом конце будет.
1. Максимум делегирования
Тимлид, как и любой другой член команды, которого в команде всего одна штука - это самый первый кандидат на бутылочное горлышко и single point of failure. Поэтому его ключевая задача - всю работу скидывать с себя на кого-то другого. Этакий вариант поговорки "работа-работа, перейди на Федота". Load balancer от мира команд.
2. Замкнутые ответственности
Доведенное до максимума делегирование подразумевает, в том числе, делегирование и уже традиционно лидерских задач. А именно - самостоятельная расстановка приоритетов по задачам и самостоятельный контроль прода во всех смыслах. В идеале: в продуктовом и инфраструктурном смыслах тоже.
3. Минимум координационного взаимодействия
Недостаток коммуникации - один из самых главных источников проблем. Но и сама коммуникация совершенно не даётся бесплатно - все эти бесконечные созвоны и болтовня сами по себе работу не двигают. Поэтому с этой точки зрения самый эффективный вариант реализации чего-либо - это в одиночку. Тогда не надо ни с кем договариваться, спорить, никого ставить в известность и нести потери от того, что кто-то что-то неправильно понял, кому-то что-то не сказал или границы ответственности у людей расставлены с огромными дырами между ними. Но, разумеется, не всегда это возможно.
Отсюда как раз моё предпочтение наиболее широкой компетенции специалиста. Несмотря на свое бэкендерское происхождение, я уже много лет всем сердцем голосую за фуллстеков, а теперь уже - за продуктовых инженеров. Именно продуктовый инженер может замкнуть на себя наиболее широкую ответственность.
В то же время вижу, что многие фанатеют от идеи собрать себе колоду, как в кино, чтобы снайпер, сапёр, пулемётчик и медик. Типа чем больше узких ролей в команде, тем лучше. Для крутого боевика - это, конечно, идеально, но я все же фанат Рэмбо - универсального суперсолдата, который в одиночку затащит все.
4. Минимум процессов
Я в своей жизни насмотрелся на процессы ради процессов: дейлики, ретро, планирования. Обязательно списывайтесь, обязательно двигайте таску по трекеру, обязательно через ветку, через 2 ревью, 0 замечаний в сонаре, 80% покрытия, написать вики. Все обязательно. Человеко-дни работы команды сгорают каждую неделю на очень логичную и зачастую очень малополезную туфту.
Поэтому процессы у нас всегда строились так: если ничего не болит, то и процесса не надо. Если что-то болит, давайте найдём подходящий инструмент. Не достаёт коммуникации - давайте введем регулярные синки. Не хватает ревью кому-то - сажаем ему в пару человека. Ну и так далее. Чем меньше процесса, чем меньше людей в нём людей, тем лучше.
5. Доверие
Это прям любимая мантра аджилистов: зачем вы нанимаете людей, которым вы не доверяете.
Вот и я всегда предпочитал играть только с козырями в руке. Нанимаешь добросовестных умных людей, разделяющих твои ценности, обучаешь их, смотришь за ними и, если все ок, отпускаешь их в самостоятельное плавание.
6. Самоорганизация
Я в банке часто слышал вопрос-упрёк от нашего аналитика: "Я не понимаю границы своей ответственности, что конкретно от меня ожидают?!"
Я всегда отвечал ей так: "Ты знаешь цели и задачи нашей команды, у тебя есть нужные нам компетенции, которых нет ни у кого больше. Пожалуйста, помоги разработчикам выполнить цели и задачи команды."
Это звучало очень неконкретно и вроде бы не отвечало на вопрос. Но, в итоге, именно отсутствие чётких границ ответственности позволяло людям самостоятельно распределять работу между собой, превращаясь в полноценный слитный организм даже без чётких заранее прописанных рамок.
Результат
Совокупность этих принципов порождала естественный процесс, в котором человек отвечает не за задачу, а за то, чтобы на продукте все было зашибись. Исполнители имеют все компетенции, полномочия и доверие, чтобы выбирать способ достижения этого зашибись. После того, как процесс построен, лид в нём может не участвовать никак, команда работает сама по себе без вмешательства.
Про подводные камни
Ну и, как обещал, давайте разберём очевидные вопросы, которые у вас 100% возникли.
1. Максимум делегирования
Первый очевидный вопрос: если лид все делегировал, какова роль лидера в такой команде?
Ну, во-первых, защищать место от человека, который придёт и сломает классно работающий механизм. И это кстати не совсем шутка: после моего ухода из банка процессы начали разваливаться со скоростью света, хотя до этого преспокойно переживали весьма длительное невмешательство.
Другие роли: визионерство, коррекция курса и внезапные смены направления движения, раннее обнаружение проблем, разруливание ситуаций, подбор достойных и прочая текучка.
2. Замкнутые ответственности
Как доверить джуну постановку себе задач и полный контроль за продуктом? Никак. Либо не нанимайте джунов, либо сажайте их в пару к тому, кому готовы это доверить. Но будьте готовы: по джуну не всегда можно понять, сможет ли он вырасти во что-то большее, в конце концов.
3. Минимум координационного взаимодействия
Режим одиночки имеет 3 основных ограничения и, соответственно, возражения:
- Bus factor. Человек ушёл в отпуск - продукт стоит. Человек уволился - продукт сильно просел. Решается просто - всегда должен быть запасной человек, который либо работает вместе на продукте, либо когда-то на нём работал.
- Существует ли человек, способный закрыть все необходимые компетенции? Во-первых, в эпоху нейронок - скорее, да. Во-вторых, всегда можно иметь одного-двух профильных специалистов на множество одиночек и пар, к которому все будут обращаться.
- Некоторые продукты заколебешься делать в одного - нужна куда большая пропускная способность. Порой это даже десятки и сотни человек, да? Да, но можно ли разделить их работу на небольшие независящие друг от друга подпродукты, которые могут делать 1-2 человека? Почти всегда - да.
4. Минимум процессов
Все эти процессы придумали не просто так. Это очень стройная система: вот вы накидали задач в бэклог, вот вы из них отобрали самые важные и запланировали на спринт, вот аналитики проанализировали и отдали бэкендерам, беки закодили и отдали на ревью, после аппрува оно уехало к фронтам, потом снова ревью, после чего задача уехала в тестирование. Потом это все поехало в прод. Круто же?
Круто, пока не начинаешь находить проблемы: огромное количество времени на коммуникацию и проблемы из-за ее нехватки; одни в мыле, другие на расслабоне; немалая часть работы делается не потому что нужна, а потому что так надо по процессу.
Сама работа постоянно гуляет туда-сюда. Например, фронт начал делать и понял, что а аналитике есть проблемы - аналитику надо переделывать и, конечно же, бэк (и ревью снова). Тестировщик проверил и нашёл на бэке косяк: теперь бэк все переделывает, подходит ревью, фронт переделывает, проходит ревью, и задача снова уходит к тестеру, чтобы тот понял, что проблема была не в ошибке бэка, а вообще в аналитике.
5. Доверие.
Как довериться человеку, которого только нанял? Может, он балду пинает. К тому же, если ты его только что нанял, то он точно ещё долго будет въезжать, прежде чем станет действительно самостоятельным.
Ответ: нельзя довериться. Доверие нужно заслужить. Просто для этого надо не так много: дать ментора и чуть-чуть времени на вход. Уже довольно скоро будет видно, можно ли доверять или нет.
Что делать, если нельзя? В идеале - поговорить честно и разойтись по-хорошему. В реальности часто: оставить вечным подопечным на второстепенных ролях у кого-то, кто тащит.
6. Самоорганизация.
Как можно работать в процессах, где у тебя нет чётко сформированной ответственности? Ведь, тебя, получается, могут спросить вообще за все, что угодно?