Рецепт как развивать студию с помощью канбана. Часть первая — визуализация

Дорогой читатель, я пишу этот цикл с целью нанести тебе непоправимую пользу.

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

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

В тексте статьи идет речь об аутсорсинге - привлечении специалистов компании для решения ряда задач. Разработка сайта у веб-студии это аутсорс, найм дизайнера у студии для помощи это аутстафф, не путайте. Если вы оказываете услуги по дизайну/разработке/чему-то ни было, взымая плату за время работы, то вы аутсорсер.

Цепочка создания ценности

Вход и выход

Операции

Результаты

Пример

Проблемы

Итог

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

В данном случае цепочка создания ценности - это структура последовательных операций компании для удовлетворения потребностей потребителя.

Простым языком - действия, которые совершаются в организации для превращения требований клиента в деньги.

Типичная цепочка создания ценности в любой студии выглядит так:

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

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

Для простоты назовем потребности/требования запросами. Сделаем вид что клиенты знают чего хотят, а мы точно это понимаем.

Запрос - обращение клиента к вам с просьбой о взаимодействии. Например, сделать корпоративный портал, поменять версию Magento или отредизайнить логотип.

услуга = F(запрос), где F(x) - цепочка создания ценности.

До того как человек стал потенциальным клиентом (лидом), он с нами общается, в каком-то виде передает запрос. Важно учитывать не только обращения в виде "у меня 2 млн, сделайте мне приложение за 5 месяцев, вот ТЗ", но и "мне нужно больше клиентов для пиццерии".

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

Посмотрев с высоты птичьего полета на любую студию, можно выделить следующие этапы:

Лиды - работа с потенциальным клиентом. Это сбор требований, присейл, формирование коммерческого предложение и т.д.

Сделки - заключение договорных отношений. Это формирование договора, подписание и оплата.

Проекты - управление проектом с точки зрения его фаз. Это инициация (запуск проекта), планирование, реализация (выполнение проекта + мониторинг) и закрытие проекта.

Этапы - управление жизненным циклом отдельных этапов проекта. Где-то у проектов предиктивный жизненный цикл, так называемый "waterfall", где-то итеративный и т.д. Большинство компаний пришли к тому, что проект разделяется на небольшие "кусочки" с поставляемым результатом за который платит заказчик.

Задачи - управление рабочими элементами на уровне команды/отдела. Рабочий элемент - это то что нужно сделать. Например, заверстать экран авторизации или поставить SSL. Часто их называют тасками или тикетами.

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

Эти доски необходимы для визуальной системы управления производством. Ранее ты не видели все цепочку. Теперь у тебя есть способ ее узреть.

Если долго смотреть в огонь на доски, то можно увидеть всю текущую ситуацию в компании по любым операциям:

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

Всегда есть какой-то общий список того, что осталось сделать по всем проектам. Не важно в разработке они с нуля или на поддержке. Соберем все такие запросы в одну очередь и назовем ее Backlog (это не беклог продукта или отдельного проекта, а общая очередь).

Так ты всегда можешь увидеть все, к чему еще даже не прикасались, но оно уже нужно клиентам.

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

Из общей очереди (backlog) мы выбираем элементы, которые необходимо поставить на данном этапе или просто в ближайшее время. Граница между "backlog" и "к выполнению" это точка принятия обязательств.

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

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

Выбираются они тогда, когда команда может их поставить. Это становится понятно, когда в потоке работ освобождается место, например на неделю вы набрали 10 задач на 2 проекта, сделали из них 6. У вас освободилось место еще под 4 задачи, вы можете провести собрание по пополнению В следующей статье я подробно расскажу как это делается.

Если вам показалось, что это похоже на скрам, то моргните, наваждение исчезнет.

Внимательный читатель заметит, что каждый статус имеет подстатусы "в работе" и "готово". Это нужно чтобы обеспечить прозрачность. Раскрою мысль - подумай, как ты поймешь что задача готова к дизайну, прямо сейчас в процессе и уже прошла дизайн, если у настолько 1 статус - дизайн. Также это нужно чтобы обеспечить процесс вытягивания. Об этом подробнее мы с тобой поговорим в следующих статьях.

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

Багом мы будем называть любую недоработку, которая повлекла несоответствие качеству, так называемый failure load.

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

Для управления багами используется механизм блокировок. Багом мы считаем все недоработки, которые найдены внутри сервиса. Пока мы кодим/тестируем и т.д. могут находится недоработки. Мы заводим отдельную задачу под баг и блокируем текущую. Например, если в задаче которая сейчас у тестировщика найден баг, то заводится баг в очереди разработки и им блокируется текущая. Она будет оставаться на месте, пока не будет починен баг.

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

При этом задачи могут быть заблокированы не только недоработками, но и внешними факторами, например падением сервера. Такие задачи откладываются в "к выполению". Обязательства по ним остаются принятыми, но не могут быть исполнены прямо сейчас.

Задачи прошедшие тестирование считаются фактически готовыми. Но формально (с юридической точки зрения по договору) еще нет, пока не были приняты заказчиком.

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

Для прозрачности добавим статус "приемка юзерами". Там будут находится те задачи, которые отданы на приемку заказчику, заказчик также может найти какие-то недоработки, которые необходимо выполнить. При этом не стоит забывать, что правки от заказчика это не недоработки, а изменения. Изменения должны влечь за собой сдвиг ограничений, например срока и бюджета. Классическая точка поставки будет перед статусом "завершено".

Таким образом мы получаем прозрачный сервис и явный контроль над процессом производства.

В жизни это действительно очень длинная доска из 14 статусов, которая даже не помещается на скриншот:

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

Правило 1 - отображаем все как есть и начинаем с того что есть сейчас.

Правило 2 - вводим реальную работу. Называем и описываем рабочие элементы как то, что происходит в реальности.

Правило 3 - перемещаем рабочие элементы между статусами. Это позволяет моментально увидеть объем незавершенной работы.

Мы не придумываем доски, а просто показываем то, как это происходит сейчас. В этом может помочь STATIK.

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

Поэтому естественно нужно думать о том, что выходит за пределы производства - лидогенерации и маркетинге.

Но я есть и позитив. Я заметил любопытный феномен - чем лучше процесс производства, то тем выше удовлетворенность клиентов, портфолио чаще пополняется и растет уровень команды. Существенно вырастает репутация компании и деловые связи. На компанию начинает работать сарафанное радио.

Визуализация процессов дает колоссальные преимущества. Рассмотрим некоторые из них:

Дорогой читатель, надеюсь ты не уснул под конец и нашел поводы для рефлекции.

Скажу коротко для закрепления:

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

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