Принципы управления бизнесом Lean для интернет-агентства

Давайте немного поговорим о производстве автомобилей: там есть много хорошего, что можно применять в веб-студии

Владимир Завертайлов

Главный бармалей Сибирикс

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

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

Итак, немного истории. Массовое производство машин возникло на заводах Форда, в 20-х годах, и выглядело это примерно так.

Нам нужно сделать машину и, допустим, в ней есть колеса и кузов. Тут у нас стоит станок, который делает только шины, и станок, который делает только диски. Результат их жизнедеятельности попадает на третий станок, который надевает шину на диск. Потом колеса отправляются дальше, где их прикручивают. Все, машина готова, можно ехать! Да, сильно упрощенная схема. Итак, в чем тут проблема.

Если по каким-то причинам станок, который делает шины, сломался, нужно останавливать и этот станок (который надевает шину на диск). Вот этот станок (который надевает шину на диск) — очень производительный (пятьсот колес в час) и очень дорогой. Допустим, миллион долларов. Час его простоя стоит заводу просто невероятное количество денег. Как избежать потерь с простоями?

Очевидно, нужно делать запасы шин.

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

Вообще это очень похоже на то, во что мы уперлись, когда нас было человек 15. Только дорогие станки нужно заменить дизайнерами и программистами. Чтобы дизайнер не простаивал — на него нужно создать запас входящих проектов. Аналогично, для верстальщика должен быть запас нарисованных макетов, для программиста — запас верстки, и так далее. Какие минусы:

WTF?

Всегда аврал. Демотивация.
Низкий обмен знаниями. Демотивация.
Много незаконченных проектов в каждый конкретный момент.
Сроки выполнения увеличиваются.
Постоянное переключение людей между проектами. Демотивация.
Дефекты выявляются поздно. Чинить — дорого.

Во-первых, эта штука страшно демотивирует. Потому что всегда аврал. Заканчивается проект — тут же надо брать делать новый, и нет никакого перерыва или удовлетворения от сделанной работы.
Каждый специалист изолирован, такой местный князёк, который делает свой кусок проекта, а весь результат его заботит мало. Как следствие:
- низкий обмен знаниями внутри студии. Люди плохо растут. Демотивация;
- никто внутри не в курсе, какие проекты релизит студия или планирует релизить. Демотивация;
- когда дизайнер узнает, что вышло в итоге из его макета, — обычно бывает в прострации. Демотивация;
Очень много незаконченных проектов внутри студии (а незавершенная фича никому не нужна).
Сроки выполнения проектов увеличиваются из-за простоя на каждом из этапов.
Приходится постоянно переключать людей с проекта на проект, а это — демотивирующий фактор, и требует времени на погружение в проект заново.
В каждый момент времени невозможно сделать наглядную демонстрацию выполненной работы. Проекты в полуготовом состоянии. Это напрягает заказчика.
Пишутся лишние функции без учета юзабилити. Большая часть дефектов выявляется на поздних этапах тестирования, когда пора сдаваться.

Долг компании Toyota в 8 раз превышает капитализацию.
Зарплаты рабочих урезаны, идут массовые сокращения.

Цель: Усовершенствовать процесс так, чтобы производительность догнала Форд.

Что же, черт возьми, делать?

Опять немного истории. На этот раз — послевоенная Япония. В 1948 году долг компании Toyota в 8 раз превышает капитализацию. Зарплаты рабочих — урезаны, идут массовые сокращения. Компания — практически банкрот. И тут тойотовцы ставят себе грандиозную цель: усовершенствовать процесс так, чтобы производительность догнала Форд.

Тайити Оно, Toyota Motor Corporation

Офигенный, блин, совет

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

Производственная система Toyota
Toyota production system

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

Вот этот веселый парень на экране — основатель производственной системы Toyota.

Он сказал, что единственное, что нужно делать — это сокращать таймлайн, то есть время от получения заказа до момента получения бабок.

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

