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

Когда мы определили на каком этапе жизненного цикла находится наш продукт и после оценки существующих метрик(если есть) — об этом можно почитать в предыдущей статье, и если мы пришли к выводу о желании и необходимости доработки продукта, то я предлагаю начать разбор с процессов. Я поделюсь своим опытом, который помог не только повысить производительность отдельных команд, но и в целом улучшить работу департамента. Мы поговорим о том, какие процессы нужны, когда их действительно стоит внедрять, как избежать карго-культов и неэффективных митингов, а также разберёмся с внутренними и внешними процессами, наймом и постепенным внедрением изменений.

Часто бывает, что в компаниях можно наблюдать две крайности:

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

2. Избыточное количество процессов: такое чаще встречается в крупных организациях или там, где менеджмент потерял доверие к департаменту разработки и пытается проконтролировать все ее аспекты. Вместо того, чтобы искать корень проблемы, вводят всё новые митинги, отчёты, согласования, формальные практики. В итоге это забюрокрачивает жизнь команды, время уходит на формальное соблюдение процессов, а реальная ценность продукта страдает.

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

Когда вы приходите в новую компанию (или новый проект), естественно хочется применить все прекрасные практики, о которых вы читали в умных книгах по Agile, Lean, Kanban или, которые видели у себя на прошлом месте работы. Но надо понимать, что любой процесс живёт в конкретном контексте. Как и к ребенку(а раз зашел разговор о пересмотре существующей работы, то явно проблемному), к продукту нужен индивидуальный подход.

При анализе стоит учесть:

1. Сложность системы: монолит или микросервисы, есть ли устаревшие технологии.

2. Зависимости от других продуктов: есть ли внешние сервисы, которые мы не контролируем, или смежные департаменты, влияющие на сроки.

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

4. Технические компетенции сотрудников: что умеет команда, нет ли серьёзного дефицита в кадрах/компетенциях.

5. Релизный цикл и способ поставки (S)SDLC: как часто релизы, CI/CD или ручные релизы, есть ли промежуточные среды).

6. Структура департамента: кросс-функциональные команды или функциональные (фронт отдельно, бэк отдельно, QA отдельно).

7. Численность департамента: одно дело, если у нас всего 10 человек, и совсем другое — 200. Советую почитать об эффекте Рингельмана — социально-психологический феномен, при котором в больших группах падает индивидуальная вовлечённость и эффективность.

8. Зрелость продукта: стартап, MVP, стабильно работающий сервис с миллионной базой пользователей и т. д.

Не стоит ломать устои, которые, возможно, строились годами и связаны с реальными ограничениями бизнеса и культуры компании. Радикальные перемены — это большие когнитивные затраты для вас и стресс для команды. Люди по природе сопротивляются резким изменениям, так что внезапное введение большого количества новых правил встретит непонимание и отторжение.

Любые изменения — это выход из зоны комфорта, и они часто встречают сопротивление. Отчасти это связано с природой человека, отчасти — с искренней убеждённостью, что "мы и так делаем всё хорошо" или "этот процесс просто не может быть плохим". Иногда встречаются и более сложные мотивы, вроде боязни потерять контроль или скрытой выгоды в статус-кво.

Изменения должны быть осознанными, понятными и постепенными, чтобы не подорвать доверие ни со стороны руководства, ни со стороны команды.

Небольшое лирическое отступление:
Нужно понимать, что любое радикальное решение будет бить по вашему авторитету руководителя, а его запас ограничен и восполнение часто бывает сложным. Хочу поделиться с вами как минимизировать его потерю небольшой выжимкой из книги "The Dichotomy of Leadership" Джоко Виллинка:

1. Старайтесь избегать авторитарных решений.

2. Позволяйте команде совершать безопасные ошибки там, где это не критично для продукта.

3. Принимайте решения своевременно, но с учётом мнений команды.

4. Показывайте личный пример (не нарушайте сами те процессы, которые призываете соблюдать).

