Дерзкая птица структур: development flow

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

Эффективность и прозрачность это никогда не одно и то же. Можно прозрачно делать неэффективные вещи, а эффективно делать вещи непрозрачные.

Построение структуры работы это сложный, индивидуальный процесс, с налётом дерзости. Потому что нужна не только смелость и рефлексия («мы работаем неэффективно, почему?»), но и умение делать изящные нагромождения.



Изящные нагромождения — залог создания структур. Кажется «нам не надо, работаем и ладно, зачем нам лишние слои», но на деле — один продуманный слой поднимет вашу работу на новый уровень. Это нагромождение, но оно изящно. Что-то вроде dependency injection или использование фотошопа вместо рисования красками.

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

Короче, наше детище изящных нагромождений мы называем «дерзкой птицей структур» или «development flow». Сейчас мы его опишем, и еще съедим пару ваших собак в спорах.

Зачем он нужен

Development Flow призван для исполнения 4 обязательств:

• Структурирование процесса
• Решения возникающих проблем
• Даёт Обратную связь
• Обеспечивает универсальный язык взаимодействия

Development Flow это инструмент, создающий Систему.

Система

Система состоит из элементов, элементы разные, и по ним идёт «ток» — рабочий процесс. В ИТ «ток» это код, дизайн, документы и прочие штуки, с которыми и над которыми мы работаем.

Системы бывают отсутствующими

Если вы не знаете, на каком этапе вашего Частного флоу сейчас находитесь (например, «разработка фичи»), и не знаете, каким этапом вы являетесь в Общем флоу (например, четвёртым, после Владельца продукта, Скрам мастера и Дизайнера), и какой этап должен пойти за вами, какие у него критерии возврата, и много всяких мелочей еще…

Или если вы знаете, но для вашей работы с вами рядом должен сидеть Проектный менеджер, и напоминать, чем именно в эту самую секунду вам следует заниматься (не отрывайся от монитора, тут же следящие программы)…

Или если вы просто чувствуете, что вы неэффективны…

… то скорее всего, у вас нет Системы.

Система бывают неработающими правильно

Не всё золото, что блестит. Не всё V12, что под капотом. И главное — не каждый двигатель работает правильно, даже если едет (привет, любимый автопром).

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

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

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

Development flow: система

Система DF подразумевает два раздела — Общий флоу (функционирование системы в целом), и Частный флоу (функционирование отдельных её частей).

Общий флоу

Система состоит из элементов, объединенных в структуру для достижения намеченной цели.
Цель в ИТ — выпуск продукта в нужное время, нужного качества. Элементы системы — участники процесса: Владелец продукта, Проектный менеджер, Скрам мастер, Разработчик, Дизайнер, Тестировщик, Техписатель… Всё это элементы, и не все они присутствуют постоянно. Иногда роли объединяются. Нужно выделить свои элементы.

Нужно выделить свои элементы. Записать их, и стрелочкой нарисовать свой первый флоу. Это называется Общий флоу.

Владелец → СМ → Дизайнер, Разработчик → Тестировщик → Техписатель

Задача — объединить элементы в структуру и показать, какие профессиональные взаимодействия возможны. Непрофессиональные — о том, что дизайнер и владелец продукта живут вместе, не надо. Надо только роли. Владелец не должен взаимодействовать с Дизайнером или Разработчиком. Только Скрам мастер. Только. Скрам мастер.

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

Владелец → даёт описание задачи → СМ

СМ её переформулирует и для Владельца, и для остальных. Оценка задачи — приблизительная — выстроится сама собой. Но задача СМ — из простого описания, применив изящное нагромождение, сделать ДОСТАТОЧНОЕ_ОПИСАНИЕ. Части этого ДО он и будет обсуждать и распределять с командой.

СМ → даёт части ДО → Дизайнеру и Разработчику

ДО включает в себя схему, все возможные её состояния, и много другого (не хочу пока нагромождать). Каждый получает свою часть. Не всегда одновременно. Обычно Дизайнер опережает Разработчика на один спринт.

Дизайнер и Разработчик на ежедневном митинге в качестве обратной связи с СМ возвращает ему своё видение задачи. Убеждаемся, что всё понимаем одинаково. Это занимает 25-28 секунд. А спасает часы и недели.

Разработчик → после своего частного флоу (об этом позже), передаёт код → Тестировщику

Разработчик отдаёт код, Тестировщик смотрит в свою часть ДО, и отрабатывает своё флоу. Обратная связь Тестировщика — для СМ → «позитивная», то есть то, как он понимает задачу, а для Разработчика → «негативная» — только в том случае, если сломано.

Разработчик не имеет представления, что его код тестируют, до тех пор, пока не появляется проблем.

Думаю, что Общий флоу правильно формулировать так. Первый отдаёт Второму, Второй обрабатывает, возвращает «позитивную» или «негативную» Обратную связь, двигает дальше в Общем флоу. Позитивная обратная связь — убеждённость, что всё работает как задумано; негативная обратная связь — показывает, где и что пошло не так.

Частный флоу

В этой статье я в общих чертах разберу частные флоу Владельца, СМ и Разработчика, в качестве примера. Если вам будет интересно, потом выложу остальные наработки.

Владелец

Главная цель
Формулировка задачи (backlog ← описание), читать обратную связь

Что дальше
Когда задачи сформулированы Владельцем, СМ их описывает → приводит к Достаточному_Описанию.

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

Взаимодействует с
СМ

СМ

Главная цель
Принять задачу, привести её в вид Достаточного_Описания, оценить задачи, распределить, читать обратную связь

Что дальше
Распределяет задачи сотрудникам

Обратная связь от
Дизайнер, Разработчик, Тестировщик, Техписатель

Взаимодействует с
Владелец, Дизайнер, Разработчик, Тестировщик, Техписатель

Разработчик

Главная цель
Разработка фичей и исправление багов. В Общем флоу ему приходят задачи от СМ, и при помощи своей профессиональной деятельности, он их реализует (git flow, rebase flow, feature flow и др).

Что дальше
Он может вносить предложения по модификации, обсуждая их с СМ и Дизайнером.

Обратная связь от
СМ, Дизайнера, Тестировщика

Взаимодействует с
СМ, Дизайнером, (важно — он не может порождать взаимодействие с Тестировщиком)

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

В сухом остатке

Development Flow решает такие задачи:

• Структурирование процесса
• Решение возникающих проблем
• Даёт обратную связь
• Обеспечивает универсальный язык, о котором мы пока ни слова не сказали

Главные достоинства — все знают, что происходит, что им делать, и не загружены лишней работой.

Очень много работы у Скрам Мастера (Тимлид, CTO). Но так и должно быть, он — главный тягач в этом подходе.

очень краткая и сухая презентация

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

(Многое пришлось вырезать, чтобы хоть немного ужать размер статьи. Из-за этого что-то мог упустить, но буду оперативно исправляться, пишите.)