Затем тойотовцы анализировали этот лог и смотрели, какие операции добавляют ценности к продукту, а какие из них — потери. Вот пример, где рабочий крепит деталь, при этом выполняется 15 операций. 12 из них — не добавляют никакой ценности к продукту или являются потерями, и только три операции — добавляют ценность. Очевидно: если мы устраним лишние операции — мы сократим время производства.

Слайд ~~стыбрин~~ взят из из вот этой клёвой и умной книжки:

OZON.ru — Книги | Дао Toyota. 14 принципов менеджмента ведущей компании мира | Джеффри Лайкер | The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer | Модели менеджмента ведущих корпораций | Купить книги: интернет-магазин / ISBN 978−5-9614−1251−2, 0−07−139 231−9

Потери: № 1 — недоделанная работа

Несданный дизайн.
Несверстанный код.
Непротестированный код.
Незапрограммированные требования.
Незадеплоенный код.

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

Потери: № 2 — ненужная функциональность

95% пользователей MS Excel постоянно используют 5% функций.

Ну, тут все просто. Потрачено время на реализацию, тестирование, отладку, а никто не пользуется. Лидер из программ с мертвыми функциями — это MS Excel. Там используют около 5 процентов функций.

Потери: № 3 — повторное изучение (relearning)

Получение новой информации о продукте, коде, заказчике не несет ценность для заказчика.
Повторное изучение — потери.

Тут немного более замысловато. Допустим, к вам приходит чувак и говорит: «Мы занимаемся страхованием автомобилей, нам нужен калькулятор». И начинает вам (проджект-менеджеру) рассказывать, как это калькулятор будет работать. Вы его внимательно два часа слушаете. Вывешиваете ценник. Он такой «Э!», и идет думать к вашим конкурентам. Потом приходит к вам через месяц, говорит — «Уууу! решил у вас все-таки сделать». А вы уже ничего не помните. Вы зовете программиста Васю, которому также два часа заказчик все рассказывает. Ну очевидно, в какой-то момент была потеря времени. Причем такая тонкость: когда вы получаете новые сведения о продукте, коде, проекте — это ценно для заказчика. А вот когда происходит повторное изучение — это потери.

Потери: № 4 — передача

Ответственности
Знаний
Проектов
Действий
Заявок

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

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

Потери: № 5 — переключение между задачами

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

Переключение между задачами — это потеря минимум 15 минут. 4 задачи — 1 час.

На восстановление контекста нужно от 15 минут до получаса. Это чистые потери.

Считайте, если вы дернули человека — это вы слили 15 минут. Помножьте на ваш рейт, вычтите у себя из зарплаты. Если будет жадно — не дергайте. Если не жалко — стоит начать рассматривать как вариант.

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

Потери: № 6 — ожидание

Ожидание согласования с заказчиком.
Внутренние согласования.
Бесполезные митинги.

Дальше. Очень такая актуальная потеря — ожидания. Пока заказчик согласует, пока тексты пришлет, логотип в векторе и так далее. Либо очень характерная для крупных контор трата времени — митинги и собрания.

Наверное, все видели демотиватор: «Надоело работать — собери собрание!». Ну тут все просто. Собираются 5 человек, начинают два часа обсуждать непонятно какой вопрос. Не принимают никаких конкретных решений (вопросов же конкретных не было) и расходятся. Вообще, это называется ППР — пришли, поговорили, разошлись.

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

Потери: № 7 — баги

Чем позже дефект найден, тем он дороже.
Иногда можно использовать конечных пользователей в качестве бета-тестеров.

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

Есть правда прикольный способ минимизировать ущерб от багов. Это когда вам практически пофигу на пользователей вашего сайта. Ну отвалилась от сервиса 1000 человек — ну и хрен с ними. Примером такого подхода, где это клево работает — фейсбук. По сути бета тестерами фейсбука являются сами пользователи. Вот тут все зависит от ситуации — если вы готовы, что будет отваливаться много пользователей из-за багов, но фичи будут делаться быстрее — велкам.

Семь видов потерь

Недоделанная работа
Ненужная функциональность
Повторное изучение
Передача
Переключение задач
Ожидание
Дефекты