5. Не скрывайте информацию, когда это возможно — пусть команда видит полную картину.

6. Старайтесь решать ситуацию по сути, а не по форме (учитывайте контекст, а не формальные правила).

7. Каждое ваше действие должно быть обоснованным и понятным коллегам.

8. Делитесь обратной связью и запрашивайте её.

   Конец лирического отступления

Я бы разделил процессы на 2 группы: карго-культы и ненужные митинги. Их отличие заключается в том, что курго-культы могут быть куда более деструтивными для продукта и команды. На ненужных митингах единственное, что расходуется - время.

Карго-культы:

Карго-культ в ИТ встречается очень часто. Это ситуации, когда мы слепо следуем какой-то "правильной" практике, услышанной где-то, но не понимаем сути и не адаптируем к реальности.
Кто-то однажды сказал: "Нельзя скипать тесты в пайплайне - это плохо". Звучит разумно, тесты — важная часть обеспечения качества. Но в итоге разработчики тратят уйму ресурсов на прогон "мертвых" тестов, бизнес-ценность которых под вопросом, и, которые всё равно падают в 4 из 5 запусков.

Что происходит? Процесс становится самоцелью (не скипать тесты), а ценность (продукт не ломается, быстро выпускается фича) уходит на второй план.

Как понять, что мы не занимаемся карго-культом?

• Осознаём ли мы конкретную боль или задачу, которую решает практика?

• Есть ли метрика, которая улучшится при внедрении?

• Проверили ли мы, что эта практика подходит нашей культуре и масштабу?

Как бороться с карго-культами:

1. Описываем и согласовываем исключения. Сразу договориваемся, что есть ситуации, когда ценность выше процесса.

2. Заранее готовим аргументы: почему мы делаем именно так, чем это помогает бизнесу или пользователям?

3. Проводим встречи и фиксируем (в Confluence, почте), какие бывают отступления от "идеальных практик" и почему. Это важно, чтобы не тратить время на долгие обсуждения в критический момент.

Ненужные митинги:

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

Один из способов решения описан в agile — ретроспектива. Периодически команда смотрит, что пошло не так и что можно улучшить. Если люди обладают достаточными компетенциями и поддерживают культуру открытости, они сами поднимут вопрос: "А зачем у нас митинг X ? Может, отменим или заменим форматом короткого апдейта ?".

Но если встреча объединяет несколько команд или целые департаменты, найти и исправить подобные митинги сложнее: кто-то привык, кто-то боится пропустить что-то важное. Здесь поможет:

• Личная проверка: сходить на несколько таких встреч как наблюдатель, изучить повестку и результаты.

• Задать прямые вопросы: "Какой итог планируем получить?", "Какие решения примем по окончании?", "Есть ли экшен-пункты и ответственные?".

• Удалить ненужное: если встреча ничего не решает, но все привыкли, постарайтесь убрать её или предложить замену в удобном асинхронном формате (чат в Slack/Jira/Telegram).

Если есть сопротивление в удаление/изменении формата, можно попробовать сначала пилотное отключение — отмена его на 1–2 итерации, посмотрите на последствия. Если негативного влияния нет, зафиксируйте, что процесс официально снят. Таким образом вы избегаете ситуации, когда коллектив просто привык ходить на митинг без цели.

Следующей группировкой процессов может быть две большие категории:

1. Внутренние — то, что происходит внутри вашего департамента или даже внутри одной команды: планирование задач, ретроспективы, код-ревью, тестирование.

2. Внешние — процессы взаимодействия с другими департаментами (безопасностью, финансовым отделом, маркетингом), а также с внешними подрядчиками или сервисами.

Важно разделять внутренние и внешние процессы, так как:

• Цели департаментов могут конфликтовать

• Влияние на чужие процессы ограниченно: мы не можем диктовать другому департаменту, как ему работать.

• Появляется "чёрный ящик", пинг-понг тикетами: тикеты улетают в соседний департамент, там лежат неделями, сроки размазываются.

