Кто такие Навигаторы и почему они вам нужны
Кому читать: руководителям и инженерам, которые хотят вырасти дальше сеньора.
Статья предлагает новую роль в компании — Навигатор. Это опытный инженер, который отвечает за целую область разработки. Например, домен или продуктовая вертикаль. Автор — Вилл Ларсон — описывает решаемые проблемы и алгоритм внедрения роли Навигатора в компанию.
Проблемы, которые решают Навигаторы:
- Разработчики не согласны с решениями, которые принимаются в другой части компании. Например, "неправильный" дизайн сервисов в соседнем домене, не те стандарты разработки, не то API и все такое.
- Непонятно, кто отвечает за весь домен или вертикаль целиком. С сервисом — понятно, есть команда. А к кому обращаться, если есть вопросы по целой группе сервисов?
- Как разрулить конфликт двух команд разных доменов без эскалации в СТО?
На моем прошлом месте работы я внедрил роль Навигатора, правда, назвал я ее стафф-инженер, потому что на тот момент Вилл Ларсон Навигаторов еще не описал. В статье описан его опыт и видение, с которым я согласен почти полностью.
В компаниях от 100 человек Навигаторы нужны как воздух, без них начнется хаос и неразбериха. Причем отдельно выделенные архитекторы проблемы не решат, а могут сделать даже хуже.
Читайте и пробуйте внедрить Навигаторов у себя — или подумайте, как вам самим стать Навигатором. Роль интересная, очень востребованная на рынке. А еще название прикольное.
Инцидент коммандер: как стать человеком, у которого есть план (даже если его нет)
Кому читать: всем, кто спасти мир — в смысле, компанию
Представьте: произошел инцидент и вы собрались, чтобы его потушить. Все беспорядочно пытаются выяснить проблему, действия не согласованы, за метриками никто не следит, коммуникацию с бизнесом никто не производит. Ужас какой-то.
Или все может пойти по иному пути: появляется человек, который скажет всем, что делать. Вася мониторит метрики, Петя проверяет последние релизы, Аня ищет ошибку в логах, а Толя дает бизнесу апдейты каждые 15 минут. Все на своих местах. Все знают, что делать.
Человек, который остановит судорожную беготню — Инцидент коммандер. Его разум холоден, действия точны, уверенность в себе непоколебима. Если такой человек есть, инцидент вы потушите в разы быстрее.
Статья рассказывает, как вам стать Инцидент коммандером и принять на себя руководство кораблем, который вот-вот потонет и спасти его. Такие люди — на вес золота, и очень быстро становятся опорой для всей компании. Даже в крупной организации на тысячу человек их имена знают все.
Инцидент коммандер — это не постоянная роль. Это плащ, который надевает обычный разработчик или руководитель, чтобы превратится в героя вечера и спасти город. В смысле, компанию.
Хотите узнать, как примерить на себя геройский плащ? Читайте! Этому городу нужен новый герой.
Вы понимаете роль Product Owner'а неправильно
Кому читать: всем, кто работает с продакт овнерами
Скрам научил нас, что у разработки может быть лишь два вопроса к продакту: какие фичи пилить и в каком порядке? Но вообще-то есть нюанс.
Автор приводит аналогию, что разработка — это солдаты на поле боя, а продакты это командиры в штабе и раздают приказы по рации. Продакт не может сказать, что именно делать, только дает задачу. Как именно ее решить, разработка знает лучше, потому что находится прямо в гуще событий.
Статья предлагает по-новому построить ваши отношения с продуктом: узнайте своих клиентов, поймите данные, которые стоят за гипотезами продакта.
Это не сухая статья, а оригинальные метафоры и примеры, которые помогут вам взглянуть на роль разработчика по-новому. Если вы работаете в продуктовой команде и ощущаете себя простым исполнителем, исправьте это — а автор подскажет вам, как.