Как использовать Definition of Ready

Старый, но хороший пост с кучей комментариев про то, что такое Definition of Ready, как он может вредить командам и как его трансформировать в полезный инструмент.

Вообще, Definition of Ready – это набор критериев, которые показывают, насколько задача готова к тому, чтобы ее брали в работу. Например, она должна быть декомпозирована до определенного размера, иметь определенную отметку от QA, или содержать в себе дизайн со всеми возможными граничными состояниями.

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

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

Чтобы Definition of Ready не причинял проблем, следуйте двум принципам:

- Не включайте в список критериев требования по 100% готовности чего-то до старта работы.
- Трактуйте DoR как набор рекомендаций, а не обязательных правил.

Причины плохого перфоманса

1️⃣Сотрудник плохо перформит, потому что вы поставили его на неподходящую ему роль.
2️⃣Сотрудник только вышел на новую роль, на него свалилось много всего неизвестного, и он не справляется из-за переизбытка информации.
3️⃣Причины кроются где-то в личных или семейных событиях.
4️⃣У вас есть неявные ожидания от роли сотрудника, а он привык работать по-другому.
5️⃣Люди меняются, и роли, которые им подходили раньше, могут переставать подходить со временем.

“Анти-требования” для модели данных

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

Распилить модель правильным образом могут помочь “анти-требования”. Идея такая – вы формулируете фейковое бизнес-требование, влияюбщее на отношения атрибутов, и оцениваете его адекватность. Например, “Когда описание товара длиннее 5000 символов, его цена должна измениться на 20%”. Если требование звучит неадекватно – нет никакой необходимости держать эти атрибуты в рамках одной сущности. Если звучит адекватно – связь есть, нужно выделять в отдельную сущность.

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

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

Challenges -> Concerns -> Problems -> Barriers

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

Ищут Тимлида в Облако Selectel.

Тимлид в Selectel это

▪️Про техническое лидерство, архитектуру и готовность залезть в код
▪️Про мотивацию и развитие своей команды
▪️Про общение и кооперацию со смежными командами и создание ценности для клиента общими силами

Откликнуться можно тут
По вопросам можно писать сюда

Подробный обзор системы грейдов в Shopify

Shopify зарефакторили свою систему грейдов. Основные идеи следующие:

- Всего у инженеров восемь грейдов, от стажера до fellow.
- Каждый грейд разделен на пять сегментов по “mastery”. Mastery – это технические навыки и доменные знания, получаемые сотрудником по мере приобретения опыта.
- Mastery отдельно оценивается по пяти характеристикам: технические знания, решение задач, принятие решений, лидерство.
- Переход между уровнями не завязан на mastery. Это просто еще одна проекция, в рамках которой можно расти в зарплате, не беря на себя новую ответственность.

Вторая часть обзора системы грейдов в Shopify

На прошлой неделе пост про новую систему грейдов в Shopify собрал под 300 комментариев. Давайте продолжим обсуждать!

👉Сотрудники сами выделяют, какой процент компенсации получать деньгами, а какой – акциями. Вот тут есть больше деталей.
👉Уровни зарплаты привязаны к локации.
👉По фидбэку сотрудников, появление шкалы Mastery позволяет не ломиться вверх по карьерной лестнице, а спокойно жить обычным сеньором, и постепенно расти в зарплате.

Вторая часть обзора системы грейдов в Spotify

На прошлой неделе пост про новую систему грейдов в Shopify собрал под 300 комментариев. Давайте продолжим обсуждать!

👉Сотрудники сами выделяют, какой процент компенсации получать деньгами, а какой – акциями. Вот тут есть больше деталей.
👉Уровни зарплаты привязаны к локации.
👉По фидбэку сотрудников, появление шкалы Mastery позволяет не ломиться вверх по карьерной лестнице, а спокойно жить обычным сеньором, и постепенно расти в зарплате.

Доклад на TeamLead Conf про импортозамещение

На этой неделе в Петербурге проходит конференция TeamLead Conf. Ребята из ГК «Астра», ветераны отечественного ПО, продукты которых внедрены на куче предприятий в разных отраслях, попросили нас рассказать об их докладе про то, как их процессы и системы внутренних сервисов помогают создавать продукты для импортозамещения и быстро адаптироваться к меняющемуся рынку. Если вы занимаетесь чем-то близким к импортозамещению, вам должно быть интересно.

Чтобы не заблудиться – 29 июня 16:30, «Зал Синий».

Три ошибки менеджеров-новичков

1️⃣Вы тратите большую часть своих усилий на менеджмент ваших сотрудников: их развитие, обратную связь, помощь в решении проблем и wellbeing. Но из-за этого вы забываете заниматься менеджментом других людей – руководителя, стейкхолдеров, ваших peers.
2️⃣Helicopter management – вы слишком трепетно относитесь к людям в своей команде, не даете им совершать ошибки, тратите слишком много собственного ресурса на поддержку их работоспособности, оберегаете от негативного фидбэка.
3️⃣Вы не мыслите системно. Если вам что-то не нравится в действии других людей, вы считаете их некомпетентными вместо того, чтобы попытаться понять, как окружающая среда могла привести их к принятым ими решениям.

Как можно жить без оценок задач

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

А вот, если что, выпуск Подлодки на эту же тему!

Результаты опроса про зарплаты СТО

В опросе приняли участие 600 человек, из которых большинство – C-level. Данные очень сильно смещены в сторону UK и Западной Европы.

👉Самый частый подход к equity: stock options с вестингом 4 года и клиффом 1 год.
👉80% CTO считают самым важным элементом своей финансовой компенсации зарплату.
👉Средняя зарплата CTO находится в интервале 176-204 тысячи фунтов, а бонус в районе 35 тысяч.
👉Средний размер equity – 1.8 миллиона фунтов.

Подкаст “Бреслав и Ложечкин”: Что является продуктом труда руководителя

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

А вообще, мы для подкаста отдельный канал завели – так что подписывайтесь, и оставляйте там фидбэк!
👉@breslavandlozhechkin

Три важных качества СТО

Если вы вдохновились размером зарплаты и опционов у СТО, и начали строить свой карьерный план в этом направлении, держите хорошую статью от СТО Lamoda про то, какие три качества ему помогают больше всего:

- Бизнес-партнерство: нужно очень хорошо понимать бизнес и помогать генеральному директору его растить.
- Коммуникации: нужно уметь общаться на языке людей, которые не похожи на вас, и объяснять нетехническим людям, почему IT команда тратит так много денег.
- Стратегическое видение: нужно балансировать между быстрыми победами, которые обеспечивают политический вес, и долгосрочными проектами, которые не приносят никакой пользы сразу, но окупаются когда-то в будущем.

Воркшоп про работу в онлайн-командах

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

Если последние несколько лет вас не подготовили к управлению удаленными командами, или вы хотите улучшить коммуникации в ней, заходите на воркшоп про работу с онлайн-командами! Организаторы обещают сразу три темы:

- Подготовка команды к удаленной работе
- Инструменты улучшения внутрикомандного взаимодействия в онлайне
- Как собрать эффективную команду и коммуникацию в онлайне

📆Дата: 4 июля в 14:00 по Москве
👉Регистрация

Гайд по обработке инцидентов

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

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