Тернистый путь к портфельному Kanban

В статье я опишу историю развития системы управления портфелем проектов в инжиниринговой компании Uniscan-research. Мы начинали с небольшой команды в 15 человек и одним проектом на всех, а пришли к команде, у которой более 70 человек и десятки R&D-проектов в параллели.

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

Для начала несколько пояснений и определений, чтобы был понятен наш контекст.

• Наша фирма разрабатывает и производит наукоемкие приборы. Это электроника, механика, софт.
• Мы оформляем в виде проекта абсолютно любую деятельность разработчиков.
  
• Проект — это деятельность, направленная на достижение четко описанной цели, ограниченная по времени и бюджету. У любого проекта есть исходные требования, заказчик, команда исполнителей, согласованный бюджет. Возможно, есть проектный менеджер.
  
• Портфель проектов — это совокупность всех проектов, находящихся на любых стадиях, как в очереди, так и в активной работе.
  
• В нашем портфеле находится обычно около 100 проектов (половина в очереди, половина в работе).
  
• Проекты бывают разноплановые: есть проекты для пары человек и пары недель работы (исправить баг, добавить простую фичу в готовый прибор), есть проекты на команду из 15 человек и длинной в пару лет (разработка нового прибора).
  
• Заказчики R&D-проектов — офис продаж (развитие и появление новых продуктов), производство (проблемы на конвейере, брак) и техсаппорт (баги и улучшения от пользователей).
  

С чего мы стартовали:

• Все заказчики недовольны тем, как реализуются их заявки в R&D.
• Никто точно не знает, какие именно проекты сейчас находятся в активной стадии. Есть субъективное представление начальников о том, кто из сотрудников чем занят. Но при детальном анализе оказывается, что конкретный инженер занят не тем проектом, о котором думает начальник. То есть он ведет работы по проекту, который как бы не запущен, а начальник отчитывается о продвижении в проекте, который реально простаивает.
• Спрогнозировать сроки окончания конкретного проекта невозможно из-за непонимания того, кто и чем занят.
• Запускаются не те проекты, которые сейчас самые важные, а те, про которые громче кричит заказчик.
• Нормальная ситуация, когда бросаем недоделанный проект, так как заказчик принес «срочняк». В итоге копится технический долг («незавершенка»).

Ситуация кажется откровенно нелепой — как умные инженеры могут допустить такой беспорядок в процессах? Но такая ситуация встречается намного чаще, чем кажется.

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

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

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

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

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

Мы провели анализ нашей R&D-системы через деревья нежелательных явлений по Голдрату и выявили проблемы, с которыми надо разбираться в первую очередь.

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

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

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

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

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

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

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

Мы увидели, что в работе намного больше проектов, чем могут вести инженеры. Были такие, которые числились как запущенные, но по факту у них были пустые команды и ими никто не занимался. Или они были пятым–шестым проектом у инженера, но реально руки никогда до них не доходили.

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

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

Мы вернули в очередь проекты, которыми никто не занимался, и начали наводить порядок среди уже запущенных.

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

В нашем случае это:

• Заказчик.
• Исходные требования.
  
• Дедлайн, если он есть.
  
• Ограничения по бюджету, если они есть.
  
• Пофамильный состав команды.
  
• Проектный менеджер.
  

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

То же самое с исходными требованиями в виде документа. Что может быть проще — умные люди встретились, поговорили и решили, что надо разработать и начать продавать некий гаджет. Зачем порождать бюрократию? Жизнь показывает, что после такого разговора в каждой умной голове осталась своя уникальная картина. И когда гаджет будет разработан, заказчик будет сильно удивлен, насколько «неумными» (не телепатами) оказались разработчики.

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

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

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

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

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

Чтобы это правило заработало, было введено «одно окно» в разработку. Добавлять проекты в очередь имеет право только один человек. Нет смысла кричать и давить на инженеров, так как у них нет возможности запустить какой-то новый проект. Все общение идет через «владельца очереди». Этот человек экранирует команду от давления заказчика.

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

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

Планирование НИРов и ОКРов — дело совсем непростое. Классические теории управления подразумевают создание сетевого графика, распределение людей по нему, вычисление критического пути и определение даты завершения проекта.

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

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

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

Заказчик же не готов запускать проект в работу, не зная хотя бы примерно, когда проект может быть завершен. Как планировать продажи, если мы не знаем дату появления товара? Так что задачу планирования всё равно надо как-то решать.

