Process design Многие знают про собеседования типа system design. Тебе на вход дают примерный масштаб системы, объемы данных, пики нагрузки, требования по хранению данных, времени отклика, отказоустойчивости и т. д. Ты еще всякие другие требования доуточняешь и конструируешь, как и из чего будет построена система, чтобы всё работало как надо. Вроде понятная инженерная задача. А что с процессами? Однако нередко бывает в айтишном руководстве, что если какие-то рабочие процессы надо построить, то не глядя лепят скрам. Сильно реже Леше Пименову респектуют, а может, хотят «не как у всех» и заводят канбан (ну как заводят канбан, на скрам-доску добавляют WIP-лимит для задач). А почему так? Мне кажется, это от непонимания, что вообще еще бывает и какую конкретно пользу приносят любые внедряемые процессы. Просто где-то написано (или деды так делали), что нужно ретроспективу проводить каждый спринт, а в спринт класть задачи и их гвоздями прибивать, мол, если хотите другие, то подождите, пока спринт до конца закончится. Или 1-1 проводить ну прям с каждым человеком обязательно раз в неделю без каких-либо исключений, и тогда почему-то пипл-менеджмент будет у вас в порядке, а люди все будут счастливые и довольные. Это типа как человек что-то где-то услышал, что Кафка — это круто и топ, поэтому в любую архитектуру он вставит Кафку не глядя. Что делать? Для понимания систем дизайна есть книга с кабанчиком или, мильен индусов на ютубе, которые довольно подробно рассказывают, что там как работает. Я еще даже пост делал о том, как к таким собесам готовиться https://t.center/general_it_talks/505. Прикол про процессы в том, что если брать тимлидские курсы, то там обычно выдают как раз шаблоны про 1-1 раз в неделю или ретроспективу с айсбрейкером какая ты феечка из Винкс. Мне кажется, что в курсах по проектному менеджменту дают побольше разной теории. Взять какой-нибудь Кеневин фреймворк, который показывает, что системы/команды/компании могут заниматься совершенно разным по сложности, запутанности, неопределенности, и из этого складывается ваш процесс работы. Не видел, чтобы на тимлидских курсах про это что-то рассказывали. ⁃ У Фила Дельгядо есть доклад на тему рефлексии о рабочих процессах ⁃ Про проекты и процессы неплохая книга ⁃ Иван Селиховкин много всякого пишет @selihovkin и снимает ⁃ У Леши Пименова книга вышла про канбан ⁃ Про топологию команд книга недавно пошумела https://teamtopologies.com/book ⁃ Виталий Шароватов делал мудрый доклад про пересмотр своих рабочих процессов https://t.center/vsharovatov/333 ⁃ Или что-то более абстрактное и заковыристое типа Дёминга, Щедровицкого, Акоффа Это примеры контента, который может расширить ваш управленческий кругозор, дать разную теорию и мысли о том, где что применимо. А дальше уже ваша ответственность хорошенько порефлексировать и понять, какое состояние у вас, что вообще бывает, что может подойти, попробовать, понять, что из попробованного подходит, а что нет, и заточить всё именно под свою ситуацию. Вот это будет дизайн процессов в команде, а не просто «Серега сказал, у него спринт три недели идет и ему норм, значит, и мне надо трехнедельные спринты в команде сделать». Итог Теоретическая подкованность может привести вас через осознанную практику к весьма хорошим результатам. И потом вы для любой команды на любом рабочем месте сможете получать эти хорошие результаты. Это как с тренажерным залом. Одно дело ты просто делаешь из года в год одни и те же подходы и повторения из журнала «Сила и красота», а другое – понимаешь, как работает тело, как распределяется нагрузка, какие особенности у каждого упражнения, что можешь и любую кастомную программу тренировок себе составить, и даже упражнение какое-то изобрести, если у тебя есть для этого повод (травма или иное ограничение). Учитесь, думайте, делайте хорошо, а плохо, конечно же, не делайте.