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

Писал как-то про DORA - метрики скорости и стабильности DevOps-процессов. В продолжение темы несколько слов о фреймворках SPACE и DevEx, нацеленных на разрабов. Их можно использовать в комплексе вместе с DORA.

SPACE - это фреймворк для измерения продуктивности разработчиков, разработан в Microsoft в 2021. Это акроним.

▪️Satisfaction and well-being (Удовлетворенность и благополучие) — насколько разработчики довольны своей работой, инструментами и балансом (оценивается через опросы). ▪️Performance (Производительность) — качество и результативность работы (не объем кода, а то, какой ценный продукт выдан в срок). ▪️Activity (Активность) — базовые количественные показатели (например, количество пулл-реквестов, сборок, коммитов — но только как часть общей картины, а не единственный критерий). ▪️Communication and collaboration (Коммуникация и взаимодействие) — как команды общаются, насколько прозрачно идет обмен знаниями и документацией. ▪️Efficiency and flow (Эффективность и состояние потока) — насколько легко разработчик доводит задачу от старта до финиша, не утопая в прерываниях и бюрократии.

DevEx (Developer Experience, опыт разработчика) - это концепция (и одноименный фреймворк), которая фокусируется на удобстве повседневной работы программиста. Она отвечает на вопрос: «Насколько легко разработчику делать свою работу, или же он постоянно борется с медленными билдами, плохой документацией и сложными процессами?».

В DevEx есть три главных измерения: ▪️Петли обратной связи (Feedback loops) — как быстро разработчик узнает результат своих действий (например, сколько минут собирается проект или проходят тесты). ▪️Когнитивная нагрузка (Cognitive load) — сколько лишней сложной информации в голове нужно держать программисту, чтобы просто внести простую правку (сложная архитектура, запутанный легаси-код). ▪️Состояние потока (Flow state) — может ли человек часами глубоко концентрироваться на задаче или его постоянно дергают на созвонах, в чатах и решают мелкие блокеры. DevEx исследует среду и «трение» (что мешает писать код быстрее и с меньшим стрессом). SPACE дает верхнеуровневый, комплексный взгляд на команду и продуктивность сразу по пяти направлениям. Вот тут и тут подробнее сравнивают эти подходы. #process

Эта осень будет урожайной на релизы проектов, которыми я занималась весь год✍️ Сегодня издательство МИФ написало нам в чате авторов, что пришла из типографии и готова к продаже наша книга «Суперкоманды». 10 главных сил, которые превратят команду в драйвер роста бизнеса. Мы написали ее вместе с Леной Черниковой и Джаннет Кашурниковой, партнерами Invisible Force. Эта книга о том, как раскрыть потенциал команды и превратить ее в источник бизнес-результата. Дождливым октябрьским вечером почти год назад мы с Леной Черниковой пили чай в Горыныче, и Лена рассказывала мне о том, что у них с командой Inforce давно есть идея написать книгу о командах. Inforce много лет проводил исследования и делал эксперименты. В результате родилась методология суперсил эффективной команды — от автономности, коллаборации и предпринимательства до психологической безопасности и непрерывного развития. Идея Лена и Джаннет была в том, что у каждой команды есть одна выраженная суперсила, которая приводит ее к успеху. Я к тому моменту перевела и отредактировала с МИФ книгу «Венчурное мышление» Ильи Стребулаева и Алекса Данга. И Лене понравился текст и стилистика этой книги на русском языке. Она попросила у меня совета, кто может помочь им с написанием книги. Не долго думая я предложила ей писать вместе. Мы объединили наши знания. Опыт Лены и Джаннет в работе с командами и лидерами, и мой — с в работе предпринимателями и текстами о них. Вот уже почти 16 лет как журналист и главный редактор больших деловых медиа я разговариваю с предпринимателями на одном языке и пишу о них в разных жанрах и форматах. Со временем мне стало ясно одно — ни один большой предприниматель или топ-менеджер не существует в пустоте. За ним всегда есть команда. И часто именно правильно собранные команды помогают идее стать больше самого лидера. Бывает и так, что даже сильные, талантливые, амбициозные люди в неправильно устроенной среде начинают буксовать, терять энергию и не могут раскрыть свой потенциал. Мне было важно, чтобы в книге оставались живые люди и реальные бизнес-истории. Поэтому здесь есть не только исследования и эксперименты, за которые отвечали Лена и Джаннет, но и кейсы российских компаний. Особенно приятно, что нам удалось поговорить о командах не только крупных корпораций — банка «Точка», КРОК, «Ренессанс страхование» — с которыми работают Лена и Джаннет, но и с предпринимателями, героями моих текстов для Forbes и «Основателей»: создательницей лектория «Синхронизация» Марией Бородецкой, фаундерами страховой компании «Лучи» (ex-BestDoctor) Марком Саневичем и Михаилом Беляндиновым, основателем SPLAT Евгением Деминым и другими. Главная мысль, которую мне хочется донести до читателя, который возьмет в руки нашу книгу — суперкоманды не возникают сами собой, их можно только построить своими руками, создавая среду, не выжигая людей негативной мотивацией, интригами и психологической небезопасностью. И если делать это осознанно, бизнес получает не просто сотрудников, а настоящую созидательную силу. @karpovaventures✍️

Про сбалансированность команд и безработицу у айтишников Несколько лет назад умный мужчина с большим опытом в IT объяснял мне следующее: "Сбалансированная и эффективная команда — это когда всех по чуть-чуть. Есть зеленые джуны, есть перезрелые сеньоры, есть мидлы. Люди внутри команды растут, обучают друг друга". А теперь никому нахер не нужна сбалансированная команда, от слова «джун» мутит прямо как Вафлю от мыла. А все потому, что в сбалансированная команда выглядит так: один синьор + 10 ИИ-агентов вокруг него. А все остальные на выход, рынок порешал сегодня так. Ничего хорошего в этом нет конечно (для работников), а для бизнеса очень даже приятно — прибыль сама по себе растет.

