Cascade of Attention-Deficit Teenagers
Представьте себе продукт, в котором со временем накопилось очень много багов и проблем. Вместо их постепенного исправления разработчики принимают решение выкинуть старый код и переписать всю систему с нуля, учтя предыдущие ошибки, и в этот раз сделав все по красоте. Проходит год, продукт переписан, баги автоматически переведены в статус закрытых, но пользователи продолжают репортить о том, что проблемы сохранились и все еще их беспокоят. Знакомая история?
Править баги – нудно и скучно. Переписывать все с нуля – челлендж и интересно. Я такое видел регулярно, но не знал, что у такого поведения уже есть название – CADT, Cascade of Attention-Deficit Teenagers. Теперь и вы можете его использовать!
Представьте себе продукт, в котором со временем накопилось очень много багов и проблем. Вместо их постепенного исправления разработчики принимают решение выкинуть старый код и переписать всю систему с нуля, учтя предыдущие ошибки, и в этот раз сделав все по красоте. Проходит год, продукт переписан, баги автоматически переведены в статус закрытых, но пользователи продолжают репортить о том, что проблемы сохранились и все еще их беспокоят. Знакомая история?
Править баги – нудно и скучно. Переписывать все с нуля – челлендж и интересно. Я такое видел регулярно, но не знал, что у такого поведения уже есть название – CADT, Cascade of Attention-Deficit Teenagers. Теперь и вы можете его использовать!
Если ИТ – это ваш конек, то Тинькофф ждет вас 23 января на катке в Москве!
Ледовый ИТ-квест, нетворкинг, дискуссии со спикерами в теплом шатре и многое другое. Вечер точно будет насыщенным и приятным. За коньки не беспокойтесь — их выдадут бесплатно.
Не медлите, регистрируйтесь сами и зовите коллег — будет весело!
Ледовый ИТ-квест, нетворкинг, дискуссии со спикерами в теплом шатре и многое другое. Вечер точно будет насыщенным и приятным. За коньки не беспокойтесь — их выдадут бесплатно.
Не медлите, регистрируйтесь сами и зовите коллег — будет весело!
Откладывайте технические решения
Откладывать принятие решения до последнего возможного момента – в общем виде хорошая практика. Чем больше мы ждем, тем больше информации собираем и снимаем неопределенности. А часто спустя время оказывается, что решение вообще принимать не нужно, так как изначальная потребность ушла.
Конечно, ключевой вопрос здесь – как определить ту точку, в которой оттягивание принятия решения приносит вред, а не пользу. Универсального ответа нет, есть только несколько рекомендаций:
- Вы решаете существующую проблему, а не что-то, что возможно станет актуально когда-то в будущем.
- Есть понятные бизнес-требования к решению, вы не пытаетесь заложиться в нем на бесконечность возможных сценариев.
Откладывать принятие решения до последнего возможного момента – в общем виде хорошая практика. Чем больше мы ждем, тем больше информации собираем и снимаем неопределенности. А часто спустя время оказывается, что решение вообще принимать не нужно, так как изначальная потребность ушла.
Конечно, ключевой вопрос здесь – как определить ту точку, в которой оттягивание принятия решения приносит вред, а не пользу. Универсального ответа нет, есть только несколько рекомендаций:
- Вы решаете существующую проблему, а не что-то, что возможно станет актуально когда-то в будущем.
- Есть понятные бизнес-требования к решению, вы не пытаетесь заложиться в нем на бесконечность возможных сценариев.
www.eferro.net
Lean Software development: The art of postponing decisions
One of the seven principles of Lean Software Development is Defer Commitment . This principle tries to maintain options open ( options have ...
Как профессионально уничтожить рутину тестирования API. Опыт перехода на BDD-Фреймворк.
Все знают, как первые пробы автоматизации могут «уронить» мотивацию команды. Статья Юлы поможет перестать «кликать мышкой» и пересылать коллекции, и при этом безболезненно перейти на автоматизацию тестирования API. Здесь расскажут по шагам, как внедрить фреймворк, навести порядок в Jira, автоматизировать тестирование с учётом мультиплатформенности. Материал статьи призван помочь сгенерировать фреймворк и обучить команду, которая может автоматизировать без знания кода и уничтожить рутину бесконечного «кликанья» мышкой.
Читать статью
Все знают, как первые пробы автоматизации могут «уронить» мотивацию команды. Статья Юлы поможет перестать «кликать мышкой» и пересылать коллекции, и при этом безболезненно перейти на автоматизацию тестирования API. Здесь расскажут по шагам, как внедрить фреймворк, навести порядок в Jira, автоматизировать тестирование с учётом мультиплатформенности. Материал статьи призван помочь сгенерировать фреймворк и обучить команду, которая может автоматизировать без знания кода и уничтожить рутину бесконечного «кликанья» мышкой.
Читать статью
О чем стоит рассказывать вашему менеджеру
Когда-то ваш менеджер решил открыть вакансию, на которую вас и наняли. Он сделал это потому, что у него самого не хватало рук и фокуса, и он готов был делегировать часть ответственности отдельному человеку. Чем больше у менеджера зона ответственности, тем больше кусков из нее приходится делегировать.
Из этого следует, что он не в курсе всех деталей вашей работы, и, скорее всего, только в общих чертах знает, чем вы занимаетесь. Это нормально, ведь если бы ему пришлось постоянно держать поднятый контекст про все, чем вы занимаетесь, ваша польза стала бы довольно сомнительной.
Но давать ему совсем отрываться от вашей работы – плохая идея. Если ваш менеджер не знает о назревающих проблемах, то это может усложнить его работу в будущем. Если он не знает о ваших целях, то может оказаться, что вы копаете куда-то не туда.
В статье разбирается несколько областей, о которых ваш менеджер скорее всего не знает, и о которых стоит его проактивно держать в курсе:
*️⃣Что замедляет вас, и решеник каких проблем могло бы помочь команде двигаться быстрее
*️⃣Ваш прогресс по ключевым проектам
*️⃣Основные технические риски
*️⃣Ваши текущие цели
*️⃣Проблемы, которые требуется эскалировать
*️⃣Чем вы занимаетесь помимо основных задач
Когда-то ваш менеджер решил открыть вакансию, на которую вас и наняли. Он сделал это потому, что у него самого не хватало рук и фокуса, и он готов был делегировать часть ответственности отдельному человеку. Чем больше у менеджера зона ответственности, тем больше кусков из нее приходится делегировать.
Из этого следует, что он не в курсе всех деталей вашей работы, и, скорее всего, только в общих чертах знает, чем вы занимаетесь. Это нормально, ведь если бы ему пришлось постоянно держать поднятый контекст про все, чем вы занимаетесь, ваша польза стала бы довольно сомнительной.
Но давать ему совсем отрываться от вашей работы – плохая идея. Если ваш менеджер не знает о назревающих проблемах, то это может усложнить его работу в будущем. Если он не знает о ваших целях, то может оказаться, что вы копаете куда-то не туда.
В статье разбирается несколько областей, о которых ваш менеджер скорее всего не знает, и о которых стоит его проактивно держать в курсе:
*️⃣Что замедляет вас, и решеник каких проблем могло бы помочь команде двигаться быстрее
*️⃣Ваш прогресс по ключевым проектам
*️⃣Основные технические риски
*️⃣Ваши текущие цели
*️⃣Проблемы, которые требуется эскалировать
*️⃣Чем вы занимаетесь помимо основных задач
Julia Evans
Things your manager might not know
Четыре признака плохих роадмапов
Сразу оговорюсь, что статья, на самом деле, не о проблемах роадмапов, а о проблемах продуктовой культуры и целеполагания в компаниях. Роадмап – просто артефакт, на котором эти проблемы становятся ярко заметными.
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, ожидаемо, тоже.
📊Профессиональный уровень людей в паре должен быть близок друг к другу. Работающие в паре два мидла показывают заметно больший скачок в качестве результата, чем сеньор и джун.
💬Пары, работающие по нескольким известным правилам коммуникаций, работают лучше, чем те, кто работает стихийно. Сами правила есть в статье.
Помимо факторов, повышающих эффективность, есть несколько антипаттернов, которые ее быстро убивают:
💬Пара слишком глубоко закапывается в детали задачи и забывает свои краткосрочные и долгосрочные цели.
💬Один партнер теряет другого, когда не может объяснить, что и зачем он делает.
💬Один партнер топит другого в слишком душных и подробных объяснениях своей работы.
Если стало интересно, посмотрите еще другой пост того же автора, где он системно разбирает плюсы и минусы парного программирования.
Парное программирование – как зарядка по утрам. Все прекрасно знают, что это очень полезная практика, но по факту мало кто действительно ее внедряет.
Не любое парное программирование одинаково полезно. Уровень разработчиков в паре, выбранная ими задача и подходы к коммуникации сильно влияют на итоговый результат. Статья дает обзор нескольких исследований, сфокусированных на изучении факторов эффективности парного программирования.
😶Личность участников, или какие-то ее особенности вроде интровертности или открытости мышления, не оказывает значимого эффекта. Любимый многими
📊Профессиональный уровень людей в паре должен быть близок друг к другу. Работающие в паре два мидла показывают заметно больший скачок в качестве результата, чем сеньор и джун.
💬Пары, работающие по нескольким известным правилам коммуникаций, работают лучше, чем те, кто работает стихийно. Сами правила есть в статье.
Помимо факторов, повышающих эффективность, есть несколько антипаттернов, которые ее быстро убивают:
💬Пара слишком глубоко закапывается в детали задачи и забывает свои краткосрочные и долгосрочные цели.
💬Один партнер теряет другого, когда не может объяснить, что и зачем он делает.
💬Один партнер топит другого в слишком душных и подробных объяснениях своей работы.
Если стало интересно, посмотрите еще другой пост того же автора, где он системно разбирает плюсы и минусы парного программирования.