Предлагаю в начале рассмотреть и начать их рефакторинг в рамках вашего юнита. Важно понимать, что его структура очень часто диктует отсутствие или наличие некого количества процессов присущих к этой структуре.

В предыдущей статье я рассказывал, что у нас были кросс-функциональные команды (каждая отвечает за полный цикл фичи). При такой структуре возникла проблема - отсутствие горизонтальных связей. Чтобы её решить, мы создали гильдию, которая объединила специалистов по общей технологии.

Гильдия может иметь "оркестратора" (руководителя гильдии), который выступает модератором и представляет интересы бизнеса. В рамках гильдии желательно проводить:

1. Синк-встречи — короткий статус: что происходит в разных командах, какие общие задачи или проблемы есть.

2. Архитектурный комитет — обсуждения дельнейшего технического вектора развития продукта. Я бы советовал проводить встречи только при наличии темы. Материалы рассылаем заранее, чтобы участники могли ознакомиться и не вникать в проблематику на самой встречи (рекомендую такую практику распространять по возможности и на другие митинги).

Таким образом, гильдия закрывает потребность обмениваться экспертизой и решать проблемы, которые отдельная кросс-функциональная команда не может взять на себя полностью.

Если же у вас команды по функциональным областям (отдельно фронтенд, отдельно бэкенд, отдельно QA), то гильдии могут не потребоваться, зато появится другая проблема: рассинхрон реализации. Потому что каждая команда имеет свой спринт, свои приоритеты и иногда даже свой бэклог. В итоге фича может застрять, пока фронтенд не догонит бэкенд или тестирование.

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

Помимо Закона Конвея, есть интересна концепция Team Topologies, где описываются разные типы команд и формы взаимодействия (stream-aligned, platform, enabling, complicated subsystem). Эта модель помогает выбирать структуру команд так, чтобы максимально ускорить поток создания ценности и уменьшить количество затруднённых коммуникаций.

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

Вне зависимости от структуры, есть некоторое количество встреч, которые я считаю минимально необходимыми:

1. Планирование: какой бы у вас ни был подход (Scrum, Kanban, классический спринт на 2 недели), нужно собираться и синхронизировать, что мы делаем в ближайшее время, расставлять приоритеты.

2. 1:1 с руководителем: регулярные (раз в неделю) короткие встречи: обсудить личные цели, проблемы, карьерные желания сотрудника.

3. Ретро: периодически (обычно раз в спринт) обсуждать, что получилось хорошо, а что нет, какие эксперименты внедрим в следующий спринт.

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

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

Для решения этих проблем:

• Прописать договорённости (SLA, регламенты): например, Отдел безопасности даёт ответ по уязвимостям в течение 3 рабочих дней.

• Отслеживать и документировать неисполнения SLA: отправлять письма, где просите указать причины и сроки решения. Это создаёт прозрачность и побуждает департамент отвечать на проблемы.

• Последним, конфликтным способом решения является эскалирование проблемы: если договорённости систематически нарушаются, обращаемся к следующему уровню руководителей. Ставим конкретные дедлайны, фиксируем письменно.

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

Однако существуют и специфические процессы, напрямую влияющие на качество и скорость разработки. Сюда в первую очередь относится организация код-ревью и то, насколько эффективно настроен CI/CD-пайплайн. Даже при хороших командных процессах, без грамотного ревью и автоматизированной проверки сборок мы можем столкнуться с критическими ошибками и задержками релизов. Без ревью есть риск, что в продакшен попадёт код низкого качества. А если процесс ревью слишком забюрократизирован и строг, разработчики будут неделями ждать, пока их изменения одобрят. Советую почитать про TBD и gitflow. Выбор сильно зависит от специфики продукта.

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

Хотя можно посвятить найму отдельную статью, здесь я кратко поделюсь основными моментами, на которые я бы обратил первое внимание и которые мы внедряли в первую очередь.

