Process design

Многие знают про собеседования типа system design. Тебе на вход дают примерный масштаб системы, объемы данных, пики нагрузки, требования по хранению данных, времени отклика, отказоустойчивости и т. д. Ты еще всякие другие требования доуточняешь и конструируешь, как и из чего будет построена система, чтобы всё работало как надо. Вроде понятная инженерная задача.

А что с процессами?
Однако нередко бывает в айтишном руководстве, что если какие-то рабочие процессы надо построить, то не глядя лепят скрам. Сильно реже Леше Пименову респектуют, а может, хотят «не как у всех» и заводят канбан (ну как заводят канбан, на скрам-доску добавляют WIP-лимит для задач).

А почему так?
Мне кажется, это от непонимания, что вообще еще бывает и какую конкретно пользу приносят любые внедряемые процессы. Просто где-то написано (или деды так делали), что нужно ретроспективу проводить каждый спринт, а в спринт класть задачи и их гвоздями прибивать, мол, если хотите другие, то подождите, пока спринт до конца закончится. Или 1-1 проводить ну прям с каждым человеком обязательно раз в неделю без каких-либо исключений, и тогда почему-то пипл-менеджмент будет у вас в порядке, а люди все будут счастливые и довольные.

Это типа как человек что-то где-то услышал, что Кафка — это круто и топ, поэтому в любую архитектуру он вставит Кафку не глядя.

Что делать?
Для понимания систем дизайна есть книга с кабанчиком или, мильен индусов на ютубе, которые довольно подробно рассказывают, что там как работает. Я еще даже пост делал о том, как к таким собесам готовиться https://t.me/general_it_talks/505.

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

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

⁃ У Фила Дельгядо есть доклад на тему рефлексии о рабочих процессах
⁃ Про проекты и процессы неплохая книга
⁃ Иван Селиховкин много всякого пишет @selihovkin и снимает
⁃ У Леши Пименова книга вышла про канбан
⁃ Про топологию команд книга недавно пошумела https://teamtopologies.com/book
⁃ Виталий Шароватов делал мудрый доклад про пересмотр своих рабочих процессов https://t.me/vsharovatov/333
⁃ Или что-то более абстрактное и заковыристое типа Дёминга, Щедровицкого, Акоффа

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

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

Это как с тренажерным залом. Одно дело ты просто делаешь из года в год одни и те же подходы и повторения из журнала «Сила и красота», а другое – понимаешь, как работает тело, как распределяется нагрузка, какие особенности у каждого упражнения, что можешь и любую кастомную программу тренировок себе составить, и даже упражнение какое-то изобрести, если у тебя есть для этого повод (травма или иное ограничение).

Учитесь, думайте, делайте хорошо, а плохо, конечно же, не делайте.