Если спросить тимлида, что он знает о процессах в своей компании, вероятно, вы услышите, что:
Процессы чаще всего наследуются. Тимлида наняли и сказали: «Вот тебе канбан».
Процессы редко меняются, либо меняются революционно. Например, когда скрам в командах внедрили с консультантами.
Процессы не рационализируются. Например, если ни у кого нет точного представления, какую проблему решает «Оценка 360», и насколько это решение оптимально.
Изначально цель любых процессных активностей — обеспечить работу и улучшить ее качество. Бездумно скопированные, исторически обусловленные и непонятно ради чего запущенные процессы — это проблема, потому что эффективность их работы неизвестна.
Например, если команда исторически использует code review для поиска дефектов, то как она понимает, что эта практика выполняет поставленную цель? И существует ли аналитика по количеству найденных ошибок?
Меня зовут Виталий Шароватов, я работаю в IT 22 года и семь лет из них обучаю руководителей и консультирую компании. В этой статье предлагаю способ как критически посмотреть на процессы разного уровня и лучше их осмыслить.
Подходы к решению процессных проблем
Чтобы убедиться в оптимальности процессов, нужно понять, подходят ли они к реальности, и если не подходят, то как их изменить. Это можно сделать несколькими способами:
Рационализация.
Понять и прописать для чего нужна и какую проблему решает каждая процессная активность.
Адаптация реактивная.
Контекст меняется постоянно: компания, мир, рынок. Вслед за изменениями контекста чаще всего необходимо менять и процессы. Когда случился ковид и команды ушли на удаленку, стало очевидно: многие процессы не работают как нужно — от проведения калибрации по перфоманс-ревью до командных обедов.
Адаптация проактивная.
Если кажется, что поставленную проблему оптимальнее решит иная процессная активность, можно провести эксперимент и попробовать. компании принято проводить адаптацию с помощью видеоматериалов по продукту, архитектуре и принятым соглашениям по работе. Кажется, практика всем хороша, и за 3-4 недели вводит новичков в курс дела. Но мы хотим попробовать вместо неё что-то новое - парное программирование новичка и опытного сотрудника. Для того чтобы сравнить старую и новую практики, нужен процесс: пробуем новую практику и смотрим, насколько она лучше или хуже.
Все три активности — рационализация, адаптация реактивная и адаптация проактивная — помогают произвести мой подход: Process Decision Record, сокращённо «PDR».
Подход называется PDR по аналогии с ADR — Architecture Decision Record. Это очень простая концепция в архитектуре: в ней описывается, для чего мы используем конкретный архитектурный подход, и при любых изменениях описываем причину изменения. Предлагаю распространить этот подход и на процессы.
Основы подхода «Process Decision Record»
Начать использовать PDR можно с самого простого — рационализации. Для этого нужно завести «карточку» каждого процесса.
Работа с карточкой процесса
Внутри карточки описываем дату появления процессной активности, её «цену», решаемую проблему. По сути, побуждаем себя прояснить, в чём «плюсы» процессной активности, какова её цель, риски и негативные факторы решения, а также подумать, когда стоит пересмотреть процесс и заодно подумать о критериях пересмотра.
Например, команда внедрила какой-то процесс 1 февраля. Напишем в карточке:
Дата старта: 01.02.
Сколько стоит процесс: в часах, в задержке, в Time to Market и т.д.
Решаемая проблема: для чего нужен процесс.
Риски и негативные факторы.
Дата пересмотра: когда, по нашему мнению, стоит вернуться к процессу и пересмотреть его.
Критерии: на что ориентироваться при пересмотре.
Однако, многие процессы взаимосвязаны, и каждый состоит из подпроцессов. Нужно описать все процессы и их flow, и для всех подпроцессов завести отдельные карточки.
Работа компании — огромный процесс. Насколько глубоко мы погружаемся в его исследования: дойдём ли до кадрового делопроизводства, увольнений, обеспечения качества и автоматизации тестирования — зависит от нашего времени. Чтобы рационализировать процесс и произвести полный аудит системы, нужно несколько месяцев. Можем ли мы позволить себе выключиться из текущей работы на эти месяцы? Кажется, что оптимальнее съесть слона по частям: сначала составить flow «крупными мазками».Потом выделить категории процессов, с которых удобно начинать анализ. Это могут быть крупные вехи, в которых задействовано много людей и подразделений. Например:
Обеспечение условий производства: когда у всех есть компьютеры, электричество, чтобы люди могли работать.
Обеспечение производственных сил, когда в компании появляются люди.
Производство продукта.
Маркетинг, где мы познаем рынок, чтобы принести хорошие идеи в процесс производства.
Сначала мы описываем процесс в общем смысле, а затем идём вглубь, чтобы его исследовать.
Далее рассмотрим некоторые примеры категорий процессов более конкретно.
Пример процесса: обеспечение производственных сил
Обеспечить компанию сотрудниками можно двумя способами:
Наём людей с рынка: Подбор → Отбор → Трудоустройство → Адаптация → Работа.
Школа или внутреннее обучение: Подбор группы → Обучение → Отбор → Трудоустройство → Менторство → Работа.
Рассмотрим первый способ: наём с рынка и составим его карточку:
Дата старта. Предположим, компания запустилась 1 января 2022 года и решила с 1 февраля начать наём.
Цена. Мы посчитали, что цена найма одного человека — примерно 500 000 рублей. Это приблизительно полтора или два оклада. Дополнительно к этой цене увеличивается фонд оплаты труда — это 300 000 рублей в месяц на человека.
Решаемая проблема. В этом пункте постулируем проблему. Например, мы думаем, что у нас не хватает «мощности» команды.
Риски и негативные факторы решения. Важно проанализировать все риски, которые мы выявим для найма новых людей:
Превышение нормы управляемости.
Менеджер ограничен в возможности управлять. У каждого руководителя есть определённое количество человек, которое он может «сдюжить». Если у вас в команде 300 человек, вы точно не сможете нормально с ними коммуницировать и, скорее всего, даже не будете всех знать.
Рост ФОТ.
Если мы добавляем нового человека, фонд оплаты труда растет.
Усложнение коммуникаций.
Хорошей иллюстрацией здесь будет закон Амдаля про предел увеличения эффективности информационной системы при параллелизации. Условно, в обычный компьютер нет смысла совать 300 ядер, потому что в этом случае ПО не сможет эффективно распараллелить вычисления, а синхронизационные косты будут огромные. У каждой системы, которая параллелизуется, есть синхронизационные косты. Сложность коммуникации можно описать по этой аналогии. Ведь каждый член команды общается с несколькими коллегами. Если у вас, предположим, 7 фронтендеров в одной команде, то, наверное, это плохие новости.
Замедление производства.
Брукс описал закон: если вы добавляете человека в проект, который задерживается, то проект задерживается ещё сильней. Это частный случай закона Амдаля.
Дата пересмотра. В примере — это первое число каждого месяца. Почему выбрали такую дату пересмотра? Я решил, что если в месяц мы нанимаем пару человек, то, наверное, в следующий месяц надо оценить, нужен ли нам еще кто-то? Может быть, проблема нехватки мощности уже решена, и во время пересмотра мы просто отменим дополнительный наем.
Критерии пересмотра. Здесь сразу задаем условия, при которых стоит пересмотреть, нужно ли продолжать наем, актуальна ли наша процессная активность:
Хватает ли мощности команды.
Попадаем ли в бюджет по деньгам. Может быть, рынок так вырос в зарплатах, что нового сотрудника мы уже не можем себе позволить.
Что с коммуникациями? Может быть, мы набрали столько людей, что время дробить команды, а не нанимать новых.
Вроде бы очевидно: мы останавливаем наем, когда больше не надо. Но круто, когда это описано, потому что так мы добавляем осмысленности в способ мышления, который используем для рационализации. Критерии при этом могут отличаться. Если в какой-то компании жестко ограничен фонд оплаты труда, то он станет самым первым критерием, потому что здесь цена важнее, чем мощность команды.
Теперь, когда у нас есть общее описание карточки процесса, можно идти вглубь. Если есть время. Например, мы решили рассмотреть подпроцессы найма. Предположим, наш найм разбивается на подпроцессы так:
Подбор → Отбор → Трудоустройство → Адаптация → Работа
Разбираем подбор и смотрим, откуда мы подбираем людей. Например, с HeadHunter и из нетворка.
Карточка PDR для процесса «Подбор с HeadHunter»
Дата старта. Итак, компания начала поиск сотрудников 1 февраля 2022 года.
Цена. Мы посчитали, сколько времени, выраженного в деньгах, тратим на наём одного человека: 10 000 рублей. И 1.3 миллиона рублей в год за доступ к базе HeadHunter, чтобы из 100 рассмотренных резюме выбрать одного.
Решаемая проблема. Нехватка людей для следующей стадии — отбора. Не подобрали людей — некого собеседовать.
Риски и негативные факторы решения. Низкая конверсия в отборе,6% — нанимающие менеджеры «устают».
В одной из компаний, с которой я общался, негативным фактором была конверсия всего 6%. Менеджеры устают от вечных собеседований: чтобы нанять одного человека, нужно было прособеседовать 16. Мы посчитали, что эту конверсию нужно прописать сюда, чтобы оценить эффективность процесса.
Дата пересмотра — каждый понедельник.
Почему каждый понедельник? Если у менеджеров и так по 16 собеседований, и в негативных факторах написано, что они устали, то, наверное, хорошо раз в неделю мониторить ситуацию.
Критерии пересмотра:
Конверсия — увеличивается / уменьшается.
Состояние нанимающих менеджеров улучшается / ухудшается.
Например, если рекрутеры приводят с HeadHunter таких людей, что менеджеры говорят: «Вообще не алё» и конверсия ещё сильнее падает, то наверное, нужно пересмотреть процесс подбора с HeadHunter. Может быть, доучить рекрутеров, или перестать работать с площадкой подбора, или ещё что-то.
Таким образом, мы каждый понедельник сверяемся с результатами и решаем, как работать с наймом дальше.
Или, может быть, те 1.3 миллиона рублей, что мы платим в год за доступ к базе резюме, можно раздать ребятам в виде реферальных бонусов за приведённых хороших спецов или потратить на свою школу, и процессная активность «подбор с HeadHunter» вовсе окажется не нужна?
Пример процесса: производство продукта
Самый частый flow продуктовой работы, который я наблюдаю:
Анализ ТЗ → Проектирование → Программирование → Ревью → Тестирование → Деплой
Посмотрим, как может выглядеть PDR для анализа ТЗ.
Карточка PDR для процесса «Анализ ТЗ»
Дата старта. Допустим, 1 января 2022 года мы начали анализировать первое ТЗ.
Цена. Чтобы убедиться, что можно приступать к проектированию, тратим на анализ два рабочих дня.
Решаемая проблема. Каждое третье ТЗ, которые получаем — неполное.
Например, в ТЗ включена кнопка «Сделать хорошо», а нам непонятно, что это значит. Нужно разобраться, что наш продакт-менеджер под этим подразумевает.
Риски и негативные факторы решения:
Задержка на возвраты/доработку до 12 дней.
Это первый и самый основной риск, который я прописал в этом случае. Когда мы проанализировали ТЗ, и нашли, что доработать, то возвращаем его продакту. Но у продакта есть своя нагрузка и задачи, поэтому к переделке ТЗ он приступит примерно через пять дней. Сколько-то дней ему понадобится на доработку, потом мы получим ТЗ обратно, но снова придется подождать, потому что у нас есть свои задачи. Итого, получается около 12 дней.
Если мы посмотрим на любую метрику, которая описывает время от идеи до продакшена — Time to Market или Cycletime, то окажется, здесь довольно серьезный негативный фактор.
Не будет позитивной динамики.
Продакты некоторых команд не стремятся улучшать способ постановки задач, им это не нужно. В этом случае процесс «Анализ ТЗ» может повлечь за собой негативную динамику.
Если бы мы решили пересмотреть эту карточку, нам следовало бы переименовать «Анализ ТЗ» в «Обучение продакта». Потому что, когда каждое третье ТЗ — неполно, то стоит позвать ментора, который научит составлять его корректно.
Уильям Эдвардс Деминг сказал: «You can not inspect quality into a product» — тестированием невозможно улучшить качество. Это значит, тестирование может только верифицировать, что получилось на выходе. Если у вас станок всё время делает детали с разными допусками, то отсевом этих деталей, в нашем случае — ТЗ, вы можете лишь показать количество брака, но качество станка не улучшите.
Возможно, нам надо доучить наш «станок» — продакта — сделать так, чтобы он поставлял нам детали, то есть ТЗ, с хорошими «допусками».
Дата пересмотра — каждые полгода.
Почему полгода? В моём случае продакт сказал: «Я научусь». Но любое обучение стоит времени и денег. Мы должны подождать, пока продакт попробует научиться и тогда посмотрим, что дальше. Через полгода мы снова обсудим качество ТЗ. Это и будет критерием пересмотра.
Критерии пересмотра: качество ТЗ.
Карточка PDR для процесса «Code review»
Ревью кода, как и в предыдущем случае — это попытка улучшить качество слишком поздно. Но это общие слова. У каждого человека есть возможность верифицировать, насколько код-ревью эффективен в его команде.
Перейдем к карточке и что у неё внутри.
Дата старта. Всё также начинаем 1 февраля 2022.
Цена. Эту задачу дали уверенному сеньору. Ему потребовалось в среднем три часа, чтобы влезть в код и в ТЗ, посмотреть, решает ли код поставленную проблему, и дать вердикт — идем дальше или переписываем код.
Решаемая проблема. В 6% задач Quality Control находит баги, которые нельзя допускать на продакшене. Поэтому запускаем код-ревью не просто так, а чтобы верифицировать отсутствие багов.
Риски и негативные факторы решения:
Плохие социальные динамики.
У этого явления много примеров. Во-первых, когда человек что-то сделал, он ассоциирует результат с собой. Сделал я из кожи картхолдер, но мне кто-то сказал, что это плохой картхолдер — я обижусь, в любом случае внутри будет неприятно.
Вторая плохая социальная динамика в том, что программисты приучаются делать тяп-ляп, потому что на код-ревью ревьювер все равно обнаружит ошибки и проблемы.
Падение качества review.
Если люди в вашей команде торопятся положить задачи на продакшен, они будут стараться уделять все меньше времени код-ревью. Вместо 3 часов станет 30 минут, особенно если код-ревью вечером. Человек устал, быстренько пробежался глазами и всё. Как результат — падает цена код-ревью, но и качество тоже падает. И наша проблема про 6% багов, возможно, уже не так хорошо решается.
Задержка на возвраты/доработку примерно два дня.
В любой системе есть нагрузка. Например, у программиста есть задачи. Если вы возвращаете ему задачу после код-ревью, то чтобы он приступил, потребуется время. Как минимум, на переключение контекста, если программист свободен. Если он занят, ему придётся остановить свою задачу и переключиться на вашу, либо закончить задачу, и чинить баги уже после код-ревью.
Дата пересмотра — каждые полгода.
За это время хочется собрать статистику, посмотреть, что тестировщики говорят о качестве задач, которые к ним поступают, и пересмотреть их.
Критерий пересмотра — частота возвратов от Quality Control.
В итоге, с помощью такой примитивной карточки мы вполне можем побудить себя целостно и системно посмотреть на маленький подпроцесс «Code Review».
Пересмотр процесса
В пересмотре круто уже то, что мы побуждаем себя менять и когда нужно, и заранее. В случае с «Code Review» можно попробовать эксперимент в рамках даты пересмотра и пойти по алгоритму:
Когда наступила дата пересмотра, проверяем критерии. Допустим, Quality Control уже не находит багов. Значит, всё нашли на код-ревью.
Задаём себе вопрос: «Может, процесс убрать? Или заменить более дешевой альтернативой?».
Принимаем решение: попробуем без код-ревью, вдруг люди научились писать код нормально. Или если в ревью много стилистических ошибок, используем Linter.
Нет серебряной пули, каждый процесс и его оптимальность определяются контекстом.
Итоги
Побуждайте себя на хорошие действия.
В США есть институт Crime prevention through environmental design (CPTED), который изучает, как окружение человека влияет на количество совершаемых преступлений. Они выяснили, что в домах с глухими заборами краж больше. Если заборы прозрачные или отсутствуют, краж меньше потому, что воришки стесняются красть, когда на них смотрят. Или когда думают, что смотрят.
Круто выстраивать систему таким образом, чтобы побуждать людей к хорошим действиям.
Делайте постепенно.
С помощью PDR мы побуждаем себя постепенно пересматривать процессы. Появилось полтора часа — заполнили карточку. Пришло время пересмотра — выделили полдня, рассудили, оптимальна ли ещё рассматриваемая активность для решения заданной проблемы.
Смотрите на всё.
Обычный тимлид не всегда отвечает за наём, скорее, этим занимаются рекрутеры. Но при этом тимлид участвует и влияет на процесс. Например, может потратить время на выступление, чтобы улучшить свой нетворк и нанимать прямо из него. Мы видим, что команда тратит 16 собеседований на наём одного человека, по два часа на каждое интервью. Может, лучше попробовать потратить эти 32 часа на то, чтобы подготовить доклад, а потом в кулуарах поговорить с людьми и нанять одного-двух человек за пять собеседований?
Получается, что когда мы описываем процессы, то гораздо лучше понимаем всю систему и как она работает.
Объясняйте команде.
Круто, когда тимлид заинтересовывает ребят в команде тем, как работают процессы. Чем больше у человека понимания, для чего на самом деле код-ревью или автоматическое тестирование, тем лучше он будет выполнять свою работу. Если кто-то пытался «силой» внедрить автотестирование в команду, наверняка помнит, как это тяжело. А уж тем более может быть сложно внедрить TDD или парное программирование.
Показывайте всем снаружи.
Кажется, что прозрачность может быть отличным конкурентным преимуществом. У Авито и других компаний есть открытые плейбуки, где описано, как они работают. Лучше всех это сделано, на мой взгляд, у GitLab — кроме процессов, у них описана культура, и есть программа Shadow CEO, когда человек изнутри может посидеть тенью с CEO некоторое время. CEO рассказывает (естественно, после подписания NDA) и показывает, что он делает и почему. Это повышает вовлеченность людей в работу компании, так как они понимают, что происходит.
Заодно, если вы показываете не только сообществу вовне, но и руководству, что вы что делаете, то гораздо проще обосновать, почему вам нужно поехать выступать или попробовать referral-бонусы сделать в дополнение или вместо найма из HeadHunter. Я видел кейсы, когда команду полностью собирали с помощью найма из нетворка. В одну компанию я так набрал четверых человек за шесть дней. Это работает, но инвестиции времени и денег чаще всего требуют обоснования и авторитета тимлида в глазах руководства.
Учитесь и узнавайте новое.
Мы всегда учимся. Ходим в университет, читаем учебники и статьи, участвуем в конференциях. И когда подходит дата пересмотра процесса, у нас уже другой багаж знаний. Внезапно мы можем понять, что делали ерунду или упустили серьезный риск. Может появиться множество разных «Ага!» и «Вау». К каждой дате пересмотра процессной активности меняется мир и мы сами, а значит процессы тоже требуют изменений. Этим простым инструментом, мне кажется, можно побудить себя регулярно пересматривать насколько ваши процессы рациональны и оптимальны к контексту и миру.
Мои контакты:
Github: git.io/teamlead
Youtube: vitalysharovatov
Telegram: @vitaly19842
Email: vitaly.sharovatov@gmail.com
Серебряную пулю пока действительно не изобрели, но профессионалы своего дела готовы делиться знаниями и опытом. Уже 27 и 28 февраля 2023 в Москве пройдёт мультиформатная конференция для тимлидов и руководителей TeamLead Conf 2023. Это не только «море» полезной информации и заряд профессиональной энергии, но и нетворкинги, мастер-классы и игры. У каждой секции свой фокус и свои решения проблем. Например, трек Aletheia Digital делает упор на практику, а в фокусе организации, команды и отдельные люди со своими переживаниями и мотивами. Подробнее на официальном сайте