1. Избавится от субъективности:

   1. Внедрить стандартные чек-листы вопросов и банк задач.

   2. Описать матрицу компетенций и четкие границы и образы грейдов.

2. Добавить этап фит-интервью: Крайне важно проверять, насколько человек впишется именно в эту команду. Одни команды работают на острие технологий, им нужны люди, которые любят новые стеки и не боятся экспериментов. Другие — более размеренные, стабильные, продуктовые. Важно найти своего человека, чтобы через полгода он не сбежал от скуки или, наоборот, от чрезмерного давления.

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

1. Начните с небольшой части. Выберите одну команду или один процесс (например, планирование команды).

2. Сформируйте ясную картину того, как всё работает сейчас и какие есть проблемы.

3. Исправьте критические проблемы в текущем процессе.

4. Соберите встречу и презентуйте свои изменения, внесите правки по её результатам.

5. Внедрите изменения.

6. Оцените эффект. По метрикам (если есть), по обратной связи от команды на ретро или встречах 1-1 .

7. Если результаты положительные, масштабируйте изменения на другие команды.

8. Если изменения не прижились, выясните почему: возможно, нужно учесть особенности команды или само решение было неверным.

Дополнительно предлагаю использовать элементы change management-подхода, например модель ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement). Важно, чтобы люди понимали, зачем вводятся новые процессы (Awareness), действительно хотели изменений (Desire), имели знания и навыки для работы по-новому (Knowledge, Ability), а затем видели постоянное подкрепление (Reinforcement).

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

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

Общий взгляд на рефакторинг процеcсов для меня выглядит вот так:

1. Процессы — это инструмент, а не самоцель. Если процесс не приносит измеримой пользы (ускоряет релиз, повышает качество, снижает рутину, повышает прозрачность) — стоит его адаптировать или убрать.

2. Баланс между отсутствием и перегрузом процессами — ключ к эффективной работе.

3. Контекст решает всё: смотрите, как устроена ваша компания, какие люди в командах, какие задачи они решают, насколько часто меняются приоритеты.

4. Сопротивление изменениям — естественно, поэтому лучше идти малыми шагами, вовлекать команду в принятие решений, объяснять выгоду.

5. Итеративные улучшения с регулярной оценкой метрик помогают корректировать курс и сохранять доверие сотрудников.

6. Учитывайте зрелость команды и распределённость сотрудников, подбирайте такие форматы коммуникаций, которые удобны всем участникам.

7. Фиксируйте измеримые результаты (KPI, SLA, время ревью, количество багов и т. п.), чтобы видеть реальную пользу или вовремя скорректировать курс.

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

Подписывайтесь на проект, в котором я участвую

Связаться со мной

Полезные ссылки и литература:

1. The Dichotomy of Leadership, Jocko Willink — книга о том, как найти баланс между жёстким и мягким стилями управления, не растеряв лидерские качества и доверие команды.

2. Статья о карго-культе: https://ru.wikipedia.org/wiki/Карго-культ — чтобы глубже понять, почему слепое копирование практик может навредить.

3. Закон Конвея: https://cleverics.ru/digital/2020/12/conways-law-importance-teams-design/ — об обратной связи между организационной структурой и архитектурой продукта.

4. Spotify-модель: https://www.atlassian.com/agile/agile-at-scale/spotify — пример организации кросс-функциональных скводов, трибов и гильдий.

5. Эффект Рингельмана — можно прочесть в работах по социальной психологии, кратко упоминается в материалах о командообразовании.

6. SSDLC продукта - https://habr.com/ru/companies/dcmiran/articles/521718/

7. Планирование - http://www.agile-process.org/iterative.html

8. О сопротивление изменениям - https://habr.com/ru/companies/oleg-bunin/articles/502852/

9. TBD и gitflow - https://habr.com/ru/companies/avito/articles/680522/

10. ADKAR - https://habr.com/ru/companies/otus/articles/828930/