Поэтому стали придумывать альтернативную систему оценки длительности проектов.

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

Попробовали делать не детальный сетевой график, а набор вех (milestones). Тогда мы имеем три–пять вех на проект длиной в год.

Например:

• Выбираем физический принцип решения задачи.
• Делаем макет.
  
• Проводим апробацию у заказчика.
  
• Делаем доработки.
  
• Внедряем в производство.
  

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

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

Если же проект для тебя непрозрачен и ты вне контекста, то любое изменение даты выглядит как проявление лени разработчиков.

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

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

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

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

Пользоваться MS Project Server сильно не хотелось, так как это очень тяжелый и безумно избыточный для нас инструмент. А простота использования — это залог того, что инструментом реально будут пользоваться.

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

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

Функциональность самописной ERP-системы предельно простая:

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

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

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

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

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

После непродолжительных изысканий по этой тематике мы наткнулись на книгу «Flow. The Principles of product development», где рассказывается, в частности, про способ оценки проектов через Cost-Of-Delay. Это попытка оценить упущенную выгоду от того, что проект еще не завершен.

Оцениваем в неких «попугаях» несколько параметров: важность проекта для бизнеса (business value), срочность проекта (time value), кросс-влияние проекта (risk reduction), трудоемкость проекта (effort). Все оценки относительные — по аналоги со StoryPoints в Agile.

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

Далее считаем приоритет по формуле: (важность + срочность + «кросс-влияние») / «трудоемкость в месяцах».

Важность — это субъективная оценка заказчика бизнес-ценности результата этого проекта. Срочность — это оценка того, насколько важно сделать проект «прямо завтра». Кросс-влияние — это оценка того, как влияет результат этого проекта на какие-то другие проекты компании.

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

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

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

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

Это приводит к тому, что надо с некоей периодичностью переоценивать всю очередь. Либо автоматически по неким правилам, либо вручную. Мы выбрали второй путь и раз в квартал переоцениваем очередь.

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

В какой-то момент мы поняли, что очень длинным путем пришли к «системе Kanban» (Kanban portfolio system). Нам не хватало некоторых деталей, но суть была та же.

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

Мы бьем поток создания ценности на следующие стадии:

• неутвержденная очередь;
• утвержденная очередь;
  
• анализ;
  
• разработка;
  
• внедрение в производство;
  
• апробации;
  
• постановка на снабжение (особенность наших заказчиков).
  

Выделяем потоки:

• поддержка производства;
• разработка новых изделий;
  
• «срочняки».
  

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

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

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

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

«Книжный» Kanban подразумевает, что карточки на доске имеют сопоставимую трудоемкость и любой член команды может брать в работу любую карточку. В нашем случае не выполняются оба условия. Можно, конечно, завести несколько досок, но тогда придется привязывать к каждой доске свою команду, чего нам очень не хотелось.

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

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

Довольно трудоемко и не так элегантно, как в книжках, но зато работает.

Также мы внедрили в ERP-систему кумулятивную диаграмму потока (Cumulative Flow Diagram).

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

Еще одна вещь, которая была заимствована из книг, — использование чеклистов для описания критериев перехода проекта из стадии в стадию. Это гарантировало, что разработчики ничего не забыли сделать перед тем, как карточка двинется вправо по доске.

Например, если проект уходит из разработки во внедрение, то мы должны убедиться, что вся нужная документация готова и доступна в правильном месте на сервере. Мы сделали по чеклисту на каждую стадию доски. Вроде мелочь, но это позволило заметно упростить жизнь менеджерам и разработчикам, так как не надо напрягать память «не забыли ли мы чего-то по дороге».

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

Очень коротко весь наш путь:

1. Вводим реестр проектов. Нет работ мимо него.
   
2. Заводим «одно окно».
   
3. Вводим единый набор атрибутов проектов.
   
4. Учимся писать исходные требования.
   
5. Вводим ограничение на количество проектов в работе. Не даем перегружать систему.
   
6. Учимся оценивать сроки проектов.
   
7. Вводим систему приоритезации очереди.
   
8. Делаем систему отчетности о состоянии портфеля.
   
9. Анализируем кумулятивную диаграмму потока, ищем узкие места.
   

Задавайте вопросы, добавляйтесь в нашу группу в Facebook.

#kanban