Четыре признака плохих роадмапов
Сразу оговорюсь, что статья, на самом деле, не о проблемах роадмапов, а о проблемах продуктовой культуры и целеполагания в компаниях. Роадмап – просто артефакт, на котором эти проблемы становятся ярко заметными.
1️⃣Топ-менеджмент в изоляции формирует роадмап и после этого отдает его на выполнение продуктовым командам.
2️⃣Роадмап содержит в себе список фичей, которые надо разработать, но ничего не говорит о целевых результатах, ради которых эти фичи делаются.
3️⃣Роадмап не учитывает зависимости между командами и необходимость совместной работы для реализации определенной фичи.
4️⃣Роадмап никак не связан со стратегией, а содержит просто набор фичей.
Автор еще предлагает несколько очевидных советов, как улучшить ситуацию («задавайте вопросы», «предлагайте сфокусироваться на результатах»). Но в большинстве случаев лучще рассматривать наличие таких проблем как сигнал к тому, что стоит поискать другое место работы – лечить топ-менеджмент сложное и очень неблагодарное занятие.
Сразу оговорюсь, что статья, на самом деле, не о проблемах роадмапов, а о проблемах продуктовой культуры и целеполагания в компаниях. Роадмап – просто артефакт, на котором эти проблемы становятся ярко заметными.
1️⃣Топ-менеджмент в изоляции формирует роадмап и после этого отдает его на выполнение продуктовым командам.
2️⃣Роадмап содержит в себе список фичей, которые надо разработать, но ничего не говорит о целевых результатах, ради которых эти фичи делаются.
3️⃣Роадмап не учитывает зависимости между командами и необходимость совместной работы для реализации определенной фичи.
4️⃣Роадмап никак не связан со стратегией, а содержит просто набор фичей.
Автор еще предлагает несколько очевидных советов, как улучшить ситуацию («задавайте вопросы», «предлагайте сфокусироваться на результатах»). Но в большинстве случаев лучще рассматривать наличие таких проблем как сигнал к тому, что стоит поискать другое место работы – лечить топ-менеджмент сложное и очень неблагодарное занятие.
www.goretro.ai
How Roadmaps Accidentally Make Teams Powerless
Roadmaps that are too restrictive limit the scope of creativity that your team has to solve problems. Look to build roadmaps that support creative outcomes.
Как получить работу технического топ-менеджера
- Работу СТО проще получить не благодаря внутреннему повышению, а поменяв компанию. Обычно эта роль уже занята, освобождается она довольно редко, и расчитывать на этот шанс довольно бесполезно.
- Вакансии СТО довольно редко попадают на доски вакансий. Кандидатов обычно ищут с помощью нетворкинга, или привлекая рекрутеров, специализирующихся на executive должностях.
- Процесс интервью будет хаотичным и в каждой компании своим. Иногда вас будут собеседовать люди с техническим бэкграундом, иногда без него. Успех зависит больше от восприятия того, насколько вы подходите компании и своим новым коллегам, а не от объективных критериев.
- Чтобы понять, за какую компенсацию торговаться, лучше всего пообщаться с людьми, занимающими схожие позиции в аналогичных компаниях.
- До принятия оффера обязательно побольше пообщайтесь с СЕО, чтобы оценить, насколько вы хотите с ним работать, попросите финансистов рассказать про текущее финансовое положение компании, и узнайте, почему увольняли прошлых топ менеджеров.
- Работу СТО проще получить не благодаря внутреннему повышению, а поменяв компанию. Обычно эта роль уже занята, освобождается она довольно редко, и расчитывать на этот шанс довольно бесполезно.
- Вакансии СТО довольно редко попадают на доски вакансий. Кандидатов обычно ищут с помощью нетворкинга, или привлекая рекрутеров, специализирующихся на executive должностях.
- Процесс интервью будет хаотичным и в каждой компании своим. Иногда вас будут собеседовать люди с техническим бэкграундом, иногда без него. Успех зависит больше от восприятия того, насколько вы подходите компании и своим новым коллегам, а не от объективных критериев.
- Чтобы понять, за какую компенсацию торговаться, лучше всего пообщаться с людьми, занимающими схожие позиции в аналогичных компаниях.
- До принятия оффера обязательно побольше пообщайтесь с СЕО, чтобы оценить, насколько вы хотите с ним работать, попросите финансистов рассказать про текущее финансовое положение компании, и узнайте, почему увольняли прошлых топ менеджеров.
Lethain
Getting a job as an engineering executive.
I started my first executive job search when I was 25.
Eventually, I got an offer to lead engineering at a startup with four engineers,
which I turned down to join Uber.
It wasn’t until a decade later that I joined Calm and started my first executive role.…
Eventually, I got an offer to lead engineering at a startup with four engineers,
which I turned down to join Uber.
It wasn’t until a decade later that I joined Calm and started my first executive role.…
Слёрм приглашает на бесплатную стрим-конференцию «Школа мониторинга» с 17 по 19 января
Сверхцель проекта — построить идеальный мир, где коммерческий директор готов и даже мечтает вкладывать деньги в развитие observability в компании, продакт оунер заранее сообщает, что и зачем хочет измерять в продукте, разработчик сразу пишет экспортеры и хелсчеки, а девопс понимает, к какой нагрузке готовиться в следующем месяце.
Что в программе?
Стрим разбит на три секции:
1️⃣Философия мониторинга — будем говорить про observability и процессы в компании.
2️⃣Техническая секция — про инструменты, подходы и кейсы.
3️⃣Бизнес-секция — про извлечение ценности из мониторинга: метрики, показатели, решения на основе данных.
Эргономичный мониторинг, удобная работа с алертами, мультитенанси мониторинг, кастомизация шаблонов для Zabbix, оценка ущерба инцидентов в деньгах — это только малая часть тем школы.
Онлайн-трансляции пройдут 17–19 января с 14:00 до 19:00.
Регистрация
Сверхцель проекта — построить идеальный мир, где коммерческий директор готов и даже мечтает вкладывать деньги в развитие observability в компании, продакт оунер заранее сообщает, что и зачем хочет измерять в продукте, разработчик сразу пишет экспортеры и хелсчеки, а девопс понимает, к какой нагрузке готовиться в следующем месяце.
Что в программе?
Стрим разбит на три секции:
1️⃣Философия мониторинга — будем говорить про observability и процессы в компании.
2️⃣Техническая секция — про инструменты, подходы и кейсы.
3️⃣Бизнес-секция — про извлечение ценности из мониторинга: метрики, показатели, решения на основе данных.
Эргономичный мониторинг, удобная работа с алертами, мультитенанси мониторинг, кастомизация шаблонов для Zabbix, оценка ущерба инцидентов в деньгах — это только малая часть тем школы.
Онлайн-трансляции пройдут 17–19 января с 14:00 до 19:00.
Регистрация
Книга «Software Engineering at Google» стала бесплатной
SWE at Google – довольно популярная книга про хорошие инженерные практики, применяемые на проектах большого масштаба. Я сам до сих пор ее так и не прочитал, но от друзей слышал много хороших рекомендаций. Вон, даже Брагилевский советует!
Так в чем новость – авторы книги решили сделать ее бесплатной, так что можете посмотреть расписание и прочитать любую главу.
SWE at Google – довольно популярная книга про хорошие инженерные практики, применяемые на проектах большого масштаба. Я сам до сих пор ее так и не прочитал, но от друзей слышал много хороших рекомендаций. Вон, даже Брагилевский советует!
Так в чем новость – авторы книги решили сделать ее бесплатной, так что можете посмотреть расписание и прочитать любую главу.
Выпуск Подлодки про онбординг
Записали выпуск с Женей Антоновым про то, какие частые косяки встречаются в процессе онбординга новых сотрудников и как можно дешево построить достаточно хороший процесс. Ближе к концу выпуска я рассказал про несколько интересных приемов, которые сам использую в онбординге в свою текущую команду:
- Notion доска с кучей задач на испыталку, которые помогают погрузиться в компанию, процессы и продукт.
- Внутренний видеокурс про то, как в техническом плане устроены разные подсистемы Kotlin, и значения слов из внутреннего словаря команды.
Записали выпуск с Женей Антоновым про то, какие частые косяки встречаются в процессе онбординга новых сотрудников и как можно дешево построить достаточно хороший процесс. Ближе к концу выпуска я рассказал про несколько интересных приемов, которые сам использую в онбординге в свою текущую команду:
- Notion доска с кучей задач на испыталку, которые помогают погрузиться в компанию, процессы и продукт.
- Внутренний видеокурс про то, как в техническом плане устроены разные подсистемы Kotlin, и значения слов из внутреннего словаря команды.
Воркшоп по выстраиванию процесса развития в команде
Начало года – хороший момент, чтобы помочь своей команде составить планы развития и начать реализовывать поставленные цели. Если вы хотите систематизировать свой подход к развитию команды, то подключайтесь к открытому воркшопу Ильи Прахта из SmartUp.
Илья расскажет:
🔸Почему важно заниматься развитием сотрудников и в чем здесь сложности;
🔸Как сделать процесс развития сотрудников системным и надежным;
🔸Какие бывают подходы к развитию сотрудников, их плюсы и минусы;
🔸Примеры инструментов, помогающих трекать эффективность сотрудников и их следование PDP
По итогу вы сформируете простой чек-лист, по которому легко можно будет проверить, насколько ваш процесс развития сотрудников целостный и самодостаточный, и нужно ли еще что-то доработать.
🗓26 января, 19:00 по Москве
👉Регистрация
Начало года – хороший момент, чтобы помочь своей команде составить планы развития и начать реализовывать поставленные цели. Если вы хотите систематизировать свой подход к развитию команды, то подключайтесь к открытому воркшопу Ильи Прахта из SmartUp.
Илья расскажет:
🔸Почему важно заниматься развитием сотрудников и в чем здесь сложности;
🔸Как сделать процесс развития сотрудников системным и надежным;
🔸Какие бывают подходы к развитию сотрудников, их плюсы и минусы;
🔸Примеры инструментов, помогающих трекать эффективность сотрудников и их следование PDP
По итогу вы сформируете простой чек-лист, по которому легко можно будет проверить, насколько ваш процесс развития сотрудников целостный и самодостаточный, и нужно ли еще что-то доработать.
🗓26 января, 19:00 по Москве
👉Регистрация
Эволюция биллинга в Додо
Разбор эволюции системы платежей в Додо за последние семь лет – от нескольких классов в монолите до платежного шлюза с плагинной системой и акторной системы с сагами внутри. В статье хорошо показаны трейдоффы, которые приходится делать при развитии сложной системы и проблемы, которые появляются даже у идеально решающей задачу с первого взгляда системы.
Разбор эволюции системы платежей в Додо за последние семь лет – от нескольких классов в монолите до платежного шлюза с плагинной системой и акторной системы с сагами внутри. В статье хорошо показаны трейдоффы, которые приходится делать при развитии сложной системы и проблемы, которые появляются даже у идеально решающей задачу с первого взгляда системы.
Вебинар для тех, кто планирует системно прокачать свои навыки коммуникации
Любая задача руководителя в какой-то момент утыкается в навыки коммуникации – выяснение потребностей и намерений коллег, согласования со стейкхолдерами, разбор обратной связи со своей командой, отказ делать чьи-то задачи, не разрушая с ними отношения. Если среди ваших планов по развитию есть галочка “прокачать коммуникации”, то приходите на открытый вебинар «Как вырасти в IT с помощью навыков коммуникации», в котором на рабочих кейсах будет разбираться:
*️⃣Как выяснять потребности и намерения коллег
*️⃣Как доносить свою позицию и обозначать личные границы
*️⃣Как давать экологичную обратную связь
*️⃣Как отвечать на манипуляции, не вызывая лишнюю агрессию
*️⃣Как эффективно коммуницировать со стейкхолдерами и учитывать разные интересы
📆Дата: 24 января в 18:30
👉Регистрация
Любая задача руководителя в какой-то момент утыкается в навыки коммуникации – выяснение потребностей и намерений коллег, согласования со стейкхолдерами, разбор обратной связи со своей командой, отказ делать чьи-то задачи, не разрушая с ними отношения. Если среди ваших планов по развитию есть галочка “прокачать коммуникации”, то приходите на открытый вебинар «Как вырасти в IT с помощью навыков коммуникации», в котором на рабочих кейсах будет разбираться:
*️⃣Как выяснять потребности и намерения коллег
*️⃣Как доносить свою позицию и обозначать личные границы
*️⃣Как давать экологичную обратную связь
*️⃣Как отвечать на манипуляции, не вызывая лишнюю агрессию
*️⃣Как эффективно коммуницировать со стейкхолдерами и учитывать разные интересы
📆Дата: 24 января в 18:30
👉Регистрация
Story Points Revisited
Когда вам в следующий раз кто-то на очередном скрам-тренинге будет продавать сторипойнты, пришлите ему эту статью. Рон Джеффрис, один из трех авторов методологии XP, и человек, изначально предложивший и популяризовавший идею сторипойнтов, спустя много лет рефлексирует по этому поводу. Он признает, что идея – неудачная, и большинство тех, кто ее использует, делает это во вред процессу разработки. Основные идеи:
👀Сторипойнты выглядят очень удобной метрикой для того, чтобы сравнивать производительность разных команд друг с другом. Это в корне неверная идея, которая не ведет к полезному исходу.
📆Наличие оценки задачи приводит к тому, что эту оценку сравнивают с итоговым потраченным временем, и на основе этого делают выводы о предсказательной способности команды. Вместо того, чтобы фокусироваться на выборе самых важных задач для разработки и декомпозиции их на небольшие кусочки, менеджеры требуют от команды повышения качества оценки ей сроков. В большинстве случаев это мусорная работа, которая не несет пользы.
👊Сторипойнты ведут к давлению на команду, от которой будут регулярно требовать наращивать их количество в каждой итерации. Сроки будут давить на команду, она будет ускоряться за счет понижения качества, а итоговый продукт будет получаться плохим. Зато сторипойнтов больше съели!
🤔Сторипойнты, как и любая другая оценка сроков, дают только иллюзию контроля и предсказуемости. На самом деле в сложных инженерных проектах никто не может предсказать, сколько займет та или иная задача.
Когда вам в следующий раз кто-то на очередном скрам-тренинге будет продавать сторипойнты, пришлите ему эту статью. Рон Джеффрис, один из трех авторов методологии XP, и человек, изначально предложивший и популяризовавший идею сторипойнтов, спустя много лет рефлексирует по этому поводу. Он признает, что идея – неудачная, и большинство тех, кто ее использует, делает это во вред процессу разработки. Основные идеи:
👀Сторипойнты выглядят очень удобной метрикой для того, чтобы сравнивать производительность разных команд друг с другом. Это в корне неверная идея, которая не ведет к полезному исходу.
📆Наличие оценки задачи приводит к тому, что эту оценку сравнивают с итоговым потраченным временем, и на основе этого делают выводы о предсказательной способности команды. Вместо того, чтобы фокусироваться на выборе самых важных задач для разработки и декомпозиции их на небольшие кусочки, менеджеры требуют от команды повышения качества оценки ей сроков. В большинстве случаев это мусорная работа, которая не несет пользы.
👊Сторипойнты ведут к давлению на команду, от которой будут регулярно требовать наращивать их количество в каждой итерации. Сроки будут давить на команду, она будет ускоряться за счет понижения качества, а итоговый продукт будет получаться плохим. Зато сторипойнтов больше съели!
🤔Сторипойнты, как и любая другая оценка сроков, дают только иллюзию контроля и предсказуемости. На самом деле в сложных инженерных проектах никто не может предсказать, сколько займет та или иная задача.
✈️ Программы миграции работают даже в сложные времена
Relocode - это консалтинговое агентство, которое помогает получить ВНЖ стартапам и удалёнщикам digital nomad, а также занимается IT-визами.
У компании более 7 лет опыта в сфере релокации. Если вы мечтаете переехать в Великобританию один/с семьёй, то Global Talent Visa создана именно для вас.
❗️Её можно получить за 4 месяца, а ВНЖ дают сразу на 3-5 лет
Relocode берёт на себя все работы по ВНЖ: от оценки шансов до сопровождения после релокации.
Виза Global Talent:
📍подходит IT и бизнес специалистам в IT компаниях (product/project-менеджер и др.);
📍не требует знания английского и готового бизнес-проекта;
📍ведёт к ПМЖ и гражданству;
📍имеет высокий процент одобрений.
Не нужно быть талантом, чтобы получить Global Talent Visa. Достаточно быть хорошим специалистом, а с правильной презентацией поможет Relocode.
Подписывайтесь на Telegram-канал Relocode, где регулярно публикуют полезную информацию о релокации: https://t.me/relocode
Relocode - это консалтинговое агентство, которое помогает получить ВНЖ стартапам и удалёнщикам digital nomad, а также занимается IT-визами.
У компании более 7 лет опыта в сфере релокации. Если вы мечтаете переехать в Великобританию один/с семьёй, то Global Talent Visa создана именно для вас.
❗️Её можно получить за 4 месяца, а ВНЖ дают сразу на 3-5 лет
Relocode берёт на себя все работы по ВНЖ: от оценки шансов до сопровождения после релокации.
Виза Global Talent:
📍подходит IT и бизнес специалистам в IT компаниях (product/project-менеджер и др.);
📍не требует знания английского и готового бизнес-проекта;
📍ведёт к ПМЖ и гражданству;
📍имеет высокий процент одобрений.
Не нужно быть талантом, чтобы получить Global Talent Visa. Достаточно быть хорошим специалистом, а с правильной презентацией поможет Relocode.
Подписывайтесь на Telegram-канал Relocode, где регулярно публикуют полезную информацию о релокации: https://t.me/relocode
Ошибки в работе с Architecture Decision Records
Architecture Decision Records – практика записи всех ключевых технических решений, принимаемых командой, с объяснением их контекста. Про какие ошибки идет речь в треде:
📚Держать ADR отдельно от кода, к которому они относятся, описывая их в виде документов и презентаций. Из-за этого их реже будут открывать, появятся дополнительные барьеры для их заведения, и все превратится в бюрократию.
🔀Выстраивать отдельный процесс по написанию и оформлению ADR. Проще не относиться к этому как к отдельному этапу разработки, а вести ADR по ходу обсуждений, сразу же записывая ключевые идеи принятого решения. ADR должны быть интегрированы в процесс разработки, а не отделены от него.
📝Вместо описания принятого решения слишком много времени тратить на перечисление возможных альтернатив. Из-за этого объем ADR раздувается, их сложнее читать, и меньше фокуса уделяется самому важному – принятому командой решению.
В треде еще много интересных обсуждений про другие ошибки в ведении ADR и подходящую организацию для их хранения, тоже советую почитать!
Architecture Decision Records – практика записи всех ключевых технических решений, принимаемых командой, с объяснением их контекста. Про какие ошибки идет речь в треде:
📚Держать ADR отдельно от кода, к которому они относятся, описывая их в виде документов и презентаций. Из-за этого их реже будут открывать, появятся дополнительные барьеры для их заведения, и все превратится в бюрократию.
🔀Выстраивать отдельный процесс по написанию и оформлению ADR. Проще не относиться к этому как к отдельному этапу разработки, а вести ADR по ходу обсуждений, сразу же записывая ключевые идеи принятого решения. ADR должны быть интегрированы в процесс разработки, а не отделены от него.
📝Вместо описания принятого решения слишком много времени тратить на перечисление возможных альтернатив. Из-за этого объем ADR раздувается, их сложнее читать, и меньше фокуса уделяется самому важному – принятому командой решению.
В треде еще много интересных обсуждений про другие ошибки в ведении ADR и подходящую организацию для их хранения, тоже советую почитать!
Mastodon
Kevlin Henney (@[email protected])
I have found myself teaching and encouraging teams to use ADRs more and more in recent years.
I am, however, constantly surprised by the failure modes that people find themselves in, typically through no fault of their own.
I am, however, constantly surprised by the failure modes that people find themselves in, typically through no fault of their own.
Частые примеры менеджерского долга
Один из самых популярных постов прошлого года – про концепцию менеджерского долга. Сегодняшний материал раскрывает определение подробнее, дополняя его несколькими частовстречающимися примерами такого долга:
*️⃣Слишком мелкое дробление команд, при котором появляются тимлиды с 1-2 сотрудниками
*️⃣Команды, состоящие из джуниоров
*️⃣Инфляция тайтлов сеньоров/стаффов
*️⃣Инфляция компенсаций
Один из самых популярных постов прошлого года – про концепцию менеджерского долга. Сегодняшний материал раскрывает определение подробнее, дополняя его несколькими частовстречающимися примерами такого долга:
*️⃣Слишком мелкое дробление команд, при котором появляются тимлиды с 1-2 сотрудниками
*️⃣Команды, состоящие из джуниоров
*️⃣Инфляция тайтлов сеньоров/стаффов
*️⃣Инфляция компенсаций
Stay SaaSy
Management Debt
Teams naturally start to incur management debt as they grow and become more complex, just as codebases incur tech debt. The combined weight of past decisions creates a web of precedents and exceptions that can cause problems of varying size over time. Here…
Хотите продать идею – напишите документ
1️⃣Изложение своих идей в письменной форме позволяет увидеть пробелы в логике, которые вы можете не замечать, прокручивая их в голове, или обсуждая с кем-то вслух. У вас есть больше времени и возможностей подобрать самые убедительные аргументы, вместо тех, которые первыми приходят в голову.
2️⃣Сложно заставить людей сфокусированно слушать тебя, особенно в течение продолжительного времени. С документом работать гораздо проще – каждый человек может прочитать его в режиме и темпе, удобном для него.
3️⃣В отличие от живого обсуждения, даже с записанным видео, документы обычно живут намного больше. Их гораздо проще проиндексировать и найти спустя несколько лет.
4️⃣Часто бывает так, что люди серьезнее относятся к идеям, изложенным в письменном виде.
5️⃣Человеческая память очень ненадежная. Спустя несколько лет вы скорее всего забудете, почему приняли то или иное решение. А бумага все помнит.
1️⃣Изложение своих идей в письменной форме позволяет увидеть пробелы в логике, которые вы можете не замечать, прокручивая их в голове, или обсуждая с кем-то вслух. У вас есть больше времени и возможностей подобрать самые убедительные аргументы, вместо тех, которые первыми приходят в голову.
2️⃣Сложно заставить людей сфокусированно слушать тебя, особенно в течение продолжительного времени. С документом работать гораздо проще – каждый человек может прочитать его в режиме и темпе, удобном для него.
3️⃣В отличие от живого обсуждения, даже с записанным видео, документы обычно живут намного больше. Их гораздо проще проиндексировать и найти спустя несколько лет.
4️⃣Часто бывает так, что люди серьезнее относятся к идеям, изложенным в письменном виде.
5️⃣Человеческая память очень ненадежная. Спустя несколько лет вы скорее всего забудете, почему приняли то или иное решение. А бумага все помнит.
brooker.co.za
Writing Is Magic - Marc's Blog
С неизбежностью изменений мы уже смирились, но вот вопрос: как работать с ними стратегически, чтобы бизнес продолжал развиваться и давать результаты?
Трансформации могут быть как внешние, так и внутренние — от изменений в мире и на рынке до новых подходов в работе команды и бизнеса.
Управлять изменениями — значит уметь создавать гибкую, адаптивную и устойчивую рабочую среду в компании.
Этому как раз можно научиться на курсе «Управление изменениями» от SETTERS EDUCATION. Вы узнаете:
— как выстраивать процесс изменений в компании
— как сделать бизнес устойчивым к трансформациям
— управлять изменениями на уровне стратегии, процессов и команды
Прямо на курсе вы разработаете пошаговый план трансформаций вашего бизнеса. Он будет учитывать ваши стратегические цели, ресурсы и особенности.
В обучении вас поддержит куратор Юра Филатов — эксперт с 10-летним опытом в продуктах и трансформациях, член совета директоров и CPO в PashaPay.
Курс стартует 27 февраля — читайте подробнее о программе по ссылке и занимайте место 🔥
Больше о курсе
Трансформации могут быть как внешние, так и внутренние — от изменений в мире и на рынке до новых подходов в работе команды и бизнеса.
Управлять изменениями — значит уметь создавать гибкую, адаптивную и устойчивую рабочую среду в компании.
Этому как раз можно научиться на курсе «Управление изменениями» от SETTERS EDUCATION. Вы узнаете:
— как выстраивать процесс изменений в компании
— как сделать бизнес устойчивым к трансформациям
— управлять изменениями на уровне стратегии, процессов и команды
Прямо на курсе вы разработаете пошаговый план трансформаций вашего бизнеса. Он будет учитывать ваши стратегические цели, ресурсы и особенности.
В обучении вас поддержит куратор Юра Филатов — эксперт с 10-летним опытом в продуктах и трансформациях, член совета директоров и CPO в PashaPay.
Курс стартует 27 февраля — читайте подробнее о программе по ссылке и занимайте место 🔥
Больше о курсе
Что влияет на эффективность парного программирования
Парное программирование – как зарядка по утрам. Все прекрасно знают, что это очень полезная практика, но по факту мало кто действительно ее внедряет.
Не любое парное программирование одинаково полезно. Уровень разработчиков в паре, выбранная ими задача и подходы к коммуникации сильно влияют на итоговый результат. Статья дает обзор нескольких исследований, сфокусированных на изучении факторов эффективности парного программирования.
😶Личность участников, или какие-то ее особенности вроде интровертности или открытости мышления, не оказывает значимого эффекта. Любимый многимигороскоп MBTI, ожидаемо, тоже.
📊Профессиональный уровень людей в паре должен быть близок друг к другу. Работающие в паре два мидла показывают заметно больший скачок в качестве результата, чем сеньор и джун.
💬Пары, работающие по нескольким известным правилам коммуникаций, работают лучше, чем те, кто работает стихийно. Сами правила есть в статье.
Помимо факторов, повышающих эффективность, есть несколько антипаттернов, которые ее быстро убивают:
💬Пара слишком глубоко закапывается в детали задачи и забывает свои краткосрочные и долгосрочные цели.
💬Один партнер теряет другого, когда не может объяснить, что и зачем он делает.
💬Один партнер топит другого в слишком душных и подробных объяснениях своей работы.
Если стало интересно, посмотрите еще другой пост того же автора, где он системно разбирает плюсы и минусы парного программирования.
Парное программирование – как зарядка по утрам. Все прекрасно знают, что это очень полезная практика, но по факту мало кто действительно ее внедряет.
Не любое парное программирование одинаково полезно. Уровень разработчиков в паре, выбранная ими задача и подходы к коммуникации сильно влияют на итоговый результат. Статья дает обзор нескольких исследований, сфокусированных на изучении факторов эффективности парного программирования.
😶Личность участников, или какие-то ее особенности вроде интровертности или открытости мышления, не оказывает значимого эффекта. Любимый многими
📊Профессиональный уровень людей в паре должен быть близок друг к другу. Работающие в паре два мидла показывают заметно больший скачок в качестве результата, чем сеньор и джун.
💬Пары, работающие по нескольким известным правилам коммуникаций, работают лучше, чем те, кто работает стихийно. Сами правила есть в статье.
Помимо факторов, повышающих эффективность, есть несколько антипаттернов, которые ее быстро убивают:
💬Пара слишком глубоко закапывается в детали задачи и забывает свои краткосрочные и долгосрочные цели.
💬Один партнер теряет другого, когда не может объяснить, что и зачем он делает.
💬Один партнер топит другого в слишком душных и подробных объяснениях своей работы.
Если стало интересно, посмотрите еще другой пост того же автора, где он системно разбирает плюсы и минусы парного программирования.
Как оценить, насколько вы хороший менеджер
Быть тимлидом – часто неблагодарное занятие. Понять, насколько много пользы ты приносишь, и отделить свой результат от результатов работы команды очень сложно. Каждый здесь изворачивается как может – кто-то пытается поставить себе измеримые цели, кто-то ведет дневничок побед, а кто-то плачет по ночам в подушку. В статье предлагается еще один подход – регулярная оценка своего прогресса по пяти менеджерским шкалам.
💪Execution: насколько качественный результат поставляет ваша команда и насколько предсказуемо это происходит
👨👩👧👧People management: насколько хорошо вы знаете людей в своей команде и помогаете им становиться лучше
📚Team development: как с течением лет развивается ваша команда
👀Strategic vision: насколько ясное видение будущего вы транслируете команде
💬Organizational influence: насколько тесно вы интегрированы в компанию и как влияете на общие успехи
Быть тимлидом – часто неблагодарное занятие. Понять, насколько много пользы ты приносишь, и отделить свой результат от результатов работы команды очень сложно. Каждый здесь изворачивается как может – кто-то пытается поставить себе измеримые цели, кто-то ведет дневничок побед, а кто-то плачет по ночам в подушку. В статье предлагается еще один подход – регулярная оценка своего прогресса по пяти менеджерским шкалам.
💪Execution: насколько качественный результат поставляет ваша команда и насколько предсказуемо это происходит
👨👩👧👧People management: насколько хорошо вы знаете людей в своей команде и помогаете им становиться лучше
📚Team development: как с течением лет развивается ваша команда
👀Strategic vision: насколько ясное видение будущего вы транслируете команде
💬Organizational influence: насколько тесно вы интегрированы в компанию и как влияете на общие успехи
CodeKraft
Evaluating Managers: 5 heuristics to measure managerial impact
Measuring a manager’s impact is hard since outcomes take time. The manager takes full responsibility for the team – be it stagnation, execution woes, poor collaboration, churn, or a lac…
Ведется поиск двух опытных тимлидов в юнит DBA Авито⚡️
Команды SQL и NoSQL поддерживают, консультируют продуктовые команды внутри Авито и решают задачи автоматизации управления и эффективного распределения ресурсов, в том числе с помощью Kubernetes. У Авито грандиозные планы: идут в облака, смотрят в сторону zero-trust в контексте баз, интегрируют хранилища БД в платформу DBaaS.
Вам предстоит выровнять процессы, подхватить внедрение скрама и довести до качественно высокого уровня, построить роадмап команды на пару лет вперёд.
Стек:
🔸В команду SQL: PostgreSQL, Patroni, wal-g, LXC/k8s, Python/Go.
🔸В команду NoSQL: MongoDB, Redis, ClickHouse, Tarantool, Consul, Elasticsearch, Docker, LXC, Kubernetes.
Зарплата: по итогам собеседования, от 361 000 рублей.
👉 Подробнее о вакансиях:
Для SQL bit.ly/3JeLUbb
Для NoSQL bit.ly/3De45df
Команды SQL и NoSQL поддерживают, консультируют продуктовые команды внутри Авито и решают задачи автоматизации управления и эффективного распределения ресурсов, в том числе с помощью Kubernetes. У Авито грандиозные планы: идут в облака, смотрят в сторону zero-trust в контексте баз, интегрируют хранилища БД в платформу DBaaS.
Вам предстоит выровнять процессы, подхватить внедрение скрама и довести до качественно высокого уровня, построить роадмап команды на пару лет вперёд.
Стек:
🔸В команду SQL: PostgreSQL, Patroni, wal-g, LXC/k8s, Python/Go.
🔸В команду NoSQL: MongoDB, Redis, ClickHouse, Tarantool, Consul, Elasticsearch, Docker, LXC, Kubernetes.
Зарплата: по итогам собеседования, от 361 000 рублей.
👉 Подробнее о вакансиях:
Для SQL bit.ly/3JeLUbb
Для NoSQL bit.ly/3De45df
Большое исследование тимлидов и руководителей разработки
Как давние подписчики канала могли заметить, я очень люблю проводить всякие опросы. Помните недавнее исследование продактов? Так вот, пришла очередь узнать, что происходит с тимлидами!
🤔Какие навыки для руководителей самые важные
💰По каким критериям оценивают их работу
💻Сколько времени уходит на написание кода
👋Как попадают в профессию, и куда из нее уходят
📚Полезные для развития каналы, курсы и книги
Проходите опрос и пошарьте его другим знакомым тимлидам! Результаты будут в открытом доступе в конце марта, а я обязательно буду смотреть на них при выборе будущих тем для канала.
👉Пройти опрос
Как давние подписчики канала могли заметить, я очень люблю проводить всякие опросы. Помните недавнее исследование продактов? Так вот, пришла очередь узнать, что происходит с тимлидами!
🤔Какие навыки для руководителей самые важные
💰По каким критериям оценивают их работу
💻Сколько времени уходит на написание кода
👋Как попадают в профессию, и куда из нее уходят
📚Полезные для развития каналы, курсы и книги
Проходите опрос и пошарьте его другим знакомым тимлидам! Результаты будут в открытом доступе в конце марта, а я обязательно буду смотреть на них при выборе будущих тем для канала.
👉Пройти опрос
survey.alchemer.eu
Исследование рынка руководителей разработки, 2023
Исследование рынка руководителей разработки, 2023.
Как выделение 10% времени команды на решение техдолга изменило проект
История стара, как мир – менеджмент подгонял команду катить как можно больше фичей и не тратить время на качество кода, и в то же время в команде не было кого-то достаточно сеньорного, чтобы заметить проблемы в таком подходе и наладить более здоровый процесс. Затем в команде появился автор статьи, смог договориться о выделении части времени команды на системную борьбу с техническим долгом, и поменять часть общепринятых практик.
Если вы находитесь в похожей ситуации, проект со временем разваливается, а как на это повлиять вы не знаете, статья может помочь.
История стара, как мир – менеджмент подгонял команду катить как можно больше фичей и не тратить время на качество кода, и в то же время в команде не было кого-то достаточно сеньорного, чтобы заметить проблемы в таком подходе и наладить более здоровый процесс. Затем в команде появился автор статьи, смог договориться о выделении части времени команды на системную борьбу с техническим долгом, и поменять часть общепринятых практик.
Если вы находитесь в похожей ситуации, проект со временем разваливается, а как на это повлиять вы не знаете, статья может помочь.
Разгребание огромного бэклога багов на багатоне
Команда устала от постоянно растущего бэклога багов, и решила поменять процессы, внедрив Zero Bug Policy. Но перед этим они решили разобрать огромный бэклог багов, скопившийся годами.
Сначала приоритет всех багов переоценили, посмотрев на их серьезность и воспроизводимость. Затем часть закрыли как неактуальные. Оставшиеся предложили командам решить в формате багатона – короткого мероприятия, в котором несколько команд соревнуются в количестве закрытых багов. Весь бэклог таким образом разобрать не получилось, но хороший прогресс появился.
Формат классный, мы организовывали очень похожую историю в Авито. Про нее важно понимать несколько вещей:
*️⃣Перекладывание багов в трекере из одной кучки в другую, даже если оно сопровождается изменением приоритетов, не очень полезная работа – продукт сам по себе от этого лучше не станет.
*️⃣Титаническое усилие по решению багов тоже в перспективе не поможет продукту. Если не менять процессы и критерии качества. вы очень быстро вернетесь к первоначальному уровню багов.
Команда устала от постоянно растущего бэклога багов, и решила поменять процессы, внедрив Zero Bug Policy. Но перед этим они решили разобрать огромный бэклог багов, скопившийся годами.
Сначала приоритет всех багов переоценили, посмотрев на их серьезность и воспроизводимость. Затем часть закрыли как неактуальные. Оставшиеся предложили командам решить в формате багатона – короткого мероприятия, в котором несколько команд соревнуются в количестве закрытых багов. Весь бэклог таким образом разобрать не получилось, но хороший прогресс появился.
Формат классный, мы организовывали очень похожую историю в Авито. Про нее важно понимать несколько вещей:
*️⃣Перекладывание багов в трекере из одной кучки в другую, даже если оно сопровождается изменением приоритетов, не очень полезная работа – продукт сам по себе от этого лучше не станет.
*️⃣Титаническое усилие по решению багов тоже в перспективе не поможет продукту. Если не менять процессы и критерии качества. вы очень быстро вернетесь к первоначальному уровню багов.