Периодически натыкаюсь на разные исследования о том, что в среднем AI не повышает эффективность разработки, что часть команд получают существенный буст, а другая часть наоборот замедляется, да и на моих консультациях это довольно распространенная проблема. Так вот, понятно, что во внедрении AI в существующие процессы и команды разработки куча нюансов и это комплексный процесс, требующий системного подхода и изучения - самостоятельного (больше шишек) либо с условным наставником, который уже успел пройти этот путь (меньше шишек, быстрее профит). Но менее очевидно другое - при внедрении такого мощного бустера, как AI замедление на начальных этапах вполне естественно. Грубо это можно сравнить с тем, как раньше все в вашем районе передвигались на велосипедах и тут все (или не все) резко пересели на автомобили, не успев получить права - да, первое время будет много аварий, но постепенно команда учится на этих ошибках и движение на дорогах сначала нормализуется, затем ускоряется (особенно, при наличии грамотного регулировщика). Главное только в течение этого процесса не расфигачить район (сломать продукт) и не растерять водителей (сотрудников) от травм, не совместимых с жизнью. А как у вас в команде обстоят дела с перфомансом после внедрения агентной разработки? И как вы этот перфоманс измеряете? @ai_driven

Попытки разорвать порочную практику и не работать в выходные в этом августе терпят полный крах. Ранним утром воскресенья заканчиваю вычитывать корректорскую правку из издательства нашей книги «Суперкоманды»✍️ Невероятное ощущение, когда твой многомесячный труд обретает форму. В ноябре мы с Леной Черниковой, сидя в Горыныче, задумали написать вместе книгу о том, как разные суперсилы проявляются в командах и к чему это ведет. Потом было ощущение ужаса от того, как мы вообще это сделаем, часы зумов и недели сидения с текстом и редактурой. И вот. Обложки пока нет, но книга на верстке в МИФ, в октябре будет презентация в Ноодоме. Ну и I’m halfway through my second book. Ее презентация будет в ноябре, а рукопись надо успеть сдать до 10 сентября. Что же, продолжаем рабочие выходные. @karpovaventures✍️

Басня: система и ее части Одна автобусная компания решила создать «лучший в мире автобус». Они разобрали лучшие машины конкурентов, взяли самый надежный двигатель от одной марки, лучшую подвеску от другой, идеальную коробку передач от третьей. Когда они попытались собрать всё вместе, детали даже не подошли друг к другу. Система - это не сумма её частей, а продукт их взаимодействия. Пример в IT У вас четыре продукта. Если вы наймете лучшего UX-дизайнера для Продукта А, лучшего data-инженера для Продукта Б и лучшего маркетолога для Продукта В, но заставите их работать изолированно, ваш портфель не станет лидером рынка. Или другой пример: попытка взять «лучшие практики» из разных фреймворков (Scrum, SAFe, Basecamp Shape Up) и слепо объединить их в один процесс без учета культурного контекста компании приведет к коллапсу разработки. Вывод Улучшение отдельных частей системы может ухудшить систему в целом. Фокусируйтесь на интерфейсах взаимодействия между вашими продуктами и командами, а не на локальной эффективности каждого из них. P.S. Кайфую от системной логики. Божечки, почему я так долго откладывал это обучение😍 #продуктовыйпуть

💁‍♀️ Просматривала вчера новый Agile Practice Guide, и там была отсылка к Google’s Project Aristotle. Они исследовали 180 команд, чтобы понять, какие факторы делают команды эффективными. Главным из них оказалась — психологическая безопасность (psychological safety). Что она подразумевает, поговорим попозже. А сейчас интересно другое — Google НЕ нашёл значимой связи между эффективностью команд и: - Совместной работой в одном месте - Принятием решений строго консенсусом - Экстраверсией участников команды - Индивидуальной результативностью - Объёмом нагрузки - Позицией членов команды - Размером команды - Стажем работы Ну, про размер команды, конечно, очень спорно, но им виднее...)

Борис Чёрный поделился у себя в твиттере инсайтом, как меняются роли в разработке продуктов:

По мере того как инженерия, продукт, дизайн, DS и другие функции трансформируются в роли нового типа, я размышлял о том, как могут эти роли выглядеть в будущем. Например, глядя на команду Claude Code, я вижу, как мне кажется, пять архетипов: 1. Prototyper: придумывает совершенно новые идеи; много их генерирует, и большинство так и не доходит до релиза 2. Builder: быстро превращает прототип или идею в production-grade продукт и инфраструктуру 3. Sweeper: приводит в порядок интерфейс, упрощает код и систему, убирает лишние фичи, оптимизирует производительность 4. Grower: берёт уже построенный продукт и итерациями улучшает его Product-Market Fit 5. Maintainer: отвечает за зрелость и масштабируемость системы — безопасность, надёжность, скорость и эффективность Люди могут совмещать несколько ролей, иногда три. Я также замечаю, что эти роли не привязаны к должности: в Anthropic одни дизайнеры соответствуют категории 1, другие — 2, третьи — 3. И то же самое с инженерами, продакт-менеджерами и DS. Здоровой команде нужен микс архетипов — в зависимости от продукта: • Новому продукту до PMF нужны люди, сильные в 1+2+3 • Растущему продукту, нашедшему PMF, нужны 2+3+4 и немного 5 • Продукту с прочным PMF нужны 3+4+5 и немного 2 Возможно продуктовые роли будущего будут выглядеть именно так — а не как сейчас, привязанные к конкретной специализации?

→ https://x.com/bcherny/status/2071379474277613732