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

Послание читателю

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

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

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

Примечание:

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

Содержание

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

В этой статье мы будем использовать более приземленную и практическую версию 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

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

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

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

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

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

Помеха 2

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

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

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

Итог

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

  • Прозрачность. Любой может видеть рабочий процесс целиком и принимать решения на основании реальности, а не личного мнения;
  • Самоорганизация. Команда сама сможет решать, что делать для того чтобы достичь цели, без постоянного присутствия менеджера;
  • Сотрудничество. Каждый видит блокировки и незавершенную работу во всех статусах процесса и может подключиться для помощи. Что делать когда закончились твои задачи? Идти помогать коллегам;
  • Понимание. За счет того что виден весь процесс появляется понимание того как происходит работа у других людей. "Опять аналитики долго пишут требования, совсем обленились" исчезает;
  • Клиентоориентированность. Мы видим как обрабатываются пожелания клиента, общение с ним происходит регулярно. Можно проследить всю последовательность и связи от "хочу больше денег" и до "поправьте пожалуйста кнопку на зеленую". Так мы приходим к пониманию что и зачем мы делаем.

Пост-скриптум

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

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

  • Начни с того что есть сейчас. Визуализируй реальность как есть на досках;
  • Уважай существующий процесс. Даже если это бардак, как то же он сложился и работает.

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

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

0
14 комментариев
Написать комментарий...
Leha Shum

Это просто доска из Трело

Ответить
Развернуть ветку
Eduard Mirchev

Нет, это из Бережливого производства, ты что? Не видишь!?

Ответить
Развернуть ветку
Артем Летюшев
Автор

И почему вы так решили?

Ответить
Развернуть ветку
Eduard Mirchev

Спасибо большое за статью, Артем!

Ответить
Развернуть ветку
Артем Летюшев
Автор

Пожалуйста. Думаю выкатить ещё 3 статьи слегка в вакууме для общего описания и одну потом с кейсом. Грузануть цифрами, cfd, control chart, все как мы любим.

Ответить
Развернуть ветку
Eduard Mirchev

Честно говоря, я бы посоветовал вам как-то это сделать в виде инструкции по внедрению. Думаю, так многим было бы проще и осознать и внедрить предлагаемое вами решение. Мне вот точно)

Ответить
Развернуть ветку
Артем Летюшев
Автор

Хмм. Можете тогда указать на недостатки статьи? Что по вашему мнению вам бы точнее помогло понять автора?

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

Далее буду уже рассказывать про более сложные практики.

Ответить
Развернуть ветку
Eduard Mirchev

Ну вот вы написали статью, ок. Я прочитал, мне понравилось, но что мне с этим делать? Если я захочу работать по вашему совету, откуда начать? 
было бы круто видеть своего рода методичку, шаг 1, шаг 2. 

Ответить
Развернуть ветку
Артем Летюшев
Автор

Понял. То есть пока не будет остальных шагов, целостной картинки не сложится.

Ответить
Развернуть ветку
Дяченко Александр

Бизнес-процессы агентства в подробной визуализации - это хорошо. Многим не хватает подобной проработки БП и в итоге сдача любого проекта клиенту затягивается на доооолгий срок. Лайк ^_^

Ответить
Развернуть ветку
Артем Летюшев
Автор

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

Ответить
Развернуть ветку
Артем Летюшев
Автор

А их и не обязательно прорабатывать для начала.

Ответить
Развернуть ветку
Artem Kargapolov

Спасибо за статью) ждем продолжения

Ответить
Развернуть ветку
Артем Летюшев
Автор

Спасибо что читаете)

Ответить
Развернуть ветку
11 комментариев
Раскрывать всегда