Ранее я описал команду, как набор следующих крупных элементов:
- структура - люди и правила
- цели и задачи - бэклог команды и дорожные карты
- процессы - например, разработка новой фичи
Цели и Задачи придают смысл структуре. Цели и Задачи отвечают на вопрос «зачем?»: Зачем нужно было собрать аналитиков, разработчиков, тестировщиков? Зачем нужен Тимлид? Зачем нужно именно такое количество участников команды ? На все эти вопросы отвечают Цели и Задачи. Сама же структура , как элемент команды , отвечает на вопрос «кто ?».
Процессы - это комбинация элементов входящих в команду , которая создает фактическую ценность. Процесс - это поезд , который везет «структуру» к «целям». Процесс - это артефакт и его состояния. Процесс - это последовательность связанных друг с другом действий. Процесс - это «как?» и «что ?»
Процесс - это алгоритм
Ближе всего к процессы относятся алгоритмы . Один из самых популярных способов описания процессов - нотация BPMN - очень похожа на описание алгоритма в виде блок- схемы. И так и есть, процесс - это алгоритм на высоком уровне, в который вовлечены и люди и программные продукты. Процесс - это программа следую которой команда производит «что-то» нужное - ценность .
Если провести аналогию с компьютером, то процесс - это программа на языке программирования (java, c#, go и т. д.). Что бы программа заработало, её необходимо выполнить, запустить. При запуске компьютер, через прослойки ввиде фреймворков (jdk, .net, и т.д.), операционной системы (windows, linux, android и т.д.), выступает в роли исполнителя программы. API фреймворков и операционной системы образуют набор доступных функций/методов для использования программой. В случае с командой такой набор доступных метод/функций предоставляет структура команды и цели и задачи.
Тимлид, ты управляешь процессами. Прояви процессы в команде. Управляй людьми, что бы реализовать выполнение процессов.
Процесс всегда имеет начало и конец. Связанность предыдущих действий, использование предыдущего результата обеспечивает непрерывность процесса и доведение его до завершения.
Разорванный процесс порождает не управляемый результат.
Составные части процесса
Процесс можно представить через разные элементы. Например:
- Действия/функции/методы
- Данные/Артефекты
- Роли
Действия/функции/методы получают и создают данные/артефакты, а роли - это те кто выполняют действия/функции/методы.
Другой способ описания процесса - это статусная модель центральной сущности процесса (граф состояний). Например, для процесса по исправлению дефекта, дефект - это центральная сущность. Дефект может иметь разные статусы: новый, в работе, исправлен, протестирован, развёрнут и закрыт. Переходы между статусами - это функции или события. Роли связаны с функцией или событием.
Выбор способа описания процесса зависит от уровня абстракции, какой способ удобнее выбирать вам.
Я часто использую описание процесса, где проявлена центральная сущность, артефакты, инструменты и роли. В упрощённом виде покажу на примере процесса разработки новой фичи.
Виды процессов
Процессы команды можно условно разделить на две группы: основные и вспомогательные. Основные процесс - это то «что» производит ценность ради которой команду создали. Вспомогательные процессы - обеспечивают поддержку работоспособности структуру команд и цели и задачи. Рассмотрим примеры:
Основные процессы:
- Процесс разработки функциональности - разработка новых фич
- Процесс релиза
- Процесс работы с инцидентами с ПРОДа
Вспомогательные процессы:
- Процесс онбординга
- Процесс работы с тех долгом
- Процесс разработки ADR
Тимлид, выясни свои основные процессы и зафиксируй их. По мере работы, выясни какие вспомогательные процессы нужны и также зафиксируй их.
Планируй, делегируй, контролируй и измеряй
Планируй внедрение процесса. Расскажи всем в команде про процесс. Запланируй регулярный контроль по выполнению процесса командой. В качестве основного способа контроля за процессом - это его измерение. Для каждого процесса стоит подумать как численного его измерять: часы, штуки, скорость, и т.д.
А что если нет процесса ?
Если процесс не описан, то он всё равно присутствует. Отсутствие минимально необходимой формализации не позволяет системно управлять, так как процесс находится в головах участников команды. Тимлиду приходится в ручном режиме заниматься постоянным «тюнингом». Если команда небольшая, то ручное управление ещё терпимо, но с ростом участником и усложнения продукта это приводит к перегрузке тимлида, конфликтам внутри команды и недовольству заказчика результатом.
Синдром самозванца часто возникает, как раз из-за отсутствия формализации процессов. Тимлид, что-то делает, но не понятно "как" и на "что" он влияет.