Предисловие

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

Понимание вашего процесса как процесса коллективного накопления знаний

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

Существует общая тенденция и желание сделать работу более коллективной. Тем не менее, когда я прошу людей в офисе нарисовать процесс своей работы, они часто предоставляют что-то такое (я упрощаю):

В этом представлении работники образуют конвейер, но их работа на самом деле не похожа на сборочную линию. Например, разработчик программного обеспечения может обнаружить логическое несоответствие в спецификации требований и отправить работу обратно к бизнес-аналитику. Инженер по качеству (QA) может сделать то же самое при тестировании созданного программного обеспечения. Аналитик обновит спецификацию и отправит задачу обратно QA. QA может найти в ней ошибку и отправить обратно разработчику. Специалист по внедрению может найти в коде что-то, что препятствует поставке. Затем разработчик вносит необходимые изменения. Теперь код нуждается в повторном тестировании, поэтому он возвращается к QA, после чего снова возвращается к внедрению.

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

Некоторые пытаются визуализировать этот процесс на доске, которую они называют «канбан»:

Затем они задаются вопросом: Что, если, например, тестировщик вернет рабочий элемент обратно аналитику или разработчику? Должна ли карточка оставаться на своем месте или перемещаться? Что, если у нас есть WIP-лимит (эти цифры в заголовках столбцов)? Что, если этот столбец уже заполнен до предела, другая карточка должна вернуться назад?

Есть ли способ лучше?

Этот вопрос довольно распространен и уходит корнями в неправильное понимание природы профессионально-сервисной работы. Вместо серии передач между специализированными рабочими местами, речь идет главным образом о создании информации и накоплении знаний. Это становится препятствием при попытке сделать процесс похожим на блок-схему. Так же как ограничением при попытке визуализировать его, следуя за выполнением работы.

В примере поставки новой функциональности программного продукта могут быть созданы следующие знания (не обязательно в этом порядке):

точная конфигурация рабочей среды (ОС, веб-сервер, сервер ба�� данных, стороннее программное обеспечение)
ключевые примеры поведения разрабатываемой функциональности, варианты использования, приемочные критерии, исполняемые спецификации и т. д.
как интегрировать новые возможности с уже существующей функциональностью продукта (процедуры обновления, миграции данных и т. д.)
как именно будет выглядеть дизайн и реализация
какие тесты необходимы для обеспечения качества разработки
как ведет себя обновленный продукт с точки зрения производительности и других нефункциональных требований
результаты юзабилити-тестов и исследовательских тестов
что еще нужно пользователям для использования обновленного продукта: настройки, обучение, локализация и т.д.
и прочее, и прочее.

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

Если бы мы попытались визуализировать процесс накопления этих знаний, то результат мог бы выглядеть так:

В этом примере работа над спецификацией доминантна на ранней стадии процесса поставки. Бизнес-аналитики могут проводить анализ функциональности, декомпозицию, уточнение требований. Но в это же время другие специалисты могут привносить свой вклад. Тестировщики могут помочь превратить приемочные критерии в исполняемые тесты. Специалисты по развёртыванию и разработчики могут оценить, какое будет влияние на кодовую базу и инфраструктуру.

Эта активность порождает множество знаний в самом начале, но в конечном итоге она затухает. Мы не можем анализировать бесконечно на протяжении всего пути к поставке. Таким образом, разработка кода становится в какой-то момент основным способом накопления знаний.

Конечно, большая часть разработки кода ложится на плечи разработчиков, но и другие тоже могут помочь. Требования все еще могут нуждаться в уточнении и разъяснении (привет аналитик). Тестировщик может взять частично готовое программное обеспечение, протестировать его и дать обратную связь разработчику. Разработчики могут сотрудничать со специалистами по внедрению, чтобы увидеть, как возникающие изменения повлияют на развертывание.

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

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

Вывод

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

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

А что дальше?

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

Мне нужно подготовить ряд статей, в качестве рекомендаций: как специалист по процессам может составить отражение процессов с командами профессиональных сервисов. Для тех, кто использует Канбан системы, этот подход имеет ряд преимуществ при проектировании и эксплуатации этих систем.

За участие в переводе большая благодарность Алексею Пименову и StepEv.

Канбан метод: Понимание вашего процесса как процесса коллективного накопления знаний