Итак, мы рассмотрели семь видов потерь. Теперь давайте посмотрим, как их выловить в повседневной деятельности веб-студии. Для этого удобнее всего использовать такой инструмент, как Value Stream Map.

Выстраиваем поток ценностей

Как сделать клиента счастливым

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

Ищем и устраняем потери

Сделать клиента счастливым — быстро!

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

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

Чтобы это контролировать — на уровне проектов мы используем канбан.

Канбан — доска для портфолио проектов

Кто вчера ходил на CodeFest — тот молодец. Там Асхат Уразбаев очень доходчиво разобрал канбан. Для тех, кто не ходил — коротенько расскажу суть, как это используется у нас в студии.

Канбан — это вот такая доска. Колонки соответствуют фазам, через которые проходят наши проекты. Липучие бумажки — это сами проекты. В первой колонке у нас вешаются все-все-все проекты, по которым мы планируем начать разработку в ближайшее время. Во вторую колонку мы перевешиваем те проекты, по которым мы вот-вот готовы начать работы. Дальше у нас идут несколько фаз разработки (ГОНЯЕМ ЗАДАЧУ ПО СЛАЙДАМ):

Задача — сократить время выполнения проекта

Далее. Под каждой колонкой у нас висит список критериев, только после выполнения которых мы можем перевешивать проект на следующий этап. Это просто наши договоренности между собой, которые мы обязуемся выполнять. Например, в Next у нас не может попасть проект, по которому не получена предоплата и запланировано время разработчиков. Эта штука позволяет отлично контролировать качество работы и все нюансы.

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

Критерии перехода между этапами

Свои для каждой команды.
Команда договаривается о них заранее и в дальнейшем — придерживается.
Критерии обновляются по мере необходимости.

Проведено тестирование внешним менеджером проектов.
Выявленные замечания устранены.
Проведен внутренний опрос работников студии относительно работы.
Выявленные замечания устранены.
Проект размещен на альфа-сервер и работает (проверен QA).
Все работы по договору выполнены.

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

Каждый проект из канбан-доски детализируется рабочей командой

Что еще помогает искать и устранять потери? Есть такая хитрая, тоже японская методика — пять почему. При возникновении любой проблемы нужно искать причину ее возникновения и задавать последовательно вопрос «почему?». Разберем пример:

5 Почему (5 Why)

Проблема: Заказчик рвет и мечет. Почему?

Ответ: Упал сервер. Почему?
Ответ: Повис скрипт. Почему?
Ответ: Бесконечный цикл в коде. Почему?
Ответ: Вася закоммитил непротестированный код. Почему?
Ответ: Вася — новый сотрудник, который не знал, что нужно отдать код на тестирование…

Затем на каждом уровне ищем противоядие:

Клиент негодует — успокоить;
Упал сервер — поднять;
Повис скрипт — перегрузить;
Убрать бесконечный цикл;
Пропинать Васю, чтобы отдавал код тестерам;

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

И начинаем применять эти противодействия. В чем плюсы? Мы не только боремся с последствиями, но и анализируем, в чем корневая причина факапа. И пытаемся ее устранить. Если получается, то нам все меньше придется разгребать последствия.

Единственный момент — если попробуете сделать такой анализ, можно упереться в две бесперспективные ветки. Например, вы дошли до уровня «Вася закоммитил непротестированный код». И решили, что Вася — в принципе умственно отсталый, и его нужно уволить. То есть вы не ищите более глубинных причин, а все сваливаете на некомпетентность Васи. Вот этого делать не надо. Да, действительно, может быть Вася — дурак, и его пора уволить. Но это не выявляет какой-то системной проблемы. Я надеюсь.

И вторая веточка, куда можно забраться — это философия. Упал сервер. — почему? Он устал. Почему? Потому, что жизнь — суровая штука. Почему? Потому, что бог нас не любит — почему — потому, что все люди грешны… Понятно, что цепочка полностью тупиковая, никаких решений вы там не найдете. Я надеюсь.

Итак, что у нас получилось

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

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