Блог http://neogenda.ru ru Соответствие предназначению: определение ключевых показателей эффективности (KPI) для надлежащего поведения http://neogenda.ru/blog/0ruvj5h3y1-sootvetstvie-prednaznacheniyu-opredeleni http://neogenda.ru/blog/0ruvj5h3y1-sootvetstvie-prednaznacheniyu-opredeleni?amp=true Tue, 23 Jan 2024 19:09:00 +0300 Андрей Сидоренко Перевод статьи David Anderson, опубликованной на medium.com. Оригинал можно прочитать здесь. Все ваши ключевые показатели эффективности (KPI) должны...

Соответствие предназначению: определение ключевых показателей эффективности (KPI) для надлежащего поведения

Перевод статьи David J. Anderson, опубликованной на medium.com.
Оригинал можно прочитать здесь.
Все ваши ключевые показатели эффективности (KPI) должны быть распознаваемы вашими клиентами. Все KPI должны быть метриками соответствия — они должны влиять на то, почему и как клиенты выбирают ваш продукт или сервис. Если клиент не распознает ваши KPI или не интересуется ими, значит, они не являются «ключевыми» и индикаторами «эффективности», они могут указывать на что-то другое, но не являются предсказателями того, насколько хорошо ваш бизнес работает или, вероятно, будет работать в будущем.
В моей недавней статье «Сегментация рынка на основе «Почему?» я объяснил, как мы определяем показатели соответствия. Эти показатели позволяют нам оценить, соответствует ли наш продукт, сервис или оказание сервиса своей цели в данном сегменте рынка. По сути, они являются KPI для каждого сегмента рынка. Все другие показатели должны либо направлять инициативу по улучшению, либо указывать на общее состояние вашего бизнеса или подразделения продукта, или возможности предоставления сервисов. Если вы не можете поместить показатель в одну из этих категорий, то он вам не нужен.

Показатели соответствия

В одной из прошлых статей мы описывали историю Ниты — менеджера проекта и матери четверых детей. Мы установили, что она находится сразу в двух сегментах рынка — кластере «работаю допоздна и заказываю еду для команды в офисе» и кластере «накормите моих детей — это срочно!». Мы также определили, что основными показателями, которые вызывают озабоченность, являются: время доставки; качество, как функциональное (соответствие меню и заказу), так и нефункциональное (горячая ли еда, вкусная, домашняя, изысканная или нет); предсказуемость (сроков доставки, качества); проблемы безопасности или нормативные требования, включая, возможно, доверие к использованию натуральных ингредиентов. В нашем примере эти 4 основные показателя применяются независимо от того, заказывает ли Нита пиццу для команды или для своей семьи. Однако пороги удовлетворенности значительно различаются в зависимости от контекста.
Когда Нита заказывает еду для команды, то они с радостью ждут доставки от часа до 90 минут. Если в заказе допущены незначительные ошибки, то это вряд ли будет иметь слишком большое значение. Однако существует порог. Если кто-то из команды вегетарианец, значит, нам должны доставить вегетарианскую пиццу, иначе мы решим, что заказ не выполнен. Меню важно в том смысле, что гики хотят более экзотического выбора. Они предъявляют нефункциональные требования. Им нужна горячая, вкусная, домашняя и изысканная пицца. Они не слишком требовательны к предсказуемости сроков доставки или точности заказа. Окно от 30 до 45 минут для доставки, вероятно, приемлемо, а также допустимо несколько мелких ошибок в заказе. Они действительно принимают во внимание здоровье и безопасность в ресторане, и даже безопасность езды курьера, но только в той мере, в какой это не ставит под угрозу качество пиццы по прибытии.
Когда Нита заказывает пиццу для своей семьи, пороговые уровни значительно отличаются. Дети очень голодны и нетерпеливы, и теперь они знают, что скоро будет пицца, и они взволнованы по этому поводу. Быстрая доставка очень важна. Предсказуемая доставка очень важна, ведь в данный момент шестилетний ребёнок запускает таймер обратного отсчёта на своём iPad. Меню было важно, но лишь потому, что предлагало простую сырную пиццу с томатным соусом. Дети так взволнованы, что не будут возражать, если пицца немного остынет или немного встряхнётся во время транспортировки. Детям важна точность заказа. Если это не простая пицца с сыром, они будут очень расстроены и вряд ли вообще её съедят. Между тем, мамочка может беспокоиться о безопасности и нормативных требованиях, поэтому дети могут предпочитать ресторан, который обещает использовать натуральные ингредиенты. Они понятия не имеют, можно ли доверять этому утверждению. Раз в ресторане сказали, что ингредиенты натуральные — то пусть мамочка волнуется о том, правда это или нет.

Итак, вкратце…

Дети
  • Быстрая доставка
  • 100% точность заказа
  • Их не слишком волнует нефункциональное качество
  • Предсказуемая доставка
  • Не слишком озабочены вопросами безопасности или нормативными требованиями
Гики
  • Приемлема более длительная доставка
  • Допустимы некоторые ошибки в точности заказа
  • Чрезвычайно привередливы к нефункциональному качеству
  • Имеют более широкие границы предсказуемости доставки
  • Не слишком озабочены вопросами безопасности или нормативными требованиями
Выводы В 4-х из этих 5-и категорий пороги соответствия для этих двух сегментов существенно различаются.
Если мы хотим успешно обслуживать оба сегмента, способствуя улучшению, чтобы обеспечить высокий уровень удовлетворенности клиентов в обоих сегментах, мы должны использовать более высокие пороговые значения для каждого показателя в качестве ориентира. В противном случае нам придётся разделить сервисы по сегментам. Мы можем сделать это, введя два класса сервиса, по одному для каждого сегмента. Это может работать через ценообразование. Например, будет ли Нита платить больше за гарантированную быструю доставку для детей? Или это может работать за счёт распределения мощностей и формирования спроса на основе этого. Например, мы можем отказаться принимать крупные коммерческие заказы в часы пик, чтобы освободить время для домашних заказов. В этом примере мы делаем ставку на обучение наших корпоративных клиентов делать заказы в начале дня, принимая риск, что они могут уйти от нас куда-нибудь ещё. Мы делаем это, потому что дорожим домашними заказами.
Для этого нет готовой формулы. Нет правильного или неправильного. Для нашего бизнеса мы делаем выбор в отношении того, какие сегменты мы хотим обслуживать и насколько хорошо мы хотим их обслуживать. Выбор имеет последствия. Мы должны быть готовы жить с этими последствиями и быть готовыми нести за них ответственность.
Метрики и пороговые значения, которые мы разработали для каждого из наших сегментов, должны стать KPI для нашего бизнеса, в данном примере — для службы доставки пиццы. Мы должны внедрить механизмы, инструменты и обратную связь с клиентами для измерения этих показателей. Мы можем использовать результаты с Ревью поставки сервисов, Операционного ревью и Ревью стратегии, чтобы определить, насколько хорошо мы обслуживаем наши рынки, где нам нужно внести улучшения, и какие сегменты мы хотим обслуживать.
В своей следующей статье из этой серии я рассмотрю другие типы показателей: показатели, определяющие улучшения, и показатели здоровья. Мой опыт работы с клиентами в 2015 году показывает, что большинство существующих KPI — это показатели здоровья. Как следствие, эти предприятия оптимизируются для неправильных целей и удовлетворенности клиентов, а их способность выживать и процветать на рынке снижается. Все ключевые показатели эффективности должны основываться на пороговых значениях показателей критериев соответствия, полученных на основе анализа сегментов рынка, которые вы выбираете для обслуживания.
]]> Насколько мы Agile? http://neogenda.ru/blog/52u8m07ns1-naskolko-mi-agile http://neogenda.ru/blog/52u8m07ns1-naskolko-mi-agile?amp=true Wed, 24 Jan 2024 19:45:00 +0300 Артур Нек Перевод статьи Fernando Cuenca, опубликованной на medium.com Оригинал можно прочитать здесь 3 показателя гибкости сервиса поставки Большинство организаций,...

Насколько мы Agile?

Перевод статьи Fernando Cuenca, опубликованной на medium.com
Оригинал можно прочитать здесь

3 показателя гибкости сервиса поставки

Большинство организаций, переходящих на Agile, в конечном итоге спросят: «А насколько мы Agile?». А также захотят, чтобы ответ был подкреплён какой-то «объективной» формой измерений, и мог быть использован для различных целей, таких как оценка прогресса усилий по трансформации или даже оправдание её существования.
Часто мы видим попытки ответить на этот вопрос путём подсчёта количества запущенных Agile-команд или количества людей, отправленных на Agile-обучение или получивших определённые сертификаты. Другие популярные метрики сосредоточены на инженерной деятельности (такой как степень автоматизации, покрытие кода или время сборки) или на показателях результатов работы команды (таких как стори поинты или скорость). Эти метрики соблазнительны, потому что их относительно просто зафиксировать, но (как я уже писал здесь ранее) они также очень мало говорят нам о влиянии Agile-трансформации на бизнес, который обслуживает IT-организация, или о том, насколько хорошо она удовлетворяет его потребности.

Клиентоориентированный дашборд

Пару лет назад, когда мы работали с общим клиентом, Алексей Жеглов предложил альтернативную модель, чтобы переосмыслить разговор с точки зрения, ориентированности на клиента, избегая внутренних, ориентированных на команду метрик. Заменить их на индикаторы того, что действительно волнует клиентов сервиса поставки.
Метафора «дашборда гибкости» была модной в то время, поэтому однажды Алексей подошёл к доске и нарисовал следующий эскиз:
Дашборд гибкости сервиса поставки, Алексей Жеглов
«Представьте, что у вас может быть что-то подобное», — сказал он.
Первая характеристика этого дашборда заключается в том, что она предназначена не для команды, а для «сервиса поставки»: с точки зрения клиентов, которых вы обслуживаете, важно то, что их потребности (а часто и явные запросы) достаточно удовлетворяются. Чаще всего для этого требуется участие нескольких команд и других лиц, и, следовательно, гибкость необходимо измерять на этом уровне через более «системную» призму, которая охватывает всех участников, задействованных в непрерывном удовлетворении запросов клиентов.
Второй смысл принятия такой точки зрения на «сервис поставки» заключается в том, что единицей измерения для этого дашборда должен быть какой-то «распознаваемый клиентом» рабочий элемент: вид рабочей единицы, которая пересекает границу клиент/сервис и становится единицей обязательства и поставки. В некоторых контекстах это могут быть небольшие истории пользователей, но чаще это будут более крупные функции, запросы на изменения или даже целые проекты.

Измеряем то, что волнует клиентов

«Цель клиентов, какой бы она ни была, очень часто связана с их временной шкалой и воздействием, которое другие события или упущенные возможности оказывают в течении времени» («Fit for Purpose», Дэвид Дж. Андерсон и Алексей Жеглов, стр. 84.)
Когда дело доходит до ожиданий от поставки, мы знаем, что наиболее распространённые ожидания клиентов связаны с её сроками. Поэтому неудивительно, что «Время выполнения заказа» (также называемое во многих контекстах «Time 2 Market») занимает видное, центральное место на дашборде.
Важный аспект, это ответ на вопрос «сколько времени это займет?» — это не число, а распределение вероятностей. То есть время, прошедшее от принятия обязательств до завершения похожих типов работ, будет варьироваться в определённом диапазоне, причём некоторые значения будут наблюдаться чаще, чем другие. «Мы знаем силы природы, которые вносят свой вклад в форму этой кривой», — отметил Алексей, и всё дело в задержках, а не в приложенных усилиях.
Показывая время выхода на рынок в виде кривой (или, возможно, гистограммы), мы можем помочь ответить на вопрос о том, «насколько быстро» мы предоставляем услуги (в среднем), а также «насколько предсказуемо» мы их предоставим около этого среднего значения (определяется формой хвоста распределения справа).
Много было написано о том, что Agile не обязательно означает более быстрые сроки доставки, но способность быстрее и изящнее реагировать на изменения в окружающей среде. С точки зрения клиента, это будет восприниматься как способность сервиса принимать новые запросы, когда они возникают, и способность клиента более часто получать результаты. На дашборде эти два аспекта представлены циферблатами частоты пополнения и выпуска, которые показывают текущие возможности в масштабе времени «Ежегодно», «Ежеквартально», «Ежемесячно», «Еженедельно», «Ежедневно» и «Ежечасно».

Насколько вам нужно быть Agile?

Очень часто предполагается, что «Agile-трансформация» должна двигаться в направлении принятия всех технических практик в инструментарии Agile. «Дашборд гибкости», основанный на таких показателях, как «количество команд, практикующих Agile» или «количество коммитов в мастер в течении часа», действительно может способствовать такому мышлению. Но реальность такова, что многие Agile-подходы не являются тривиальными и для своей реализации могут потребовать значительных затрат. Вместо этого Дашборд гибкости поставки сервиса может помочь направить разговор в другое русло.
Основное усилие, определяющее стратегию перехода на Agile, следует направить на глубокое понимание потребностей клиентов и на то, что делает сервис соответствующим их целям. Это, в свою очередь, может изменять стратегию «выхода на рынок», которая затем может быть использована для оценки степени соответствия текущих возможностей потребностям клиентов.
Хочешь развиваться системнее?
Выбери, что ближе тебе — и получи 🎁 подборку материалов от Neogenda.
Хочу научиться управлять целями и командой Хочу стать продуктивнее и эффективнее Хочу структурировать хаос и навести порядок в работе
Мы можем представить себе дашборд с этими «волшебными ползунками», которые управляют инструментами и процессом на месте и производят показания на циферблатах и диаграммах выше. Красные маркеры на рисунке показывают позицию, которая нам нужна на каждом слайдере для выполнения предполагаемой стратегии «выхода на рынок». Так мы можем увидеть, какая корректировка нам нужна по каждому аспекту, перемещая ползунки вверх или вниз и, таким образом, метафорически выбирая соответствующие Agile-подходы и практики для достижения желаемых результатов.
Дополнительная подсказка заключается в заштрихованных областях на циферблатах, которые дают некоторые рекомендации относительно методов, которые можно использовать для поддержки различных частот. Если пополнение заказов в настоящее время происходит, скажем, ежемесячно или ежеквартально, то организация может без последствий обойтись практикой «Масштабное проектирование прежде всего» (Big Design Up Front — BDUF). Для частоты пополнения около отметки «еженедельно» может быть достаточно внедрения общей Agile-практики еженедельного (или двухнедельного) планирования спринта. Но если этот показатель становится «ежедневным» и приближается к «ежечасному», то потребуются более агрессивные методы планирования и пополнения «точно в срок» («Just In Time»). Аналогично и для завершения цикла: когда релизы происходят ежемесячно или реже, то можно поддерживать эту скорость без Непрерывной Интеграции (Continuous Integration — CI); более частые циклы поставки сделают CI/CD необходимостью.

Построение дашборда

Учитывая его клиентоориентированный характер, первым вопросом, который нужно задать, чтобы начать создавать дашборд — «Кто ваш клиент?». А затем «Что вы ему предоставляете?». С этой информацией мы можем обратиться к нашей системе учёта и получить информацию об этих рабочих элементах, чтобы помочь нам определить Сроки выполнения, Частоту Пополнения и Частоту Выпуска.
Недавно, проводя такой анализ для одного из моих клиентов, я обнаружил, что единицей обязательств перед их заказчиками был «Проект» (набор функциональных возможностей, объединённых вместе), но единицей разработки и выпуска была «Этап» (часть проекта, обычно означающая логичные суб-наборы возможностей). Обязательства принимались примерно раз в год для совпадения с началом фискального года, что привело к «ежегодной периодичности пополнения» для этого вида работ. Этап, как правило, имеют срок выполнения от 3 до 9 месяцев, но, запуская несколько из них параллельно, организация может поддерживать частоту в 1 релиз каждые 1−2 месяца.
Жюри все еще не определилось, подходит ли все это для клиентов этой организации: достаточно ли брать новую работу один раз в год? Нормально ли для бизнеса ждать от 3 до 9 месяцев, чтобы получить часть этого обещания? Достаточно ли для них, чтобы новая функциональность была доступна им примерно каждый месяц?
Тем не менее, такой разговор в терминах этих трёх показателей, безусловно, более продуктивен, чем попытка получить такое же понимание, проанализировав количество Agile-команд, отсортированных по охвату кода и сгруппированных по количеству сбоев сборки в неделю.
]]> Что мы знаем о продолжительности: рабочие процессы. Часть 2 http://neogenda.ru/blog/6r9mgnm8t1-chto-mi-znaem-o-prodolzhitelnosti-raboch http://neogenda.ru/blog/6r9mgnm8t1-chto-mi-znaem-o-prodolzhitelnosti-raboch?amp=true Mon, 19 Feb 2024 19:49:00 +0300 Артур Нек Перевод статьи Дэвида Андерсона, размещённой на djaa.com. Оригинал можно прочитать здесь. Читайте 1-ю часть этой серии статей по ссылке....

Что мы знаем о продолжительности: рабочие процессы. Часть 2

Перевод статьи Дэвида Андерсона, размещённой на djaa.com.
Оригинал можно прочитать здесь.
Читайте 1-ю часть этой серии статей по ссылке.
Взгляд со стороны: недавно я посетил пятидневный курс «Реальные риски» с Нассимом Талебом. Говоря о науке в целом и управлении рисками в частности, Талеб сказал, что не существует принципа «давайте предположим». Я намерен включить это заявление во все записи в блогах, связанные с управлением рисками, прогнозированием, планированием и так далее. Каждый раз, когда вы видите, что мне приходится использовать фразу «давайте предположим», чтобы защитить или отстаивать существующий метод, который я считаю ошибочным, мы переходим в область фантастики. Не существует принципа «давайте предположим».
Использование стоимости задержки для определения приоритетов или выстраивания последовательности работ становится все более популярным в сообществе Agile. Есть несколько авторов, которые популяризуют несколько схожие количественные, математические подходы к ранжированию запросов для определения приоритетов или упорядочивания серии конкурирующих запросов. Дональд Рейнертсен популяризует использование техники теории очередей, известной как WSJF (Weighted Shortest Job First — взвешенная продолжительность самой короткой задачи), а Джошуа Арнольд пропагандирует более простую, по его мнению, производную CD3 (Cost of Delay Divided By Duration — стоимость задержки, поделенная на продолжительность). Некоторые другие авторы используют производные от этих двух идей и часто, что сбивает с толку, называют их одинаково, даже несмотря на то, что они изменили параметры в уравнениях. И WSJF, и CD3 используют «продолжительность» в качестве знаменателя, и я показал то, что мы знаем о продолжительности, для различных аспектов запросов на интеллектуальную работу. В первой части рассматривались индивидуальные активности, а во второй — запрос клиента, который проходит через серию активностей по добавлению информации или знаний в рабочий процесс предоставления услуг.
Канбан-сообщество с момента появления в 2007 году измеряет, сообщает, изучает и действует на основании информации о продолжительности. У нас были данные об индивидуальных активностях и продолжительности рабочих процессов в первой Канбан-системе в Microsoft в 2004 году. В Канбан-сообществе продолжительностью обычно называют время выполнения заказа. Оно недвусмысленно определяется как время от взятия обязательства принять, выполнить и поставить запрос клиента, и до момента фактического получения этим клиентом. Имея опыт и данные за десятилетие, мы многое узнали о продолжительности.
На Рис. 1 показаны типичная доска и Канбан-система. На доске есть несколько буферов и состояний ожидания. Важно понимать, что буферы или состояния ожидания не являются очередями и обычно не имеют определенной дисциплины очередей. Точнее, эти буферы и состояния ожидания больше похожи на то, что инженеры-промышленники называют «супермаркетами», я считаю более полезным думать о них как о «конкурсах красоты». Элемент будет выбран из состояния ожидания или буфера, если есть доступные рабочие с правильными навыками и если профиль риска элемента таков, что это лучший выбор с учетом набора доступных вариантов. Иногда вариант может быть только один. В других случаях этот единственный вариант зависнет в ожидании, потому что у свободных рабочих нет необходимой квалификации. Ключевой урок состоит в том, чтобы признать, что время ожидания или задержка в буфере или состоянии ожидания не могут быть определены заранее, они полностью произвольные и, следовательно, недетерминированные по своей природе.
Следующее, что нужно понять, — насколько большая задержка на самом деле типична для профессиональных услуг, интеллектуальной работы, рабочего процесса. Отношение общей продолжительности ко времени, потраченному на ожидание, называется эффективностью потока. На Рис. 2 показано, как рассчитывается эффективность потока. В лучших тематических исследованиях, о которых сообщалось в Канбан-сообществе, эффективность потока достигает более 40%. В самой первой Канбан-системе в 2004 году она начиналась с 8%. Оказывается, 8% — это высокое начальное значение, были сообщения и об 1−2%. Обычно мы ожидаем, что эффективность потока будет в диапазоне 1−25%, причем, в большинстве случаев, это будет нижняя граница вышеуказанного диапазона. Поэтому есть важное следствие: для продолжительности рабочего элемента от 75 до 99% времени составляет время ожидания, а ожидание полностью недетерминировано по своей природе.
Остальные 1−25% рассматриваются в первой статье этой серии «Что мы знаем о продолжительности: индивидуальные активности». Вывод этой предыдущей статьи состоит в том, что продолжительность отдельной задачи может варьироваться в пределах 200 раз от минимума до максимума, она не детерминирована по своей природе. Теперь мы знаем, что эта недетерминированная продолжительность задачи составляет от одной сотой до одной четверти общей продолжительности. Таким образом, у нас есть полностью недетерминированное время задержки, которое составляет 75−99% от общей продолжительности, и сумма длительностей задач, которые могут меняться по масштабу на 2 порядка, и составляют остаток. Давайте предположим, что мы считаем, что можем определять размеры элементов и что их размер и сложность действительно коррелируют с продолжительностью отдельной задачи, тогда у нас все еще есть проблема с недетерминированностью буферов и состояний ожидания, которые определяют фактическую продолжительность рабочего процесса. Даже если бы мы могли точно сказать «эта пользовательская история займет 4 дня», вполне вероятно, что общая продолжительность составит от 16 до 400 дней. Представьте, что мы сравниваем этот элемент с другим, выполнение которого, по нашему мнению, займет всего 2 дня. Наш детерминистский анализ, без сомнения, предполагает, что задание 2 будет выполнено раньше задания 1. Однако реальность недетеминированных состояний буфера и ожидания означает, что вероятность того, что второй элемент (выполнение которого мы оценили как половину времени по сравнению с первым) на самом деле будет выполняться дольше, близка к 50%. Помимо того, что вероятность более продолжительного выполнения близка к 50%, существует вероятность того, что выполнение может занять в пределах 100 раз больше времени.
В управлении рисками 50-процентная вероятность того, что потребуется больше времени, известна как «вероятность x», в то время как фактическое большее количество времени известно как «функция от x или f (x)». В управлении рисками нам нужно больше беспокоиться о f (x) — или воздействии — чем о вероятности. Если бы мы использовали наши значения за 4 дня в сравнении с 2 днями в уравнении приоритизации для принятия решений о выстраивании последовательности, существует почти 50% вероятность того, что мы примем неправильное решение с точки зрения выстраивания последовательности, и влияние неправильного решения может быть существенным. Учитывая, что эти два элемента существуют не в вакууме, сложность проблемы резко возрастает, если мы рассмотрим значительное количество других альтернатив, с которыми мы будем их сравнивать. Достаточно всего лишь нескольких элементов сравнения, и мы достигнем точки, в которой вероятность правильного выстраивания последовательности из них на основе продолжительности стремительно приближается к нулю. И, конечно же, весь этот анализ включал в себя «давайте предположим», что мы действительно можем правильно определить продолжительность отдельной задачи. Но это предположение является ложным, как мы знаем из первой части этой серии статей.
Рис. 3, 4 и 5 были предоставлены Рамешем Патилом, техническим директором Digite, и взяты из аналитики данных реальной разработки функционала программного обеспечения в продукте SwiftKanban.
На Рис. 3 показано количество баллов за историю в эпике по сравнению с фактическим записанным рабочим временем для таких действий, как разработка. Если бы существовала корреляция между размером эпика, состоящей из агрегированного набора пользовательских историй индивидуального размера, мы бы увидели кластер точек в виде примерно линейной диагональной линии от начала координат к правому верхнему углу графика. Мы этого не видим, и разброс точек говорит о том, что корреляции нет.
На Рис. 4 термин «время цикла» фактически отражает время выполнения заказа или продолжительность от момента принятия до готовности к предоставлению. В этом примере мы наносим баллы за историю для эпика, агрегированных из набора историй индивидуального размера, в сравнении с фактической продолжительностью, необходимой для завершения заказа. Если бы была корреляция, мы бы увидели кластеризацию точек на примерно прямой линии от исходной точки до правого верхнего угла графика. Мы этого не видим и, как следствие, можем сделать вывод, что количество баллов за историю не коррелирует с продолжительностью и не может использоваться для расчета стоимости задержки с использованием уравнений WSJF или CD3.
На Рис. 5 показан график общей продолжительности или времени выполнения заказа в зависимости от времени ожидания заявки. На этом графике мы видим некоторую корреляцию. Это строго определенный линейный график точек, поднимающихся по диагонали от начала координат к верхнему правому углу. Мы также видим несколько точек на оси X. У них высокая эффективность потока. Это типично для элементов обслуживания «ускоренного» класса. Промежуточные позиции в нижней правой половине графика под диагональю предполагают элементы с более высокой эффективностью потока, возможно, получающие более высокий класс обслуживания, это могут быть элементы с какой-то фиксированной датой предоставления. Но с учетом характера разработки продукта, они, скорее, являются дефектами при более высоком классе обслуживания, направленном на устранение блокировками основной разработки.
В верхнем левом углу диаграммы почти нет точек, потому что мы не ожидаем увидеть какие-либо точки, где общая продолжительность была меньшей, чем время ожидания. Несколько точек, сгруппированных вокруг оси Y, могут быть шумом в наборе данных или потребовать дальнейшего исследования.
Из Рис. 5 видно, что самый лучший способ повлиять на продолжительность — это, по сути, использование классов обслуживания. Предоставляя элементу более высокий класс обслуживания, мы фактически делаем его более «красивым», чем другие заявки. Ему отдается предпочтение при принятии решений о выборе. Как следствие, он тратит намного меньше времени на ожидание, а время выполнения заказа резко сокращается. Для действительно ускоренной заявки продолжительность будет выглядеть как продолжительность отдельной задачи, как показано в первой части этой серии статей, или как сумма продолжительностей нескольких отдельных задач.

Время выполнения (или продолжительность) распределено по закону Вейбулла

На Рис. 6 показаны сводные кривые распределения для сроков выполнения заказа. Они соответствуют распределению Вейбулла с различными значениями параметра формы.
Как описано в первой части этой серии, индивидуальные действия, когда они не были упреждены, будут иметь форму, близкую к гауссовой, с кривой Вейбулла с параметром формы каппа, k, лежащим в диапазоне 2,0 < k < 4,0. Однако, учитывая, что упреждение все же происходит и возникает некоторая задержка, а также учитывая, что конкретный элемент определенного типа может по-прежнему иметь размер и сложность, которые варьируются на два порядка, вполне вероятно, что мы увидим продолжительность задач с кривой распределения, имеющей параметр формы в диапазоне 1,5 < k < 2,0. В некоторых доступных нам наборах данных, например данных о деятельности по разработке из первой Канбан-системы в Microsoft в 2004 году, параметр формы чуть больше, чем k = 2,0, но для тестирования он ближе к k = 1,7. Это говорит о том, что тестировщиков опережали или задерживали чаще, чем разработчиков.
Для рабочих процессов, в которых мы используем Канбан, ограничивая незавершенную работу, упреждение в действиях, доступные варианты в состояниях ожидания и буферах и, следовательно, повышая эффективность потока до диапазона 25−40%, мы обычно видим кривые распределения времени выполнения заказа с параметром формы 1,0 < k < 2,0 и обычно в диапазоне 1,3 < k < 1,6.
Если мы движемся к пре-канбану, неограниченному количеству незавершенных работ и отсутствию внимания к устранению задержки, отсутствию предотвращения или смягчения проблем с блокировками, мы постепенно наблюдаем, что параметр формы уменьшается до значения k = 1,0 (экспоненциальная функция), а затем и ниже его. Мы называем это «левым формированием» или «правым перекосом» распределения, поскольку хвост все длиннее и длиннее тянется к правой стороне. Более длинный хвост означает, что у нас все меньше и меньше предсказуемости и все больше и больше влияние задержки. Возможно, существует лишь небольшой процент элементов, которые откладываются на более длительные периоды, малая вероятность x, но продолжительность задержки, влияние f (x) значительно. Именно здесь возникают проблемы, особенно в организациях с более низкой зрелостью, которые паникуют при стрессе. Значения параметра формы k ниже 1,0 соответствуют ситуациям с высоким риском и большой вероятностью нежелательных результатов. Мы связали распределения с длинным и толстым хвостом с k < 1,0 с ИТ-работами, ИТ-услугами и разработкой программного обеспечения с очень низким уровнем зрелости. Опубликованы наборы данных в диапазоне k ~ 0,75.
Андреас Бартель из Гамбурга опубликовал эти данные о времени (продолжительности) поставки ИТ-услуг в Twitter в начале марта. Мода в этих данных составляет менее 1 дня, медиана — 6 дней, среднее арифметическое — 9 дней, а хвостовая часть в наборе данных составляет 77 дней, или примерно в 100 раз больше, чем мода. Для этого набора данных параметр формы Вейбулла принимает значение k ~ 0,8.

Моделирование наборов данных о времени выполнения

В сообществе развиваются две школы. Одна школа, возглавляемая такими светилами, как Трой Магеннис, Ларри Максерон и Рамеш Патил, считает, что нет смысла пытаться построить кривые распределения «наилучшего соответствия». Вместо этого они предпочитают стиль статистического моделирования и симуляции, известный как «бутстрэппинг», где они используют только точки из набора исторических данных и игнорируют пробелы. Другая школа считает, что для истинного моделирования Монте-Карло нужны параметрические модели. По сути, аргумент — это ошибка модели против ошибки прогноза. Учитывая, что любой из подходов дает прогнозы, которые намного превосходят другие существующие методы для гибкой разработки программного обеспечения, это, в некотором роде, эзотерическая точка, она в значительной степени находится на «переднем крае Канбанленда» с точки зрения экспериментирования и разрешающей способности.
На Рис. 8 показано распределение времени выполнения для разработки программного обеспечения и тестирования функциональности архитектуры среднего уровня телекоммуникационного узла. Это распределение было зафиксировано у одного из моих клиентов и извлечено из программы отслеживания Jira летом 2014 года.
Набор данных достаточно хорошо соответствует распределению Вейбулла с параметром формы k ~ 1,4 и параметром масштаба 61. Однако есть и некоторые отдаленные точки данных. Хвост длиннее и толще, чем можно было бы смоделировать по кривой Вейбулла. Это типично для многих реальных наборов данных.
На Рис. 9 показана модель, аналогичная реальным данным на Рис. 8. Ее можно смоделировать с помощью двух кривых Вейбулла: одной с тонким хвостом с формой k > 1,0, а другой с более толстым хвостом с формой k < 1,0. Имея лишь две кривые, мы получаем параметрическую модель, которая довольно точно моделирует реальный набор данных. Эту агрегированную параметрическую модель или кривую распределения можно использовать в моделировании Монте-Карло для прогнозирования результата для большего набора элементов, проходящих через один и тот же рабочий процесс обслуживания, или для установления ожидаемых уровней обслуживания или соглашений о предоставлении услуг.

Выводы

Что мы знаем о продолжительности:
  1. Продолжительность (или время выполнения заказа) соответствует кривым распределения Вейбулла, но с более длинными и толстыми хвостами. Обычно для адекватного моделирования реального набора данных необходимо сопоставить две кривые.
  2. Кривая распределения времени упреждения обычно демонстрирует разброс вариаций между модой и хвостом в 4−200 раз. Разброс отклонения от наименьшего до наибольшего значения может находиться в диапазоне от 50 до 200 раз.
  3. Сроки выполнения полностью недетерминированы
  4. Наибольшее влияние на время выполнения заказа можно достичь за счет сокращения времени ожидания.
  5. Лучший способ положительно повлиять (сократить) время выполнения заказа — это использовать классы обслуживания, которые сокращают время, затрачиваемое на состояния ожидания и буферы.
  6. Ограничение количества незавершенных работ с помощью Канбан-системы имеет драматический положительный эффект (сокращение) для времени выполнения заказа, поскольку сокращает выбор состояний ожидания и буферов и увеличивает вероятность того, что элемент будет выбран для следующего действия.
  7. Параметры формы кривой Вейбулла для сроков выполнения заказа в рабочих процессах предоставления услуг варьируются в диапазоне 0,5 < k < 2,5 в наблюдаемых наборах данных из реального мира.
  8. Различия в размере или сложности для элементов одного типа не коррелируют со временем выполнения заказа (продолжительностью).
  9. Класс обслуживания для элементов одного типа действительно коррелирует со временем выполнения заказа, так как эффективность потока значительно повышается.
  10. Ускоренный класс элементов обслуживания для элементов того же типа будет демонстрировать распределение времени выполнения заказа с параметром формы Вейбулла k в диапазоне около 2,0.
  11. Эффективность потока редко превышает 40%. Обычно эффективность потока без использования Канбан-системы и улучшения процесса, направленного на уменьшение задержки и устранение проблем с блокировкой, обычно составляет менее 10%, а иногда всего 1%. Как следствие, размер или сложность элемента очень мало влияют на его продолжительность.
  12. Состояния ожидания и буферы в профессиональных сервисах, рабочие процессы со знаниями не являются очередями и редко имеют какую-либо дисциплину очереди, если это явно не указано в определении класса обслуживания. Как следствие, время ожидания полностью недетерминировано.
  13. Поскольку эффективность потока низкая, а время ожидания полностью недетерминировано, для элементов данного типа невозможно определить их продолжительность более точно, чем границы кривой распределения времени выполнения заказа.
В качестве общего вывода, если мы имеем дело с элементами одного и того же типа, например, пользовательскими историями по сравнению с другими пользовательскими историями, с явным намерением использования продолжительности для помощи в выстраивании последовательности работ с использованием уравнения стоимости задержки, такого как WSJF, мы не можем заранее определить или отличить продолжительность одной пользовательской истории от другой. То же самое верно и для рабочих элементов разного масштаба, таких как эпики, совокупный набор связанных пользовательских историй. Мы не можем определить продолжительность одного эпика по сравнению с другой.
В масштабе проекта — как минимум на 2 порядка большего, чем отдельная пользовательская история — мы можем смоделировать продолжительность проекта, учитывая известный определенный, детерминированный объем пользовательских историй, используя моделирование Монте-Карло. Это будет темой следующей публикации из серии про стоимость задержки.
]]> Визуализация работы: если вы её не видите, вы не можете управлять ею http://neogenda.ru/blog/i5zb0nel71-vizualizatsiya-raboti-esli-vi-eyo-ne-vid http://neogenda.ru/blog/i5zb0nel71-vizualizatsiya-raboti-esli-vi-eyo-ne-vid?amp=true Tue, 20 Feb 2024 20:07:00 +0300 Алексей Пименов Перевод статьи Fernando Cuenca, размещённой на squirrelnorth.com. Оригинал можно прочитать здесь. Вы когда-нибудь были на таком стендап-митинге? Тогда...

Визуализация работы: если вы её не видите, вы не можете управлять ею

Перевод статьи Fernando Cuenca, размещённой на squirrelnorth.com. Оригинал можно прочитать здесь. Вы когда-нибудь были на таком стендап-митинге?
Тогда вы могли заметить закономерность: люди по очереди усердно информируют друг друга о том, чем они занимались в течение предыдущего дня, а в завершении делают ремарку о том, что у них «блокеров нет». Звучит так, что препятствий почти нет, и работа движется.
Это неплохое мероприятие, на котором вам нужно присутствовать. С точки зрения клиентов этой команды, одной из действительно важных вещей является поток ценности: от точки принятия обязательства, до точки, когда обязательство выполнено и их потребности удовлетворены. Однако, странно то, что в той же среде наиболее распространённым источником недовольств Клиентов, является недостаточно быстрое и частое получение ценности, что явно противоречит утверждению «блокеров нет».
Я не верю, что эти команды лгут или намеренно вводят в заблуждение. Напротив. Скорее всего, они проводят стендап-митинг перед доской, похожей на эту, которая показывает, что они действительно очень заняты и двигаются вперёд.

Блокеры для работы, а не для людей

Это может помочь осознать, что заблокированными редко бывают именно люди. Если мы не можем работать над чем-то, то обычно есть много другой работы, которую мы можем сделать, либо переключившись на другую задачу, либо начав новую. Когда мы делаем так, конечно, основная работа ждёт.
Работа блокируется. На самом деле, поток может легко остановиться из-за внешних зависимостей, а также от того, как мы его обслуживаем, или из-за многих других причин. Но зачастую это трудно понять, учитывая «невидимый» характер интеллектуальной работы, основанной на знаниях.
И в этом заключается проблема — работа не течёт, но доска, которую команда использует во время стендап-митингов, не показывает этого. Поскольку у нас есть склонность сосредотачиваться на том, что мы можем видеть (т.е. на людях), то нам легче будет сосредоточиться на своей занятости, а не на управлении потоком работы. Доски с тремя колонками и кучей стикеров просто недостаточно.
Эта проблема, конечно, не специфична для ежедневных стендап-митингов. Но она будет проявляться в любой ситуации, когда мы пытаемся осмыслить нашу работу и принять решения по управлению ею таким образом, чтобы она дошла до Заказчиков как можно скорее.
Мы сможем преодолеть эту проблему, если воспользуемся нашими механизмами визуализации, чтобы помочь нам увидеть невидимое. В этой серии статей я рассмотрю различные способы, с помощью которых мы можем это сделать, и таким образом создать контекст, в котором поток работы может более эффективно управляться командой, работающей над ним.
Однако, прежде чем двигаться дальше, я хотел бы выделить некоторые общие принципы:
Вам может не нравиться то, что вы видите, но признание вашей текущей реальности — это первый шаг к её пониманию, а затем и принятию осознанного прагматичного решения о том, что нужно изменить.
Посмотрите со стороны, наблюдайте, задавайте вопросы.
Причина, по которой мы визуализируем работу, в том, что визуализация даёт возможность отойти в сторону, внимательно рассмотреть работу, сделать наблюдения, прийти к некоторым выводам, а затем принять решения.
Подумайте, на какие повторяющиеся вопросы вам нужны ответы (над чем мы работаем? Кто над чем работает? Где сейчас застряла работа? и т. д.) и создайте свою доску, чтобы сформулировать все ответы. Но будут и специальные вопросы. С этим также может помочь ваша доска. Либо вы можете адаптировать её так, чтобы она помогала вам искать ответы или пути решения.
Слушайте свою доску.
Одно из самых распространённых возражений, которые я слышу от людей, когда я предлагаю визуализировать их работу с помощью стикеров: «Нам понадобится много стикеров, мы заклеим всю стену!» По сути, это доска подсказывает вам: «У вас много незавершенной работы (WIP)» или «вы взяли на себя много обязательств, которые ждут выполнения».
Ваша доска будет вам кое-что рассказывать. Иногда неприятные вещи. Прислушайтесь к своей доске (и научите свою команду прислушиваться к ней), а затем предпринимайте какие-то действия.
]]> Пошаговый план постановки целей в стартапе с помощью метода OKR http://neogenda.ru/blog/idshn8r3t1-poshagovii-plan-postanovki-tselei-v-star http://neogenda.ru/blog/idshn8r3t1-poshagovii-plan-postanovki-tselei-v-star?amp=true Thu, 22 Feb 2024 20:11:00 +0300 Андрей Сидоренко В статье разберем план постановки целей в стартапе, благодаря которому вы сможете держать фокус команды...

Пошаговый план постановки целей в стартапе с помощью метода OKR

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

Как поставить цели?

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

Распространенные проблемы на ранних стадиях, которые важно решить:

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

Когда нужно ставить цели в стартапе?

Так вы заранее синхронизируете участников ваших процессов и будете понимать ожидаемый результат. Нужда в системном целеполагании возникает, когда:
  • Энтузиазм уходит и начинают возникать конфликты.
  • Весь фокус на сотрудниках, а не на росте компании.
  • С ростом команды на координацию сотрудников уходит много времени.
  • Хочется, чтобы участники сами договаривались между собой.
  • Мы хотим ставить цели в формате OKR — objectives and key results, который применяется в Google, Tinkoff, Avito и других компаниях.
Если команда стартапа насчитывает до 30 сотрудников, то стоит сразу провести общую сессию постановки целей.
Не все участники сессии внесут вклад в постановку целей. Но все равно лучше позвать — пусть будут в курсе, зачем вообще компания существует.

Шаг 2. Определение формата встречи

Офлайн — лучший формат встречи для активного участия присутствующих в постановке целей и мощного мотивационного заряда. Заранее запланируйте встречу на полный день.
Если у вас удаленная команда, то стоит учитывать специфику дистанционных встреч. Разбейте встречу на 2 дня по 4 часа, иначе к концу однодневной 8 часовой встречи сотрудники будут сильно уставшими. Добавьте интерактивности, используя miro и похожие инструменты.

Шаг 3. Определение приоритетных направлений

Вариант №1. Простой
Business Model Canvas — один из простейших инструментов для генерации идей по приоритетным направлениям, в том числе с участием команды. После заполнения схемы проголосуйте командой за наиболее важное.
Вариант №2. Еще проще!
Подробно ответьте на следующие вопросы:
  • За что клиент скажет нам «спасибо»? Какая реальная ценность для клиента?
  • Как будем выходить в ноль и зарабатывать первый миллион?
  • Какую проблему нужно решить в первую очередь? ( Составьте список проблем в порядке приоритета).

Шаг 4. Формирование целей (Objectives)

Многие руководители усложняют менеджмент и формируют objective путем сложных преобразований из приоритетных направлений. Возьмите за правило упрощать!
Если вам необходимо решить вопрос «Как выйти в ноль и не сгореть через 3 месяца?», то пусть цель такой и будет. Цель должна быть ясна и мотивировать вас и команду.

Шаг 5. Определение ключевых результатов (Key Results)

Максимально подробно определите цель и добавьте ограничения, чтобы не усложнять себе путь достижения результата.
Пример: Как выйти в ноль и не сгореть через 3 месяца?
1) «Выйти в ноль» — это про доходы и расходы. Можно использовать переменные: KR1 — достигнуть дохода Х, KR2 — удержать расходы на уровне Y
2) «Не сгореть через 3 месяца«. Сгореть сотрудники могут, если, например, работать днями и ночами. В этом случае KR может быть следующим: KR3 — не более Х ночных смен для всей команды в следующие 3 месяца.

Шаг 6. Написание дорожной карты

Часто после постановки целей команда продолжает работать по прежнему шаблону. Чтобы этого не произошло, обязательно сделайте дорожную карту достижения целей.
Устройте брейншторм. Возьмите KR и сформулируйте задачи, которые могут на него повлиять.
Критерии задач:
  • Не создавайте громоздких задач. Лучше успеть сделать больше мелких и средних, так как не каждая задача даст желаемый результат.
  • Каждая задача должна быть понятной и влиять на 1-2 ключевых результата.
  • Назначьте ответственного на каждую задачу после составления дорожной карты.

Простой пример постановки задач в стартапе

Имеем: Стартап-сервис для продвижения акций с командой из 30 энтузиастов
Проблема: Множество мнений среди сотрудников на тему точек роста компании. Клиенты уже были, но не можем масштабироваться.
Решение: Команда сформировала понятную и мотивирующую цель — «Масштабировать финтех клиентов», после чего подобрала ключевые результаты.
Изменения: Продуктовая команда сделала User story под финтех сегмент, продажники точно определили ЦА продукта и запустили продвижение, а поддержка сервиса стала решать новые кейсы. У команды появился четкий фокус на ключевых результатах и полная синхронизация по задачам.
Результат: Стартап научился работать в сегменте финтех и хорошо зарабатывать.
Статья написана по мотивам интервью Павла Стоянова (Product Manager из Тинькофф) с Артуром Неком.
]]> OKR и KPI – в чем разница и как совместить внутри компании? http://neogenda.ru/blog/xmv799i4r1-okr-i-kpi-v-chem-raznitsa-i-kak-sovmesti http://neogenda.ru/blog/xmv799i4r1-okr-i-kpi-v-chem-raznitsa-i-kak-sovmesti?amp=true Fri, 23 Feb 2024 20:29:00 +0300 Андрей Сидоренко Привет, друзья! Чем KPI отличается OKR? А если у нас уже есть KPI, подойдет ли...

OKR и KPI – в чем разница и как совместить внутри компании?

Привет, друзья!
Чем KPI отличается OKR? А если у нас уже есть KPI, подойдет ли нам OKR? Как их совместить? Эти очень похожие вопросы входят в ТОП самых задаваемых на наших тренингах и сессиях по планированию OKR.
В этой короткой статье мы на них ответим.
Прежде, чем начать, Давайте договоримся, что KPI мы обсуждаем только в контексте показателей эффективности, не связывая его с премированием, оплатой труда и т.п..
Итак, поехали.

Разберем пример

Цель:
«Заработать в три раза больше денег в этом году»
KR 1 – Кол-во клиентов +30% к прошлому году
KR 2 – Cредний чек +30% к прошлому году
KR 3 – CSI не ниже X%
Такое мы часто видим в компаниях. Попробуйте сначала взглянуть и пару минут подумать, что же здесь не так.
Видно, что компания хочет заработать денег, при этом ставит значения, превышающие их трендовые показатели год к году. При этом, совершенно не факт, что компания понимает, как будет это делать. В случае, если не получится, такой OKR позволит конце года сказать, что цель была слишком амбициозной, поэтому не получилось. В особо тяжелых случаях, это позволит сказать, что OKR совсем не работает, давайте жить по-старому.
Это называется «постановка OKR на основании текущих KPI». Как правило, это абсолютно не рабочая связка, которая ни коим образом не отвечает на вопрос: «Что нужно сделать и не помогает найти точку роста». Так делать не стоит. Давайте разбираться, как сделать лучше?

Что такое OKR и что такое KPI?

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

Формулирование OKR на основе важного на данный момент KPI

Чтобы создать OKR на основе KPI, обычно определяется тот KPI, который требует особого внимания или влияния.
Например, мы хотим повысить удовлетворенность клиентов — CSI. Это метрика, которую мы измеряли и будем измерять. Мы можем понять, какие изменения с ней произошли. Однако, важна не сама метрика, а понимание того, почему сейчас результат не тот , который мы хотим. Нам необходимо определить область воздействия, которая даст максимальный результат на метрику. Обычно это делается при помощи исследований, опросов и т.д..
Допустим, мы понимаем, что клиенты недовольны большим количеством ручной работы на нашем сайте, каждый второй об этом говорит в опросах. Мы можем даже определить, какие именно области нашего сайта используются чаще и сфокусироваться на них.
Таким образом, может появиться следующая цель:
«Автоматизировать ключевые услуги на сайте».
Или что-то более вдохновляющее:
«Сделать клиента лояльнее за счет автоматизации».
Итак, определив KPI компании, который мы хотим изменить, мы получили основу для Objective компании, который понятен и указывает, что именно мы хотим сделать.

Использование KPI в качестве ключевых результатов.

Как только цель определена, нужно подобрать набор KR.
Напомню, что в качестве KR можно выбирать вехи, метрики (которые можно посчитать или поставить базисные значения), поставить конкретные действия, которые мы хотим совершить, чтобы добиться цели или результаты этих действий.
Какого-то запрета на то, чтобы взять в качестве ключевого результата конкретный KPI – нет. Более того, если у вас уже есть рабочий дашборд KPI, он послужит отличным ориентиром в метриках и поможет быстрее подобрать KR для вашей цели.
Давайте попробуем придумать KR для цели выше:
«Сделать клиента лояльнее за счет автоматизации».
Наша задача — определить KR, которые раскроют суть слов: «Лояльнее», «Автоматизации».
Начнем с результата, который мы ждем: Как мы поймем, что клиенты стали лояльнее? Показывает ли это наш CSI? Если да, то он вполне подходит в качестве KR.
Однако, стоит посмотреть, не нужно ли сузить выборку. Не будет ли привычный CSI слишком «грязным». Рекомендую уточнить методику расчета. Так же, мы можем попробовать исследовать саму суть ответов в опросах клиентов. Какие именно моменты в ручной работе им не нравятся. Например, приходится много раз отсылать запросы, много кликов, много времени или еще что-то. То, что упоминается чаще – может стать основой для KR.
Теперь про автоматизацию. Поскольку пример выдуманный, то и KR здесь будут скорее «с потолка», поэтому скажу проще. Это может быть, как веха, (например, автоматизация конкретного функционала), так и метрика – показывающая кол-во автоматических запросов по сравнению с ручными. В общем, здесь уже имеет значение сам контекст.

Как же все-таки живут KPI и OKR в компании.

Я думаю, вы вы уже поняли, что, хоть это и разные сущности, но они вполне уживаются в одной организации. Более того, совместив KPI и OKR, компания может обеспечить прямую связь между показателями эффективности и целями.
Это позволит использовать более основанный на данных подход к управлению целями, поскольку ключевые показатели эффективности дают ценную информацию о существующих процессах. Однако важно отметить, что OKR выходят за рамки KPI, фокусируясь на более широких результатах, в то время как KPI сигнализируют о производительности и эффективности процесса.
]]> OKR. Обзор книг по теме http://neogenda.ru/blog/dinnmf8vc1-okr-obzor-knig-po-teme http://neogenda.ru/blog/dinnmf8vc1-okr-obzor-knig-po-teme?amp=true Sat, 24 Feb 2024 21:35:00 +0300 Андрей Сидоренко Предисловие Привет, друзья! Если вы заинтересованы в том, чтобы глубже изучать OKR (Objectives and Key...

OKR. Обзор книг по теме

Предисловие

Привет, друзья!
Если вы заинтересованы в том, чтобы глубже изучать OKR (Objectives and Key Results) или только заинтересовались этой темой и вас вопрос — с чего начать, то эта статья для вас. Здесь вы найдете подборку книг с аннотациями от автора статьи и рекомендациями, что лучше читать в какой ситуации. Мы надеемся, что это поможет вам достичь замечательных результатов с помощью OKR.
Кратко об OKR.
OKR (Цели и ключевые результаты) — это эффективный фреймворк, используемый для постановки, выравнивания и достижения целей, которые призваны менять текущее состояние и достигать результата. Первоначально он был разработан Энди Гроувом, бывшим генеральным директором Intel, затем был популяризирован компанией Google и непосредственно Джоном Дорром. В последние годы такие успешные компании, как Amazon, Twitter, Netflix и другие, также достигали своих целей, используя OKR.
О краткой истории появления и популяризации OKR читайте в нашей предыдущей статье.
OKR – состоит из двух основных частей:
Цель:
Качественное изменение текущего состояния, то, чего мы хотим достичь. Ключевые результаты:
Вехи или метрики, которые призваны создать общее понимание образа цели. То, как мы поймем, что ее достигли и сможем понять динамику достижения.
Обычно это все, что рассказывают про OKR начинающим. И всем начинается казаться, что это очень просто. Однако, все кроется в деталях. Когда вы начнете использовать OKR у себя, то у вас возникнет множество вопросов: — как планировать и перепланировать — как совместить OKR и операционную деятельность — как делать выравнивание — как поставить мотивирующую цель и т.д.
Ниже я предлагаю список книг, который поможет вам понять, что такое OKR и обогатить свое понимание данного подхода.

Измеряй Самое важное. Джонн Дорр

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

Цели и ключевые результаты. Полное руководство по внедрению OKR.

Пол Нивен и Бен Ламорт.
Это практическое руководство содержит пошаговые инструкции, охватывающие все, от основ до продвинутых стратегий, которые помогут вам максимально эффективно использовать OKR.
Его авторами — известные консультанты и эксперты в OKR: Пол Нивен, автор нескольких бестселлеров по сбалансированной системе показателей, и Бен Ламорт, который успешно внедрил методологию в таких глобальных компаниях, как eBay, Sears, Zalando, Dun & Bradstreet и GoNoodle.
Руководство призвано служить всеобъемлющим ресурсом для организаций, стремящихся превратить качественные цели в поддающиеся количественной оценке результаты. В нем подчеркивается важность предоставления командам возможности сосредоточиться на достижении измеримого прогресса в достижении их наиболее важных целей.
От автора:
Рекомендую читать эту книгу тем, кто пошагово внедряет у себя OKR. Она дает ответы на очень много вопросов, которые у вас возникнут на этапе внедрения, от того, какой выбрать вариант внедрения до проведения различных сессий по постановке. Очень многое из того, что пишут авторы, откликается с Российской бизнес-средой и многое из этого вам действительно подойдет.
Подробнее о книге.

Toolbox. Daniela Kudernatsch

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

Start Less, Finish More — Dan Montgomery

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

Полевая книга OKR. Бен Ламорт

Это книга для коучей – тех, кто учит внедрению и применению OKR. В ней вы найдете всеобъемлющую структуру для управления пользователями на всех этапах процесса внедрения OKR, обеспечивая успех проекта.
От автора:
Рекомендую эта книгу опытным пользователям OKR, тем, кто хочет сделать всю систему эффективнее через эволюционное развитие.
Заключение
Безусловно, мы перечислили не всю литературу, которая существует об OKR и по мере появления качественных и проверенных статей и книг, мы будем дополнять данную статью.
]]> OKR в Intel и Google. Краткая история. http://neogenda.ru/blog/6mi56ffkn1-okr-v-intel-i-google-kratkaya-istoriya http://neogenda.ru/blog/6mi56ffkn1-okr-v-intel-i-google-kratkaya-istoriya?amp=true Sun, 25 Feb 2024 21:48:00 +0300 Андрей Сидоренко Предисловие В данной статье мы решили рассказать о некоторых фактам, которые относятся к появлению OKR....

OKR в Intel и Google. Краткая история.

Предисловие

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

Что предшествовало OKR

В 60-70-х годах в деловом мире широко использовалась модель MBO (Управление по целям), которая предполагала постановку конкретных целей и задач перед сотрудниками, а затем оценку их эффективности на основе того, насколько хорошо они достигают этих целей. Этот процесс использовали многие компании в деловом мире, и он считался эффективным способом повышения эффективности работы сотрудников и согласования индивидуальных целей с общей стратегией компании. Так было и в Intel

Intel

В какой-то момент в Intel обнаружили, что процесс MBO был слишком медленным и бюрократичным для их быстро развивающейся и конкурентоспособной отрасли. Процесс включал в себя постановку годовых целей, которые пересматривались раз в год, что затрудняло быстрое реагирование компании на изменения на рынке. Кроме того, MBO не очень хорошо подходил для динамичной и инновационной культуры Intel, которая ценила гибкость и маневренность. Энди Гроув — генеральный директор компании на тот момент признал, что компания нуждается в новом подходе и предложил изменения в текущую систему.
OKR (Цели и ключевые результаты) — это система постановки целей, которую он представил в 1978 году, как систему целеполагания для всей компании. Примерно так он говорил про OKR на своей презентации:
Цель — это направление:
«Мы хотим завоевать часть рынка среднеразмерных компьютеров».
Это цель — здесь и сейчас. То, куда мы хотим двигаться.
Ключевой результат:
«Победить с 10 новыми дизайнами для процессора 8085»
Это первая веха, которую мы можем достичь в ближайшем будущем. Ключевой результат должен быть измеримым, чтобы в какой-то момент мы могли оглянуться и точно сказать — сделали мы это или нет. Ни чуть-чуть, ни почти. Вот так просто. Обернуться назад и посмотреть, выпустили мы 10 новых дизайнов или нет.
Таким образом, есть два элемента системы, которые используются, как на уровне года, так и на уровне квартала. Годовые OKR формируются через годовое планирование, когда совместно собирается единый годовой план, а каждое подразделение формирует свой набор целей и ключевых результатов. А при следующем годовом планировании, мы увидим, какие получили результаты, сделаем выводы, посмотрим, что можно изменить и применим в следующем цикле. Гораздо более существенными являются квартальные планирования, когда подразделения выбирают цели и ключевые результаты на квартал. По его словам — это была «очень простая» система, которая уже использовалась в разных подразделениях Intel».

Что это дало

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

Google

Корпорации Google часто приписывают создание самого подхода. Это происходит из-за того, что компания сыграла огромную роль в популяризацию фреймворка и его широкое применение в технологической индустрии.
OKR был впервые представлен в Google Джоном Дорром — известным венчурным капиталистом, который узнал о фреймворке от Энди Гроува. Дорр полагал, что OKR может помочь Google согласовать свои амбициозные цели с четкими и измеримыми результатами. OKR был впервые опробован в Google в 1999 году, когда компания все еще была небольшим стартапом, и продолжал использоваться по мере того, как Google превратился в глобального технологического гиганта.
С помощью OKR, Google получил несколько преимуществ, которые помогли сделать качественный рывок вперед.Во-первых, получилось сформулировать и донести до общественности четкие и амбициозные цели, которые соответствовали миссии и видению компании. Это обеспечило основу для определения результатов и измерения прогресса, что способствовало связанности и прозрачности. Во-вторых OKR поспособствовал формированию культуры постоянного совершенствования, поскольку командам было предложено ставить перед собой амбициозные цели и извлекать уроки как из своих успехов, так и из неудач. И в-третьих OKR помог расставлять приоритеты в инициативах и эффективно распределять ресурсы, обеспечивая соответствие усилий стратегическим приоритетам.

Как OKR работал в Google

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

Примеры OKR в Google

На протяжении многих лет Google использовала OKR различными способами. Один из известных примеров «Упорядочить мировую информацию»: цель была поставлена на раннем этапе и помогла реализовать миссию компании — сделать информацию общедоступной и полезной.
Другим примером является цель: «Повышения удовлетворенности пользователей» с такими ключевыми результатами, как «Сокращение количества запросов в службу поддержки на 10%» «Увеличение коэффициента удержания пользователей на 15%». Это помогло компании сосредоточиться на улучшении пользовательского опыта своих продуктов и сервисов.
OKR также использовался для стимулирования инноваций с такими целями, как «Запуск прорывного продукта» или «Выход на новые рынки» с соответствующими ключевыми результатами.
Стоит отметить, что использование OKR в Google развивалось с течением времени, и конкретные детали того, как OKR реализован в Google, возможно, изменились с момента его первоначального внедрения. Однако, раннее внедрение OKR компанией Google и ее успех во внедрении фреймворка способствовали его широкой популярности и внедрению в других организациях по всему миру.

Дальнейшая популяризация

Внедрение Google OKR помогло еще больше популяризировать его среди других технологических компаний и стартапов. Успех Google и видимые результаты, достигнутые благодаря использованию OKR, вызвали широкий интерес к фреймворку, и в результате он начал набирать обороты в деловом мире.
Кроме того, Джон Дорр, сыграл значительную роль в популяризации OKR. Дорр, который был одним из первых инвесторов Google, представил OKR многим стартапам из своего портфолио, а также стал автором книги «Измеряй самое важное», в которой рассказывает о том, как OKR использовался в Intel и Google. Книга помогла распространить концепции и принципы OKR на более широкую аудиторию, сделав ее более доступной и популярной среди организаций различных размеров и отраслей.
«OKR создает среду для маневренности и динамичного планирования. Для Intel, Google, Facebook, Amazon, Microsoft это стало синонимом успеха.» (Дж. Дорр «Измеряй самое важное»)
]]> Как проверить качество OKR? Пошаговый чек-лист http://neogenda.ru/blog/lec1djg8u1-kak-proverit-kachestvo-okr-poshagovii-ch http://neogenda.ru/blog/lec1djg8u1-kak-proverit-kachestvo-okr-poshagovii-ch?amp=true Mon, 26 Feb 2024 21:55:00 +0300 Андрей Сидоренко Вы сформулировали OKR и теперь хотите проверить его качество? Мы собрали ключевые пункты, на которые...

Как проверить качество OKR? Пошаговый чек-лист

Вы сформулировали OKR и теперь хотите проверить его качество?

Мы собрали ключевые пункты, на которые нужно обратить внимание при составлении OKR.
PDF и JPEG в конце статьи!
Чек-лист проверки OKR

Цель

1. Важна для бизнеса и ведет к качественному изменению состояния
Цель — это результат. Не процесс. Цель отталкивается от текущих проблем, финансовых ожиданий стратегии и другого контекста вашего текущего состояния. Цель отражает качественное изменение этого состояния. Цель важна в ближайший период и является важнейшим приоритетом. Тогда она будет работать..
2. Цель попадает под один из трех типов
Исследование — когда мы понимаем, что нам необходимо открыть новую перспективную область. Например: «Определить ключевые клиентские сегменты», «Найти ТОП проблем оттока клиентов». Такие цели, как правило краткосрочны и быстро меняются на более конкретные
Достижимая на 100% — цель, основанная на конкретном проекте или решении, которое является самым важным. Когда мы понимаем прямую причинно-следственную связь.
Амбициозная, но выполнимая — такая цель вызывает здоровое волнение. Заставляет нас отойти от привычных способов работы и подумать над новыми решениями.
3. Формулировка раскрывает и подчеркивает суть того, что нужно сделать
По формулировке цели должно быть понятно, что нужно будет сделать. Формулировка — это прямое отражение сути цели.
Например, цель «Постепенно завоевываем новые рынки» — по сути понятна, но формулировка слишком туманная, есть риск потерять фокус. Если мы переформулируем такую цель и скажем: «Успешно выйти на рынок Китая», то суть останется прежней, но станет понятно, что нужно сделать. Такая формулировка отражает суть и достаточно конкретна.
Универсальный шаблон для формулирования цели выглядит следующим образом: «Что сделать? Как сделать? Куда приложить усилия?»
Что сделать — выйти на рынок
Как сделать — Успешно
Куда приложить усилия — Китай
4. Имеет описание с ответами на вопросы
Описание — это крайне важный атрибут, который позволяет не забыть, что имелось ввиду при постановке цели, а так же подготовить базу для презентации и обсуждения этой цели с другими участниками процесса. Для этого необходимо подготовить ответы на вопросы: Что имеется ввиду? Почему это важно? На основании чего цель именно такая? Кто оказывает основное влияние на цель?
5. Лаконичная
Проверьте, что цель состоит из одного предложения, не имеет деепричастных оборотов и большого количества запятых. Чем более лаконичная цель, тем она более понятна другим.

Ключевые результаты

1. Ключевые результаты напрямую связаны с целью
Ключевые результаты — это набор показателей. по которым мы понимаем, что цель достигнута. С их помощью мы отвечаем на вопрос: «Как мы поймем, что достигли цели». Так же, они показывают прогресс достижения.
2. Раскрывают суть туманных формулировок из цели
Ключевые результаты раскрывают суть всех туманных формулировок из цели, превращая их в цифры или в конкретные ожидания. Прилагательные, наречия и глаголы необходимо раскрыть, причем для одного наречия может быть более, чем один ключевой результат.
3. Выбран оптимальный вариант из типов KR и типов метрик
Набор ключевых результатов может содержать все типы KR и метрик и в зависимости от типа цели, баланс может быть разным, например:
Исследовательская цель будет состоять больше из KR в виде вех и действий (Input), Гипотеза — будет основываться на базисных значениях, действиях (Input), а Конкретные решения на Результатах (Output) и Ценности (Outcome). Подробнее о типах KR и метрик в нашем видео.
4. Для ключевых результатов описаны методики расчета
Это обязательный атрибут для создания ключевых результатов. Методики расчета должны быть доступны и прозрачны.
5. Есть понимание, кто будет влиять на каждый из ключевых результатов.
При формировании KR, нужно заранее подумать о том, кто будет осуществлять основное влияние на их достижение. Это может быть команда, подразделение, набор подразделений или конкретный человек в компании. Важно, что бы для каждого Ключевого результата были определены сущности. которые будут на них влиять.

OKR набор

1. Понятен.
По итогу, у участников процесса не должно остаться вопросов, почему OKR именно такой, как будут считаться метрики, как это все будет работать.
2. Определены владельцы OKR
Владелец или владельцы — это рабочая группа по организации достижения ц ели. Эти люди организуют процесс работы вокруг целей и ключевых результатов, чтобы обеспечить динамику достижения. Для каждого Objective или отдельных KR может быть один и более владелец цели.

Как пользоваться чек-листом?

Поскольку у каждой организации и команды свой контекст, нет четкого определения, сколько пунктов нужно отметить, чтобы сказать, является ваш OKR качественным, некачественным, хорошим или плохим. Мы рекомендуем вообще избегать бинарных и оценок и помнить, что важно не просто сформулировать что-нибудь, что будет соответствовать формату. Важна суть и изменения, которые дадут результат. Формулируя OKR, ответьте на вопрос: «Будет ли качественное изменение?», а подводя итоги, проверьте. произошло ли это изменение.
По ссылке вы можете скачать в формате PDF или JPEG.
Удачи в бизнесе.
]]> Действительно ли вы применяете Канбан Метод? http://neogenda.ru/blog/0rxhv0ygv1-deistvitelno-li-vi-primenyaete-kanban-me http://neogenda.ru/blog/0rxhv0ygv1-deistvitelno-li-vi-primenyaete-kanban-me?amp=true Mon, 26 Feb 2024 23:30:00 +0300 Алексей Пименов В 2014 году вышла статья Дэвида Андерсена, в которой он рассказывает про Лакмусовый тест применения...

Действительно ли вы применяете Канбан Метод?

В 2014 году вышла статья Дэвида Андерсена, в которой он рассказывает про Лакмусовый тест применения Канбана. Этот же тест описывается в книге Essential Kanban Condensed.
Он был создан для того, чтобы ответить на очень популярный вопрос: «Как понять, что наш Канбан реально работает?». Или, как часто говорю я: «Насколько наш Канбан действительно Канбан?».
В условиях глобального использования трекеров задач, таких как Kaiten или Jira, где сразу из коробки пользователям доступны канбан-доски или другой
«канбан-функционал», базовый вопрос можно трансформировать в: «Если мы используем Канбан-доску, выставляем WIP-лимиты в Jira — у нас Канбан?»
По сути, люди пытаются выяснить действительно ли они внедрили достаточное число практик Канбан Метода, чтобы изменить и стабилизировать свою проблемную ситуацию и запустить двигатель эволюционных изменений.
И начиная с ноября 2019 года навигатором в этих рассуждениях стала Модель организационной зрелости Канбан.
Но мне кажется, она является достаточно сложной для быстрого поиска ответа и еще более сложной для объяснения с ее помощью ответа другим людям, которые только погружаются в Канбан Метод или просто пытаются понять чем он может быть им полезен.
Вот здесь и пригождается Лакмусовый тест Канбан. Он специально был создан простым, но заставляющим глубоко задуматься о применении практик Канбан Метода в организации.

Канбан-система

Прежде чем перейти к самому тесту, давайте ответим на еще один популярный вопрос: «У нас канбан-система или нет?». На самом деле этот вопрос очень схож с первым, но стоит помнить, что Канбан Метод использует и создает канбан-системы для улучшения клиентского сервиса.
В первом приближении это очень простой вопрос для ответа. Если вы построили и управляете сквозным процессом поставки ценности клиенту, который связывает несколько внутренних подразделений, и используете
WIP-лимиты на каждом из его этапов, то первом приближении, вы используете канбан-систему. Если же нет, то канбан-системы у вас точно нет.
Полноценные канбан-системы — это вытягивающие системы, в которых спрос и возможности балансируют между собой. Настоящим источником спроса всегда является клиент, внешний человек или организация, по отношению к вашей, а не внутренний заказчик, например «бизнеса». И фактически, созданные вами системы могут оказаться прото-канбанами, которые объясняются уровнями
ML0−2 Модели организационной зрелости Канбан.
Это означает, что в полноценных канбан-системах, работа над клиентским запросом начинается только тогда, когда у организации есть на это возможность. Все запросы, над которым не ведется работа, это фактически реальные опционы (клиентские запросы, по которым организация еще не приняла обязательства и из которых она будет делать выбор), живущие в upstream (процесс работы с опционами) по своим правилам и процессам, а не просто статичный список того, что надо сделать. Канбан-система — это вытягивающая система с отложенными обязательствами.
Лакмусовый тест Канбана заставляет задуматься об этом. Он разрушает иллюзию «внедрения Канбана». Если вы не можете уверенно ответить хотя бы на один вопрос — вы неправильно применяете Канбан Метод или в лучшем случае используете прото-канбан.

Лакмусовый тест Канбан

Тест состоит всего их 4 вопросов, на которые вам предстоит честно ответить.
Изменился ли способ взаимодействия с клиентом?
После того, как вы начали применять Канбан Метод:
  • Изменился ли способ планирования?
  • Изменился ли способ приоритезации работ?
  • Появилось ли уважительное отношение между вами при выборе работы, исходя из ваших возможностей поставки?
Если нет, то вы почти наверняка не применяете корректно инструменты Канбан Метода.
Изменились ли соглашения с клиентом?
После того, как вы начали применять Канбан Метод:
  • Изменился ли способ ваших коммуникаций с клиентом?
  • Применяете ли соглашение об уровне сервиса основанный на вероятностном понимании времени производства?
  • Учитывает ли соглашение об уровне сервиса клиентские ожидания вашей организации?
  • Используете ли вы модели прогнозирования, основанные на статистическом анализе исторических данных, чтобы давать клиентское время поставки?
Если нет, то вы почти наверняка не применяете корректно инструменты Канбан Метода.
Изменилась ли бизнес модель вашего клиентского сервиса?
После того, как вы начали применять Канбан Метод:
  • Внедрили ли вы классы обслуживания, базирующиеся на понимании бизнес рисков по каждому из типов клиентских запросов?
  • Распределяете ли вы производственные возможности, чтобы хеджировать риски от разных источников запросов и различных типов запросов?
  • Вы учитываете стоимость задержки и их влияния при выборе клиентских запросов и управлении классами обслуживания?
  • Вы построили и управляете потоком работы через несколько внутренних подразделений, чтобы сбалансировать риски и вариативность в стиле haijunka?
  • Вы понимаете категории клиентских ожиданий и исследуете новые классы обслуживания?
Если нет, то вы вероятно ваша организация теряет много ценности и дальнейшее более глубокое применение инструментов Канбан Метода может дать больше возможностей для вашего бизнеса.
Изменил ли менеджмент свое поведение?
Этот вопрос явным образом обозначает, что Канбан Метод — это инструмент менеджмента. Полноценные вытягивающие системы с отложенными обязательствами на уровне организации не могут быть созданы и управляться без изменения поведения руководства.
Давайте скажем честно, что на самом деле, многие канбан-системы это проталкивающие (push) системы, где Канбан Метод помогает защититься от многозадачности, или системы созданные для локальных оптимизаций, а не всего процесса поставки ценности клиенту целиком. В подобных случаях очевидно, что менеджмент не изменил свое поведение.
Типичная реализация командного канбана (один из видов прото-канабанов) не может дать положительного ответа ни на один из первых трех вопросов. И четвертый вопрос лишь ярко подтверждает это.
Если менеджеры не изменили своего поведения, то маловероятно, что у вас настоящая вытягивающая система, и уж точно вы не применяете Канбан Метод.
Лакмусовый тест Канбан — это набор простых вопросов, на которые сложно отвечать.
Если вы не можете уверенно сказать «Да» на первый вопрос, то у вас впереди еще много работы. Но хорошие новости заключаются в том, что это значит, что у вашей организации впереди еще много ценности, которую она может получить, используя вытягивающие системы с отложенными обязательствами и управляя процессом работы с настоящими опционами.
]]> Встречи в OKR: OKR ретроспектива. Шаблон проведения http://neogenda.ru/blog/n9rsccrag1-vstrechi-v-okr-okr-retrospektiva-shablon http://neogenda.ru/blog/n9rsccrag1-vstrechi-v-okr-okr-retrospektiva-shablon?amp=true Tue, 27 Feb 2024 23:34:00 +0300 Андрей Сидоренко Ретроспективы уже давно плотно вошли в жизнь команд, которые хотят улучшать свою совместную работу над...

Встречи в OKR: OKR ретроспектива. Шаблон проведения

Ретроспективы уже давно плотно вошли в жизнь команд, которые хотят улучшать свою совместную работу над продуктом, процессом, взаимодействиями и другими аспектами работы, в которых могут наблюдаться проблемы.
OKR – это система, которая состоит не только из вариантов формулировок целей, но так же предполагает и события, которые должны стартовать, поддерживать и развивать эту систему. Именно для развития и подходит ретроспектива.
Есть ли какие-то особенности проведения ретроспективы в OKR?
Чтобы ответить на этот вопрос, давайте для начала попробуем понять, из каких основных элементов она состоит. Для этого, воспользуемся несложным шаблоном, который поможет собрать встречу.
При подготовке любой встречи всегда начинайте с цели. Тогда будет понятно, что должно быть на выходе, на входе, какие шаги нужно пройти на самой встрече и кто в ней должен участвовать.
Цель OKR ретроспективы: Спланировать список действий, которые помогут сделать текущий процесс целеполагания еще лучше.
Исходя из цели, мы можем понять, что должно быть на Выходе с такой встречи: список действий, договоренностей, которые помогут сделать процесс целеполагания лучше.
Входные данные: все, что может помочь выявить текущие проблемы и обсудить их, а именно: наблюдения с Check-In (встречи по отслеживанию прогресса), наблюдения о том, как проходили мероприятия по формулированию и выравниванию целей, как происходило их достижение и какое было взаимодействие при этом.
Резонный вопрос, который стоит задать: «а кто же должен участвовать в такой ретроспективе? Неужели вся компания?»
Состав участников может быть разным. Ретроспективу OKR может проводить отдельно взятая команда у себя внутри, ТОП-менеджмент на уровне всей организации, лидеры, которые поддерживают процесс целеполагания. В зависимости от состава участников, на выходе будет немного разный контекст данных. Ведущим может быть один из лидеров, внутренний OKR-коуч или приглашенный фасилитатор.
Тайминг такой ретроспективы, как правило не более 1.5-2 часов, а Периодичность можно «привязать» к циклам целеполагания или к календарным периодам, если циклы слишком короткие и не позволяют накопить контекст.
У нас остается последний элемент, а именно:

Как именно проводить ретроспективу?

Давайте намеренно отбросим такие части агенды, как «открытие и закрытие встречи и дополнительные опции» и посмотрим на основную механику:
1. Собираем от участников данные о прошедшем периоде, попутно систематизируя по явным повторяющимся признакам.
2. Обсуждаем с группой и осмысляем эти данные
3. Вырабатываем конкретные варианты решения системных проблем, которые мы смогли выявить.
4. Договариваемся о том, кто и как будет драйвить соблюдение новых договоренностей.
Это стандартный «скелет» встречи, на который мы можем нанизывать различные инструменты, которые помогут организовать каждый из этапов такой встречи.

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

Радар OKR
Этот классический инструмент показывает то, как участники оценивают части нашего процесса. Он позволяет взглянуть с высоты на общую среднюю оценку того, что происходило, поговорить о контексте и выработать решения по улучшению системы.
Подготовка
Готовим флипчарт или доску Miro. Можно рисовать в форме радара, а можно в виде графика. Нам необходимо подготовить значения, которые мы будем обсуждать. Все они должны относиться в явном виде к процессу целеполагания. Я используем такие:
Цели – все что касается качества, формулировок, понятности и т.д. KR – понятность, методики расчета, совместимость с целью Планирование – как оно проходило, насколько качественно
Реализация– как мы двигались к целям, что подкачало, а что было хорошо,
Отслеживание– достаточно ли хорошо проходили Check-In, принимали ли правильные решения по ходу
Взаимодействие – каким было наше взаимодействие, помогали ли мы друг другу
Вы можете сами дополнять или убирать значения исходя из вашего контекста и задавать для них более широкие или узкие формулировки. Например, иногда мы добавляем вопросы «связанности» или «стратегии», если видим, что в этом могут быть точки роста.
Теперь вторая часть радара – это оценка. Тут все просто:
Размечаем на радаре цифры от 1 до 5, где
1 – ужасно
2 – плохо, надо менять
3 – удовлетворительно
4 – хорошо
5 – отлично
Получается такая картинка:
Проведение
Идем по «скелету», который был ранее:
1. Собираем от участников данные о прошедшем периоде, попутно систематизируя по явным повторяющимся признакам.
Цель: Синхронизировать всех участников в понимании общей картины и «подсветить» области, требующие внимания
1. Даём задание участникам поставить оценку по каждому из значений и пояснить её. Обычно на это хватает 10-12 минут.
2. Далее, каждый из участников по очереди клеит свои стикеры на радар и поясняет поставленную оценку.
3. Подмечаем системные повторения и просим прокомментировать крайние значения. Например, 1-2 или 5
4. По итогу мы можем увидеть общую картину и области, над которыми стоит поработать.
2. Обсуждаем с группой и осмысляем эти данные
Цель: Завалидировать с участниками те области, которые требуют внимания и обсуждения.
Это можно делать сразу по ходу предыдущего этапа, постепенно осмысляя наличие вопросов, которые нужно решить.
Если вопросов слишком много, можно устроить этап голосования за то, какими из них надо заняться в первую очередь. Если немного, то можно предложить группе рассмотреть варианты решения сразу по всем. Как правило 2-3 темы достаточно для проработки на ретроспективе.
3. Вырабатываем конкретные варианты решения системных проблем, которые мы смогли выявить.
Цель: Выработать конкретные предложения, действия, шаги, которые позволят изменить текущую ситуацию.
1. Распределение — Можно выбрать того, кто будет лидировать каждый из вопросов и предложить участникам, выбрать себе стол по интересам.
2. Задание — Важно правильно дать задание, чтобы группа сформулировала конкретные предложения, а не абстрактные вещи. Наподобие «нужно лучше общаться».
3. Групповая работа (обычно хватает 15-20 минут) — Внутри группы можно использовать мозговой штурм, когда сначала каждый из участников в тишине выписывает свои идеи, далее они все обсуждаются, после чего проходит голосование за лучшие.
4. Презентация идей – на этом этапе представители каждой из групп презентуют свое предложение, а остальные участники задают вопросы. На этом этапе важно, чтобы остались те шаги, в которые группа действительно верит и не испытывает скепсиса в большинстве.
5. Выбор предложений – бывает так, что идей слишком много и стоит договориться с группой, сможем ли взять в работу все, или нужно как-то сократить список на следующую итерацию. Здесь на помощь придет простое голосование точками. У каждого есть три точки и он может распределить их в любом порядке. В течение пяти минут вся группа проходит по всем стикерам и мы выбираем ТОП предложений.
4. Договариваемся о том, кто и как будет драйвить соблюдение новых договоренностей.
Цель: Получить конкретный список договоренностей по реализации предложений.
Поскольку все проблемные области были завалидированы, а предложения обсудили, группа полностью владеет контекстом и теперь нужно выбрать тех, кто будет активно лидировать реализацию предложенных вариантов. Как правило, здесь работает простой вопрос в зал о том, «кто готов?». Однако здесь стоит следить за тем, чтобы один человек или отдел не взял на себя слишком много вопросов. Так же можно задавать дополнительные вопросы, например о сроках или необходимой помощи. Таким образом, на выходе мы получаем дорожную карту действий с ответственными и сроками.
Обещанный шаблон для ретроспективы вы найдете по ссылке.

ИТОГ

Подводя итог, хочу сказать, что на деле, OKR ретроспектива кардинально не отличается от обычной ретроспективы, однако имеет свой определенный контекст, который заключается в фокусировке на процессе целеполагания и основных его элементах, вокруг которых мы и должны строить всю встречу.
Также хочу отметить, что я рассказал только об одном из возможных вариантов проведения такой ретроспективы. Помните, что инструменты нужно подбирать с умом, исходя из вашего контекста, поэтому они могут быть разными. Всегда отталкивайтесь от цели и от того, что хотите получить в итоге.
Удачи в жизни и бизнесе.
]]> Почему нужные навыки отсутствуют, когда они так нужны? http://neogenda.ru/blog/vzvatku3t1-pochemu-nuzhnie-naviki-otsutstvuyut-kogd http://neogenda.ru/blog/vzvatku3t1-pochemu-nuzhnie-naviki-otsutstvuyut-kogd?amp=true Wed, 28 Feb 2024 23:49:00 +0300 Алексей Пименов Перевод статьи Martin Aziz, размещённой на squirrelnorth.com. Оригинал можно прочитать здесь. В современной бизнес среде...

Почему нужные навыки отсутствуют, когда они так нужны?

Перевод статьи Martin Aziz, размещённой на squirrelnorth.com. Оригинал можно прочитать здесь.
В современной бизнес среде организации всё чаще имеют дело с неустойчивым и меняющимся рынком. Достаточно только упомянуть акроним VUCA (volatility — изменчивость; uncertainty — неопределённость; complexity — запутанность; ambiguity — неоднозначность) в разговоре с руководителем, чтобы начать разговор о современных бизнес-вызовах.
Пока я несколько лет работал над этим вопросом, поддерживая организацию, в которой работал, меня продолжал преследовать вопрос о том, как обладать нужными навыками, чтобы соответствовать изменчивости нашего рынка. Короче говоря — о высокой ликвидности навыков. Большую часть времени мне казалось, что я хожу по кругу: организую приобретение оптимальных навыков, переживаю изменение рынка, и вновь организую получение новых оптимальных навыков, и всё сначала.
Но как мы можем сделать навыки более ликвидными для нашей организации, т. е. иметь возможность задействовать необходимые навыки без длительных задержек и дорогостоящих транзакционных издержек? Проблема в том, что люди довольно сложны, особенно потому, что они применяют свои навыки в интеллектуальной работе, и ими нельзя управлять, как товаром.
К этой проблеме нельзя относиться легкомысленно; отсутствие навыков, может создать серьёзные узкие места, вызывающие задержки в ваших рыночных предложениях и, в конечном итоге, проявиться как белые пятна в вашей конкурентоспособности.
Многое было сделано для уменьшения влияния такой изменчивости, в частности, адаптация концепций организационных подходов, таких как Lean, Agile, Kanban и TPS, и это лишь некоторые из них. Интересно, что некоторые из этих подходов предложили своё собственное решение, например «кросс-функциональные команды», популяризированные Scrum-практиками. Изучая и используя различные подходы, я начал замечать, что многие из них не противоречат друг другу, а зачастую дополняют. Особенно если вы позиционируете их как один из нескольких подходов по пути роста в модели зрелости.

Представляем модель зрелости ликвидности навыков (SLiMM v0.5)

Представляя модель зрелости ликвидности навыков, я решил использовать семиуровневую шкалу, чтобы упростить её стыковку с существующими моделями, включая Модель зрелости Канбан (KMM). KMM уже достаточно надёжен в структурировании и упорядочивании нескольких областей, включая Lean / TPS, Real World Risk, CMMI и Mission Command. В рамках такой стыковки первый уровень зрелости ликвидности навыков начинается с 0, а 4-й и 5-й помечены как 3 + 4 и 5 + 6 — это совпадает с существующими уровнями зрелости KMM.
Ликвидность навыков — не единственный аспект организационной зрелости. Я хочу, чтобы это было полезно для вас, и дополняло любые другие модели, которые вы, возможно, уже используете.
Уровни зрелости задуманы как строительные блоки: высокие уровни используют более низкие уровни в качестве фундамента для более зрелой практики.
Рисунок 1 — Модель зрелости ликвидности навыков (SLiMM v0.5)
Уровень зрелости 0 — Специализация навыков
Большинство команд визуализируют свою работу, создавая стикер для каждого элемента, а затем записывают на нём название элемента. Часто добавляется дополнительная информация, например идентификатор из системы отслеживания, данные по оценке или кто работает над тикетом. Однако дизайну самого тикета уделяется не так много внимания.
Дизайн тикетов выходит за рамки простого согласования «стандарта» о том, какую информацию отображать, и где писать каждую часть; это возможность передать подробную информацию о работе, которую члены команды могут использовать для принятия решений.
Возможно, следует отметить, что цель не в том, чтобы использовать доску в качестве источника документации. Я видел, как команды пытались разместить слишком много информации в своих тикетах (например, подробные описания, критерии приёмки и т. д.). Этот уровень детализации лучше хранить в цифровом виде в вашей системе отслеживания или других базах знаний, используя тикеты для отражения информации, необходимой для принятия решений и самоорганизации.
Хороший пример — практика отображения списка чекбоксов с типичными внешними зависимостями, которым подвергается работа в данный момент. Чекбоксы указывают, действительно ли зависимость необходима для данного конкретного элемента, и была ли она уже выполнена или нет. С помощью этой информации член команды может решить, кого ещё необходимо привлечь к выполнению этой части работы, можно ли её вообще начинать сейчас или нет и т. д.
Рисунок 2 — У каждого человека есть определённый навык. На рисунке он обозначается формой и цветом.
На самом низком уровне зрелости мы начинаем со специализации навыков, практики укомплектования штата людьми с навыками, которые требуются для предложения ваших текущих услуг/продуктов. Это естественная точка для начала: почти каждая компания начинает с этого, при этом большинство здесь и остается. Вы можете наблюдать это в компаниях, где основное внимание уделяется требуемым навыкам кандидата на конкретную должность.
Преимущества
Этот подход предлагает несколько преимуществ: процесс найма может быть относительно простым — при условии, что требуемые навыки легко доступны. Формальные должностные инструкции могут использоваться для определения ожиданий и ограничений для конкретной роли.
С точки зрения сотрудника это даёт возможность для долгосрочного развития определённого нишевого набора навыков — вплоть до мастерства.
Ограничения и проблемы
Долгосрочная проблема этого подхода — неравномерность рыночного спроса на ваш бизнес, как по объёму, так и по типу услуг. Если когда-то организации потребовалось определённое количество специалистов в какой-либо области, то они быстро обнаружат нехватку или избыток таких специалистов.
Проблема недостатка обычно проявляется в виде узких мест внутри организации, препятствующих поставке вашим клиентам. Переизбыток можно рассматривать как чрезмерные инвестиции в неконкурентные категории — это чрезмерное обслуживание определённого рынка.
Тип мышления, связанный со специализацией навыков, как правило, распространяется на организацию компании в целом. Команды со специализациями, отделами и подразделениями — это типичная матричная организация. Нет ничего естественного в том, чтобы иметь IT-отдел, отдел финансов или HR. Это просто конструкции, основанные на специализации организационных практик, которые мы считаем нормой. Они обеспечивают глубокую экспертизу, но создают узкие места.
Рисунок 3 — Т-образные квалифицированные сотрудники имеют первичную специализацию и вторичные навыки. Крупная форма означает специализацию, мелкие фигуры — дополнительные навыки.
Попытка устранения ограничений ликвидности специализации навыков породила концепцию «Т-образных» людей. Её популяризировал Тим Браун (IDEO), а также она была поддержана несколькими фреймворками Agile. Понятие «Т-образности» относится к наработке одной специализации вместе с развитием смежных вторичных навыков. В разработке ПО примером может служить разработчик ПО, который также может вносить изменения в базу данных.
Преимущества
Преимущество такого подхода заключается в снижении частоты зависимости от других специалистов. Продолжая пример с разработчиком ПО: человеку, которому требуются относительно простые и частые изменения в базе данных, не нужно ждать специалиста по базам данных. Это уменьшает потенциальный источник узких мест в организации.
Для людей, любящих развивать навыки в нескольких областях сразу, работа в организации с таким подходом может принести удовлетворение и открыть несколько путей для карьерного роста.
Ограничения и проблемы
Процесс найма усложняется: помимо поиска необходимых первичных (основных) навыков, необходимо определить способность и интерес к развитию смежных навыков. В некоторых случаях высококвалифицированные специалисты могут быть не заинтересованы в том, чтобы участвовать в структуре, стремящейся навязать этот подход всем. Это отсутствие интереса может быть связано с личностью высококвалифицированного мастера и может вызвать культурные проблемы, если его заставить. Цитируя известного вымышленного врача: «Я врач, а не шахтер». Организации, которые хорошо работают на этом уровне зрелости, решили не навязывать его всем сотрудникам и оставлять места для индивидуальной специализации.
Компании на этом уровне зрелости продолжают организовываться вокруг специализации. Как и в ML0, при наблюдении за их организационной структурой, вы обнаружите отдельные подразделения, выполняющие определённые функции: маркетинг, информационные технологии, бухгалтерский учёт и т. д.
Человеческие ограничения на глубину и количество вспомогательных навыков, которые можно развить, приводят либо к задержкам в развитии навыков, либо к постоянным запросам на доступ к большему количеству специалистов.
На этом уровне зрелости общие источники задержек, связанные с отдельными людьми, уменьшаются, но узкие места в команде и организации сохраняются.

Уровень зрелости 2 — Кросс-функциональные команды

Рисунок 4 — Кросс-функциональные команды наследуют общие навыки, которыми обладают их сотрудники. Рамки вокруг команды означают чёткие границы команды.
Кросс-функциональная команда, популяризированная Scrum, представляет собой микс (предпочтительно Т-образных) людей с разными навыками в одной команде. Типичным примером является группа разработчиков ПО, которая раньше передавала выполненную работу группе тестировщиков. В кросс-функциональной конфигурации одна команда будет иметь возможность как разрабатывать, так и тестировать ПО.
Преимущества
Кросс-функциональность направлена на снижение частоты, с которой команде необходимо использовать помощь извне, например другой команды, специалиста или общего сервиса. Взаимодействия между командами являются распространенным источником задержек, поэтому перекрёстная функциональность снижает частоту, с которой это происходит, и уменьшает задержки.
Рисунок 5 — Кросс-функциональность устраняет проблемы с передачей, с которой могли бы столкнуться специализированные команды.
Разнообразие навыков также позволяет команде производить больше комбинаций возможной работы. Это даёт организациям повышенную гибкость в отношении работы, которую они могут предложить рынку.
На рисунке ниже вы можете увидеть это наглядно.
Рисунок 6 — Учитывая возможность производить по одному продукту для каждой команды за раз, в этом примере 3 кросс-функциональные команды могут производить 10 различных возможных комбинаций результатов. Команды специалистов могут создать только одну возможную комбинацию.
Ограничения и проблемы
По мере того, как компании работают над разнообразием и объёмом работы, способность отдельных кросс-функциональных команд обеспечивать необходимый потенциал и разнообразие навыков быстро достигает своего предела.
В какой-то момент становится экономически невыгодно развивать все возможные навыки в одной команде. Например, команде может потребоваться редизайн UX своего приложения каждые 2−3 года; из-за такой низкой частоты для команды может не иметь особого смысла вкладывать значительные средства в развитие навыков UX сверх того, что требуется для регулярного обслуживания.
Все размеры команд предусматривают практические ограничения количества навыков, которыми может обладать команда. Хорошие размеры команды, как правило, варьируются от 4 до 10 человек. Попытка обеспечить достаточное количество навыков, необходимых для сложных поставок, значительно расширит это число.
Кросс-функциональные команды также могут привести к потоку работы с низкой ценностью, когда их навыки не соответствуют потребностям бизнеса. Типичный паттерн — это когда главный приоритет команды, ограниченный её навыками, не является оптимальной работой для организации. Если позволить этому сохраняться в течение некоторого периода времени, то замкнутость группы и модели самоорганизации могут привести к тому, что команды будут формировать идентичность на основе своего набора навыков, в отличие от потребностей клиентов организации.
Рисунок 7 — Кросс-функциональные команды могут расставлять приоритеты в зависимости от имеющихся у них навыков. Это может позволить выполнять работу с меньшей ценностью для бизнеса за счёт ожидания работы с более высокой ценностью.
Ещё одно следствие практических ограничений кросс-функциональности в том, что отдельные команды редко формируют весь поток ценности для рабочего продукта в организации. Иными словами, командам по-прежнему необходимо получать работу из других подразделений и, в свою очередь, передавать её другим командам.
Это вновь создает проблему задержек из-за передачи задач из рук в руки. Задержки могут даже усугубляться локальной оптимизацией. Когда усилия по улучшению потока и мастерства внутри команды отвлекают организацию от улучшения общего потока к клиенту; местами даже мешает общему течению.
Рисунок 8 — Руководство и команды могут чрезмерно сосредотачиваться на оптимизации работы внутри команды. Время, затрачиваемое на работу в команде, на самом деле может составлять небольшую часть общего времени, которое ожидают клиенты. Это может привести к оптимизации очень небольшой части рабочего процесса с незначительными улучшениями сервиса.

Уровни зрелости 3 и 4 — Ликвидность сервиса

Когда мы оставляем работающими возможности, полученные на более низких уровнях, а также поддерживаем их, мы подходим к более высокому уровню зрелости. На нём происходит сдвиг в мышлении — от мышления о командах и отдельных лицах к мышлению через призму сквозных (end-to-end) сервисов для ваших клиентов.
Нехватка навыков, независимо от вашего бюджета, является распространённым явлением, которым необходимо управлять; особое внимание уделяется не столько обеспечению рабочих потоков внутри команд, сколько потоку через всю организацию.
Для этого люди должны находиться в правильных местах независимо от структуры их команды. Границы команд должны быть ослаблены в пользу организации сквозного сервиса клиентов. Внутренние команды общих сервисов становятся не только точкой опоры, но и способом экономичного управления дефицитными навыками.
Рисунок 9 — Пунктирные линии вокруг команд обозначают более проницаемую границу между командами. Концепция исходной команды ослаблена в пользу динамичных организаций. Команды выступают в качестве источников для отдельных лиц, для организации вокруг потока сервиса.
Допуская эту форму конфигурации, ориентированной на ценность, вы избегаете последствий для сквозных сервисов с высокой ценностью, которые застревают. В то время как области с более низкой ценностью работают. Как показано ниже. * Обратите внимание, что-то, как определяется ценность не, предназначено исключительно для определения ROI, но может включать стоимость задержки, стратегическое выравнивание и ряд соображений, выходящих за рамки этой статьи.
Рисунок 10 — Команды имеют динамическую конфигурацию для поддержки приоритетов* организации. Команда B, в частности, может обладать только второстепенными «круглыми» навыками, однако это всё же даёт больше экономических преимуществ по сравнению с продвижением малоценной работы с их основными навыками.
Необходимо установить циклы обратной связи для проверки сквозного сервиса в той или иной форме регулярной каденции. Ликвидность навыков в этих каденциях управляется путём понимания того, где формируются узкие места в навыках, и распределения людей таким образом, чтобы обеспечить поток работы по всему сервису.
Рисунок 11 — Циклы обратной связи должны охватывать весь рабочий процесс сервиса клиентов. Это означает, что область видимости потребуется для нескольких команд, нескольких отделов и, возможно, целых бизнес-подразделений.
Ограничения и проблемы
Организации, пытающиеся достичь этого уровня зрелости, скорее всего, столкнутся с наибольшим сопротивлением со стороны существующих управленческих структур. Конфликты между целями существующего «матричного» департамента и целями сквозного сервиса проявляются довольно быстро. Например: если бы вы были в финансовом отделе, вы бы задержали аудит и столкнулись с незначительным штрафом, а также выговором в пользу подтверждения налоговых правил для продукта, который (если он будет доставлен вовремя) будет иметь гораздо большую ценность для организации?
Рисунок 12 — Поток работы может пересекать существующие функциональные и политические границы. Доступ к нужным навыкам может быть подчинён местной повестке.
Смещение существующих норм организации требует значительных усилий со стороны руководства, чтобы бросить вызов существующим структурам в пользу сервисной ориентации. Короче говоря, зрелость лидерства в организации должна соответствовать уровню зрелости этого подхода к ликвидности навыков. В сочетании с этим любой существующий процесс вознаграждения и признания должен быть адаптирован таким образом, чтобы сбалансировать вклад в сквозной сервис в отличие от вклада в отдел или команду.

Уровни зрелости 5 и 6 — Организационная ликвидность

Опираясь на предыдущие уровни зрелости, на уровнях 5 и 6 перспектива управления своими навыками фокусируется на здоровье всей организации. Это взгляд на все сквозные сервисы в компании, ориентированный на управление рисками в целях обеспечения пригодности компании и долгосрочного выживания.
Управление этим риском также допускает, что не все сервисы в компании имеют одинаковую ценность в любой момент времени. Ваша стратегия ликвидности нуждается в способности адаптироваться к продвижению и понижению существующих сервисов наряду с созданием новых. И часто упускается из виду своевременное удаление тех, которые больше не имеют смысла.
Рисунок 13 — В любой момент времени сквозные сервисы различаются по важности для реализации стратегии организации. Критически важным сервисам предоставляются «более широкие каналы» вместе с более широким доступом к распределению критических навыков.
Циклы обратной связи должны выходить за рамки представления не только одного сквозного сервиса, но всех сервисов в целом. Эта визуализация поможет поддерживать регулярную настройку того, где навыки должны быть распределены.
Ниже приведён пример простой визуализации инициатив предприятия по двум измерениям риска: роль на рынке и стратегический сегмент. Каждой организации, очевидно, потребуется разработать собственную визуализацию, основанную на её стратегии.
Рисунок 14 — Визуализация корпоративных приоритетов в сравнении со стратегией. Позволяет визуализировать принятые обязательства во всех сервисах, а также ограничения ёмкости в соответствии со стратегией.
Распределение мощностей осуществляется в соответствии со стратегией. Ликвидность навыков управляется так же, как в ML4,5, с добавленным уровнем ранжирования навыков в ряде сквозных сервисов. Границы вокруг команды и отдельных лиц продолжают ослабевать, уже не обязательно иметь сходство с конкретным сервисом, но там, где потребность в каком-либо сервисе наиболее выгодна для организации.
Виртуальные команды могут быть созданы по мере необходимости для охвата всего рабочего процесса сервиса или отдельных частей, требующих их навыков. Команды и общие сервисы могут поддерживать несколько сервисов, ограниченных только возможностями и навыками группы. В этой среде ликвидности с высокой долей заёмных навыков усиливает продвижение ликвидности индивидуальных и командных навыков — это обеспечивает ещё большую организационную гибкость.
Рисунок 15 — Границы вашего пула навыков теперь сдвинулись, чтобы охватить несколько сервисов — потенциально все сервисы в организации. Очень немногие постоянные команды остаются сторонниками динамичной организации.
Концепция постоянных групп уменьшается, если не полностью устраняется в пользу динамической организации сквозного потока сервиса.
Это может показаться похожим на уровни зрелости 0 и 1, но ключевое отличие — в принятии сквозной сервисной призмы на организационном уровне, которая разблокирует таланты во всех областях. Компании на этом уровне зрелости испытали успех сервисной ориентации и могут придерживаться концепции постоянной команды только как пережиток прежних способов работы.
Обратите внимание, что более постоянные сообщества для обмена и развития навыков, вероятно, будут расширяться.
В этой среде различие между командами общих сервисов и кросс-функциональными командами стирается, ведь все группы начинают иметь характеристики общего сервиса. Некоторые в большей степени (поддерживаются несколько сквозных потоков сервиса) или в меньшей степени (поддерживается только один сквозной поток сервиса). Когда команда находится в этом спектре, это будет результатом сочетания их навыков и стратегий компании.
Ограничения и проблемы
Этот уровень зрелости наследует те же проблемы, что и в ML3,4, и ещё более усиливает их. Все политические границы в организации должны быть преодолены, чтобы организовать всю компанию вокруг сквозных потоков сервиса. Существующие структуры власти, исторически сложившиеся вокруг функциональных разрозненных структур, необходимо будет разрушить. А это потребует значительной зрелости лидеров, начиная с верхушки организации, и поддерживая её на всех уровнях. Успех в ML3 и 4 на какое-то время может стать путём к развитию необходимого лидерского капитала для перехода к ML4 и 5.
Циклы обратной связи и визуализация могут быть сложными для всей организации, особенно для получения всех данных по всей выполняемой работе. Никакие рабочие обязательства не могут быть скрыты или обособлены. С этой визуализацией также приходит принятие объективных решений, ориентированных на стратегию — если организация традиционно принимала решения на основе интуиции, чувств, отношений или других субъективных средств, может быть трудно осуществить этот переход.

SLiMM в контексте

Ликвидность навыков — не единственный аспект, который необходимо учитывать для улучшения результатов бизнеса. Как упоминалось ранее, я выбрал 7-балльную шкалу, чтобы иметь возможность связать её с более надёжными моделями, такими как KMM (Модель зрелости Канбан), которая, в свою очередь, также сопоставляется с другими моделями. Я призываю вас изучить выгоды и другие методы, которые соответствуют каждому уровню ликвидности навыков.
Вот как SLiMM подключается к KMM:
Рисунок 16 — Согласование SLiMM v0.5 с KMM
Модель зрелости ликвидности навыков была предназначена для того, чтобы предложить вам некоторые прагматические соображения о том, какие подходы могут подойти вашей организации. Каждый уровень предлагает набор преимуществ, а также проблем. Некоторые предприятия могут счесть риск приемлемым для работы на более низких уровнях зрелости, и это следует уважать.
Мой вам совет: не доводить внедрение до самого высокого уровня, а подумать о том, как ваша организация соответствует каждому уровню. И исходя из этого определить, какой уровень будет подходящим для вашей компании, какой уровень имеет смысл для ваших рыночных задач и разумно достижим с того места, где вы находитесь сейчас.
Модель зрелости ликвидности навыков всё ещё находится в стадии разработки, в настоящее время её первая опубликованная версия v0.5.
]]> Нужно ли разделять OKR и пересмотр зарплат? http://neogenda.ru/blog/dbkhbyf0u1-nuzhno-li-razdelyat-okr-i-peresmotr-zarp http://neogenda.ru/blog/dbkhbyf0u1-nuzhno-li-razdelyat-okr-i-peresmotr-zarp?amp=true Wed, 28 Feb 2024 07:23:00 +0300 Андрей Сидоренко OKR — это подход для постановки целей, который будет способствовать не только достижениям компании, но и росту и развитию сотрудников. Компании...

Нужно ли разделять OKR и пересмотр зарплат?

OKR — это подход для постановки целей, который будет способствовать не только достижениям компании, но и росту и развитию сотрудников. Компании годами используют отслеживание целей и OKR для принятия решений о заработной плате. Но должны ли руководители совмещать OKR и пересмотр зарплат?
Неудивительно, но 91% компаний хотят привязать производительность к вознаграждению. Часто аттестация является единственным формальным свидетельством трудовых достижений сотрудника и его вклада в бизнес. Данный факт затрудняет поиск другого подхода для пересмотра заработной платы. Совмещение же OKR и пересмотра зарплат, часто наносит вред сотрудникам, а не помогает, поскольку OKR является инструментом управления, а не инструментом оценки людей. OKR подсвечивает именно то, как работает система выстроенная руководителем. В то время, как вклад отдельных персоналий в достижения этой системы составляет лишь 15%. Возможно, вы наблюдали данный факт в компании на позициях, где люди постоянно меняются и поиск «золотого» или идеального сотрудника происходит годами, но все кандидаты почему-то не подходят. Это свидетельствует о том, что существует системная проблема.
Мнения руководителей о том, следует ли совмещать OKR-ревью с пересмотрами зарплат, на практике расходятся и, зачастую, кардинально. Есть много факторов, которые надо учесть, но сначала давайте разберемся, что представляет собой каждый из них.

Что такое OKR?

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

Что такое пересмотр заработной платы (ревью зарплат)?

Пересмотр заработной платы (ревью зарплат) — регулярная практика в большинстве современных компаний. Несмотря на необходимость такой практики, многие руководители озадачены вопросом: «Как правильно проводить пересмотр заработной платы?» Можно ли делать «бесшовную» интеграцию управления производительностью и пересмотра заработной платы?
Вы можете использовать различные способы оценки производительности сотрудников: результаты встреч один на один, постановку индивидуальных планов и их достижение, опросы удовлетворенности и оценки 360, чтобы определить необходимость изменения в оплате труда.

Каковы плюсы и минусы совмещения OKR и пересмотра зарплат?

Во-первых, давайте поговорим об отрицательной стороне совмещения пересмотра зарплат и OKR. Основная причина, по которой некоторые компании считают, что лучше их разделять в том, что зарплаты, основанные на OKR, могут привести к заниженным по амбициозности целям и завышенным достижениям на бумаге, не принося реальных изменений для всей компании.
Например, сотрудник, А работает в продажах, у него отличные результаты и он очень активен в своей работе. Но если по какой-то причине он не выполнил свой месячный план, он может потерять свой денежный бонус. В то время как сотрудник B работает не так усердно, как сотрудник A, но имеет гораздо более низкий план продаж. Ему все же удается ежемесячно получать бонусы. Сотрудник B не заслуживает бонуса в той же степени, что и работник A, но из-за заниженной планки для работника B ожидается, что он все же получит свой бонус. Такая культура может быть очень токсичной в любой организации, так как может привести к несправедливому анализу результатов работы сотрудников. А это приводит к ухудшению сотрудничества между членами команды, поскольку они могут чувствовать, что их работа не ценится и не вознаграждается справедливо.
При этом в некоторых случаях повышение заработной платы или выделение денежных бонусов могут стать мощными стимулами работать усерднее. Например, сотрудник B может начать работать усерднее, если будет знать, что получит премию. Это может привести к положительным результатам и более частому выполнению целей. В таком случае есть смысл в том, чтобы в рамках ваших OKR-сессий договориться о показателях, указывающих на исключительный успех. Вы премируете за их достижение. Чтобы эта практика давала плоды, стоит четко разделять output (результаты) и outcome (выгоды).
Результаты — это зачастую количественный показатель нашей работы: количество звонков, строк кода. А выгоды отвечают на вопрос: «Зачем мы делаем эти звонки и пишем код?». Как вы уже догадались количественные показатели часто не показывают заметного результата с точки зрения компании, поэтому премирование за количественные результаты — пагубно. А когда вы делаете связку повышение зарплаты и OKR, нужно посчитать тренд формирования выгод: сколько мы получим, если будем работать как обычно, например на какой показатель продаж можно рассчитывать в этот период. И держать в голове, что исключительный успех состоит в превышении этого тренда.
К такому превышению, как раз хорошо привязывать премирование. А дальше, для его достижения, нам стоит поставить в OKR метрики так, чтобы они стимулировали изменение нашей привычной работы системно, и как следствие давать нужные финансовые результаты (например, начать работать в командных продажах, а не индивидуальных).

Выводы

OKR и пересмотр заработной платы или премий служат разным целям, и нужно рассматривать вопрос о целесообразности их совмещения очень внимательно.
Они работают лучше всего, когда побуждают сотрудников стать амбициозными и целеустремленными. Цели изменяют неустраивающую вас систему, а сотрудники поддерживают вас в изменениях, потому что видят в этом способ получить значимые бонусы. Положительная сторона этого сочетания в том, что OKR напрямую не влияет на премии, а сотрудники и команды следуют внутренним мотивирующим факторам: автономия, принадлежность к чему-то большему, мастерство и принятие новых вдохновляющих целей.
Однако, как только на сцену выходят вознаграждения или бонусы за прямое достижение OKR, мотивация может сместиться в сторону гораздо менее значимых целей. Это приведет к изменению поведения с креном в сторону хорошей оценки руководителем или перекладывании вины на кого угодно за любые неудачи.
]]> 12 фокусирующих вопросов для Agile-коучей. Часть 2 http://neogenda.ru/blog/1jmkk2bf01-12-fokusiruyuschih-voprosov-dlya-agile-k http://neogenda.ru/blog/1jmkk2bf01-12-fokusiruyuschih-voprosov-dlya-agile-k?amp=true Thu, 29 Feb 2024 07:26:00 +0300 Артур Нек Перевод статьи James Steele, размещённой на squirrelnorth.com. Оригинал можно прочитать здесь. Итак, вы agile-коуч. Вы входите в кейс...

12 фокусирующих вопросов для Agile-коучей. Часть 2

Перевод статьи James Steele, размещённой на squirrelnorth.com. Оригинал можно прочитать здесь.
Итак, вы agile-коуч. Вы входите в кейс компании или команды, и от вас ожидают немедленной оценки контекста, в котором вы оказались.
Что вы будете делать? Как вы можете оценить ситуацию, чтобы предложить актуальное предложение своему клиенту?
В первой части этой серии статей я дал вам первые 6 техник наблюдения и ориентации для коуча. В этом материале я собираюсь раскрыть оставшиеся 6 фокусирующих вопросов.
Давайте приступим!

7. Что примечательно, интересно или необычно?

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

8. Какие варианты или альтернативы были опробованы?

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

9. Какие варианты вы могли бы предложить?

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

10. Каковы плюсы, минусы и побочные эффекты ваших действий?

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

11. Что бы вы сделали дальше?

Предугадывайте ситуации. Всегда задавайте себе вопрос: «Что бы я сделал дальше?»
Будьте готовым. Потратьте время, чтобы обдумать возможные вопросы, которые могут возникнуть, и будьте готовы проявить гибкость и вести переговоры. Не будьте просто реакционером.
Это касается не только ситуаций здесь и сейчас! Всякий раз, когда вы слышите истории о том, что переживает другой коуч, или говорите с кем-то о его предыдущих проблемах, или размышляете о прошлых ситуациях, обязательно старайтесь извлечь уроки из этого. Если бы вы оказались в одной из таких ситуаций, какой следующий шаг вы могли бы предпринять?

12. Что вы узнали из этой истории и что вы могли бы перенять?

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

Выводы

На вашу способность реагировать на ситуации контекстуально уместным образом будет в значительной степени влиять ваша способность наблюдать и эффективно оценивать ситуации с коучинговой позиции.
12 фокусирующих вопросов, которыми я поделился с вами, — это проверенные способы посмотреть на ситуации с разных точек зрения, чтобы увидеть то, что часто остается незамеченным коучами, которые больше занимаются «процессным коучингом» и контролем аспектов внедрения процесса.
]]> 12 фокусирующих вопросов для Agile-коучей. Часть 1 http://neogenda.ru/blog/5861g601j1-12-fokusiruyuschih-voprosov-dlya-agile-k http://neogenda.ru/blog/5861g601j1-12-fokusiruyuschih-voprosov-dlya-agile-k?amp=true Fri, 01 Mar 2024 07:30:00 +0300 Артур Нек Перевод статьи James Steele, размещённой на squirrelnorth.com. Оригинал можно прочитать здесь. А вы можете заметить то, чего не...

12 фокусирующих вопросов для Agile-коучей. Часть 1

Перевод статьи James Steele, размещённой на squirrelnorth.com. Оригинал можно прочитать здесь.
А вы можете заметить то, чего не видят другие Agile-коучи? Самые эффективные из них, как правило, замечают гораздо больше деталей, но как они это делают?
Коучи должны точно оценивать ситуацию, чтобы понимать как именно им отреагировать и как помочь людям, с которыми они работают. Это очень важно. В этом коучу могут помочь 12 вопросов, которые сфокусируют его на важном.
Первая часть этой серии статей познакомит вас с первыми 6 фокусирующими вопросами (во второй части будут рассмотрены оставшиеся 6).

1. Идентичность отдельных лиц и групп

Вам предстоит столкнуться со множеством ситуаций, когда поведение людей будет казаться иррациональным, беспорядочным и хаотичным. Это озадачивает и порой кажется безумием. У вас может возникнуть соблазн спросить: «Почему?». Но вместо этого вам следует спросить «Кто?», а уже после «Почему?».
У людей и групп есть идентичность. Как коуч, вы должны задаваться вопросом: «Кто вы как личность? Как вы себя воспринимаете? Кто эта группа, частью которой вы являетесь? Что лежит в основе этой группы? Что вы готовы защищать любой ценой?».
Если вы хотите понять поведение отдельных лиц и групп, вам нужно сначала искать объяснения, связанные с идентичностью. Ищите подсказки в том, как люди описывают себя, что они читают, о чем они говорят, какую должность занимают и т. д. Вам необходимо понимать личные, профессиональные и организационные особенности, когда вы пытаетесь повлиять на поведение.
Спросите сначала «КТО?», а потом «ПОЧЕМУ?».

2. Эмоциональная мотивация к изменению

Нравится вам это или нет, но первоначальная реакция человека на предлагаемые изменения воспринимается через призму его эмоций. У вас могут быть самые веские аргументы в пользу изменений, но если вы не учтете эмоциональную составляющую, то столкнетесь с сопротивлением, к которому вы не готовы должным образом. Люди даже не услышат и не поймут ваши логические рассуждения.
Вы должны спросить себя: «Какие эмоциональное поведение и действия я вижу?». Выявление и понимание этих факторов являются ключевыми рычагами, которые есть у вас есть для мотивации изменений. Только тогда люди будут готовы рационально обдумать то, что вы говорите.
По большей части вы обнаружите, что люди готовы жить со статус-кво — для них это зона комфорта и безопасное место. Внесение изменений в такие периоды может быть довольно сложным. Один из способов преодолеть эту проблему — понять эмоциональные потребности и то, как они соотносятся с сопротивлением, которое вы ожидаете или видите.
Если вы пытаетесь катализировать изменения в периоды статус-кво и хотите разработать подходы, которые эффективно справлялись бы с сопротивлением или использовали его, вы должны быть в гармонии с эмоциями людей.

3. Точки пунктуации и равновесие

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

4. Камни — источники сопротивления

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

5. Организационная зрелость и терпимость руководства

Эффективные коучи заботятся о том, чтобы стимулировать эволюцию организационной зрелости, стремясь помочь этим организациям достичь желаемых результатов.
Слишком часто коучи ограничиваются тем, что можно назвать «процессным коучингом». Они сосредотачивают огромную часть своих усилий на установлении и контроле за применением конкретной структуры или методологии. Кроме того, они делают это без учета уровня зрелости и терпимости организации к принятию практик, являющихся стандартом для указанной структуры или методологии.
Очень важно, чтобы вы как коуч точно оценивали текущую организационную зрелость.
Спросите себя, на каком уровне зрелости находится эта организация и какой уровень терпимости у руководства к различным изменениям. Зрелость необходимо оценивать по разным направлениям: культура, ценности, риск, лидерство, практики и т. д.
Ключевой компонент успешных изменений проистекает из введения стрессоров, которые контекстуально подходят для уровня их зрелости. Внедрение практик, не соответствующих текущей организационной зрелости, приведет к неудаче.
Также признайте, что у руководителей есть определенный уровень терпения, при котором они будут терпеть падение производительности в периоды перемен. Важно, чтобы вы попытались нащупать этот уровень и не вышли за его пределы.
Организационная зрелость и терпимость руководства будут ограничивающими факторами в ваших достижениях. Хорошая новость заключается в том, что они также могут быть стимуляторами.

6. Что представляет собой соответствие предназначению (F4P) для вашего продукта или сервиса?

Можете ли вы определить, есть ли у организации четкое понимание того, что делает их продукт или сервис соответствующим предназначению? Есть причины, по которым клиенты выбирают их? Почему? Понимают ли они пороговые значения, которые есть у клиентов по каждой из этих причин?
Клиенты диктуют предназначение или организация больше смотрит внутрь и оценивает себя? Вы коуч и хотите помочь организации улучшить ее способность предоставлять продукты и сервисы. Если это так, то вы должны спросить себя, что представляет собой соответствие предназначению в этой организации на уровнях бизнеса, сервиса и проекта.
Вы можете оказаться в ситуации, когда этого понимания не хватает. Или вам может повезти, если вы обнаружите, что они очень хорошо разбираются в F4P. Как бы то ни было, чтобы предоставить соответствующие рекомендации вам необходимо сформулировать эти критерии. Если вы не можете этого сделать, то вы не сможете помочь своим клиентам определить, что нужно изменить и когда эти изменения приведут к результатам, которые подходят для целей клиентов, потребляющих продукты или сервисы организации.
]]> Распространённые ошибки при формировании OKR http://neogenda.ru/blog/viy8x6b311-rasprostranyonnie-oshibki-pri-formirovan http://neogenda.ru/blog/viy8x6b311-rasprostranyonnie-oshibki-pri-formirovan?amp=true Sat, 02 Mar 2024 13:42:00 +0300 Андрей Сидоренко OKR (Цели и Ключевые результаты) — отличный способ достичь самых смелых целей. Ведь постановка OKR...

Распространённые ошибки при формировании OKR

OKR (Цели и Ключевые результаты) — отличный способ достичь самых смелых целей. Ведь постановка OKR вынуждает сотрудников, команды и компании формулировать свои цели на установленный период и в измеримой форме. И хотя составление OKR — это только часть процесса, их правильное формулирование играет огромную роль в их достижении.
В книге «Измеряйте самое важное» Джон Дорр описывает классические ошибки при написании OKR, которые следует избегать. Они включают в себя отсутствие ключевых результатов, которые необходимы или недостаточны. А также OKR, которые имеют низкую ценность для бизнеса, чего стоит избегать.
В общем, распространенные ошибки — лакмусовая бумажка, чтобы решить: действительно ли вы измеряете то, что имеет значение? Проверьте себя, посмотрев на распространенные ошибки OKR, они взяты из учебника OKR в Google:

Ошибка 1: Неспособность различить обязательные работы и амбициозные OKR

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

Ошибка 2: «OKR, как обычно»

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

Ошибка 3: Робкие амбициозные OKR

Вдохновляющие OKR очень часто начинаются с текущего состояния и фактически задают вопрос: «Что мы могли бы сделать, если бы у нас было больше людей и удачи?» Но лучше начать с вопроса: «Как мог бы выглядеть мой мир (или мир моих клиентов) через год, если бы мы были освобождены от большинства ограничений?» По определению, неизвестно как достичь этого состояния, и поэтому когда OKR будут впервые сформулированы — они амбициозны. Но без понимания и формулирования желаемого конечного состояния вы гарантированно не сможете их достичь.
Лакмусовая бумажка: если вы спросите своих клиентов, чего они хотят на самом деле, соответствует ли ваша амбициозная цель их запросам или превосходит их?

Ошибка 4: «Мешки с песком».

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

Ошибка 5: Цель с низкой ценностью

OKR должны обещать понятную ценность для бизнеса, иначе нет смысла тратить ресурсы на их выполнение. Цели с низкой ценностью (Low-Value Objectives, LVO) — это такие цели, которые никто не заметит и не будет о них заботиться, даже если они выполнены 100%.
Классический пример LVO: «Увеличить утилизацию процессора на 3%». Эта цель сама по себе не помогает ни пользователям, ни компании напрямую. Тем не менее, цель (предположительно связанная) «Уменьшить количество ядер, необходимых для обслуживания пиковых запросов, на 3 процента без изменения качества/задержки/… и вернуть полученные избыточные ядра в свободный пул» имеет очевидную экономическую ценность. Это более сильная цель.
Вот лакмусовая бумажка: может ли OKR быть выполненным на 100% при разумных обстоятельствах, не давая прямой выгоды конечному пользователю или экономической выгоды? Если да, то переформулируйте OKR, чтобы сосредоточиться на ощутимой выгоде. Классический пример: «Запуск X» без критериев успеха. Лучше формулировать так: «Удвойте Y по всему флоу, запустив X на 90%+ элементах кластера».

Ошибка 6: Недостаточное количество Ключевых результатов для принятых Целей

OKR делятся на желаемые выгоды (цель) и измеримые шаги, необходимые для его достижения (Ключевые результаты). Крайне важно, чтобы Ключевые результаты были написаны так, чтобы 100% достижение по всем ключевым результатам давало 100% достижение цели.
Распространённой ошибкой является использование ключевых результатов, которые необходимы, но недостаточны для достижения цели. Ошибка заманчива, потому что она позволяет команде избежать трудных обязательств (ресурсы/приоритет/риск), необходимых для достижения «трудных» ключевых результатов.
Эта ловушка особенно пагубна, потому что она скрывает как обнаружение потребности в ресурсах для цели, так и обнаружение того, что цель не будет выполнена в срок.
Лакмусовая бумажка: если достичь все ключевые результаты на 100% будет ли достигнута цель? Если нет, добавляйте или перерабатывайте ключевые результаты, пока их успешное выполнение не станет гарантией того, что цель также будет успешно выполнена.

Ошибка 7: Слишком много OKR на квартал

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

Ошибка 8: Ваши ключевые результаты — это задачи

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

Ошибка 10: Вы пропускаете ретроспективы в OKR

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

Ошибка 11: Неизмеряемые OKR

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

Ошибка 12: Нет контроля за ответственностью

OKR управляются данными. Они контролируются регулярными сверками, объективной оценкой и постоянной переоценкой для обеспечения полного контроля и подотчётности.
Дэн Бэйли, президент WikiLawn, объясняет, что он на собственном опыте убедился, что «всегда должен быть кто-то, кто управляет кораблем, даже если команда отвечает за то, чтобы помочь безопасно доставить его в гавань. В работе с OKR невероятно важно иметь квалифицированного человека, отвечающего за цель. Ему нужно точно знать, что ожидается и как это будет измеряться, чтобы он мог контролировать процесс и обеспечивать достижение прогресса».

Ошибка 13: Нет командной работы

Прозрачность OKR позволяет всем членам команды видеть цели — начиная с генерального директора и заканчивая рядовым сотрудником. Отдельные лица связывают свои цели с инициативой компании и выявляют взаимозависимости для эффективной координации с другими командами. Связывая каждого участника с успехом компании, координация внутри бизнеса придает смысл работе.
]]> Как великие лидеры используют идентичность http://neogenda.ru/blog/e8yt9pk401-kak-velikie-lideri-ispolzuyut-identichno http://neogenda.ru/blog/e8yt9pk401-kak-velikie-lideri-ispolzuyut-identichno?amp=true Sun, 03 Mar 2024 21:23:00 +0300 Алексей Пименов Перевод статьи James Steele, размещённой на squirrelnorth.com. Оригинал можно прочитать здесь. Я работаю с лидерами по всему миру...

Как великие лидеры используют идентичность

Перевод статьи James Steele, размещённой на squirrelnorth.com. Оригинал можно прочитать здесь.
Я работаю с лидерами по всему миру. Я обучил бесчисленное количество из них технике, которая позволяет понимать и объяснять поведение, которое другие просто не могут распознать. Лидеры, с которыми я работал, постоянно сообщали мне, что эта техника была одним из самых полезных вкладов в их успех, она позволила им достичь желаемых результатов и преодолеть сопротивление изменениям. В этой статье я поделюсь с вами этой техникой. Она прагматична, и вы сможете применить её на практике сразу, как только закончите читать эту статью.
С этой техникой вы станете более эффективным лидером. Вы сможете увидеть то, чего не видят другие, и добиться результатов, которые не достигаются большинством.

Роль идентичности

Понимание индивидуальности отдельных лиц и групп необходимо для эффективного лидерства.
Почему идентичность актуальна? Потому что вы окажетесь в ситуациях, когда поведение, свидетелем которого вы являетесь, кажется необъяснимым. Вы увидите, как люди делают что-то совершенно бессмысленное, и спросите себя: «Почему они ведут себя так?» Это озадачит вас, и на первый взгляд покажется, что в этом нет никакой логики. Вы даже можете подумать, что эти люди сумасшедшие.
Столкнувшись с такой ситуацией, многие лидеры реагируют из лучших побуждений и вводят изменения, которые, по их мнению, станут катализатором нового поведения, которое «имеет смысл» и вытеснит всё необъяснимое и нежелательное поведение, которое они видят вокруг себя. Они надеются, что с этими новыми изменениями они начнут видеть поведение, соответствующее результатам, которых они пытаются достичь.
Кажется, что это вполне разумный подход, не так ли? Так почему же он так часто терпит неудачу? Что ж, проблема в том, что этот подход редко даёт устойчивые результаты, если индивидуальная и/или групповая идентичность не была тщательно понята и учтена. Почему?
Отдельные лица и группы ВСЕГДА будут испытывать и оценивать изменения через призму своей индивидуальной или групповой идентичности. Если изменение воспринимается как угроза этой идентичности, они его отвергнут!
Иногда неприятие активно (вы обнаружите его и будете бороться с ним), а иногда оно будет пассивным (вы не заметите его и будете думать, что всё в порядке, пока не обнаружите его гораздо позже). Крайне важно: чтобы успешно понимать, объяснять поведение и влиять на него, вы должны иметь чёткое представление о действующих лицах.
Итак, что я имею в виду под индивидуальной и групповой идентичностью?

Индивидуальная идентичность

Как я уже упоминал, у идентичности есть два аспекта. Давайте займёмся первым — это психологическая идентичность людей. Этот аспект идентичности можно понять через вопрос: «Кто вы как личность?»
Как люди, мы отвечаем на этот вопрос как с внутренней, так и с внешней точки зрения. Это то, как мы воспринимаем себя (внутренне) и как мы проецируем себя на других (внешне). Оба компонента играют важную роль в формировании нашего образа самого себя, самооценки и самоуважения.
Как лидеры, которые хотят понимать людей и влиять на них, мы должны быть внимательны к личностям людей. Нам нужно искать ключи к личностям, но не торопиться с этим. Гораздо информативнее спросить: «Кто вы?» вместо «Почему вы ведёте себя таким образом?» Ответ на второй вопрос можно найти и первом, но многие люди никогда не осознают этого.
Так как же мне узнать, кто вы? Люди проецируют на нас свою идентичность несколькими способами, на которые нам следует обращать внимание:
  • Как они представляют себя
  • Визитные карточки
  • Профили в социальных сетях
  • Наряд
  • Название должностей
  • Бейджи
  • Сертификаты
  • Удостоверения
  • и так далее…
Звучит просто, не так ли? Но, не будем торопиться. Часто у людей есть личная (скрытая) личность, которую гораздо труднее обнаружить, но, как правило, она гораздо более актуальна для более тонкой и точной оценки того, кем они являются на самом деле!
Пример:
Публичная идентичность:
«Я руководитель отдела управления продуктами. Я управляю проектами и менеджерами проектов. Я делаю всё возможное, чтобы проекты выполнялись вовремя, в рамках бюджета, с максимальным качеством и к удовольствию наших клиентов. У меня есть сертификат PMP, и для меня важно, чтобы я придерживалась этого стандарта, чтобы он отражался в моей работе».
Личная (скрытая) идентичность:
«Я — Королева пожаротушения! Когда случается чрезвычайная ситуация (а их здесь много), я тот, кто тушит пожар. Если для реализации этого проекта требуется героизм, то вы можете рассчитывать на меня. Я сделаю всё, что потребуется, и я хочу быть первой, кому вы позвоните и доверите решение срочных вопросов».
Этот конкретный пример довольно распространён. Из этого краткого примера видно, что между публичной и индивидуальной идентичностью может быть существенный контраст. Лидерам важно осознавать, что зачастую и то, и другое существует, и то, и другое имеет силу, и понимание того и другого имеет решающее значение. Как только вы настроились на индивидуальность человека, вам нужно использовать её как фильтр в своих усилиях понять, объяснить и повлиять на его поведение.
После того, как вы это сделаете: то, что раньше вызывало недоумение, обретёт смысл, а то, что раньше было необъяснимым, теперь окажется понятным.
Если вы понимаете индивидуальную идентичность, вы можете быть более эффективным лидером: можете достигать желаемых результатов и помогать подчинённым добиваться того, что важно для них. Самое главное, делать это так, чтобы не посягать на чьи-то представления о самом себе, самооценку или самоуважение.
Групповая идентичность
Второй аспект идентичности, который я хотел бы осветить, — это идентичность социальных групп. Оказывается, у групп тоже есть идентичность! При рассмотрении понятия идентичности мы также можем задать вопрос: «К какой группе (группам) вы принадлежите?» Подобно индивидуальной идентичности, группы, к которым принадлежат люди, имеют основополагающее значение для оценки людьми себя и окружающих. Понимание групповой идентичности — ещё один ключ к разгадке тайны поведения и мотивов людей.
Люди — социальные существа. Мы процветаем в группах, и это имеет решающее значение для нашего выживания. Существует бесконечное количество групп, к которым принадлежат люди: спортивные команды, профессиональные организации, политические партии, корпоративные организации, благотворительные организации и так далее. Мы используем группы как способ сравнения себя с другими людьми. Они определяют, кто мы есть и кем мы не являемся. Если я либерал, то я не консерватор. Если болею за «Манчестер Юнайтед», то я не болею за «Ливерпуль».
Вероятно, что как лидер, вы несёте ответственность за руководство группами. Эти группы имеют идентичность. Кроме того, люди в этих группах принадлежат к другим группам, каждая из которых также имеет свою собственную идентичность. Это группы и идентичности повсюду! От этого никуда не деться.
Подобно отдельным людям, вы столкнетёсь с группами, характеристики и поведение которых отражают идентичность этих групп. Если вы хотите точно понимать, объяснять и успешно влиять на группу, вам необходимо обратить внимание на групповую идентичность. Определить, к каким группам принадлежат люди, обычно довольно просто (и это похоже на определение индивидуальной идентичности), поэтому я не хочу много говорить об этом.
На чём я хотел бы сосредоточиться, так это на трёх компонентах групповой идентичности, которые необходимы для эффективного лидерства, внесения изменений и преодоления сопротивления.

1 — Что лежит в основе вашей группы, что делает её такой, какая она есть?

Группы будут иметь ядро своей идентичности. Именно оно будет движущей силой поведения, которое вы видите. Неспособность понять это ядро приведёт к неспособности понять и повлиять на групповое поведение. Кажется, что это очевидно, но на деле я много раз видел, как лидеры пытались внедрить изменения, которые прямо противоречат основной идентичности группы. У вас нет шансов быть эффективным без острого понимания этого мотивирующего фактора групп.
Пример: крупный банк, консервативный, иерархический и бюрократический по своей сути, решает открыть какую-то меньшую организацию — назовем её цифровой лабораторией/фабрикой. Они открывают её в каком-то модном районе в центре города: кожаные диваны, опен спейс, модные кофемашины, бильярдные столы и самое новое крафтовое пиво на разлив!
Они делают это, чтобы привлечь молодые таланты, у которых есть вкусы и ожидания, которые движутся в этом направлении при поиске следующего шага в карьере. Им нужен гибкий график, быстро меняющаяся среда, быстрое принятие решений и большая автономия. Конечно же, эта молодая талантливая толпа появляется. Миссия выполнена, верно? Не совсем. Новые сотрудники довольно быстро обнаружат, что на самом деле способ ведения бизнеса здесь совсем не модный. Несмотря на все излишества, по своей сути эта организация большая, медлительная, с вертикальной структурой, где требуется одобрение сверху для любого действия.
Неважно, насколько вы харизматичны, блестящи или влиятельны в качестве лидера. Если вы не будете тщательно рассматривать то, что лежит в основе идентичности группы, вам придётся очень тяжело.
Основная идентичность всегда будет побеждать!

2 — Что представляет вас как группу?

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

3 — Группы могут потерять свою идентичность.

Бывают случаи, когда идентичность группы может быть утеряна. Я слышал, что это называют «зомби-группой». Находясь в этом состоянии, группа бродит вокруг, она не уверена в том, кто они такие. Люди сбиты с толку, разочарованы и дезориентированы.
Удивительно, но такое явление довольно сложно обнаружить, если не следить за этим специально. Тем менее, эта статья поможет вам понять, есть ли у вас такая «зомби-группа».
Пример: я достаточно старый и помню, что групповая идентичность Yahoo была в том, что они были веб-порталом для организации и категоризации контента в Интернете. Но потом случился Google! Соответствующая предназначению поисковая система, которая могла найти в Интернете для вас сразу всё, введя пару слов. Это предложение разрушило самобытность Yahoo. Они потеряли свою групповую идентичность. Порталы больше никому не нужны. Они больше не знали, кто они такие. Их основной артефакт был уничтожен. Теперь мы знаем, что Yahoo отреагировала на это созданием новой групповой идентичности — медиакомпании.
Когда группы теряют свою идентичность, они теряют ощущение того, кто они есть. Если вы лидер и окажетесь в такой ситуации, вы начнёте помогать им в развитии новой идентичности. Без сильного понимания того, кто они, группа будет неэффективной.
Группы не всегда будут такими большими, как компания размером с Yahoo. Это может быть просто команда, которая сбилась с пути и не уверена, что представляет собой. Ваша задача — обнаружить это и помочь им начать процесс открытия и разработки новой идентичности.

Ключевые выводы

Надеюсь, теперь вы понимаете, почему так много лидеров пытаются понять, объяснить и повлиять на поведение. Несмотря на их самые искренние усилия, неспособность принять во внимание индивидуальную и групповую идентичность часто упускается из виду.
Техника и ключевой вывод для вас как лидера, когда вы пытаетесь объяснить поведение и повлиять на него, заключаются в следующем: ищите связанные с идентичностью объяснения поведения, которое вы хотите понять или изменить.
]]> В чём преимущества OKR? http://neogenda.ru/blog/mmjz93yix1-v-chyom-preimuschestva-okr http://neogenda.ru/blog/mmjz93yix1-v-chyom-preimuschestva-okr?amp=true Mon, 04 Mar 2024 21:26:00 +0300 Андрей Сидоренко Преимущества процесса постановки целей с помощью OKR очевидны, учитывая, что в России их использует уже...

В чём преимущества OKR?

Преимущества процесса постановки целей с помощью OKR очевидны, учитывая, что в России их использует уже более 100 компаний, а список международных еще больше: Adobe, Google и Netflix. Многие из использующих достигают поразительного успеха. OKR — это мощный способ выразить цели любой компании. Также фреймворк может стимулировать разработку стратегии и стратегическиго плана, помочь вовлечь сотрудников и выявить основные OKR — главные приоритеты компании.
Но если вы только начинаете изучать эту тему, то у вас может возникнуть вопрос: «Что делает OKR такими полезными не только для постановки, но и для достижения самых смелых целей команд и отдельных лиц? Почему я должен начать использовать OKR?».
В интервью Harvard Business Review Джон Дорр говорит, что есть пять ключевых преимуществ OKR. Эти пять преимуществ расшифровываются как аббревиатура «F.A.C.T.S.». Так что при использовании OKR мы можем сказать, что OKR дают нам только «ФАКТЫ».
Эти пять ключевых преимуществ OKR включают…

Преимущества OKR

  • Фокус (Focus): Фокус — это первое преимущество, потому что, когда вы устанавливаете OKR, вы ограничены в их количестве. Целей может быть больше одной, но всегда меньше семи. Чем меньше, тем лучше. Каждая цель должна помещаться на одной строке. Что касается ключевых результатов, их у вас должно быть не более пяти на одну цель. Из-за этой необходимости ограничения количества направлений, на которых нужно сосредоточиться, OKR действительно вынуждают делать предварительный выбор. Цикл OKR должен начинаться с вопроса: «Что наиболее важно в ближайшие три (или шесть, или двенадцать) месяцев?». Этот привязанный к периоду вопрос отличает OKR от других систем постановки целей, потому что они выявляют несколько инициатив, которые могут иметь реальное, моментальное значение, откладывая при этом менее срочные. Твёрдо поддерживая несколько основных OKR, лидеры дают своим командам компас и отправную точку для оценки.
  • Выравнивание (Alignment): как только поставлены основные цели, начинается настоящая работа. По мере перехода от планирования OKR к их выполнению, менеджеры и участники одинаково связывают свою повседневную деятельность с видением всей организации. Термин для этой связи — «выравнивание», и его значение невозможно переоценить. По данным Harvard Business Review, компании с высококвалифицированными сотрудниками более чем в два раза чаще добиваются высоких результатов.
  • Обязательство (Commitment): после фокусировки и выравнивания следуют обязательства. Обязательства — это OKR, которые по общему согласию будут выполнены, а роудмапы и ресурсы будут скорректированы для обеспечения их выполнения. Отслеживание этих обязательств осуществляется прозрачно. Каждый член команды должен подавать всем чёткие сигналы о том, что он работает над достижением своих OKR. Независимо от того, делается ли это с помощью Google Sheet или специализированного программного инструмента отслеживания OKR,, необходимо делиться результатами OKR на слайдах ежемесячно или распечатывать их и размещать на стенах в офисе. Это нужно, чтобы сказать, что теперь вы знаете, к чему стремитесь. Достигаете этого или нет — не имеет значения, пока есть согласованность и прозрачность.
  • Отслеживание (Tracking): Отслеживание OKR от промежуточных результатов до конечных результатов — вот почему управление по целям так популярно в компаниях высшего класса. Каждый OKR должен иметь возможность отслеживаться с помощью метрик, установленных при их написании. И хотя OKR не требуют ежедневного отслеживания, регулярные проверки (предпочтительно еженедельные) необходимы для предотвращения отставания. Наличие этих контрольных точек для оценки ваших текущих OKR — это долгосрочная магия на индивидуальном уровне. Вы на пути к достижению этой цели или нет? Почему да или почему нет?
  • Отслеживание (Tracking): Отслеживание OKR от промежуточных результатов до конечных результатов — вот почему управление по целям так популярно в компаниях высшего класса. Каждый OKR должен иметь возможность отслеживаться с помощью метрик, установленных при их написании. И хотя OKR не требуют ежедневного отслеживания, регулярные проверки (предпочтительно еженедельные) необходимы для предотвращения отставания. Наличие этих контрольных точек для оценки ваших текущих OKR — это долгосрочная магия на индивидуальном уровне. Вы на пути к достижению этой цели или нет? Почему да или почему нет?
  • Растягивание (Stretching): «Растягивание» — последнее, но не менее важное дело. Как говорит Джон Дорр, «Ларри Пейдж из Google — это гуру 10-кратного увеличения и растягивания. Он скажет: «Я бы предпочёл, чтобы цель выглядела как полёт Марс, и если мы не добьемся успеха, мы доберёмся до Луны». OKR по своей сути подталкивают организации к значимым усилиям, чтобы получить немного больше, чем они считали возможным.
Вот почему так много компаний используют систему OKR. Преимущества фокуса, выравнивания, обязательства, отслеживания и растягивания оказались неоценимыми для очень многих.
]]> Управляйте работой, а не людьми http://neogenda.ru/blog/j8a6g4spg1-upravlyaite-rabotoi-a-ne-lyudmi http://neogenda.ru/blog/j8a6g4spg1-upravlyaite-rabotoi-a-ne-lyudmi?amp=true Tue, 05 Mar 2024 21:29:00 +0300 Алексей Пименов Перевод статьи James Steele, размещённой на squirrelnorth.com. Оригинал можно прочитать здесь. У большинства руководителей, с которыми я работаю,...

Управляйте работой, а не людьми

Перевод статьи James Steele, размещённой на squirrelnorth.com. Оригинал можно прочитать здесь.
У большинства руководителей, с которыми я работаю, есть общая жалоба: они не могут добиться значимых успехов в скорости и предсказуемости выполнения работы для своих клиентов.
В моей работе в качестве консультанта и тренера есть одна стратегия, которую я помогаю им нащупать. Обычно, это приводит к кардинальным изменениям в их мышлении и в том, как они относятся к работе и сотрудникам в своей организации. Итак, какова же эта стратегия?

Эффективность потока

Рабочие элементы (т. е. пользовательские истории, фичи, эпики) или любые другие артефакты, представляющие узнаваемую для клиента ценность в вашем контексте, могут в течение своего жизненного цикла переходить между двумя состояниями: активным и ожидающим. Работа активна, когда мы в данный момент занимаемся добавлением ценности к рабочему элементу — он привлекает наше внимание, и мы активно над ним работаем.
Работа находится в состоянии ожидания, когда она была начата, но затем прервана (по разным причинам), чтобы заняться чем-то другим. Активное время по отношению к общему сроку службы рабочего элемента представляет собой конструкцию, известную как эффективность потока. Понимание этого отношения может иметь серьёзное влияние на то, как вы смотрите на свою работу и на принимаемые вами решения.
Это выражается в процентах по следующей формуле:
(Активное время / Общее время) *100
Вот пример. Создание пользовательской истории заняло 26 часов (от начала до конца). Из этих 26 часов только 2 часа фактически были потрачены на работу над элементом, а 24 часа из общего числа находились в состоянии ожидания. Это эффективность потока 7,7%. (2/26) * 100 = 7,7.
Вы можете быть удивлены, как и многие из моих клиентов и учеников, обнаружив, что в интеллектуальной работе (например, в разработке ПО) типичная эффективность потока измеряется на уровне 4−8%! На самом деле, 40%+ было бы ОЧЕНЬ хорошо.
Подумайте об этом!
Это означает, что рабочие элементы проводят своё существование в основном в состоянии ожидания. Даже если мы начали над чем-то работать, в 92−96% случаев мы не добавляем ценности работе! Существует множество причин, по которым рабочие элементы помещаются в состояние ожидания: переключение задач, очереди, блокеры, внутренние/внешние зависимости и т. д. (Помните: если вы работаете более чем над одним элементом, когда вы переводите своё внимание с одного элемента на другой, то этот элемент фактически переходит в состояние ожидания).
Итак, какие могут быть последствия от системы с низкой эффективностью потока, и как она может изменить нашу работу и принимаемые нами решения?

Следствие № 1. Насколько заняты люди, по большому счёту не имеет значения

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

Следствие № 2: производительность людей в значительной степени не имеет значения

Стремясь увеличить скорость и объём работы, выполняемой командами, большая часть менеджеров считают лучшим решением нанять больше людей и/или заставить их работать быстрее и усерднее. Большинство моих тренингов, обычно, начинаются с того, что менеджер встречается со мной и умоляет о помощи: «Пожалуйста, помогите моим командам работать быстрее!». Так начинается процесс, когда я помогаю им понять, что если они работают в среде с низкой эффективностью потока (как правило, так и есть), сосредоточение внимания на повышении производительности отдельных лиц (или найме большего их числа) на самом деле не окажет большого влияния на решение проблемы. Почему?
Представьте себе, что у этого расстроенного менеджера есть среда, в которой эффективность потока составляет 6%. Таким образом, 94% времени работа находится в состоянии ожидания, и только 6% времени фактически добавляется ценность к работе. Если мы решим сосредоточиться на оптимизации производительности 6% активной работы, любые улучшения будут очень незначительными по сравнению с общим увеличением времени выполнения работы на протяжении всего срока её службы — мы работаем только с 6% от общего числа!
Давайте предположим, что из этих 6% — 2% занимает разработка. Даже если вы сделаете свою команду разработчиков в 10 раз быстрее или удвоите её размер, вы окажете очень незначительное влияние на систему в целом.
Возможности для улучшения, которые действительно изменят сроки поставки и предсказуемость, заключаются в устранении 94% задержек, существующих в потоке работы. В такой среде нам нужно помочь менеджерам отказаться от управления и измерения людей, а вместо этого управлять и измерять поток работы.

Следствие № 3: ваши оценки обречены

Большинство организаций ужасно оценивают. Для этого есть множество причин, но ключевой является то, что, когда мы оцениваем, мы производим оценки «усилий». Мы оцениваем количество усилий, которые, по нашему мнению, потребуются для завершения рабочего элемента. Когда мы это делаем, мы оцениваем 4−8% активного рабочего времени, добавляющего ценность. Но мы НЕ оцениваем количество времени ожидания, которое наш рабочий элемент потратит за время своего существования.
Это 92−96% срока службы рабочего элемента, и мы не принимаем это во внимание. Неудивительно, что мы так далеки от наших оценок. Мы можем попытаться обмануть систему, добавив буферы к нашим оценкам, но, увы, эта тактика часто бесполезна и вредна для развития предсказуемости.

Следствие № 4. Фокус внимания на эффективности команды — не ведёт к бизнес гибкости

По моему опыту, в большинстве организаций, в которых работает более 50 человек, идея самоорганизующихся кросс-функциональных команд — это фантастика. Снова и снова, когда я смотрю на то, как работа проходит через организацию, она редко существует в рамках одной команды и не зависит от каких-либо других команд. То, что я чаще всего наблюдаю, — это кросс-функциональные разрозненные команды, зависящие друг от друга.
Ещё более пагубным для сроков поставки и предсказуемости нашей работы являются задержки между командами. Если работа проходит более чем через одну команду (обычно так и происходит) и эта работа не поступает к нужной команде в нужное время, тогда появится задержка, которая отрицательно повлияет на эффективность потока.
Не будет иметь значения, насколько оптимизированы отдельные команды, если поток работы между ними не будет организован так, чтобы обеспечить плавность. Гибкость бизнеса достигается не количеством высокоэффективных команд, а тем, насколько хорошо вы управляете взаимодействием между ними.
«Производительность системы — это не сумма её частей. Это ПРОДУКТ их ВЗАИМОДЕЙСТВИЯ». — Доктор Рассел Акофф.

Давайте что-нибудь с этим сделаем

Теперь, когда мы знаем о некоторых последствиях низкой эффективности потока, какие практические и действенные рекомендации мы должны принять во внимание, чтобы улучшить предоставление наших услуг и обеспечить ценность для наших клиентов, когда они в ней нуждаются? Как сделать это так, чтобы управление работой и её измерение были предпочтительнее, чем управление и оценка людей?
Визуализируйте работу: интеллектуальная работа и профессиональные услуги — это области, в которых выполняемая работа в основном невидима. Нам нужно найти способ сделать эту работу видимой, чтобы у нас было что-то осязаемое, о чем мы могли бы поговорить. Нам нужно увидеть, как «работает» наша работа!
Ограничьте объём WIP: если мы хотим стимулировать улучшения в работе и развивать устойчивый темп, нам нужно начать ограничивать объём работы, которую мы берём на себя за раз. Предсказуемость наших поставок невозможна, если мы не ограничим объём WIP.
Управляйте потоком работы: как мы обсуждали в этой статье, нам нужно сосредоточить наши усилия на выявлении тех вещей, которые мешают потоку. Нам нужно переключить внимание с использования людей на управление работой и то, как она протекает.
Сделайте правила явными: всякий раз, когда мы обнаруживаем препятствия для потока, мы должны стремиться к их устранению. Часть решения должна включать обновление правил того, как работа проходит через нашу систему. Их нужно сделать явными. Развитие наших правил и их чёткое изложение является краеугольным камнем постоянного совершенствования.
Внедрите циклы обратной связи. Гибкость бизнеса и постоянное совершенствование основаны на желании быстро учиться и реагировать на отзывы. Нам нужно создать механизмы, с помощью которых мы можем собирать и оценивать отзывы, чтобы мы могли поддерживать или корректировать наш курс. Эти механизмы должны способствовать получению значимой обратной связи, с которой мы можем работать.
Сотрудничайте и экспериментируйте: соглашение о стремлении к эволюционному совершенствованию путём поощрения актов лидерства и сотрудничества на всех уровнях организации необходимо. Особенно, если мы стремимся к культуре, в которой изменения могут процветать с помощью экспериментов, основанных на научном методе. Наш подход должен двигаться к недетерминированному вероятностному мышлению и отказаться от спекулятивного мышления и принятия желаемого за действительное.
Помочь организациям понять последствия плохой эффективности потока, а затем использовать эти методы для преодоления этой проблемы — стратегия, которая оказалась очень эффективной для меня и моих клиентов.

Заключение

Я не утверждаю, что одержимость точностью отслеживания эффективности потока будет правильно потраченным временем. Даже если вы этого захотите, то без электронных инструментов это будет непросто. Тем не менее, даже приблизительное понимание эффективности вашего потока или поиск прерываний потока (заблокированные элементы, стареющие элементы, зависимости и т. д.), и сосредоточение внимания на развитии быстрого и плавного потока может иметь огромные преимущества: вы сможете доставлять услуги клиентам быстрее и надёжнее.
Сосредоточьтесь на устранении времени ожидания ваших рабочих элементов! Стремитесь к плавному и быстрому потоку! Тратьте больше времени на управление и оценку работы, а не на управление и оценку людей.
]]> От целей к результатам: что такое OKR и как он поможет твоему бизнесу http://neogenda.ru/blog/3gm4e7fmt1-ot-tselei-k-rezultatam-chto-takoe-okr-i http://neogenda.ru/blog/3gm4e7fmt1-ot-tselei-k-rezultatam-chto-takoe-okr-i?amp=true Wed, 06 Mar 2024 07:46:00 +0300 Артур Нек Сегодня компании всё чаще стараются улучшить процессы управления. Некоторые пытаются внедрить OKR — систему...

От целей к результатам: что такое OKR и как он поможет твоему бизнесу

Сегодня компании всё чаще стараются улучшить процессы управления. Некоторые пытаются внедрить OKR — систему постановки и достижения целей. Это особая модель, которую уже успешно используют в своей деятельности Uber, Avito и Google. Но применять OKR можно в бизнесе любого масштаба. Что это за инструмент и зачем он нужен, разбираемся с Neogenda.

OKR приводит компании к успеху

В 1970-е годы корпорация Intel разработала новый метод управления компанией. В нём команда достигает успеха за счёт правильной постановки цели и постоянного отслеживания ключевых результатов. При этом лидеры получают полное представление о том, что происходит на каждом этапе работы. Свою эффективность метод OKR доказал, когда в 1999 его применили тогда ещё в неразвитой компании Google. Дальше, как говорят, история.
Сегодня метод постановки и достижения целей показывает свою пользу на биржевом рынке. За 2021 год компании, которые его применяли, выросли практически на 100%. Успех OKR в том, что он вдохновляет сотрудников достигать простые и понятные цели, а руководству виден реальный результат и прогресс, которые двигает вперёд всю компанию.

Помогает правильно формулировать и достигать цели

Модель OKR — метод управления в менеджменте. Он состоит из нескольких частей. Первая буква «O» означает Objectives, то есть цели. Это конечные точки в работе, к чему компания стремится и куда направляет свой рост. То, чего нужно достичь.
Сначала нужно поставить глобальную цель компании. Например, выйти на международный рынок. Такая цель амбициозна, на реализацию уйдет много времени и ресурсов. Однако сотрудники и руководство видят направление развития, понимают, чего хочет в конечном итоге достичь компания.
Дальше возникает проблема, как эту глобальную цель достичь. Для этого компания дробит глобальную цель на десятки промежуточных и ставит им конкретный дедлайн. Например, если глобальная цель — выйти на международный рынок, то первая промежуточная может быть такой — увеличить объём продукции на 20% за квартал. Эту цель можно также дробить на несколько более мелких задач.
В итоге все сотрудники работают в этом направлении и встречаются в конечной точке, когда цель достигнута. Но часто бывает путаница. Компании не отличают глобальное с промежуточным. Чтобы этого избежать, нужно правильно использовать OKR.

Даёт конкретные результаты

В аббревиатуре OKR первая буква означает цели, в то время как две оставшиеся расшифровываются как Key results или ключевые результаты. Они закладываются на этапе формирования цели, чтобы в будущем точно понимать, достигнуты они или нет.
Например, компании нужно увеличить количество водителей — это цель.
Ключевой результат № 1: увеличить количество водителей на Х%
Ключевой результат № 2: уменьшить время ожидания машины на Х минут
Это показатели, которые можно отслеживать еженедельно. Так будет понятно, в правильном ли направлении идет работа и, если что-то идёт не так, быстро принимать решения. К ключевому результату добавляют измеримый показатель, который докажет, что цель достигнута. Например, отдел по продажам уменьшил время переработок на пять часов из пяти возможных. Здесь есть однозначное положительное решение с числовым показателем.
Но это не относится к целям на уровне компании. У них не должно быть результатов в цифрах. Те точки развития, которые направляют бизнес, выполняют свои отдельные функции. Они согласовывают все OKR команд с целями компании, чтобы с их помощью она продвигалась вперёд.
Пример
Цель: Занять лидирующее положение по доходам среди студий подкастов в России
Ключевой результат 1: выпустить X подкастов (за квартал)
Ключевой результат 2: увеличить долю рынка с 20% до 30% (за квартал)

Улучшает работу сотрудников

Правильная постановка цели и возможность увидеть реальный результат, также нужны для мотивации. Это один из главных критериев успеха компании. Система OKR рассчитана на улучшение работы сотрудников за счёт их поощрения. Речь идет не только о финансовой стороне вопроса, но и о психологической:
1) В этой системе сотрудники сами выбирают свои цели и ключевые показатели, определяющие результаты.
2) Человеку проще работать, если он понимает, что и зачем он делает. В системе OKR проводятся еженедельные, ежеквартальные или ежемесячные собрания и другие подобные совещания. С их помощью сотрудник отслеживает свои достижения и обсуждает их с коллегами.
3) Установка и достижение целей сплачивает коллектив и вырабатывает систему доверия, когда каждый контролирует свою работу ради общего результата. В 2016 году в журнале Personality and Social Psychology Review появилось исследование, в котором учёные доказали, что от сплоченности коллектива напрямую зависит производительность труда и состояние здоровья сотрудников. Поэтому система OKR — хороший способ улучшить эти показатели.

Создаёт возможность эффективного управления

В модели OKR руководство задаёт общую цель, а подразделения ориентируются на неё и выстраивают собственные. Благодаря чётким ключевым результатам, работу нижних звеньев можно отслеживать и корректировать на любом этапе.
Внедрять инструмент OKR следует поэтапно:
1) собрать небольшую контрольную группу;
2) начать обсуждение, придумать цели и результаты;
3) запустить рабочий процесс;
4) по прошествии установленного срока собрать и оценить результаты;
5) в случае успеха можно масштабировать OKR на подразделение, а затем и на всю компанию.
Важно помнить, что внедрение системы целей и результатов — это не свод жёстких правил, а общая схема работы. Поэтому её аспекты необходимо адаптировать к конкретной организации.
]]> Что делает OKR хорошими? http://neogenda.ru/blog/rz6y9439b1-chto-delaet-okr-horoshimi http://neogenda.ru/blog/rz6y9439b1-chto-delaet-okr-horoshimi?amp=true Thu, 07 Mar 2024 07:49:00 +0300 Андрей Сидоренко Забота о качестве Должен сказать, что я уже много лет обучаю OKR людей и бизнес,...

Что делает OKR хорошими?

Забота о качестве

Должен сказать, что я уже много лет обучаю OKR людей и бизнес, и один из первых вопросов, который кто-либо спрашивает после составления первых OKR (Целей и Ключевых результатов), это: «Хороши ли они?». На самом же деле люди спрашивают: «А это сработает?».
Очень понятное беспокойство. Когда дело доходит до изменений в вашей организации, ставки могут быть высоки. Итак, давайте поговорим о качестве!
Но мы не хотели бы оперировать терминами «хороший или плохой». Вместо этого мы будем говорить об эффективных и о менее эффективных OKR.

Определение эффективных OKR

Во-первых, давайте рассмотрим некоторые общие признаки эффективных OKR.
Помните, OKR описывают ваши главные приоритеты на следующие 30−90 дней. Что ещё более важно, OKR представляют собой значимые изменения, улучшения и рост. По этой причине, часто они могут выглядеть как-будто они просят экстраординарной и непревзойдённой производительности. Это хорошая новость!
Когда речь заходит об OKR, мы говорим о вдохновляющих достижениях, таких как:
  • Внедрение прорывных инноваций
  • Установление различий между вами и вашими конкурентами
  • Признание лидером отрасли в своей категории
Так что, если вы посмотрите на свои OKR и увидите, что они описывают постепенные изменения или легкие цели, возможно, вам нужно мыслить шире.
Кроме того, OKR указывают, что нам нужно делать дальше. Должно быть ясно, соответствуете ли вы и ваша команда критериям успеха!
Давайте разберём далее и рассмотрим цели и ключевые результаты более корректно.

Определение эффективных целей

Чтобы посмотреть на эффективность Целей, давайте конкретизируем наше понимание того, что они из себя представляют.
Цели являются производными от стратегии. Так что, во-первых, если ваша Цель не связана с большей стратегией, она не будет эффективной.
При рассмотрении целей мы часто смотрим на три пункта:
  • Имеет ли она смысл? Является ли цель главным приоритетом? Даёт ли она чёткое направление?
  • Она дерзкая? Принимается ли результат как должное, или она выводит на новый уровень ваше ежедневную деятельность? Представляет ли она значительное изменение по сравнению с тем, где мы находимся сегодня?
  • Она вдохновляет? Легко ли запомнить цель? Даёт ли она силу вашим командам?

Определение эффективных Ключевых результатов

Теперь давайте уточним наше понимание ключевых результатов.
На самом базовом уровне Ключевые результаты должны поддерживать прикреплённую к ним цель. Если неясно, как достижение этих контрольных показателей сделает цель реальной — это первый признак того, что Ключевые результаты могут быть неэффективными.
Как и Цели, эффективные Ключевые Результаты также имеют некоторые общие характеристики, с которыми мы можем их сравнить, чтобы убедиться, что они выполняют свою работу:
  • Являются ли они конкретными и ограниченными во времени? Чётко ли указано, что должно произойти и к какому сроку?
  • Являются ли они агрессивными, но реалистичными? Являются ли они вдохновляющими, но не настолько из ряда вон выходящими, чтобы не реализовать их?
  • Поддаются ли они измерению и проверке? Понятно ли, когда будут соблюдены критерии успеха?

Итоги

  • Эффективные OKR представляют собой значимые изменения, улучшения и рост. Это наши приоритеты на ближайшие 30−90 дней.
  • Эффективные Цели значимые, дерзкие и вдохновляющие.
  • Эффективные Ключевые результаты являются конкретными и ограниченными по времени, агрессивными и реалистичными, а также измеримыми и проверяемыми.
]]> Что такое OKR? Определение и примеры http://neogenda.ru/blog/bv9togv5o1-chto-takoe-okr-opredelenie-i-primeri http://neogenda.ru/blog/bv9togv5o1-chto-takoe-okr-opredelenie-i-primeri?amp=true Fri, 08 Mar 2024 07:51:00 +0300 Андрей Сидоренко Введение OKR (Objectives and Key Results) расшифровывается как «Цели и ключевые результаты». Это эффективный инструмент...

Что такое OKR? Определение и примеры

Введение

OKR (Objectives and Key Results) расшифровывается как «Цели и ключевые результаты». Это эффективный инструмент для постановки целей и превосходства над другими игроками рынка, который позволяет сообщать о том, чего вы хотите достичь, и какие этапы необходимо для этого пройти. OKR используются некоторыми ведущими мировыми организациями для создания и реализации своих стратегий. В этой статье мы дадим определение OKR, посмотрим, как используется этот инструмент, и приведём несколько примеров.

Что такое OKR? Определение и примеры

Аббревиатура OKR расшифровывается как «Цели и ключевые результаты». Это методология коллективного целеполагания, используемая командами и отдельными лицами для постановки сложных, амбициозных целей с измеримыми результатами. OKR — это то, как вы отслеживаете прогресс, управляете согласованностью и поощряете участие в достижении измеримых целей.
OKR работают одинаково для постановки целей на всех уровнях компании: будь то офисная деятельность, разработка ПО, некоммерческая деятельность и т. д. Также OKR могут работать для достижения личных целей и даже использоваться отдельными лицами для выполнения задач там, где высшее руководство их не использует.

Каковы компоненты OKR? Цели и ключевые результаты

Формула OKR
OKR обычно формируют в виде Цели (Objective) верхнего уровня, а под ней — от 3 до 5 поддерживающих ключевых результатов (Key Results). Их также можно записать в виде утверждения:
Я достигну (Цель) измеримую (Ключевыми результатами).
Например: «Я стабилизирую сайт для большинства пользователей, это измеряется тем, что 7 из 10 человек достигнут результата, при этом время отклика составит — 1 секунда, а частота ошибок — 1%».
Цели (Objectives)
Цель — это то, что должно быть достигнуто, ни больше ни меньше. По определению, цели значимы, конкретны, ориентированы на действия и (в идеале) должны быть вдохновляющими. Если их правильно формулировать и применять, то они станут вакциной от неконкретного мышления и неэффективного исполнения.
Ключевые результаты (Key Results)
Ключевые результаты — это контроль за тем, как мы добивается Целей. Эффективные KR конкретны, привязаны ко времени и агрессивны, но в то же время реалистичны. Прежде всего, они измеримы и отслеживаемы. Вы либо соответствуете требованиям ключевого результата, либо нет — нет неопределённости, нет места для различных трактовок. В конце определённого периода (обычно квартала), мы проводим регулярную сверку и оцениваем ключевые результаты как выполненные или невыполненные.
Там, где цель может быть долгосрочной, отложенной на год или дольше, Ключевые результаты развиваются по мере продвижения работы. Как только все они будут выполнены, цель будет достигнута.

Кто создал OKR?

Методология OKR была создана Энди Гроувом из Intel, он же и обучил этому подходу Джона Дорра. С тех пор OKR приняли многие компании, в том числе Google, Allbirds, Apartment Therapy, Netflix и ряд некоммерческих организаций, такие как Code for America.
В книге «Измеряйте самое важное» Джон Дорр пишет о MBO или «Управлении по целям» (Management by Objectives). MBO были детищем Питера Друкера и послужил Энди Гроуву основой для его теории OKR. На самом деле Гроув изначально называл их «iMBO», что означает «Управление по целям Intel» (Intel Management by Objectives). Несмотря на первоначальное название, Гроув заложил некоторые важные различия между ними, которые он передал Дорру.
Гроув редко упоминал Цели, не связывая их с «Ключевыми результатами» — этот термин, который он придумал сам. Другие ключевые различия между MBO и OKR заключаются в том, что отслеживание последних проводится ежеквартально, а не ежегодно, и не связаны с вознаграждением.
Дорр был тем, кто придумал название «OKR». Он познакомил основателей Google с этой философией в 1999 году. Собравшись за столом для пинг-понга, который использовался как стол в зале заседаний, Дорр продемонстрировал презентацию в PowerPoint молодой команде основателей. В неё входили Ларри Пейдж, Сергей Брин, Марисса Майер, Сьюзан Войжитски и Салар Камангар.
Цель и Ключевые результаты Дорра по той презентации были следующими:
О. Создать модель планирования для их компании, измеряемую тремя ключевыми результатами:
KR1. Я закончу свою презентацию вовремя.
KR2. Мы создадим набор примеров ежеквартальных OKR для Google.
KR3. Я получу согласие руководства на трёхмесячный тестовый период OKR.
*Из книги: «Измеряйте самое важное»

Примеры OKR

Какие есть примеры OKR высокого уровня?
Город Сиракузы, штат Нью-Йорк, недавно поставил перед собой цель: «Достичь финансовой устойчивости». Финансовая устойчивость — великая цель, но она должна быть измеримой. Вот почему Сиракузы использует Цели и Ключевые результаты. В письменном виде OKR Сиракуз выглядит так:
О. Достичь финансовой устойчивости.
KR1. Сократить отклонение бюджета с 11% до 5%.
КR2. Израсходовать 95% от уставного капитала проекта в долларах до конца финансового года.
КR3. Потратить 95% от суммы грантов в долларах
Давайте рассмотрим ещё один пример OKR.
Allbirds — популярная компания по производству одежды, известная своей экологичной обувью. У них есть миссия «создавать лучшие вещи лучшим способом». В рамках своей приверженности принципам устойчивого развития они решили, что их обувь должна быть углеродно-нейтральной. Итак, они написали эти OKR:
О. Создать самый низкий углеродный след в нашей отрасли.
KR1. Цепочка поставок и транспортная инфраструктура на 100% безотходны.
KR2. Платить 100% углеродную компенсацию за расчётные выбросы углекислого газа.
KR3. 25% материала компостируется.
KR4. 75% материала биоразлагаемо.
OKR могут работать в любой части организации и не обязательно должны быть на высшем уровне. Давайте рассмотрим пример OKR для конкретной команды и отдела.
Например, команда разработчиков в музее хочет расширить свою клиентскую базу (покупателей абонементов). Они поняли, что способы, которые использовали устарели и не нравятся новому поколению посетителей музеев. Они могли бы использовать эти OKR:
О. Привлечь различных молодых владельцев сезонных абонементов.
KR1. Увеличить на 100% число участников программы «30 долларов — до 30 лет».
KR2. Попасть в Instagram-аккаунтах пяти местных влиятельных людей.
KR3. Получить реакцию 25% получателей прямой почтовой рассылки на различные почтовые индексы.
KR4. Привлечь 75 новых человек в месяц, не являющихся членами клуба, на живые встречи с артистами.
Некоторые люди добились успеха, устанавливая личные OKR. Вот пример, написанный кем-то, кто хочет пробежать 10 км:
О. Пробежать 10 км менее чем за 50 минут к июню.
KR1. Бегать 3 раза в неделю не менее 30 минут.
KR2. Увеличить дистанцию бега на 1 милю каждую неделю.
KR3. Увеличить скорость прохождения 1-й мили на 5 секунд каждую неделю.

Какие типы OKR существуют?

OKR могут быть трёх видов: Обязательные, Амбициозные или Обучающие.
Обязательные OKR, как следует из их названия, — обязательства. Ожидается, что при оценке в конце цикла «Обязательные OKR» будут иметь высокую степень выполненности.
Амбициозные OKR иногда называют растягивающими целями или «запуском ракеты на Луну» (moonshots). Следует понимать, что путь к Амбициозным OKR проходится долго, поскольку никто другой не достигал этого раньше. Амбициозные OKR также могут быть долгосрочными и существовать вне цикла OKR или даже передаваться между членами команды, чтобы увеличить вовлечённость сотрудников.
Обучающие OKR нужны, когда изучение чего-то нового является наиболее ценным результатом цикла. Если команда не знает, что делать дальше, она может установить Обучающие OKR, отвечающие на вопрос: «Какая самая важная вещь, которую мы пытаемся понять в следующие 90 дней?». Затем результаты могут быть использованы для соответствующих Обязательных или Амбициозных OKR в следующем периоде.

Преимущества OKR

OKR обеспечивают множество преимуществ: ясность, улучшенную коммуникацию и последовательную, прозрачную стратегию в масштабах всей организации. Джон Дорр всегда говорит о F.A.C.T.S. при описании преимуществ OKR. F.A.C.T.S. означает:
  • Фокус (Focus): OKR позволяют команде сплотиться вокруг небольшого набора тщательно выбранных приоритетов.
  • Выравнивание (Alignment): OKR предоставляют метод для всей организации, чтобы согласовать свои цели на каждом уровне с приоритетами высшего уровня и конечной целью.
  • Обязательство (Commitment): OKR требуют определённого уровня коллективной ответственности от вовлечённых сторон, чтобы выбрать согласованные приоритеты и придерживаться их.
  • Отслеживание (Tracking): OKR позволяют команде или организации отслеживать свой прогресс в достижении цели и заранее знать, когда следует изменить тактику.
  • Растягивание (Stretching): OKR позволяют командам ставить цели, выходящие за рамки BAU — или «бизнес как обычно» (business as usual) — и вносить значительные и значимые изменения.

Распространённые ошибки OKR

Написание OKR — это навык, который требует практики и времени для развития. Каждый набор OKR должен включать обратную связь внутри организации и подвергаться множественным проверкам.
Есть несколько распространённых ошибок, которых следует избегать при написании OKR:
  • Избегайте тактики «бизнес как обычно»: OKR должны быть направлены на изменение, а не на сохранение статуса-кво.
  • OKR против KPI: OKR — это больше, чем просто KPI (ключевые показатели эффективности). Это показатели изменений, тогда как KPI — показатели здоровья.
  • «Мешки с песком»: OKR предназначены для того, чтобы «взбодрить» команду, и их успех не должен быть чем-то само собой разумеющимся.

Как вы оцениваете OKR?

OKR предназначены для регулярного отслеживания и оценки в конце цикла. Существует несколько методов оценки OKR.
Метод Энди Гроува для оценки OKR — это простой подход «да» или «нет». Вы достигли этого? Или нет? Большинство организаций предпочитают более детализированные оценки, поэтому они будут использовать систему светофора «красный, желтый, зеленый», где красный означает «мы потерпели неудачу», жёлтый означает «мы добились прогресса», а зелёный — «мы достигли нашей цели».
Метод оценки Google обеспечивает наиболее подробную информацию, используя процентную шкалу (0,0−1,0), чтобы дать каждому ключевому результату числовой балл в конце цикла. Они усредняют баллы ключевых результатов, чтобы определить общий балл этой цели.
]]> Управление потоком — часть 2: взгляд за пределы команды http://neogenda.ru/blog/oh6hbv3141-upravlenie-potokom-chast-2-vzglyad-za-pr http://neogenda.ru/blog/oh6hbv3141-upravlenie-potokom-chast-2-vzglyad-za-pr?amp=true Sat, 09 Mar 2024 07:54:00 +0300 Алексей Пименов Перевод статьи Fernando Cuenca, размещённой на squirrelnorth.com. Оригинал можно прочитать здесь. В первой части этой серии статей, я указал, что поток...

Управление потоком — часть 2: взгляд за пределы команды

Перевод статьи Fernando Cuenca, размещённой на squirrelnorth.com. Оригинал можно прочитать здесь.
В первой части этой серии статей, я указал, что поток не является головной болью на командном уровне. Это значит, что поток, который действительно имеет значение — поток, воспринимаемый Клиентом. И обычно он должен переплетаться через несколько команд по мере перехода от «Я обещаю» к этапу «Готово!». Во второй части мы опишем некоторые модели поведения, которые необходимо принять, если мы хотим начать управлять потоком за пределами команды.

Вступление: Исходная Позиция «Фокус на команду»

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

Расширение поля зрения

В первой части кратко упоминалась, что во время перехода к Клиентоориентированной организации, исчезает поведение «смотреть внутрь себя». Этот переход начинается с появления кого-то, кто явно берёт на себя ответственность за расширение поля зрения, чтобы начать управлять сквозным рабочим потоком. Этот человек связан с Клиентом и в начале и в конце. Это может принимать разные формы (обсуждение выходит за рамки данной статьи), но достаточно сказать, что это может быть один человек или группа, внутри команды или извне, и что это ключевой акт лидерства, необходимый для скачка в зрелости.
Под этим руководством необходимо применить практику, обеспечивающую три основных типа поведения:
  • Понимание того, кто наш клиент и что для него важно
  • Получение базовых знаний о сквозном процессе
  • Принятие мер по устранению системных барьеров потока

Кто наши Клиенты? Что их волнует?

Если мы намерены оптимизировать поток с точки зрения клиентов, которых мы обслуживаем, то в первую очередь важно знать, кто эти клиенты. На удивление часто встречаются команды, которые не могут дать чёткий и недвусмысленный ответ на вопрос: «Кто ваш клиент?».
Второй вопрос, который следует задать: «Какими видами деятельности вы занимаетесь?». Командам легче ответить на него. Часто ответы будут включать такие вещи, как «пользовательские истории», «баги», «тесты», «задачи» и т. д. Независимо от ответа, вот два дополнительных вопроса, которые вы можете задать. Спросите: «Можете ли вы содержательно поговорить об этих видах деятельности со своим клиентом?» и «Достаточно ли они значимы для клиента, чтобы использовать их в качестве предмета торга в процессе пополнения?» (то есть: «Это то, что их волнует?»).
Относительно простой способ изменить ситуацию — убедиться, что мы формулируем работу с точки зрения людей, которые получат от неё пользу, используя типы работ с узнаваемыми ими названиями. Если мы можем вести содержательный разговор с Клиентом о конкретной части работы так, чтобы это имело для него значение и могло использоваться в качестве предмета торга в процессе пополнения, то тогда мы называем это «Распознаваемый клиентом тип рабочего элемента»». Типичными примерами распознаваемых клиентами типов работ могут быть: «эпики», «фичи», «возможности», «проекты», «сценарии использования» и т. д.
Вы можете быть удивлены, не найдя «пользовательские истории» в приведённом выше списке примеров. Фактически, пользовательские истории могут быть сформулированы так, чтобы соответствовать критериям распознаваемости клиентами (и можно даже утверждать, что это именно то, «как истории должны использоваться»). Однако в реальном мире такое встречается редко: чаще всего пользовательские истории пишутся, чтобы удовлетворить потребность в разделении части работы на управляемые кусочки. В процессе они либо становятся нераспознаваемы для Клиента (как в случае с «техническими историями»), или недостаточно осмысленными, чтобы принимать компромиссные решения (например, история, которая просто добавляет кнопку на экран), или и то, и другое.
Также вы можете прийти к выводу, что рабочие элементы, распознаваемые клиентом, всегда являются «крупными частями работы». Возможно, в целом они будут больше, чем задачи на уровне отдельных команд. Однако, ничто не мешает вам работать с вашим Клиентом так, чтобы в процессе взаимного обучения и согласования, работа могла быть разделена на всё более и более мелкие части, которые сохраняют распознаваемость и ценность. Уменьшение размера пакета всегда считалось способом увеличения потока, поэтому постепенное уменьшение размера «эпиков» и «фич» (возможно, до такого размера, чтобы мы назвали это просто «историей») может быть желанной целью.
В то же время моделирование работы с помощью распознаваемых клиентом элементов не обязательно означает полное устранение типов работы, обращённых внутрь себя. В некоторых случаях может быть полезно сохранить их (по крайней мере на начальном этапе), но в качестве второстепенных задач, которые являются частью доставки работы, распознаваемой клиентом.
Такая смена парадигмы может помочь повысить осведомлённость о сервисном характере работы, которую выполняет группа. Это очень распространённый первый шаг в переходе от ориентации на команду к ориентации на клиента.

Смотреть шире и дальше

Что происходит с работой перед тем, как она попадает к вашей команде? Что происходит с ней после того, как команда говорит, что работа выполнена? Как правило, вы обнаружите, что вокруг процесса, который команда считает своим собственным, также существует некая форма процесса «доработки». Она необходима для подготовки работы. А также есть ещё один процесс-«Релиз», необходимый для её выпуска.
Часть процесса доработки на самом деле происходит внутри команды (часто под такими названиями, как «груминг» или «оптимизация бэклога»), но это редко визуализируется. В конечном итоге нечто подобное происходит с действиями по релизу: часто обнаруживается, что после того, как работа была названа «выполненной», для её выпуска всё ещё требуется несколько действий (настройка feature toggle, запуск скриптов развёртывания, написание примечаний к релизу и т. д.)., но часто эта работа представлена в виде дополнительных «технических историй» или вообще не визуализирована. В обоих случаях результатом является то, что эти действия остаются неявными и не признаются частью рабочего процесса.
Я писал в другой статье более подробно о том, как вы можете расширить своё поле зрения, чтобы сделать доработку и релиз более видимыми. Результатом является появление восходящего и нисходящего рабочего процесса, который начинает повышать осведомлённость о более длительном, сквозном пути, который работа должна пройти.
Как только поле зрения становится шире, становится очевидным, что команда не одна участвует в этом сквозном рабочем процессе: другие команды и группы могут быть вовлечены в эти нисходящие и восходящие действия. Теперь становится понятно, что их нужно учитывать при попытке управлять потоком на этом уровне.
Вы можете, конечно, продолжить и расширить поле зрения ещё вверх и вниз по течению потока, насколько позволяет ваша сфера влияния.
Наконец, более широкий взгляд на рабочий процесс может помочь лучше понять обязательства: в какой момент мы даём обещания клиентам и какова природа этих обязательств? Как долго нам нужно работать, чтобы выполнить это обязательство? С этим пониманием мы получаем возможность выполнять некоторые элементарные измерения Системного времени выполнения (System Lead Time), делая первые шаги к количественному анализу потока.

Устранение системных барьеров для потока

Взяв всё это за основу, теперь мы можем понять, что мешает гладкому течению работы, и предпринять корректирующие действия: сквозная визуализация позволит увидеть места, где накапливается работа. А количественные измерения (даже если они неточны) могут позволить увидеть, как время выполнения заказа распределяется во времени. И мы можем задать вопросы о тех случаях, которые заняли слишком много времени. Всё это может помочь сузить фокус нашего внимания при поиске возможностей для улучшения.
Старение WIP — это относительно простой индикатор, который также можно отслеживать, чтобы определить работу, которая перестала двигаться. И это может быть просто добавление «точек» на тикеты с каждым прошедшим днем. Затем можно объединить с определением «триггерных точек», чтобы предпринять какие-либо действия, если конкретная часть работы слишком долго оставалась на доске.
В дополнение к задержкам, вызванным многозадачностью при высоком уровне WIP, типичные препятствия для потока включают: ожидание внешних зависимостей, зависимость от немгновенной доступности ресурсов и ожидание в очередях и буферах.
Важно понимать, что устранение отдельных блокеров, влияющих на определённые рабочие элементы, является важным аспектом управления потоком, но обнаружение системных причин этих блокеров может иметь гораздо большее влияние.
Для этого нам нужно уметь обнаруживать общие закономерности, которые имеют тенденцию повторяться. Полезным методом для этого является кластеризация блокеров. Это метод, впервые предложенный Клаусом Леопольдом. Он заключается в маркировке рабочих элементов «тикетами блокеров», которые впоследствии собираются и анализируются. Это делают, чтобы выяснить, как блокеры объединяются в течение времени, а далее используют эту информацию для определения воздействия, вероятности и вариантов коррекции.
]]> Управление потоком. Часть 1: От командного потока к клиентскому потоку http://neogenda.ru/blog/f564oaln31-upravlenie-potokom-chast-1-ot-komandnogo http://neogenda.ru/blog/f564oaln31-upravlenie-potokom-chast-1-ot-komandnogo?amp=true Sun, 10 Mar 2024 15:32:00 +0300 Алексей Пименов Перевод статьи Fernando Cuenca, размещённой на squirrelnorth.com. Оригинал можно прочитать здесь. Что это за «поток»? Когда мы говорим об «управлении..

Управление потоком. Часть 1: От командного потока к клиентскому потоку

Перевод статьи Fernando Cuenca, размещённой на squirrelnorth.com. Оригинал можно прочитать здесь.

Что это за «поток»?

Когда мы говорим об «управлении потоком», какой именно «поток» мы имеем в виду?
Есть аспект потока, который относится к личной производительности. Он достигается в зоне, которая пересекает наш воспринимаемый уровень сложности с нашим уровнем мастерства: люди (и команды) находятся «в этой зоне», когда они чувствуют, что их работа продвигается с лёгкостью, будто время остановилось. Этот вид потока, безусловно, нуждается в управлении, но это не тот поток, на который ссылается Канбан в своей основной практике «управляйте потоком».
Давайте вспомним, что Канбан поощряет нас управлять работой, а не работниками. Эта работа должна двигаться с точки, где обещание доставки предоставлено клиенту до другой точки позже, когда обещание будет выполнено и эта ценность будет доставлена. У клиентов есть ожидания относительно того, насколько быстрой и предсказуемой должна быть доставка. Также мы знаем, что регулярная (или бесперебойная) доставка ценности помогает укрепить доверие. Поэтому, важно обращать внимание на то, как работа движется (или течёт) между этими двумя точками (от «Я обещаю» до «Готово!»), если мы хотим предложить нашим Клиентам услуги или сервисы, соответствующие их предназначению.

Поток — это не заботы командного уровня

Agile-командам обычно рассказывают о том, как важно уделять внимание потоку, который затем интерпретируется как обеспечение плавного перехода работы от «Нужно сделать» к «Сделано». Чем всё это отличается от движения от «Я обещаю» к «Готово!»?
Во-первых, момент «Я обещаю» часто происходит «выше по течению» по отношению к команде, и очень часто раньше по времени, т. е. до того, как команда примет участие. Это говорит о том, что ещё до того, как работа попадёт в бэклог команды или в колонку «Нужно сделать» на их доске, должен быть какой-то процесс, позволяющий осуществить это движение.
С другой стороны, момент «Готово!» так же часто сдвинут по времени по сравнению с моментом, когда команды объявляют рабочие элементы «выполненными». Даже когда команды внедряют методы непрерывной поставки, нередко требуется «выполнить» минимальный набор действий, прежде чем клиенты смогут их увидеть (часто с помощью «feature toggles»). В более традиционных средах процедуры интеграционного тестирования, сертификации и управления релизами обычно применяются в конце процесса разработки.
Дополнительный фактор, который следует учитывать: обычно этапы между «Я обещаю» и «Готово!» не выполняются одной командой. Чаще всего мы можем наблюдать, что нескольким командам, группам и отдельным лицам (часто из нескольких отделов) необходимо сотрудничать, чтобы обеспечить ценность для Клиента.
Хотя поток в рамках команды — это то, на что следует обратить внимание, чтобы управлять потоком от начала до конца и сделать его соответствующим предназначению, нам нужно смотреть за пределы команды и сосредоточиться на «пустом пространстве» между ними.
Эта способность выходить за рамки команд для повышения эффективности сквозной поставки, требует введения новых моделей поведения, которые выходят за рамки создания хорошо функционирующих и высокопроизводительных команд.
В Канбане мы описываем это расширение фокуса, как вопрос повышения «организационной зрелости», как это заложено в модели зрелости Канбана (KMM).
KMM описывает последовательность «прото этапов», которые организации обычно проходят по мере развития своих возможностей. Модель можно использовать в качестве «дорожной карты», чтобы помочь организации перейти между этими этапами. Это происходит, благодаря принятию конкретных практик, которые, как было замечено, помогают продвигать и закреплять этот переход. Переход с одного уровня зрелости на другой достигается за счёт введения новых моделей поведения и конкретных практик. И всё это, как мы надеемся, приведёт к лучшим результатам.

Путь к управлению потоком более высокой зрелости

Предполагая, что ваша организация достигла способности организовывать людей в относительно хорошо функционирующие команды, как вы расширяете своё видение, чтобы улучшить поток, воспринимаемый клиентами?
Когда вы смотрите на KMM как на руководство, обратите внимание, что организация с уровня «Фокус на команды» (уровень зрелости 1) уже справилась с «проблемой командной работы». Однако, эти команды зачастую «смотрят внутрь себя»: акцент на командной работе может легко привести к ситуации, когда каждая группа развивает свою собственную идентичность. Они становятся очень сплочёнными, чувствуют, что у них есть миссия, и они вкладывают в это всю свою энергию. Недостатком является то, что этим командам очень легко научиться мыслить локально, а не глобально, а также развить понимание работы и процессов управления ею, которые в большей степени ориентированы на их внутренние потребности, чем на потребности их Клиентов.
Некоторые организации могут оставаться на этом этапе долгое время, даже бесконечно. Но многие, в конечном итоге, переходят на следующий уровень. В конце концов кто-то берёт на себя ответственность и начинает понимать, что команды являются частью более крупных потоков создания ценности или систем доставки, которыми необходимо управлять как проблемой самого высокого уровня, а не ожидать, что общая оптимизация произойдёт в результате оптимизации отдельных команд. Взяв на себя ответственность за эту сквозную систему, этот человек пытается собрать общую картину воедино. В этот момент поле зрения начинает выходить за рамки команды и ориентироваться на сквозные потоки создания ценности. Понимание работы и клиента углубляется, организация становится более «Ориентированной на клиента» (Уровень зрелости 2). В результате клиенты начинают получать лучший сервис, хотя они все равно будут описывать его как ненадёжный и непоследовательный.
С точки зрения новых моделей поведения для управления потоком, этот переход зрелости от «команд, смотрящих в себя» к «системе клиентоориентированных команд» требует:
  • Понимания того, кто является клиентом и что для него важно;
  • Получения базовой осведомлённости о сквозном процессе;
  • Принятия мер по устранению системных барьеров для потока.
Как только будут достигнуты сквозное понимание потока и видимость, наступит следующий этап эволюции, когда весь поток создания ценности будет сосредоточен на том, чтобы сделать клиентский опыт «Соответствующим предназначению» (Уровень зрелости 3). Основное отличие этого этапа от предыдущего — клиент воспринимает сервис как надёжный и дающий стабильные результаты.
Новые модели управления потоками, которые превращают организацию из «системы клиентоориентированных команд», в организацию «Соответствующую предназначению», включают:
  • Развитие более глубокого понимания действий в рабочем процессе
  • Развитие базовой способности формировать спрос
  • Повышение количественного понимания потока
  • Развитие способности к прогнозированию
  • Понимание того, что именно делает ваш сервис «соответствующим предназначению»
Однако есть одна загвоздка: на данном этапе очень легко удовлетворить потребности клиентов способами, которые в долгосрочной перспективе являются неприемлемыми для организации. Подумайте о случае, когда компании создают продукты, которые нравятся клиентам, но оставляют за собой много технических долгов, или нарушают и обходят некоторые нормативные акты, которые теперь подвергают компанию юридическому риску.
Чтобы улучшить эту ситуацию, организации необходимо развить способность управлять работой так, чтобы сбалансировать многочисленные потребности и риски, став организацией с «Хеджированием рисков» (Уровень зрелости 4). По сути, речь идёт о том, чтобы прийти к пониманию, что всем будет лучше, если организация будет устойчивой в долгосрочной перспективе. Клиентам нравится надёжный сервис, но не нравится, когда услуги и продукты, к которым они привыкли, неожиданно исчезают. И это также плохо для стейкхолдеров.
Модели управления потоками, которые обеспечивают этот переход от организации «Соответствующей предназначению» к организации «Постоянно соответствующей предназначению», являются:
  • Развитие способности предпринимать чёткие действия для сглаживания потока в рамках рабочего процесса
  • Повышение сложности количественного анализа
  • Развитие способности чётко распределять потенциал
В оставшихся статьях этой серии мы более подробно рассмотрим конкретные практики, связанные с этим поведением.
]]> Сегментация рынка на основе «Почему» http://neogenda.ru/blog/4ahx4sxhc1-segmentatsiya-rinka-na-osnove-pochemu http://neogenda.ru/blog/4ahx4sxhc1-segmentatsiya-rinka-na-osnove-pochemu?amp=true Mon, 11 Mar 2024 15:36:00 +0300 Перевод статьи Дэвида Андерсона, размещённой на medium.com. Оригинал можно прочитать здесь. После моей статьи об оценке сервисов с помощью Fitness Box...

Сегментация рынка на основе «Почему»

Перевод статьи Дэвида Андерсона, размещённой на medium.com. Оригинал можно прочитать здесь.
После моей статьи об оценке сервисов с помощью Fitness Box Score я подумал, что хочу объяснить, как мы используем эти результаты для сегментации рынка. А также хочу предоставить идеи об особенностях, функциях и уровнях сервисов поставки, ожидаемых для каждого сегмента. Это не «дедовская» сегментация рынка на основе демографических данных. Это сегментация, основанная на целях потребителя — сегментация на основе «Почему!».
Как мы узнаем, является ли изменение улучшением? Если мы инвестируем в улучшение возможностей предоставления сервисов, действительно ли это сработает? Станет ли сервис в последствии более соответствующим предназначению? Ценят ли это потребители? Если мы инвестируем в особенности сервиса, функции или возможности сервисов, оценят ли это потребители? Не переобслуживаем ли мы рынок, предлагая слишком много, и возможно, слишком рано?
Это справедливые и разумные вопросы. Они должны управлять нашими решениями о портфеле сервисов, как мы ими управляем, как мы принимаем решения и куда мы выбираем инвестировать, консолидировать и расширять.
Согласно теории эволюции, мутация выживает и процветает, если она «более соответствует» для окружающей среды (на самом деле это грубое упрощение, но оно подходит для вводной части по маркетингу и стратегии). Итак, как мы узнаем, сделало ли изменение в наших возможностях сервиса поставки его более соответствующим для окружающей среды? Что мы подразумеваем под «окружающей средой» в этом контексте?
«Окружающая среда» — это рынок, на который мы поставляем продукты или услуги. Таким образом, «соответствие» определяется тем, насколько рынок воспринимает наш продукт или услугу и их поставку, «соответствующими предназначению». Поэтому, чтобы понять «соответствие» для обеспечения и стимулирования эволюционных улучшений, нам сначала нужно понять наш рынок и то, что определяется «соответствие предназначению». Для этого мы сегментируем рынок по целям клиентов и критериям, по которым они оценивают наше «соответствие для [этой] цели»…
Сервисы, «соответствующие предназначению»: инновации, исполнение и доставка — всё это вносит свой вклад
В Lean Kanban Inc мы сегментируем рынок с помощью кластеризации рассказов о наших клиентах. Мы делаем это, рассказывая о них истории. Эта техника является прямым применением техники Дейва Сноудена из его Cynefin Framework. Для объяснения, я рассказываю историю о Ните – вымышленном менеджере проекта и матери 4-х детей. Прообраз Ниты – это реальная женщина, которая работает в канадском государственном секторе и имеет значительный опыт в улучшении предоставления сервисов в агентстве провинции Онтарио. Ните нужно заказать доставку пиццы в офис, чтобы накормить свою команду, которая работает допоздна. В другой вечер этой же недели, ей нужно заказать доставку пиццы домой, чтобы накормить своих детей, которые проголодались, потому что она пришла домой поздно. Нита представляет не один сегмент рынка, а два! Причина в том, что цель, контекст и критерии выбора соответствия различны в каждом из двух контекстов.
Нита — типичный потребитель службы доставки пиццы
Когда Нита заказывает пиццу для своих детей, ей необходимы: быстрая доставка (в идеале в течение 20 минут); ей нужна точность заказа — детям нравится только простая пицца с сыром; её не слишком волнует нефункциональное качество — дети будут есть даже холодную пиццу, если это пицца с сыром; ей нужно простое меню и предсказуемое обслуживание; она хочет получить пиццу в обещанный срок, потому что детям нужно оправдать свои ожидания, и они неумолимы; она также заботится о том, чтобы в ресторане была чистота и соблюдение правил техники безопасности; её может волновать, используют ли они натуральные ингредиенты, потому что она кормит свою семью.
Когда Нита заказывает пиццу в офис, её потребности аналогичны, но некоторые критерии различаются и пороговые значения разные: ей нужно получить пиццу в течение 90 минут; точность заказа важна, но если будут 1−2 ошибки — это не будет иметь большого значения, до тех пор пока в заказе есть вегетарианские пиццы. Однако нефункциональное качество теперь имеет значение — горячая, вкусная, пицца с изысканным вкусом и экзотическими ингредиентами необходима этим взыскательным гикам; неважно, если доставка не так предсказуема, ведь команда занята работой; и да, Ниту всё ещё волнует, соответствует ли ресторан стандартам безопасности, но натуральность ингредиентов, вероятно, не так уж и важна.
Другими словами, Нита решает, нравится ли ей доставка пиццы и будет ли она пользоваться ею снова, на основе двух разных наборов критериев, в зависимости от её контекста. Это может привести к тому, что она будет использовать разных поставщиков для каждой цели, если один поставщик не сможет удовлетворить оба набора её потребностей. В результате Нита представляет собой два сегмента, а не один.
Откуда вы знаете, что Нита представляет собой два сегмента, а не только один? Традиционное демографическое профилирование не дало бы вам такого понимания! Возможно, она использует разные кредитные карты или механизмы оплаты в зависимости от контекста? И адрес доставки другой. Итак, есть несколько очевидных доказательств. Однако люди в бизнесе, которые знают историю Ниты, — это человек, который принял её заказ по телефону, и курьер, который доставил пиццу. Именно эти сотрудники лучше всего понимают потребителей.
Персонал, работающий непосредственно с клиентом, больше всего знает о потребителях и целях, которые побуждают их к совершению покупок.
Если вы собираетесь сгруппировать рассказы клиентов для сегментации, вам необходимо привлечь к участию в сторителлинг-сеансах персонал, напрямую работающий с клиентом. Вам нужно прислушиваться к контексту, цели и критериям выбора и создавать сегменты, основанные на близости этих аспектов рынка. Дайте каждому кластеру никнейм. Помните, что отдельный клиент может появляться в нескольких сегментах в зависимости от их контекста в определённый день и время.
Результаты сеанса кластеризации рассказов о клиентах
На этом рисунке показаны результаты сегментации рынка на сессии стратегического планирования 2012 года для Lean Kanban Inc и, в частности, лицензированного и сертифицированного учебного заведения Lean Kanban University. Шесть сегментов были идентифицированы путём сторителлинга о реальных клиентах и группирования рассказов по сходству с последующим присвоением им запоминающихся имён — GRQ (расшифровывается как get rich quick, т. е. «быстро разбогатеть»). Мы отказались от этого сегмента в 2016 году, успешно изменив восприятие рынка, чтобы избежать клиентов с такими ожиданиями.
Для многих компаний проблема здесь заключается в том, что люди, которые лучше всего понимают контекст, цель и критерии выбора клиента, часто являются сотрудниками с самой низкой оплатой, коротким сроком работы и самой высокой текучестью кадров в бизнесе. По глупости многие компании недооценивают ценность сотрудников, работающих с клиентами. Традиционные компании 20-го века по оказанию услуг придерживаются транзакционного взгляда на взаимодействие с клиентами, а не взгляда с точки зрения отношений. Если вы цените повторный бизнес и цените идеи, которые позволят вашему бизнесу развиваться и выживать на быстро меняющемся рынке, тогда вам необходимо ценить людей, ориентированных на клиентов, и вовлекать их в своё стратегическое планирование.
Как только у вас будут сгруппированные рассказы, определяющие ваш сегмент, выберите сегменты, которые вы хотите обслуживать. Это ключевой элемент стратегического планирования. В каком бизнесе вы хотите работать? А что вас не волнует совсем? Что вы не хотите поощрять? На основе этого вы разработаете метрики соответствия, которые будут способствовать принятию управленческих решений и эволюционному совершенствованию.
Теперь создавайте свои сервисы с учётом потребностей каждого сегмента. Например, представьте, что мы разработали службу доставки пиццы премиум-класса для матери, которой нужно накормить голодных детей? Мы гарантируем 20-минутную доставку в радиусе от нашего ресторана с 16:00 до 19:00 каждый вечер. Нам нужно зарезервировать некоторое количество свободных духовок. Нам нужно простое меню и пицца, подготовленная для выпекания. Для выполнения SLA нам может потребоваться резервный персонал по доставке. Сколько это может стоить? Выборка среди проджект-менеджеров на конференции в Стокгольме, в Швеции, в 2014 году, дала ответ — 60 шведских крон (или около 6 долларов США). Теперь вы должны решить, хотите ли вы этот премиальный бизнес с более высокой маржой? Можете ли вы создать предложение? Сможете ли вы успешно донести это до целевой аудитории? Вот в чём суть действительно эффективного стратегического планирования!
]]> Визуализация работы. Часть 2. Делаем рабочий процесс видимым http://neogenda.ru/blog/nn8tsb8zk1-vizualizatsiya-raboti-chast-2-delaem-rab http://neogenda.ru/blog/nn8tsb8zk1-vizualizatsiya-raboti-chast-2-delaem-rab?amp=true Tue, 12 Mar 2024 15:41:00 +0300 Алексей Пименов Перевод статьи Fernando Cuenca, размещённой на squirrelnorth.com. Оригинал можно прочитать здесь. Что представляет собой ваш процесс? Когда команды...

Визуализация работы. Часть 2. Делаем рабочий процесс видимым

Перевод статьи Fernando Cuenca, размещённой на squirrelnorth.com. Оригинал можно прочитать здесь.

Что представляет собой ваш процесс?

Когда команды сталкиваются с этим вопросом, то часто ответом является описание ролей исполнителей, и то, как работа передаётся от одного человека к другому:

Процесс, состоящий из ролей

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

Доска с ролевыми шагами

Возможно, нам нужен другой взгляд на этот вопрос.
Совместный поиск знаний, вместо передачи
Проблемы, возникающие при попытке смоделировать передачу данных, могут быть решены с помощью другого подхода и понимания того, что разработку ПО можно рассматривать как упражнение в поиске знаний. Алексей Жеглов много писал об этом процессе; вот ещё один способ подумать об этом:
Представьте, что вы разговариваете с группой друзей, когда поднимаетесь по этой лестнице с целью полюбоваться видом с вершины. Разговор прыгает с темы на тему в случайном порядке. Возможно, вы говорите о том, по какой лестнице идти дальше, или комментируете вид. С каждым шагом вы лучше видите окружающий ландшафт, но вы продолжаете идти, ваша цель — добраться до вершины, поэтому вы не идёте обратно.
Мы также можем рассматривать разработку как «путешествие», в котором мы совершаем открытия, узнаём что-то новое по ходу дела и находим путь по ходу дела. Мы всегда добиваемся прогресса. Каждый раз могут потребоваться разные действия, возможно, в том же или другом порядке, и повторяться по мере необходимости. Но познание никогда не возвращается назад

Процесс поиска знаний с «доминирующими видами деятельности»

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

Доска с шагами поиска знаний

Колонка «Описание» на картинке выше — это не та часть, где бизнес-аналитики пишут истории, или проводят «груминг-митинг», но это место, где мы совместно работаем над ответом на вопрос «понимаем ли мы особенности?» Точно так же колонка «Верхнеуровневое представление» предназначена не для представления работы архитектора или ведущего разработчика, а для совместной работы, чтобы ответить на вопрос «Знаем ли мы, как это построить?» Архитектурное проектирование, выполняемое архитектором, может быть доминирующим видом деятельности на данном этапе, но, возможно, во время проектирования мы обнаружим, что нам нужно больше спецификаций или что нам нужно реализовать быстрый вброс, чтобы попробовать что-то и т. д.
На каждом этапе мы продвигаемся в башне на один пролёт вверх: от неопределённого к понятному, затем от понятного к спроектированному и т. д. Поэтому тикеты не возвращаются.

Как мы узнаем, какие знания нам необходимо получить, чтобы выполнить работу?

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

Разные рабочие процессы, одна и та же доска

Как мы обрабатываем различные виды работ?

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

Где находятся все составные части конечного продукта?

Какова доля завершённой работы?
Какие результаты достигаются совместно/независимо?
Что ждёт чего?
Разные уровни абстракции соответствуют разным рабочим процессам, и это можно визуализировать с помощью отдельных досок. Сделав это, вы, скорее всего, обнаружите, что на более высоком уровне абстракции, рабочий процесс выходит далеко за рамки отдельной команды. И вы начнёте видеть более крупные сквозные сервисы, возможно, с участием нескольких команд, открывающие возможности для моделирования внешних зависимостей и общих сервисов. Связывая эти доски, у вас появляется больше шансов действительно начать управлять потоком от начала до конца, а также управлять зависимостями и решать проблемы координации.
Иерархические Доски

Как взаимосвязаны различные сервисы?

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

Где задерживается работа?

Обычно, вы можете представить каждую колонку на вашей доске из двух подколонок: «Выполнение» (что означает «мы активно работаем над элементом») и «Готово» (что означает «мы выполнили достаточно и готовы перейти дальше»).
Столбцы «В работе/ «Сделано»
Разъяснение этих двух этапов может быть полезным, как способ показать, где работа ждёт и «накапливается».
В некоторых других случаях рабочий процесс может состоять из этапов, представляющих очереди. Разъяснение этого также может помочь понять, где работа застревает и перестаёт течь.
Явные очереди процессов
Насколько мы близки к завершению? Где прекращается поток работы? Где застрял?

Переосмысление колонок Сделать/В Процессе/Сделаноё

Итак, как насчёт типичного дизайна доски с тремя колонками «Сделать/В процессе / Сделано»?
Типичная доска с 3 столбцами
Это доска, которая скрывает больше, чем визуализирует. Колонка «В процессе» создаёт, возможно, ложное впечатление о движении работы и скрывает все сложности и состояния ожидания. Тем не менее, этот дизайн может быть неплох в самом начале, или быть «переходным» состоянием.
Простой способ начать разговор для более детализированного понимания рабочего процесса — попросить людей перемещать и размещать тикеты горизонтально в соответствии с приблизительным представлением о «завершении», а затем начать задавать вопросы, чтобы уточнить, каковы различные этапы и состояния ожидания.
Что мне нужно, чтобы моя команда увидела прямо сейчас?
]]> Визуализация работы — Часть 1: Делаем актуальную работу видимой http://neogenda.ru/blog/holrinzsn1-vizualizatsiya-raboti-chast-1-delaem-akt http://neogenda.ru/blog/holrinzsn1-vizualizatsiya-raboti-chast-1-delaem-akt?amp=true Wed, 13 Mar 2024 15:54:00 +0300 Перевод статьи Fernando Cuenca, размещённой на squirrelnorth.com. Оригинал можно прочитать здесь. Вы решили создать доску, чтобы сделать работу...

Визуализация работы — Часть 1: Делаем актуальную работу видимой

Перевод статьи Fernando Cuenca, размещённой на squirrelnorth.com. Оригинал можно прочитать здесь. Вы решили создать доску, чтобы сделать работу вашей команды видимой: что на ней должно быть и как это должно быть представлено? Первую статью из этой серии читайте по ссылке.

Моделируйте разные виды работы по-разному

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

Направляйте внимание на распознаваемые результаты для клиентов

Ещё одно важное наблюдение: то, что вы визуализируете, будет сильно влиять на то, о чём вы будете говорить, когда будете вести обсуждения перед доской (например, во время ежедневного стендапа).
Когда доски содержат в основном задачи по реализации, то обсуждения, как правило, направлены внутрь, а не на клиента. Более того, эти задачи часто связаны с конкретными людьми. В будущем это приведёт к тому, что обсуждение будет сосредоточено на выполнении индивидуальных задач, а не на результатах команды. Всё это можно смягчить, визуализируя только «распознаваемые клиентами» результаты (т.е. «запросы, которые клиенты ожидают от команды, выраженные в знакомых им терминах).
Если большая часть вашей работы сегодня выражается в терминах задач по реализации, этот совет не следует интерпретировать как призыв скрыть эту работу. Скорее, я бы посоветовал вам отследить распознаваемый результат клиента, который породил эти задачи по реализации (очень возможно, объединение нескольких задач в один внешний результат) и визуализировать их.
Если вы отойдёте и посмотрите на свою доску со стороны, сможете ли вы чётко увидеть (и различить) разные результаты, над которыми работает ваша команда?

Обратите внимание на дизайн тикета

Большинство команд визуализируют свою работу, создавая стикер для каждого элемента, а затем записывают на нём название элемента. Часто добавляется дополнительная информация, например идентификатор из системы отслеживания, данные по оценке или кто работает над тикетом. Однако дизайну самого тикета уделяется не так много внимания.
Дизайн тикетов выходит за рамки простого согласования «стандарта» о том, какую информацию отображать, и где писать каждую часть; это возможность передать подробную информацию о работе, которую члены команды могут использовать для принятия решений.
Возможно, следует отметить, что цель не в том, чтобы использовать доску в качестве источника документации. Я видел, как команды пытались разместить слишком много информации в своих тикетах (например, подробные описания, критерии приёмки и т. д.). Этот уровень детализации лучше хранить в цифровом виде в вашей системе отслеживания или других базах знаний, используя тикеты для отражения информации, необходимой для принятия решений и самоорганизации.
Хороший пример — практика отображения списка чекбоксов с типичными внешними зависимостями, которым подвергается работа в данный момент. Чекбоксы указывают, действительно ли зависимость необходима для данного конкретного элемента, и была ли она уже выполнена или нет. С помощью этой информации член команды может решить, кого ещё необходимо привлечь к выполнению этой части работы, можно ли её вообще начинать сейчас или нет и т. д.
Хочу понять, как работает Канбан Хочу понять, подходит ли мне Канбан Хочу разобраться, как это работает на практике
Эта практика может быть расширена ещё больше, чтобы отразить этапы процесса, ограничения и другие решения. Например, представьте, что вы работаете в команде, которая разрабатывает приложение, используемое в нескольких географических регионах. Приложение разрабатывается постепенно, при этом разные регионы получают новые функции в разные моменты времени, в зависимости от их потребностей и других ограничений локального развёртывания. В большинстве случаев конкретную сборку можно безопасно развернуть в местах, где не требуются содержащиеся в ней новые функции. Но в других случаях необходимо проявлять особую осторожность, чтобы НЕ развёртывать некоторые сборки в некоторых местах, поскольку локальные несовместимости сделают приложение непригодным для использования. Когда команда планирует релиз, ситуация анализируется, и список на тикете обновляется, чтобы отразить сделанные выводы и решения.
Если вы отойдёте и посмотрите на тикеты на своей доске со стороны, сможете ли вы чётко увидеть информацию о каждой части работы, как о значении, так и о статусе, а также для принятия обоснованных решений?

Сделайте блокеры заметными и запоминающимися

Ещё одна распространённая практика — помечать заблокированные элементы маленьким красным стикером. Практика имеет очевидное преимущество, т.к. направляет внимание на работу, которая по какой-то причине перестала двигаться.
Следующий шаг состоит в записи дополнительной информации о блокере: дата возникновения блокировки и причина. Если ставить точки на тикете за каждый день, когда наклейка с блокером остаётся на доске, это даст визуальное представление о том, как долго блокер остаётся на месте. Это поможет команде принимать решения о расстановке приоритетов, эскалации и т. д.
Если все эти «стикеры блокеров» собираются с течением времени, вы можете использовать их в качестве входных данных для «Кластеризации блокеров», а это может привести к лучшему пониманию и управлению источниками задержек в вашем процессе.
Если вы отойдёте и посмотрите на свою доску со стороны, сможете ли вы чётко увидеть, какая работа остановилась, как долго она была заблокирована, и что требует немедленного внимания?
]]> Что мы знаем о продолжительности: сравнение. Часть 3 http://neogenda.ru/blog/9b0u606u91-chto-mi-znaem-o-prodolzhitelnosti-sravne http://neogenda.ru/blog/9b0u606u91-chto-mi-znaem-o-prodolzhitelnosti-sravne?amp=true Thu, 14 Mar 2024 16:10:00 +0300 Артур Нек Перевод статьи Дэвида Андерсона, размещённой на djaa.com. Оригинал можно прочитать здесь. Первая часть серии статей Вторая часть...

Что мы знаем о продолжительности: сравнение. Часть 3

Перевод статьи Дэвида Андерсона, размещённой на djaa.com.
Оригинал можно прочитать здесь.
Это третья часть моей серии статей, в которой развенчивается наше восхищение определением приоритетов с использованием стоимости задержки и соответствующих уравнений теории очередей, таких как WSJF (взвешенная продолжительность самой короткой задачи) или его производных, таких как CD3 (стоимость задержки, поделенная на продолжительность). Я искренне верю, что мы все должны быть защищены от этого культа. Я не думаю, что он хорошо служит инициативам бережливой разработки или Канбан — люди просто не могут получить надежные числа для этих уравнений приоритизации, и даже если бы они могли, лежащая в основе математика неадекватна. Мне понадобится 6 частей, чтобы полностью разобраться в бесполезности и бесперспективности этих методов. Это третья, последняя часть, где мы исследуем знаменатель в этих уравнениях, продолжительность…
Первые две статьи из этой серии должны были убедить вас в том, что если какие-либо два элемента относятся к одному типу, например, пользовательские истории, то для нас невозможно заранее оценить их соответствующие продолжительности.
Продолжительность обоих элементов одного типа будет соответствовать одной и той же функции распределения вероятностей, она будет полностью недетерминирована. Следовательно, для двух элементов одного типа мы должны априори рассматривать их соответствующие продолжительности как идентичные. Другими словами, продолжительность будет постоянной для всех приоритетов однотипных элементов, например пользовательских историй. Это верно, даже если пользовательские истории были «подобраны по размеру» с использованием некоторого механизма относительной оценки, например, баллов за историю. Нет корреляции между «размером» и продолжительностью.
Таким образом, любая форма, использующая для определения приоритетов элементов одного и того же типа уравнение, связанное со стоимостью задержки, фактически должна полностью игнорировать продолжительность в качестве входных данных — продолжительность должна рассматриваться как константа для всех элементов одного и того же типа. Это исключает использование WSJF или CD3 в качестве механизма приоритезации для многих классов проблем: определение приоритетов невыполненных пользовательских историй в проекте или выстраивание последовательности вытягивания для запросов на изменение в рабочем процессе по предоставлению услуг сопровождения программного обеспечения.
Итак, остается вопрос: существуют ли обстоятельства, при которых мы можем сравнивать продолжительность, и если да, как нам это делать?

Сравнение проектов в портфолио

Проекты имеют тенденцию быть достаточно разнородными, поэтому, хотя мы используем одно название типа — «проект» — на самом деле они уникальны каждый по отдельности: у них разное количество функций, выделенных людей и ресурсов. Допустим, что уровень неоднородности не соответствует действительности в серии выпусков продукта, где каждый выпуск имеет примерно одинаковый размер с точки зрения свойств или функций, разработанных за один и тот же период времени одной и той же командой специалистов. Тогда мы будем рассматривать каждый выпуск, как элемент одного и того же типа, и его продолжительность будет считаться постоянной, даже если эта константа является функцией распределения вероятностей.
Итак, если у нас есть разнородные проекты, как рассчитать продолжительность? Лучший метод, известный нашему сообществу, — моделирование Монте-Карло. Он становится одновременно популярным и легкодоступным. SwiftKanban имеет встроенное моделирование Монте-Карло в качестве стандартной функции. Существует также несколько других нишевых инструментов точечных решений от лидеров нашего сообщества, таких как Трой Магеннис и Ларри Макчероне. Если мы смоделируем где-то 1000 итераций проекта с использованием метода Монте-Карло, мы получим функцию распределения вероятностей для продолжительности проекта. На Рис. 1 показаны 6 различных сценариев функций распределения вероятностей для двух проектов, обозначенных (а) зеленым и (b) фиолетовым.
Итак, если мы рассмотрим эти два проекта, мы увидим, что теперь у нас есть разные профили для их распределения. Однако, если бы мы использовали уравнение WSJF (или CD3), чтобы определить приоритеты и выбрать один из предметов в качестве следующего для запуска в нашем портфеле, нам понадобится лишь одно значение для знаменателя — значение продолжительности. Мы не можем использовать функцию распределения вероятностей. Вопрос в том, какое значение выбрать?

Кратчайшая возможная продолжительность?

Джошуа Арнольд, популяризатор CD3, рекомендует выбирать минимальное значение. Один из наших общих клиентов называет это «продолжительностью мечты», т. е. наилучшим возможным случаем, минимальной возможной продолжительностью. В нашей функции распределения вероятностей это будет значение процентили 1%, которое всегда будет визуально находиться в левой части графика функции.
Если мы рассмотрим сценарий 1, у проекта (a) самая короткая продолжительность, но на самом деле у проекта (b) есть около 40% шансов на окончательное завершение раньше проекта (a). Между тем, разница между самыми короткими значениями для (a) и (b) составляет 1 к 10 000, а вероятность того, что (b) завершится раньше (a), составляет примерно 6 из 10. Таким образом, продолжительность мечты — плохой выбор в этом сценарии, по крайней мере, 6 раз из 10.
Если мы перейдем к сценарию 2, теперь больше шансов, что (a) завершится раньше (b), вероятно, примерно в 75% случаев, но разница в минимальных значениях для (a) и (b), скорее всего, будет приводить к очень искаженным результатам уравнения. Если мы просто хотим выбирать между этими двумя проектами, это тривиально, но если бы было больше вариантов для ранжирования, тогда выбор минимального значения был бы очень проблематичным.
В сценарии 3 использование минимальной продолжительности, вероятно, приемлемо, но мы по-прежнему предполагаем «лучший исход», и это, как правило, неразумный подход к управлению рисками.
В сценарии 4 минимальная продолжительность, вероятно, является справедливым методом сравнения, но мы также должны признать вероятность приблизительно 30% того, что (b) завершится раньше (a), и, следовательно, минимальное значение безопасно только в 70% случаев, и мы не можем определить это априори.
В сценарии 5 проект (a) создает функцию распределения вероятностей мультимодальной продолжительности. Это говорит о том, что проект подвержен внешним рискам, вызывающим задержку. Если предположить, что мы не можем заранее определить, возникнут ли эти риски на самом деле, тогда использование минимального значения для продолжительности (а) и (b) реально опасно. Если мы можем определить, существует ли на самом деле один или несколько рисков, тогда мы хотели бы использовать минимальное число для продолжительности с учетом известного риска, то есть мы хотели бы смоделировать продолжительность проекта с исключенной из нашего набора данных возможностью того, что риск не произойдет. Тогда у нас останутся две одномодальных функции распределения вероятностей для (a) и (b), которые могут напоминать один из первых 4 сценариев.
В сценарии 6 минимальные (и максимальные) значения идентичны, но проект (a) имеет гораздо более высокую вероятность завершения до (b) — примерно в 85% случаев. В этом случае выбор минимальной продолжительности для сравнения — бесполезный нонсенс.

Медиана или среднее арифметическое?

Учитывая, что смоделированные продолжительности проекта, как правило, являются функциями с тонким хвостом, разница между медианой (процентилью 50%) и средним арифметическим (для набора данных возможных результатов) несущественна. Мы можем выбрать использование медианы или среднего арифметического, главное — быть последовательными. В этом случае я набросал медианные значения на функции распределения вероятностей на Рис. 1.
  • В сценарии 1 у обоих проектов одинаковое медианное значение, но при этом продолжительность проекта (a) непостоянна и сильно варьируется, в то время как продолжительность проекта (b) является устойчивой с низкой изменчивостью. В результате вероятность завершения (b) до (a) гораздо выше. Использование среднего значения, одинакового для обоих проектов, приведет к ненадежным результатам.
  • В сценарии 2 среднее значение дает более справедливое сравнение и определенно является лучшим выбором, чем минимальное значение.
  • В сценарии 3 среднее значение дает справедливое сравнение, и если нам нужно что-то использовать, это очень разумный выбор.
  • В сценарии 4, опять же, среднее значение дает справедливое сравнение, но оно маскирует возможность того, что (b) завершится раньше, чем (a), возможно, в 30% случаев.
  • В сценарии 5 медиана вводит в заблуждение, поскольку (a) выглядит лучше, чем (b). На самом деле значения среднего арифметического будут ближе друг к другу и покажут вариант (b) в более благоприятном свете. Независимо от этого, учитывая риски, связанные с длинным мультимодальным хвостом в проекте (a), (b), не имеет достаточных шансов при использовании для сравнения медианы или среднего арифметического.
  • В сценарии 6 медиана фактически дает достаточно разумную сравнительную оценку рисков, связанных с завершением проектов.

А что насчет процентили 85%?

Красными пунктирными линиями на Рис. 1 показаны процентили 85% функций распределения вероятностей продолжительности проекта. Теперь мы имеем дело с наихудшим случаем: вероятность того, что проекты продлятся так долго, составляет 1 из 7, и, следовательно, 1 из 49 (или около 2%), что они оба будут длиться как минимум столько времени. Это гораздо более консервативный метод сравнения, чем лучший случай, который мы рассмотрели вначале.
Теперь в сценарии 1 (b) выглядит более привлекательно, чем (a), что является справедливой оценкой.
В сценарии 2 (a) и (b) выглядят одинаково, но на самом деле (a) должен быть гораздо более привлекательным, так как он имеет шанс примерно 60% всегда завершиться до (b).
В сценарии 3 процентиль 85% дает нам справедливое сравнение и (а) выглядит более привлекательно. Это лучший выбор, чем медиана или среднее арифметическое? Трудно сказать, но процентная разница между двумя значениями процентили 85% будет ниже, чем при использовании для сравнения медианы или среднего арифметического, и, следовательно, вариант (b) выглядит относительно более привлекательным при использовании процентили 85% по сравнению с процентилью 50% или средним арифметическим.
В сценарии 4 вариант (а) выглядит привлекательнее, чем (b), и это справедливое сравнение.
В сценарии 5 (b) теперь выглядит более привлекательно, чем (a), и это также может быть справедливым сравнением.
В сценарии 6 (a) выглядит более привлекательно, чем (b), и снова, вероятно, это справедливое сравнение, и соотношение между ними, вероятно, дает справедливую оценку различных рисков продолжительности.

А что насчет худшего случая?

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

Выводы

Этого небольшого упражнения должно быть достаточно, чтобы продемонстрировать вам, что в зависимости от сравниваемых проектов и их соответствующих функций распределения вероятности продолжительности используется метод, используемый для сравнения их продолжительности как одного числа — лучший случай, худший случай, медиана, среднее арифметическое или процентиль 85% дадут разные результаты, некоторые из которых являются справедливой оценкой сравнительных рисков, а другие — нет. Ни одно решение не работает лучше всего в каждом сценарии.
Из этого я пришел к выводу, что для сравнения продолжительности проектов вам нужна вся функция распределения вероятностей, и вам нужно провести параллельное визуальное сравнение, а затем взвесить другие факторы, такие как предоставляемая ценность и сроки. Упрощение продолжительности до одного числа, независимо от того, каким образом это число получено, — нонсенс. Нам нужно отмести это предположение и начать надлежащим образом управлять риском продолжительности. В части 6 этой серии статей будет рассмотрен жизнеспособный метод для принятия правильных решений с оценкой риска для планирования, выстраивания последовательности и выбора проектов и других видов работ.
]]> Что мы знаем о продолжительности: индивидуальные активности. Часть 1 http://neogenda.ru/blog/1f33it8uf1-chto-mi-znaem-o-prodolzhitelnosti-indivi http://neogenda.ru/blog/1f33it8uf1-chto-mi-znaem-o-prodolzhitelnosti-indivi?amp=true Fri, 15 Mar 2024 16:13:00 +0300 Артур Нек Перевод статьи Дэвида Андерсона, размещённой на djaa.com. Оригинал можно прочитать здесь. Последней модой в сообществе гибкой разработки ПО является...

Что мы знаем о продолжительности: индивидуальные активности. Часть 1

Перевод статьи Дэвида Андерсона, размещённой на djaa.com.
Оригинал можно прочитать здесь.
Последней модой в сообществе гибкой разработки ПО является популяризация использования стоимости задержки для определения приоритетов. Многие читатели знают, что я был сторонником определения приоритетов в зависимости от «Стоимости задержек», и в моей книге 2003 года «Agile Management for Software Engineering» («Гибкое управление в разработке программ») были несколько алгоритмов, связанных со стоимостью задержки. Тем не менее, я вижу в мире много дезинформирующих, упрощенных и потенциально опасных руководств по использованию стоимости задержки, и пришло время внести некоторую ясность.
Большая часть материалов по стоимости задержки в Agile-пространстве основана на ссылках и модификациях уравнения WSJF (Weighted Shortest Job First — взвешенная продолжительность самой короткой задачи) из последней книги Дональда Г. Рейнертсена The Principles of Product Development Flow: Second Generation Lean Product Development («Принципы потока разработки продукта: второе поколение бережливой разработки продукта»).
Суть уравнения WSJF — это общая прибыль за весь срок службы, разделённая на продолжительность проекта разработки продукта.
В первых нескольких публикациях из этой серии я хочу рассмотреть, что мы знаем о знаменателе в этом уравнении — продолжительности проекта. WSJF также применяется в некоторых фреймворках для определения приоритетов пользовательских историй, функций и пр. Я не верю, что это хотя бы отдалённо уместно, и я хочу начать с объяснения того, что мы знаем о продолжительности таких пользовательских историй или функций, и пояснения, почему использование продолжительности в знаменателе уравнения WSJF не подходит для сравнительной оценки, выстраивания последовательности и приоритизации детализированных рабочих элементов, таких как пользовательские истории.

Что мы знаем о продолжительности: индивидуальные активности

24 февраля 2001 года я впервые опубликовал в своём блоге uidesign.net 5-балльную степенную шкалу для оценки размера и трудоёмкости функций в методе разработки, управляемом функциями.
Позднее, сравнивая мои данные с некоторыми известными сторонниками экстремального программирования (XP), такими как Тим Маккиннон, я понял, что лондонская школа написания пользовательских историй создаёт пользовательские истории схожего размера и сложности. Эта шкала формально появилась в моей книге 2003 года Agile Management for Software Engineering («Гибкое управление разработкой программного обеспечения»). Впервые я использовал её в проекте в Дублине (Ирландия) летом 1999 года.
На Рис. 1 показана шкала. Это не случайные данные. Она не основана на «оценке» или разговорах. Она основана на анализе. Другими словами, она полностью детерминирована. Управляемая структура предложения для написания функций в методе разработки, управляемом функциями, позволяет специалисту в данной области быстро оценить, как эта функция повлияет на код. Предложение содержит подсказки для имени метода, класса, в котором будет закодирован метод, и возвращаемого значения из метода. Зная возвращаемое значение, кто-то, владеющий этой техникой, может почти с первого взгляда оценить, по скольким классам потребуется перемещаться для получения желаемого результата. У проектирующего дизайн оценщика появляются другие источники информации кроме собственного суждения. Он точнее оценивает, что дизайн может повлечь за собой с точки зрения классов, к которым осуществляется доступ, и вызовов методов.
Итак, я создал 5-балльную шкалу: функционала размером от 1 до 5. Я оценил, что средний уровень трудоёмкости для такого функционала возрастёт по квадратичному закону: 0,5 дня; 1 день; 2 дня; 4 дня; 8 дней и более.
Предположим, что мы выбрали правильный размер. Это разумное предположение, поскольку более 90% функций, измеренных с использованием этого метода, вероятно, будут иметь правильный размер., Но всё ещё маловероятно, что задача, такая как проектирование и написание кода для функционала— фактически написание всех вызовов методов и всех модульных тестов — займёт именно среднее время. Фактически, время, вероятно, будет случайным и достаточно равномерно распределённым.
Если бы у нас было достаточно точек данных (несколько сотен) и не было многозадачности, задержек или блокировки по другим зависимостям и сбоям во время выполнения задачи, мы могли бы ожидать обычного нормального распределения с масштабом примерно на 50% выше и ниже среднего. Таким образом, функционал размера 2, выполнение которых занимает, в среднем, 1 день, должны выполняться за 0,5−1,5 дня.
Существует вырожденный случай, когда многозадачность не искажает форму нормального распределения. Здесь скорость переключения задач в два или несколько раз выше, чем минимально возможная продолжительность задачи: если у нас задача длиной 31 минуту, и мы переключаем задачи каждые 15 минут, есть одинаково случайный шанс, что все задачи будут прерваны и следовательно, распределение останется нормальным. Конечно, такое быстрое переключение задач означало бы, что процесс чрезвычайно неэффективен, и, как следствие, всё распределение было бы сдвинуто вправо и масштабировано вправо. Вот почему это случай генерирования: он существует в математической теории, но больше он нигде не существует.
Если теперь учесть, что самая короткая задача может занять 30 минут (0,5 часа), а самая длинная — 12 дней (96 часов), мы получим разброс вариаций для трудоёмкости по функциям, который охватывает 200 наименьших продолжительностей. Множитель 200 соответствует результатам Рейнертсена. Вероятно, разумно предположить, что время выполнения задачи будет охватывать как минимум 50-кратный минимальный размер независимо от используемого процесса. Опять же, эти данные представляют собой «уровень трудоемкости» и по-прежнему предполагают отсутствие переключения между задачами, задержек и нарушений обслуживания.
Теперь, давайте рассмотрим разброс вариативности размеров функций в данном проекте…
На Рис. 2 показано, как может варьироваться распределение продолжительности задач, когда мы суммируем распределения для каждого размера функционала. Другими словами, если мы будем рассматривать весь функционал просто как функции, сколько времени может потребоваться для завершения их разработки? На верхней диаграмме показано мультимодальное распределение для равномерного распределения функций, то есть у нас примерно такое же количество размеров 1, как и размеров 2, 3, 4 и 5. Такого равномерного распространения я ещё никогда не видел. Более типичным является перекос в сторону малого и среднего размера, когда наиболее распространённым является размер 2. Это даёт распределение, более похожее на нижний пример.
Как многозадачность, задержки и нарушения влияют на форму распределения?
Если уменьшается вероятность задержки чего-либо, хвост распределения постепенно смещается вправо. Следовательно, у долгосрочных задач больше шансов быть отложенными, а у отложенных — больше шансов быть отложенными еще раз. Вот что даёт длинный хвост справа.
Математически, когда мы тянем хвост вправо, параметр формы в уравнении Вейбулла сокращается. Мы называем это изменением формы или искажением распределения слева. Все распределение физически сдвинуто вправо. Обратите внимание, что я разместил шкалу на оси X. Мода|медиана|среднее арифметическое в нормальном распределении составляют 4,0, в то время как у нижней кривой мода равна 11, медиана примерно равна 11 и среднее арифметическое примерно равно 12. Таким образом, средняя продолжительность задачи увеличилась в 3 раза из-за задержек и многозадачности.
Средние значения легко объяснить, но именно хвост распределения представляет основную часть риска. В идеальной ситуации с нормальным распределением задача выполняется максимум за 8, в то время как после введения многозадачности, задержек и нарушений обслуживания максимум вырос до 38.
На Рис. 3 показан перекос в распределении для функционала размера 4, когда возникает некоторая многозадачность, а также задержка из-за зависимостей и нарушения обслуживания (т. е. недоступности работника, например, из-за болезни или службы в суде присяжных). Вы можете себе представить, когда мы моделируем это для всех пяти размеров, а затем свёртываем в единое распределение, подобное показанному на Рис. 2, мы получаем ещё более выраженный эффект длинного хвоста.
Все это показано для одного действия. Мы даже не начали рассматривать рабочий процесс, состоящий из нескольких действий с задержками между ними. Я расскажу об этом во второй статье из этой серии.

Итак, что мы знаем о продолжительности задач?

Таким образом, если у вас есть только детерминистский метод анализа, позволяющий быстро и дешёво оценить размер и сложность, вы сможете разбить продолжительности задач по таксономии категорий.
Как указал Юрген Аппело в своей книге Management 3.0 («Менеджмент 3.0»), ряд Фибоначчи, столь любимый агилистами, на самом деле не встречается в природе. Кроме того, его индекс недостаточно редок: история, оценённая как 3 по шкале Фибоначчи, скорее всего, будет иметь вес 1, 2, 4 или 5, в то время как альтернативы выше и ниже по шкале Фибоначчи — 2 и 5. Следовательно, он совершенно случаен, для пользовательских историй с весом 2, 3 или 5. Вероятность того, что вес на самом деле 3, составляет менее 50%. Если мы предположим, что во время выполнения задачи никогда не происходит упреждения, корреляция между её размером или сложностью и её реальной продолжительностью всё равно очень мала. Конечно, упреждение действительно происходит, и, следовательно, на самом деле нет никакой корреляции между количеством баллов за историю и её продолжительностью. Это делает продолжительность проекта бесполезной в качестве средства сравнительной оценки и определения приоритетов в уравнении, таком как WSJF, поскольку существует высокая вероятность того, что знаменатель в уравнении для каждой задачи или элемента неверен. Это может сильно повлиять на результат или рейтинг, основанный на результатах уравнения. Как следствие этого, размер информации практически не имеет никакой ценности, и для целей расчёта продолжительности мы можем также предположить, что все пользовательские истории имеют одинаковый размер. Мы не можем детерминировано оценить продолжительность любого элемента данного типа по сравнению с продолжительностью другого элемента того же типа. Этот анализ исключает размер пользовательской истории как полезный параметр в уравнении WSJF.
С другой стороны, степенные законы и распределения Вейбулла, включая (k = 4,0) нормальное распределение и (k = 1,0) экспоненциальное распределение, действительно существуют в природе. Поэтому гораздо более вероятно, что размер для пользовательских историй следует степенному закону. В 2009 году Юрген обнаружил, что я опубликовал такой степенной закон, и самое раннее упоминание о нём в Интернете датируется 24 февраля 2001 года. Даже со степенной шкалой существует некоторая, но меньшая вероятность того, что фактическая продолжительность наложится на элемент другого размера или сложности. Надеюсь, Рис. 1 убедит вас, что балльная шкала, оценивающая размер и сложность, не имеет смысла при оценке продолжительности задачи для целей сравнительной оценки и определения приоритетов. Если нет, то, возможно, вторая статья из этой серии приведёт вас к выводу, что оценка продолжительности с целью использования её в качестве знаменателя в уравнении WSJF бесполезна при детализации задач, историй, функций или эпиков.
Из других результатов мы знаем, что продолжительность задач обычно имеет разброс до 200 раз. Разработанная мною степенная шкала метода разработки, управляемая функциями, демонстрирует это довольно легко, если предположить, что рабочий день составляет 8 часов. В своей книге 2003 года я предполагал, что в день возможно только 5,5 часов продуктивной работы. Использование меньшего числа по-прежнему даёт кратность 132 от наименьшей к наибольшей функции.
Итак, мы понимаем, что проблема оценки продолжительности задач, таких как разработка пользовательской истории, является нелинейной, но мы также понимаем, что она не является детерминированной. Если мы знаем, например, из детерминистского анализа, что эта функция включает 3 класса и 5 вызовов методов, мы все равно не можем сказать с детерминированной точностью, сколько времени займет её реализация. Продолжительность — это случайная величина, распределённая по закону Вейбулла.
Итак, в целом, для индивидуального действия в рабочем процессе продолжительность задачи до завершения действия изменяется нелинейно и не является детерминированной. Она распределена приблизительно по закону Вейбулла с параметром формы в диапазоне 1,0 < k < 4,0 и, наиболее вероятно, в диапазоне 1,3 < k < 2,0. Разброс от самого короткого до самого длинного значений может составлять до 200 кратчайших значений.
Если вы пытаетесь «оценить» продолжительность такой задачи, как проектирование, кодирование, тестирование пользовательской истории, вы, в основном, пытаетесь угадать. Вы бросаете кости и наносите удары в темноте. Фактическое истекшее календарное время (или продолжительность) действия, вероятно, будет сильно отличаться от вашей «оценки».
]]> Канбан-игры http://neogenda.ru/blog/2npxfrhkb1-kanban-igri http://neogenda.ru/blog/2npxfrhkb1-kanban-igri?amp=true Sat, 16 Mar 2024 16:15:00 +0300 Артур Нек Перевод статьи Кирилла Климова, размещённой на kirillklimov.com. Оригинал можно прочитать здесь. Вот краткий список всех игр и...

Канбан-игры

Перевод статьи Кирилла Климова, размещённой на kirillklimov.com.
Оригинал можно прочитать здесь.

Вот краткий список всех игр и симуляторов, перечисленных в статье:

Онлайн-игры:

Kanban board game (Канбан-игра по мотивам разработки ПО)
Okaloa Flowlab
Featureban
FlowBan
TWiG — The WiP Game

Офлайн-игры:

getKanban
Okaloa Flowlab
Featureban and Changeban
KanbanPizza
Kanban Policy Game
The Flow Hour
AskKanban!
GWAN (Game Without a Name) aka Spry Agility Board Game
The Scrumban Game
NoEstimates Game
CarBan game
Scrumban simulation
TWiG — The WiP Game
The Lego Kanban Game
Ubongo Flow Game
Lean Lego Game
The Penny Game
Paper Boats
The Sudokuban
Multitasking Name Game
Fire Dice
Lean Startup Snowflakes
Agile Airplane Game
The Dot Game
The Motor City
The Bottleneck Game
Ball Point Game
The Ball Flow Game
The Beer Game
Часто мне задают вопрос: «Как можно на собственном опыте объяснить некоторые идеи, лежащие в основе потокового мышления и Канбана, например с помощью игр или симуляций». Я исследовал это вопрос и не нашёл единого списка Канбан-игр. Итак, поехали…
В этом материале я буду использовать термины «игра» и «симулятор» как синонимы. Несмотря на то, что Патрик Стюарт (автор FlowLab, см. ниже) довольно строго относится к разнице, имея в виду симуляции, в которых нет конкуренции между командами, и они будут более открытыми, чем игры, которые следуют определённому сценарию. Мой опыт показывает, что всё это сильно зависит от вашей фасилитации. Например, недавно я понял, что даже фасилитируя некоторые игры из приведённого ниже списка, я делаю это без конкуренции и часто без ограничений — так что это очень похоже на симуляцию. Поэтому тонкая грань между играми и симуляторами субъективна, я оставлю её за границами этого материала.
Ещё одно очень важное соображение, которым следует поделиться. Исходя из моего опыта многочисленных (насчитывающих сотни) фасилитаций различных игр и из мнений других участников сообщества, обучение участников в игре в большей степени зависит от фасилитации и анализа деятельности, чем от самой деятельности. Я видел проведение проверенных мощных игр, которые в итоге мало чему обучали. А с другой стороны, видел базовые игры, которые обучали и приводили к правильным выводам. Кроме того, некоторая потенциальная мощь игры может быть связана с дополнительными возможностями её проведения, которые могут быть описаны или не описаны в официальной документации или где-либо вообще. Типичной иллюстрацией может быть запуск getKanban через нескольких разных целей для разных команд.
Я должен упомянуть, что я проводил сессию на тему Канбан-игр на конференции Kanban Leadership Retreat 2018 (в Праге). Сессия была слишком короткой, чтобы должным образом проработать все детали. Первоначальная идея состояла в том, чтобы использовать возможности высокоинтеллектуальной аудитории, чтобы 1) получить список игр и 2) получить функции/свойства игр, чтобы увидеть, что вы можете показать/проиллюстрировать с помощью игры. Вы можете увидеть результаты сессии на фото:
Ниже я приведу полный список и свой опыт в конкретных играх (конечно, когда у меня есть опыт — я фасилитировал больше половины, но не все). Не стоит ожидать, что этот список будет исторической справкой для всех игр — некоторые игры были доступны в прошлом, но уже исчезли, их здесь нет… В этом списке нет определённого порядка. Всего в списке более 20 игр.

getKanban

Источник: getkanban.com
Автор: Рассел Хили
Время: 2,5 часа — полный день (в зависимости от того, как вы играете и о чём проводите разбор)
~ Год создания: 2009
Лицензия: закрытая/доступна для покупки
Пожалуй, всё ещё самая распространенная полнофункциональная (тяжёлая) настольная игра, способная проиллюстрировать большинство аспектов Канбана. Очень хорошо описана (инструкция по фасилитации входит в комплект). Из-за этого игра по-прежнему является (рекомендуемым) выбором по умолчанию для новых аккредитованных тренеров Канбан в Kanban University, для использования в классе Kanban System Design (также известного как KMP1). Должен заметить, что Рассел Хили получил награду Brickell Key Award в 2011 году за игру getKanban.
В игре доступно несколько игровых режимов с разной общей продолжительностью. Самый продвинутый (и самый продолжительный) режим у меня занял больше половины дня, а с анализом — ещё больше времени. Также следует отметить, что помимо версии, которая продается широкой публике (на момент написания это версия 5), есть более старая версия 2, которая находится в свободном доступе на сайте, которую вы можете скачать, распечатать и использовать. Судя по тому, что я видел и слышал, эта версия широко распространена среди PST (тренеров scrum.org), которые преподают классы «Professional Scrum with Kanban». В течение многих лет в сообществе была идея создания и поддержки альтернативных сценарных потоков (альтернативных наборов ежедневных событий). Я не слышал ни о каких доступных реализациях.
Затронутые концепции: push vs pull, дизайн доски, WIP-лимиты, вероятностное прогнозирование, время выполнения, пропускная способность, блокеры и дефекты, политики, Диаграмма распределения времени выполнения, классы обслуживания (CoS) и Соглашение об уровне сервиса (SLA); Контрольная диаграмма, совокупная блок-схема и многое другое.
Что касается дополнительных ресурсов, то есть запись внутреннего вебинара на тему советов и приёмов фасилитации getKanban, где я и Алексей Жеглов делились своим опытом, доступным для тренера Kanban University через внутреннюю платформу (COYO). Ещё один полезный ресурс, о котором стоит упомянуть, — это статья Алексея по этой теме.

Kanban board game (Канбан-игра по мотивам разработки ПО)

Это онлайн-игра, во многом вдохновленная getKanban. Она предоставляет 2 сценария с помощью 2 различных наборов карт событий: getKanban v2 (бесплатная, но довольно старая), 21-дневный игровой процесс и собственные события, 35-дневный игровой процесс.
Источник: www.kanbanboardgame.com

Okaloa Flowlab

Источник: okaloa.com/flowlab
Автор: Патрик Стюарт
Время: 1,5 часа — полный день (в зависимости от того, как вы играете и о чём проводите разбор)
~ Год создания: 2016
Лицензия: закрытая/доступна для покупки.
Ещё один очень сильный игрок в списке, который даёт возможность получить полноценный опыт работы с потоком, различными аспектами Канбана, графиками, метриками и т. д. Игра доступна в нескольких вариантах. Базовый набор (teamFlow) доступен для покупки всем желающим. Набор расширенных симуляций включает в себя Upstream-моделирование (сквозное), мульти-командное моделирование и симуляции ликвидности персонала, которые доступны только после посещения очного 2-дневного курса по их фасилитации. Многие AKT (в том числе и я) используют это семейство в симуляции в сертификационных классах. Я использую их как при проектировании Канбан-систем, так и при их совершенствовании.
По сравнению с getKanban, Flowlab обеспечивает большую гибкость — я смотрю на неё, как на конструктор симуляций. Она более открытая, что также означает большую открытость для недостатков фасилитации, поэтому (как я это вижу) требуется больше опыта в фасилитации.
Было бы разумно ожидать различных вариантов моделирования на основе Flowlab. Один из примеров, о котором стоит упомянуть, — это «Распределение мощностей» Сюзанны и Андреаса Бартелей. Я также всё время экспериментирую с этим набором, с несколькими построенными и использованными мною моделированиями — «исследование показателей» и «вероятностное прогнозирование». Есть сообщество практиков, канал Slack для общения — всё, чего вы ожидаете в наши дни …
Доступна онлайн-версия Okaloa Flowlab, но пока мало общедоступной информации, но вы можете заказать демо версию и купить пакеты. На данный момент доступна только базовая версия, но расширенное моделирование появится позже.

Featureban и Changeban

Источник: featureban и changeban
Автор: Майк Берроуз
Время: 1,5−2 часа
~ Год создания: 2014
Лицензия: Creative Commons (CC)
Эти игры — хороший пример из другого конца спектра. Это быстрые игры, которые хорошо подходят для того, чтобы проиллюстрировать некоторые аспекты потока, а также бросить вызов существующим убеждениям. Я помещаю сюда обе игры, так как они довольно близки. Исторически Featureban был первым. Changeban появился немного позже и является производным от Featureban, вдохновленным Lean Startup. У него схожая игровая динамика, но из-за разных контекстов цели обучения также различаются.
Игры активно развиваются, меняются некоторые аспекты игровой динамики. Но доступны все версии, так что вы можете выбирать по своему усмотрению. Есть сообщество практиков, слабый канал в AgendaShift для общения — вот и все плюсы.
Доступна онлайн-версия Featureban 3.0. Он построен на kaiten. io — одном из онлайн инструментов с поддержкой Канбан Метода.
Источник: tools.kaiten.io/Featureban

KanbanPizza

Источник: agile42.com
Автор: Ральф Круз из Agile42 (на момент создания)
Время: 60−90 мин.
~ Год создания: 2011
Лицензия: CC
Ещё один отличный пример очень известной и широко распространённой игры в сообществе. Она не является «полнофункциональной», но довольно уникальна по нескольким аспектам. Это единственная игра (насколько мне известно), в которой используется физическое пространство и ограничения. Кроме того, вы проектируете свою рабочую среду/пространство и то, как вы это делаете в своей команде.
KanbanPizza доступна довольно давно. В сочетании с CC-лицензией она получила очень широкое распространение. Лично я сомневаюсь, что это должен быть выбор по умолчанию при начале использования Канбана или потокового мышления, но игра определённо может быть лучшим выбором в самых разных ситуациях.

Kanban Policy Game

Источник: training.modernmanagement.bg
Автор: Димитар Бакарджиев
Время: 60−90 мин.
~ Год создания: 2016
Лицензия: CC
Эта игра также помогает исследовать некоторые аспекты Канбана (вытягивание, WIP-лимиты, сотрудничество) и то, как применять эти эффекты в потоке работы, уделяя особое внимание правилам и делая их явными.

The Flow Hour

Источник: github.com
Автор: Родриго Йошима
Время: 1,5−2 часа
~ Год создания: 2010
Лицензия: CC.
Симуляция/деятельность, созданная Родриго, заключается в том, что за час в течение нескольких раундов и итераций учащиеся знакомятся с некоторыми аспектами Канбана. Эта игра была вдохновлена Extreme Hour. Это не CC (Creative Commons), поэтому, пожалуйста, проверьте лицензию перед её использованием.

AskKanban!

Источник: store.huge.io
Автор: Брендан Вовчко
Время: 10−15 мин.
~ Год создания: 2016
Лицензия: закрытая/доступна для покупки
Приятно иметь в этом списке некоторое разнообразие. Большинство игр и симуляторов здесь построены либо на доске и перемещении карточек на ней, либо на построении чего-либо с течением времени. Эта игра совсем другая и супер простая. Цель состоит в том, чтобы добавить немного геймификации, чтобы улучшить застарелые ежедневные стендап митинги. Доступно отличное 17-минутное видео с подробными объяснениями и инструкциями по игре. Вы можете создать свои собственные электронные карты или приобрести распечатанные на HugeIO.

FlowBan

Источник: flowban.herokuapp.com
Автор: Мауро Стрионе
~ Год создания: 2020
Лицензия: n/a
Чистый онлайн-симулятор, первый подобного рода в этом списке. Вы можете просмотреть двухминутное видео, чтобы получить быстрое представление об этой симуляции. Она всё ещё находится в стадии бета-тестирования и разработки, но мне кажется очень интересной. Мне кажется, что во многих аспектах она очень похожа на getKanban.

GWAN (Игра без имени) aka Spry Agility Board Game

Источник: spryagility.co.za/board-game/
Автор: Берто Кётзее
Время: 45−90 минут
~ Год создания: 2017
Лицензия: n/a
GWAN затрагивает концепции потока, размера пакета, переключения контекста, WIP-лимиты, стоимость задержки. Хорошая игра-симулятор для понимания концептов. Видео инструкция и все материалы доступны.

The Scrumban Game

Источник: github.com
Автор: Димитар Бакарджиев
Время: 90−120 минут
~ Год создания: 2018
Лицензия: CC
Эта игра проведёт вас через моделирование эволюционных изменений в контексте разработки ПО. Интересно, что она имитирует XIT команду в Microsoft, которая представляет собой тематическое исследование, часто используемое во второй день фундаментального курса Kanban System Design. Это вторая игра от Димитара в списке. В ней есть отличные инструкции и все необходимые материалы. Игра даёт игрокам возможность изучить большинство Канбан-практик, включая эффективность потока, производительность в срок, SLE-Performance; которые довольно редко встречаются в играх и симуляторах.

NoEstimates Game

Источник: noestimates.wordpress.com
Автор: Мэтью Филип
Время: 90−120 минут
~ Год создания: 2016
Лицензия: CC 4.0
Отличная игра, чтобы узнать о NoEstimates, прогнозировании и источниках вариаций в поставке ПО. Свободно доступна для загрузки (с GitHub) для печати и игры, или вы можете купить профессионально напечатанный набор.

CarBan game (также известная как CarBan Kanban Simulator)

Источник: github.com
Автор: Рубен Ольсен Лёрк
Время: 90−120 минут
~ Год создания: 2016
Лицензия: n/a
Ещё одна отличная предопределённая симуляция, которая познакомит вас с тем, как использовать Канбан-доску и другие артефакты в командных условиях. По словам Рубена, в ней также есть расширенный режим, имитирующий процесс разработки в нескольких командах.

Scrumban simulation

Источник: simu-learn.net/scrumban
Автор: Сангита Шридхар и Коэн Вэстманс
Время:
~ Год создания: 2018
Лицензия: CC
Симулятор Scrumban на основе игр Kanban Pizza (см. выше) и No Estimations Game. Все необходимые материалы доступны.

TWiG — The WiP Game

Источник: Leanability.com/en/twig/
Автор: Клаус Леопольд
Время: 1,5−2 часа
~ Год создания: 2018
Лицензия: CC
Я оставлю в стороне все обсуждения и теории о том, на какие ещё симуляции похожа эта игра. На её веб-странице говорится, что: «TWiG вдохновлён простотой Featureban и очарован управляющими событиями getKanban». По моему опыту, это всё ещё ближе к «быстрому/простому» концу спектра.
Доступна онлайн-версия TWiG, построенная на другом электронном инструменте (ActionableAgile).
Источник: Leanability.actionableagile.com/twig/
Было бы странно, если бы здесь не было симуляторов на основе Лего, да? У нас есть несколько.

The Lego Kanban Game

Источник: slideshare.net
Автор: Лиз Кеог
Время: 60−90 минут
~ Год создания: 2017
Лицензия: CC
Несмотря на то, что игра состоит из слайдов в Slideshare, этого достаточно для запуска симуляции. Здесь рассматриваются концепции: кросс-функциональность (совместная работа), вытягивание, организация рабочего пространства.

Lego Flow Game

Источник: availagility.co.uk
Авторы: Карл Скотлэнд и доктор Саллианн Фройденберг
Время: 60−90 минут
~ Год создания: 2013
Лицензия: CC
Как и в большинстве симуляторов на основе Lego, структура аналогична — есть несколько раундов, когда небольшие команды создают что-то с помощью Lego с разными правилами/политиками в перерывах между разными раундами. В этом случае есть 3 модели, которые нужно испытать: «Пакетный и поэтапный (водопадоподобный)», «Ограниченный по времени (как Scrum)» и «На основе потока (как Канбан)».

Ubongo Flow Game

Источник: teamworkblog.de
Автор: Ян Фишбах
Время: 60−90 минут
Год создания: июль 2015
Лицензия: n/a
Интересная комбинация Lego Flow Game — вся механика (3 раунда, учебные цели и т. д.) используется оттуда, но вместо кубиков Lego используется игровой материал Ubongo. Помимо описания на английском языке, есть описание на немецком языке.

Lean Lego Game

Источник: dtsato.com
Автор: Данило Сато и Франсиско Триндади
Время: 1,5−3 часа
~ Год создания: 2008
Лицензия: CC
Эта игра была вдохновлена The Lego XP Game, появилась и развилась внутри ThoughtWorks. Здесь коснулись концепций: push vs. pull, Канбан, потери, Кайдзен.
Однажды, я запустил её в 2014 году на конференции: я помню, что ёё приняли очень хорошо, но для запуска потребовалось довольно много кубиков Lego.

The Penny Game (aka «Penny Flow», aka «Pass the pennies», aka «Coin Game»)

Источник: deliciouscupcakes.org
Автор: источники трудно отследить, учитывая ряд вариаций. Похоже, что её улучшили несколько практиков в Agile-сообществе. Первые упоминания относятся к Джо Литтлу, Джорджу Динвидди, Джеффу Сазерленду и Хенрику Книбергу.
Время: 20−45 минут
~ Год создания: 2008
Лицензия: CC
Ещё одна очень простая игра, показывающая концепции небольших партий, ограничений и общения. У вас должно быть всё больше монет для игры, которые становится всё сложнее и сложнее собрать только с группы????
Онлайн-версия The Coin Game была разработана компанией Solutioneers
Источник: solutioneers.co.uk/coingame/
Год создания: 2020
Также доступно краткое руководство для фасилитатора.

Paper Boats

Источник: Leanability.com
Автор: Клаус Леопольд
Время: 45−60 минут
~ Год создания: 2016
Лицензия: n/a
Ещё одна симуляция для исследования разницы между проталкиванием и вытягиванием, на этот раз с помощью конвейерной линии по сборке бумажных корабликов. Можно найти некоторое сходство с игрой The Lean Cups Game. Мартин Азиз и Фернандо Куэнка запускают эту игру для более чем 100 человек и проводят встречу AgileTO. Они создали отличное руководство по фасилитации и предоставили другие вспомогательные материалы. Теперь вы можете запускать её, затратив разумное время на подготовку.

The Sudokuban

Источник: unbounddna.com
Автор: Рене Тротон и Крейг Смит
Время: 45−60 минут
~ Год создания: 2013
Лицензия: CC
Помимо обычных аспектов (WIP-лимиты, вытягивание, поток, время выполнения), здесь добавлена ускоренный класс. И да, вы должны знать о головоломках судоку, поскольку это часть механики.

Multitasking Name Game

Источник: crisp.se
Автор: Хенрик Книберг
Время: 30−45 минут
~ Год создания: 2009
Лицензия: CC
Супер простое, но сверхмощное быстрое моделирование, позволяющее выявить проблемы с многозадачностью. Теперь эта игра является частью Team Kanban Practitioner class. Я узнал её от Мэри Поппендик в 2009 году, а она позаимствовала у Хенрика Книберга. Я запускал эту игру несколько раз с большим успехом.

Fire Dice

Источник: theagilefactor.com
Автор: Джейсон Тайс
Время: 45−60 минут
~ Год создания: 2014
Лицензия: n/a
Изученные концепции: применение ToC к интеллектуальной работе, WIP-лимиты, определение размеров пакетов с помощью аналитики процессов.

Lean Startup Snowflakes

Источник: deliciouscupcakes.org
Автор: Андре Дондт
Время: 60−90 минут
~ Год создания: 2012
Лицензия: CC
Затронутые концепции: обнаружение клиентов, сотрудничество, потери, критерии приёмки.

Agile Airplane Game

Источник: oledru.free.fr
Автор: Джон Хайнц
Время: 1−2 часа
~ Год создания: 2011
Лицензия: CC
Затронутые концепции: выявление клиентов, сотрудничество, потери, критерии приёмки, push/pull, Кайдзен.

The Dot Game

Источник: portal.netobjectives.com
Автор: Аль Шаллоуэй
Время: 45−60 минут
~ Год создания: 2011
Лицензия: CC
Затронутые концепции: push/pull, сотрудничество, Кайдзен.
Это ещё один симулятор, который я имел удовольствие запускать много лет назад. Прошёл гладко ???? Он основан на игре Lean Manufacturing Cup Game.

The Motor City

Источник: yorkesoftware.com
Автор: Джон Йорк
Год создания: 2017
Лицензия: закрытая/доступна для покупки.
Затронутые концепции: Канбан, WIP-лимиты и Теория Ограничений.
В игру можно играть в группах до 4 человек (как и во многие другие в этом списке) на один набор. В симуляторе вы будете собирать автомобили, как в золотой век автомобильной промышленности.

The Bottleneck Game

Источник: agilecoach.net
Автор: Паскаль Ван Каувенберге, Порция Тунг
Время: 2−3 часа
~ Год создания: 2009
Лицензия: CC
Это моделирование поможет вам применить пять фокусирующих шагов теории ограничений (ToC).

Ball Point Game

Источник: borisgloger.com
Автор: Борис Глогер
Время: 45−90 минут
~ Год создания: 2008
Лицензия: CC
Несмотря на то, что изначально эта игра была создана для обучения Scrum (и, вероятно, до сих пор в основном используется для этого), это довольно общая игра. В зависимости от целей, вы можете сосредоточиться на разных задачах обучения. Я запускал её несколько раз. Некоторые из возможных обучающих пунктов (более актуальных для этой статьи): командная работа, Кайдзен, типы потерь и их сокращение, поток, оценка и вероятностное прогнозирование. Итак, как видите, даже с этой игрой вы можете изучить довольно много концепций, лежащих в основе потокового мышления. Карл создал версию, более ориентированную на поток (см. ниже).

The Ball Flow Game

Источник: availagility.co.uk
Автор: Карл Скотлэнд
Время: 45−60 мин.
~ Год создания: 2010
Лицензия: CC
Очень близко к начальной игре с правилами/динамикой (раунды ограничены не рамками времени, а количеством пропущенных мячей), с акцентом на такие показатели потока, как время выполнения, пропускная способность, а также на диаграмму совокупного потока.

The Beer Game

Источник: web.mit.edu
Автор: Школа менеджмента Sloan при Массачусетском технологическом институте.
Время: 45−60 мин.
~ Год создания: 1960-е
Лицензия: n/a
Наверное, самая старая игра в списке. Игра показывает покупательский спрос, распространение знаний и общение. Цитата из описания: «Игра даёт наглядный опыт работы со сложной системой, где игроки могут увидеть, как коллективные результаты индивидуально разумных решений могут быть катастрофическими; где они могут увидеть связь между структурой системы и динамикой, которую она порождает».
Интересно, что игра упоминается как «авиа-симулятор» для менеджеров (management flight simulator) — концепция, активно используемая Патриком Стюартом в его симуляциях Okaloa (что не должно быть странным, учитывая влияние Джона Д. Стермана). Кроме того, для кого-то может быть «откровением» увидеть, что множество принципов и концепций (например, на первом месте — опыт), которые используются в «передовых» Agile-играх и симуляторах, существуют уже полвека.
Как вы, наверное, уже заметили, очень сложно провести тонкую грань между симуляциями Kanban, Lean, Agile-симуляциями и играми. Очень часто затронутые концепции смешиваются. В этой статье я ограничивал область действия только вещами, связанными с Канбаном, иначе это было бы нереально долго и вообще не использовалось бы, потому что в целом существует действительно много Agile-игр (сообщество, похоже, немного одержимо играми и моделированием). Если вы хотите узнать больше в этой области, я бы посоветовал посмотреть самостоятельно:
В этой статьей перечислены только Канбан-игры, но также есть множество Agile и Lean игр.
Наслаждайтесь игрой!
]]> Метрики Agile-трансформации http://neogenda.ru/blog/2x2c4ppt41-metriki-agile-transformatsii http://neogenda.ru/blog/2x2c4ppt41-metriki-agile-transformatsii?amp=true Sun, 17 Mar 2024 16:18:00 +0300 Артур Нек Перевод статьи Fernando Cuenca, размещённой на www.agileadvice.com. Оригинал можно прочитать здесь. Когда вас попросят предоставить показатели для оценки...

Метрики Agile-трансформации

Перевод статьи Fernando Cuenca, размещённой на www.agileadvice.com.
Оригинал можно прочитать здесь.
Когда вас попросят предоставить показатели для оценки того, «насколько хорошо» идёт Agile-трансформация, сосредоточьте обсуждение вокруг измерения изменений в то, какое влияние IT-организация оказывает (или нет) на её бизнес-среду, и определите небольшой набор метрик «соответствия предназначению».

Неизбежный вопрос о показателях Agile-трансформации

Рано или поздно, когда IT-организация начнёт движение в сторону Agile-мышления и практик, кого-то попросят предоставить «веские доказательства» того, что усилия окупаются. Вывод будет заключаться в том, что метрики — это средство для удовлетворения этого запроса. Каковы же ваши метрики Agile-трансформации?
По моему опыту, такой запрос обычно приводит к обсуждению оценки конкретных Agile-инициатив, запущенных IT-организацией. В организациях, где упор идёт на инженерные дисциплины, такими метриками могут быть покрытие кода модульными тестами или время сборки интеграции. Если фокус был на командах и процессе, то в качестве выбора может появиться подсчёт количества команд, «преобразованных» в Scrum, или людей, отправленных на обучение Scrum Master.
Хоть эти измерения и могут быть полезными индикаторами в определённом контексте, но у них есть две проблемы. Во-первых, они сродни измерению производительности автомобильного двигателя, не глядя в окно: двигатель может работать хорошо, но если у машины нет колёс, то мы никуда не поедем. Что ещё более важно — эти цифры обычно бессмысленны для заинтересованных сторон бизнеса, которые обычно и просят их в первую очередь. Метрики Agile-трансформации должны быть значимыми для бизнеса.

Переосмысление вопроса о метриках Agile-трансформации

Усилия по Agile-трансформации могут быть очень дорогостоящими, поэтому законно спросить о результатах таких усилий. Однако, важно понимать, что этот вопрос на самом деле эквивалентен другому: «Увеличивает ли IT-организация влияние на свою бизнес-среду». Другими словами, заимствуя терминологию, используемую Канбан-сообществом: «становится ли IT-организация всё более и более соответствующей предназначению?» Ответ на этот вопрос, конечно, требует чёткого понимания того, чего бизнес ожидает от взаимодействия с IT.
IT-организацию можно рассматривать как организацию, предоставляющую клиентам различные сервисы. Возможно, если IT-специалисты решили каким-то образом «трансформироваться» (возможно, путём перехода к Agile-мышлению), они делают это, чтобы усилить своё влияние на этих клиентов. Поэтому это именно то, что нужно измерить, чтобы знать как происходит трансформация.
Некоторые из этих клиентов относятся к разным сферам деятельности организации (например, финансы или HR). Но это ещё не всё, потому что взаимодействие бизнеса с IT не имеет ценности само по себе. В конечном итоге бизнес использует IT, как способ оптимизации своей деятельности, чтобы предоставлять внешним клиентам более эффективные продукты и услуги. Более того, в наши дни IT — это прямой канал, через который эти продукты и услуги доставляются внешним клиентам (например, через веб-сайты и мобильные приложения). Таким образом, концепция «соответствия предназначению» IT-организации может быть расширена, чтобы учитывать соответствие предназначению бизнеса в отношении внешних клиентов, которых он намерен обслуживать.

Определение метрик «Agile» трансформации

Измерение «успеха Agile-трансформации» на самом деле означает измерение успеха взаимодействия между IT и бизнесом, а также между бизнесом и его внешними клиентами. Измерение внутренних процессов и практик, которые IT-компании внедряют в рамках этой «трансформации», не имеет значения. Это подразумевает, что начинать нужно с тщательного определения границ, которые покажут очертания этого взаимодействия (который мы хотим измерить). К примеру, соответствие предназначению внешнего клиента может иметь большее значение, чем IT-операции. Это необходимо учитывать при определении метрик Agile-трансформации, особенно, если позже мы будем делать выводы о причинно-следственных связях.
Определение метрик Agile-трансформации, конечно же, будет всегда лежать в неком контексте, потому что каждая бизнес-организация индивидуальна. Но тем не менее, мы можем снова позаимствовать у Канбан-сообщества некоторые общие рекомендации о том, что искать. Их идейные лидеры говорят о классификации показателей на 3 категории: показатели соответствия предназначению, показатели здоровья и драйверы улучшения. Используя эту структуру, когда мы говорим о «показателях Agile-трансформации», мы имеем в виду в основном первую категорию и, возможно, немного вторую. На их основе могут быть реализованы инициативы по улучшению, которые, возможно, будут управляться с помощью показателей, относящихся к третьей категории.
Показатель соответствия предназначению (также известный как KPI) — это показатель того, что нужно клиенту. Это ключевое различие: если показатель не является легко узнаваемым и значимым для клиента, то это не ключевой показатель эффективности. Другой ключевой характеристикой является то, что можно определить минимальный порог для его значения: если показатель опускается ниже порогового значения, бизнес ставит под угрозу отношения со своими клиентами (возможно, они уйдут, инициируют судебные иски и т. д.). Другими словами, бизнес больше не «соответствует предназначению». Затем мы можем измерить эффективность «Agile-трансформации», проанализировав, как значения KPI с течением времени сравниваются с соответствующими пороговыми значениями. Типичный KPI — это время доставки, которое измеряется с момента принятия и выполнения запроса клиента до момента его поставки в производство. Обычно, это хорошая метрика Agile-трансформации.
Индикаторы здоровья — это метрики, обращенные вовнутрь. На самом деле, клиенты не заботятся о них (или даже не понимают), но они показывают, как работает тот или иной аспект системы. Ключевой особенностью является то, что они не имеют прямого действия; они только предоставляют информацию, которую необходимо проанализировать и поместить в контекст. По мере изменения значения индикатора работоспособности мы можем сделать некоторые выводы о том, как работает система, или объяснить, почему что-то происходит (или нет), но это не обязательно ведёт к конкретным действиям. Яркий пример этого — подсчёт дефектов. Клиенты, безусловно, будут заботиться о качестве продукта, и мы можем сделать выводы об этом качестве, посмотрев, сколько у нас дефектов, но абсолютное количество дефектов не обязательно сделает продукт более или менее пригодным для использования. Может случиться так, что покупатели сочтут текущее качество «достаточно хорошим» независимо от количества дефектов.
Наконец, метрики драйвера улучшения — это показатели, которые используются для влияния на поведение по отношению к конкретному изменению. Их ключевая особенность в том, что они временные: мы устанавливаем для них цель, и как только цель достигнута, метрика больше не нужна. Причина этого связана с непреднамеренным поведением, которое метрика может стимулировать у людей, что может привести к локальной оптимизации метрики за счёт других аспектов, что приведёт к глобальной субоптимизации системы. Здесь примером может служить покрытие кода модульными тестами: если мы определили, что данный сервис не соответствует предназначению, и причина связана с плохим покрытием модульными тестами, то установка целевого показателя минимального покрытия может повлиять на разработчиков, чтобы они работали над добавлением тестов для изменения ситуации.
]]> Стимулирование эволюционных изменений с помощью Канбан Метода http://neogenda.ru/blog/hpxuyn1551-stimulirovanie-evolyutsionnih-izmenenii http://neogenda.ru/blog/hpxuyn1551-stimulirovanie-evolyutsionnih-izmenenii?amp=true Mon, 18 Mar 2024 16:22:00 +0300 Артур Нек Перевод статьи David J Anderson, размещённой на djaa.com. Оригинал можно прочитать здесь. Замечание переводчика: Эта серия статей была опубликована...

Стимулирование эволюционных изменений с помощью Канбан Метода

Перевод статьи David J Anderson, размещённой на djaa.com.
Оригинал можно прочитать здесь.
Замечание переводчика: Эта серия статей была опубликована задолго до появление классов KMM и KCP. Поэтому стоит читать все упоминания KCP, как современный уровень AKC. И классы претерпели серьёзное изменение, поэтому проверьте текущую повестку классов соответствия вашим ожиданиям, если соберётесь их пройти.
Это четвёртая часть моей серии статей, посвящённой Канбану, организационной зрелости и эволюционным изменениям. Если вы еще не читали части с 1 по 3, вы можете наверстать упущенное здесь:
Часть 1: Организационная зрелость и эффект J-кривой
Часть 2: Паттерны зрелости Канбана
Часть 3: Канбан-паттерны и организационная зрелость
Эта серия предназначена для освещения навыков и опыта специалистов по Канбан-коучингу (KCP), которые завершили своё обучение в рамках профессионального мастер-класса по Канбан-коучингу, а затем завершили период практики, представив эссе с описанием своего опыта и инициатив по изменению, в которых они сыграли ведущую роль. В конце они прошли групповое интервью с действующими KCP, чтобы завершить программу и быть номинированными в качестве новых KCP своими коллегами. Мы связываем результаты сильных улучшений и успешные инициативы по изменениям с вовлечением специалистов по Канбан-коучингу. Успех — не случайность, KCP используют ряд моделей в своих взаимодействиях с клиентами и имеют доступ к широкому сообществу коллег через онлайн-форумы и личные мероприятия, такие как Kanban Leadership Retreat — глобальная серия конференций в формате лагеря консультантов. Если вы стремитесь улучшить свою организацию эволюционным образом, подумайте об обучении своих лидеров изменений в качестве KCP или привлеките существующего KCP в свою команду для обучения инициативе по изменениям.

Вступление

До сих пор в этой серии статей мы пытались понять, как оценить организационную зрелость, различные виды Канбан-досок и систем. И мы увидели, что различные виды прото-канбана или Канбан-систем больше подходят для разных уровней организационной зрелости. Отсюда становится очевидным, почему у нас так много разнообразия на рынке, и как первоначальные реализации Канбана оказывались на уровнях зрелости с 3 по 5, в то время как бОльшая часть рынка находится на уровнях 1 и 2. Это объясняет, почему более 80% рынка находится на очень упрощенных уровнях прото-канбана. Мы также поняли, почему важна организационная зрелость, а также рассмотрели её преимущества — предсказуемость, управление рисками, надёжность и «антихрупкость». В этой статье мы рассмотрим то, как вы продвигаетесь по лестнице зрелости и как вы углубляете свою реализацию Канбана для получения преимуществ более высоких уровней. Как и всё, чего стоит достигать, достижение более высокого уровня организационной зрелости требует небольшого стресса. Навык коучинга состоит в том, чтобы знать, насколько большой стресс нужен и какого типа, чтобы эффективно добиться результатов. Каждый раз, когда мы вызываем небольшой стресс, мы получаем небольшой эффект j-образной кривой. Хитрость в том, чтобы стресса было достаточно для мотивации изменений, но при этом не так много, чтобы привести к регрессу. Рисунок 1 взят из первой статьи в серии и служит напоминанием о пяти уровнях организационной зрелости.

Катализатор эволюционных изменений

На Рисунке 2 показана картинка с обложки моей книги «Канбан: «Успешные эволюционные изменения для вашего технологического бизнеса». Она была нужна, чтобы передать суть Канбан Метода в одной картинке. Она содержит все элементы, необходимые для ускорения улучшений.
На картинке (рис. 2) команда собирается перед своей Канбан-доской. Из разговора и изображения тикетов на доске за ними видно, что не всё у них идёт хорошо. Что-то создаёт для них стресс. Встреча для них — это средство поразмышлять о том, что происходит, а четвёртый персонаж совершает акт лидерства и предлагает им «что-то с этим сделать». Картинка содержит все три элемента, которые необходимы нам для эволюционного улучшения: фактор стресса; механизм рефлексии и лидерство.

Формула, способствующая эволюционному совершенствованию

На рисунке 3 показана модель организационной зрелости вместе с формулой для эволюционных улучшений и некоторыми показателями того, как элементы по-разному проявляются по мере взросления организации и углубления использования Канбан.
Формула, приводящая к эволюционным изменениям:
  1. Стрессор
  2. Механизм рефлексии
  3. Лидерство
Наиболее часто под фактором стресса в Канбане понимают WIP-лимит. Он вызывает стресс, когда работники оказываются без дела, зачастую по причинам, не зависящим от них: по внутрисистемным и случайным причинам или же по внешним причинам, у которых есть определенная первопричина. Как бы то ни было, безделье или «расслабленность» создают стресс.
Наиболее часто концепцией механизма рефлексии является Канбан-митинг. Такие собрания по умолчанию проводятся ежедневно перед Канбан-доской. Каденции зависят от контекста. Частота влияет на количество возможностей для изменения процесса и, следовательно, на эволюционный шаг. Что само по себе несущественно для механизма эволюции. Для эволюции важно то, что митинги происходят. На эффективность эволюционных изменений будет влиять их частота. Важно адаптировать её к окружающей обстановке: проводить митинги достаточно часто, чтобы производить изменения, но в то же время достаточно редко, чтобы обеспечить поступление новой информации со времени последней встречи.
Третий принцип управления изменениями в Канбан — «поощрять акты лидерства на всех уровнях». Важно, чтобы акты лидерства могли происходить и действительно происходили во время рефлексии. Канбан-митинг, на котором нет лидерства, потому что участники не чувствуют себя вправе вносить изменения, — это плохо спланированный митинг и плохо спроектированный механизм рефлексии. Частично ответственность за поощрение лидерства и работу со средним и старшим руководством ложится на коуча, чтобы гарантировать работу механизмов рефлексии, чтобы лидерство могло иметь место и действительно происходило.
Как правило, если предложения по улучшению не исходят из вашего механизма рефлексии, значит, он плохо спроектирован — подумайте о работе со специалистом по Канбан-коучингу, чтобы улучшить его.

Повышение организационной зрелости путём эволюционных изменений

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

Уровень зрелости 1

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

Что делать, если любая форма визуализации создаёт слишком большой стресс?

Бывают обстоятельства, когда визуализация не является простым или возможным выбором. Это может произойти в более зрелых, но нефункциональных организациях. Мы видели примеры, когда вице-президенты из Project Management Office (PMO) в ярости срывали Канбан-доски Портфеля проектов. Некоторые неуверенные в себе менеджеры среднего звена не ценят прозрачность. Часто их самооценка основана на способности контролировать информацию. Слишком большая прозрачность ослабляет основу их власти, снижает самооценку и наполняет их страхом, что всё вышло из-под контроля. Они существуют в своём ограниченном мире, в котором управление информационным потоком означает, что всё под контролем.
Канбан-коучам, которые сталкиваются с ситуацией, когда визуализация представляет собой слишком много стресса, рекомендуется начать с других аспектов и практик Канбан Метода. В частности, рекомендуется начать с «явных правил».

Известны ли побочные эффекты «явных правил»?

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

Визуализация, Канбан-митинги и персональные WIP-лимиты

Наиболее распространённые факторы стресса и механизмы рефлексии на уровне зрелости 1 — это использование доски для визуализации работы и рабочего потока; проведение Канбан-митингов зачастую на уровне команды, а иногда и на более широком уровне рабочего процесса (на более высоких ступенях уровня зрелости 1); и использование WIP-лимитов на одного человека. Честно говоря, я не уверен, что персональные WIP-лимиты являются стрессорами. На самом деле они имеют противоположный эффект — они приносят облегчение. Облегчение перегрузки создаёт возможность для размышлений. Таким образом, на уровне зрелости 1 мы полагаемся в основном на визуализацию и, возможно, на чёткие политики для создания стресса. В то же время регулярные митинги перед доской в сочетании с персональными WIP-лимитами подтолкнут на размышления, необходимые для улучшений.

Уровень зрелости 2

На 2-м уровне у нас уже есть предсказуемость процесса. У нас есть концепция клиента, работа по запросу клиента и поток задач. Теперь у нас есть цепочка работников умственного труда, сотрудничающих в серии мероприятий. Фактором стресса теперь является Канбан-система — WIP-лимиты в столбцах на доске. Хотя Канбан-митинг остается ключевым элементом метода и является механизмом рефлексии и обратной связи, теперь, как часть процесса мы видим прямое взаимодействие с заказчиком и людьми, которые принимают поставку и управляют готовым продуктом в производственной или полевой среде.
Теперь собрания по пополнению и собрания по планированию поставок действуют и как стрессоры, и как механизмы рефлексии. Мы должны начать видеть предложения по улучшению и изменения процессов, происходящие в результате этих встреч. Это становится ещё более верным, когда мы продвигаемся вверх по уровням зрелости 3 и 4. Однако уже на уровне зрелости 2 у нас впервые появляется вытягивающая система. Это создает положительную напряженность в отношениях с теми, кто создаёт запрос — с клиентами. Теперь они должны решить: над чем работать сейчас, а что оставить на потом, на сколько позже, а от чего вообще стоит отказаться, так как пропускной способности не хватит на всё. Точно так же наша способность обеспечивать частые поставки должна начать подталкивать последующие операции. Мы должны увидеть, как внешние изменения ускоряются в результате нашего решения использовать Канбан в нашем рабочем процессе поставки сервисов.

Уровень зрелости 3

На уровне зрелости 3 показатели становятся гораздо более важными. Теперь у нас есть формальное понимание ожиданий клиентов и, возможно, формальные соглашения об ожидаемых поставках, такие как Соглашение об уровне сервиса (Service Level Agreement, SLA). Мы увидим появление классов обслуживания в Канбан-системах. Есть веские аргументы в пользу того, что ожидания клиентов, выраженные как SLE (ожидания уровня обслуживания, Service Level Expectations) или формальные SLA (соглашения об уровне сервиса), теперь становятся источником стресса. Они, безусловно, повлияют на повседневные операционные решения о том, что вытягивать, и куда распределять работников и другие ресурсы. Если у вас есть конкретные истории, описывающие, как метрики управляют эволюцией процесса, мы хотели бы их услышать. Механизмы рефлексии совершенствуются с использованием Ревью сервисов поставки, где рассматриваются внешние метрики возможностей, а также Ревью рисков, на которых рассматриваются факторы, влияющие на поставку и возможности внутри компании. Масштаб, как правило, находится на уровне независимых рабочих процессов поставки сервисов. Хотя мы уже можем начать видеть использование объединения рабочих процессов обслуживания как новую форму фактора стресса.

Уровень зрелости 4

Обычно два рабочих процесса, в которых один выполняет элементы, зависимые от другого, отделены неограниченным буфером или «парковкой». По мере развития организации и масштабирования реализации Канбан эти неограниченные буферы ограничиваются WIP-лимитами. Это создаёт напряжение между Канбан-системами и требует использовать механизм обратной связи и рефлексии на уровне организации — Операционное Ревью.
На уровне зрелости 4, определение размера буфера для зависимых рабочих процессов и распределение мощности по типам рабочих элементов и классам обслуживания становится важным фактором стресса, приводящим к организационным улучшениям и общим улучшениям в обслуживании клиентов и соответствию поставленной цели. Стратегии хеджирования рисков, выбранные по особо чувствительным причинам, вызовут стресс. Например, возникнет желание использовать множество тактических возможностей в ущерб стратегическим инициативам. Для организации становится важным не терять самообладание и оставаться в рамках WIP-лимитов. Возможность сделать это указывает на институционализацию уровня зрелости 4.

Уровень зрелости 5

На 5-м уровне зрелости, чтобы спровоцировать дальнейшие и более масштабные эволюционные изменения на уровне бизнеса, мы начинаем выходить за рамки Канбан Метода и использовать элементы планирования сервисов уровня предприятия (ESP): сравнение стратегии с возможностями; и использование Ревью стратегии как механизма рефлексии для стимулирования изменений.
На этом уровне стрессором является сочетание бизнес-стратегии и бизнес-целей. Важно, чтобы стратегия была сбалансирована с возможностями и расширяла их ровно настолько, чтобы действовать как позитивный двигатель изменений, улучшений и инноваций, а не просто разрушать организацию. Военные лидеры веками понимали, что если вы хотите добиться успеха, то выбираете стратегию, основанную на ваших способностях. Если есть разрыв между желаемым результатом, стратегией, необходимой для его достижения, и текущими возможностями, тогда они сначала инвестировали в возможности. Они не позволяли политикам настраивать их на провал, безрассудно следуя стратегиям, которых невозможно достичь с помощью имеющихся возможностей. Обычно корпоративные лидеры не проходят такого обучения. Зачастую они выбирают «большие непослушные и дерзкие цели» и считают, что это действует как фактор стресса, побуждающий к переменам. Однако эти лунные съёмки, как правило, никогда не финансируются и не поддерживаются так хорошо, как программа «Аполлон». Более вероятно, что руководство операционного уровня останется в неведении относительно того, как они могут выполнить запросы своего высшего руководства. Поэтому они просто щёлкают кнутом, ожидая бОльшего от организации, которая на это неспособна. За этим следует чрезмерная нагрузка, чрезмерное усилие и чрезмерное растяжение. Результатом часто бывает катастрофическая неудача и, возможно, возврат к уровню зрелости 1 или 2.
В настоящее время коучинг корпоративных целей и стратегии как отражение возможностей предоставления услуг выходит за рамки программы Kanban Coaching Professional.

Как далеко может нас довести тренер?

Специалист по Канбан-коучингу (KCP), возможно, работая с аккредитованным Канбан-тренером (AKT), может провести вас от среднего уровня зрелости 1 до уровня зрелости 5. Более высокие уровни зрелости требуют знакомства с планированием сервисов уровня предприятия (ESP) и, в частности, стратегии и соответствия целевым предметам учебной программы. В настоящее время существует лишь небольшая часть KCP, обладающих такими знаниями и опытом.

Как далеко может нас довести ваш Agile-коуч?

Основываясь на данных, которые мы видим на рынке, то ситуация обстоит так. Если Agile-коуч не проходил специального обучения Канбану, но имеет некоторое представление о методе через сообщество, конференции по Agile и, возможно, прочитал несколько книг (чаще всего очень тонкую, бесплатную книгу 2008 года, которая мало раскрывает тему и несёт в себе ряд мифов и неточностей), то такой Agile-коуч может начать вести вас с 1-го уровня зрелости с помощью Персонального Канбан и довести до среднего уровня зрелости 1 с Командным Канбан. Некоторые Agile-коучи способны довести вас до 2-го уровня зрелости с помощью Агрегированного Командного Канбана, реализации прото-канбана. Возможно они продемонстрируют вам некоторые атрибуты реализаций уровня 3 или 4, например такие как элементарные классы сервиса или некоторые метрики.
Agile-коучи, которые помогут вам продвинуться дальше, будут иметь специальную подготовку и опыт, которыми они поделятся с вами в рамках своих маркетинговых материалов. Они будут считать себя тренерами по Канбану.
Оценивая Канбан-тренера, спросите его, какое обучение по Канбан Методу он проходил и какие сертификаты у него есть. Спросите на каких конференциях по Lean Kanban он бывал и выступал ли он когда-нибудь. Спросите, какие мероприятия Kanban Leadership Retreat он посетили чему он научился из этого опыта. Попросите его показать вам свой вклад в сообщество: статьи в Интернете, в печатных СМИ или общественных организациях, таких как Limited WIP Society или Lean Coffee в их регионе. Канбан-тренеры, которые могут показать результаты, могут показать вам этот материал. А вот тренеры, которые блефуют, не смогут показать вам ничего из вышеперечисленного.

Вывод

Достижение преимуществ для более высоких уровней организационной зрелости может быть достигнуто с использованием Канбан Метода в качестве подхода к улучшенной поставке сервисов и эволюционным изменениям. Кто-то, возглавляющий инициативу Канбан, должен осознавать уровень зрелости организации при выборе механизма для эволюционного улучшения. По мере развития организации и углубления использования Канбан, важные факторы стресса и механизмы рефлексии, необходимые для дальнейшего развития организации, изменятся. Объём и масштаб так же изменятся. Персонал, который будет участвовать в этом процессе тоже изменится, а уровни его заработной платы будут расти, пока, в конце концов, мы не окажемся на вершине. Специалисты по Канбан-коучингу обучены навыкам проектирования Канбан-систем и досок, которые настроены на уровень организационной зрелости и имеют правильные факторы стресса для ускорения улучшений, не перенапрягая организацию и не вызывая сбоя Канбан-системы и регресса в организационной зрелости.
В обучении Канбану и его использовании для стимулирования изменений есть много тонкостей. Есть причина, по которой требуется от 10 до 15 дней обучения плюс месяцы или годы практического опыта, чтобы стать эффективным тренером по Канбану. Если вы хотите добиться успеха в эволюционных изменениях, работайте с профессионалом — выберите кого-то с историей участия в сообществе Lean Kanban, кого-то, кто посещал мастер-классы по коучингу Канбан, кого-то, кто является спикером на конференциях Lean Kanban, кто посещает Kanban Leadership Retreats, чтобы делиться опытом и учиться у своих коллег. Мы соотносим успешные результаты со знаниями и опытом.
]]> Канбан-паттерны и Организационная зрелость http://neogenda.ru/blog/97a6i9zmj1-kanban-patterni-i-organizatsionnaya-zrel http://neogenda.ru/blog/97a6i9zmj1-kanban-patterni-i-organizatsionnaya-zrel?amp=true Tue, 19 Mar 2024 07:47:00 +0300 Артур Нек Перевод статьи Дэвида Андерсона, опубликованной на djaa.com. Оригинал можно прочитать здесь. Это 3-я часть моей серии статей,...

Канбан-паттерны и Организационная зрелость

Перевод статьи Дэвида Андерсона, опубликованной на djaa.com.
Оригинал можно прочитать здесь.
Это 3-я часть моей серии статей, посвящённой изучению Канбан-систем и дизайна досок, а также их соотнесению с организационной зрелостью, как основным инструментом коучинга. Если вы ещё не читали, то прочтите Часть 1: Организационная зрелость и эффект J-кривой и Часть 2: Паттерны зрелости Канбана. В этой части я беру все Канбан-доски и системы из Части 2 и сопоставляю их со структурой оценки организационной зрелости из Части 1.
Ценность материала в том, что это быстрый и эффективный метод оценки организационной зрелости, а также небольшой каталог паттернов повышения зрелости Канбан-досок и Канбан-систем обеспечивает профессионалов Канбан-коучинга последовательным набором начальных дизайнов, которые, будут успешными в ускорении применения Канбана и катализировании дальнейших эволюционных изменений.
Другими словами, мы сопоставляем сложность дизайна со сложностью организации. В Части 4 я рассмотрю, что нужно для продвижения вверх по лестнице организационной зрелости с эволюционными изменениями.

Сопоставление Канбан-дизайнов с уровнями организационной зрелости

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

Персональный Канбан

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

Агрегированный Персональный Канбан

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

Командный Канбан

Командный Канбан демонстрирует, что открытое сотрудничество происходит на уровне команды от 2 до 6 человек (возможно до 12 человек). Команда может предоставлять отдельные сервисы, но чаще всего они являются частью большого рабочего процесса. На этом уровне обычно отсутствует сервис-ориентация. Командные Канбан-системы остаются внутренне-ориентированными, освобождая от чрезмерной нагрузки. Как правило, они ориентированы на задачи, а не на клиента. Когда тикеты действительно представляют собой работу, ценную для клиента, а клиента можно идентифицировать — это признак того, что команда предоставляет отдельные сервисы, и в организации зарождается некое сервис-ориентированное мышление.
На рисунке 3 показано, что Командный Канбан появляется на уровне зрелости 1, когда мы начинаем видеть переход от сосредоточения внимания на отдельных лицах к групповому сотрудничеству. Командный Канбан, скорее всего, будет успешным, даже если будет полагаться на индивидуальный героизм и некоторую долю удачи в выполнении ожиданий клиентов.

Возникающие рабочие процессы

Что отличает возникающие рабочие процессы от Командного Канбана, так это явное понимание того, что существует рабочий процесс и, следовательно, предоставление сервиса. По определению существует заказчик, обращающийся с запросом на сервис. Тикеты на доске возникающих рабочих процессов, как правило, запрашиваются клиентом и, следовательно, представляют собой работу, которая ценится клиентом. В этом дизайне мы видим появление сервис-ориентированности. Хотя рабочий процесс (пока) не совсем понятен, существует ориентация на клиента. Становятся более очевидны ценности и принципы Канбан Метода. По этой причине показано, что доски возникающих рабочих процессов требуют бОльшей организационной зрелости, чем доски Командного Канбана. Мы всё ещё находимся в рамках уровня зрелости 1, как показано на Рисунке 4, поскольку мы не можем определить рабочий процесс поставки сервисов, но семена растущей зрелости уже посеяны.

WIP-лимит на человека

С доской «WIP-лимит на человека» впервые мы имеем определённый рабочий процесс. Сейчас мы находимся на границе уровня зрелости 2, как показано на рисунке 5. Организация готова к стрессу от вытягивающей системы со сквозными WIP-лимитами, но у нас есть сервис-ориентация, определённый рабочий процесс и доска с визуализацией важных для клиента рабочих элементов. Мы наблюдаем более глубокую реализацию Канбан Метода с большим количеством существующих ценностей и практик.

CONWIP & Развязанные каденции

Способность отделять каденцию планирования, выполнения или выбора работы от каденции поставки, демонстрирует растущую организационную зрелость и способность координировать действия с избранной аудиторией. Необычно, чтобы аудитория на собрании по пополнению совпадала с аудиторией на собрании по планированию поставки. Следовательно, разделение их с точки зрения приглашённых участников и частоты появления — является признаком растущей зрелости. Кроме того, обладание возможностью продолжать работу во время поставки, демонстрирует некоторые дополнительные технические возможности: для разработки ПО требуется способность управления конфигурацией с возможностью использования маркировки или ветвлений в системе контроля версий, или для встраивания в код динамических переключателей кода, чтобы сделать частично готовые функции неактивными при поставке.
Управление конфигурацией — это область процесса уровня зрелости 2 в CMMI. Вместе с определённым рабочим процессом и реальной системой вытягивания, теперь мы прочно находимся на территории уровня зрелости 2. Этот стиль доски показан, как пограничный уровень зрелости 2 на Рисунке 6, поскольку рабочий процесс может быть неглубоким. Мы можем иметь дело с Командным Канбаном, который был выделен, или с командным уровнем пакетного процесса, таким как Скрам, который был отделён. Необязательно, чтобы доска с таким дизайном была частью сервис-ориентированного и клиент-ориентированного рабочего процесса. Следовательно, может быть меньше значений и принципов Канбан, присутствующих в организации, применяющей CONWIP, как показано на Рисунке 6, чем «WIP-лимит на человека», как показано на Рисунке 5.
Я решил показать его, как немного более зрелый из-за появления надлежащей системы вытягивания впервые и, следовательно, — это пограничная правильная Канбан-система. С этим дизайном мы оставляем прото-канбан позади.

Агрегированный Командный Канбан

Мы прочно стоим на территории уровня зрелости 2, как показано на Рисунке 7. У нас есть определённый рабочий процесс, ориентированный на сервис и клиента. У нас есть командный уровень Канбан-систем с локализованным вытягиванием и выраженной перегрузкой. Качество, предоставляемое клиенту, почти наверняка улучшится, даже если другие аспекты предоставления сервисов, такие как время выполнения заказа и предсказуемость, всё ещё могут страдать. Организация не готова к стрессу от правильной системы вытягивания. Концепция собраний по пополнению на уровне рабочего процесса и собраний по планированию поставки, возможно, ещё не появилась.
У нас всё ещё может быть система выталкивания с точки зрения клиента с локализованным вытягиванием на каждом уровне команды. Вполне вероятно, что клиент не участвует в принятии решений о вытягивании и очень мало взаимодействует с работниками, поставляющими сервисы. Поэтому сотрудничество по-прежнему является локальным для организации, поставляющей сервисы, но появление подобной доски показывает, что прозрачность, визуализация и сотрудничество между командами в рамках рабочего процесса имеют большое значение. Это свидетельство того, что существует определённая ориентация на обслуживание клиентов и соответствие их ожиданиям. Работа будет отражать это, а тикеты будут представлять собой рабочие элементы, ценные для клиентов, а не задачи командного уровня.

Канбан в виде физических слотов

В этот момент у нас есть вытягивающая Канбан-система. Вероятно (но не обязательно), что мы привлекаем клиентов участвовать в собраниях по пополнению, а собрания по планированию поставок тоже становятся необходимым элементом этого процесса. Теперь мы начинаем управлять потоком, поскольку мы сосредоточены на сокращении времени выполнения заказа и улучшении предсказуемости. Теперь WIP-лимиты являются явным фактором стресса в системе. И мы увидим появление поведения для управления потоком тикетов и некоторых усилий по оптимизации ликвидности в системе. Как показано на Рисунке 8, мы движемся вверх к уровню зрелости 3. Мы, вероятно, ещё не достигли его, поскольку мы выбираем Канбан-доску, предназначенную для работы с менее дисциплинированными организациями. Мы ожидаем, что организация на твёрдом 3-м уровне будет обладать дисциплиной, чтобы не злоупотреблять WIP-лимитами и понимать, когда их нарушать по тактическим причинам, а когда менять их в качестве системной корректировки.

Канбан-доска с подвижным токеном

С принятием Канбан-доски с физическими токенами, где токены, такие как магниты на магнитной доске, являются теперь Канбанами в системе и представляют собой WIP-лимит. Мы достигли уровня, на котором мы доверяем себе управлять потоком через определённый рабочий процесс. Организация не паникует при незначительных стрессах, таких как превышение WIP-лимита. Она держит свою дисциплину и реагирует, пытаясь улучшиться, когда испытывает небольшой стресс. Мы твёрдо достигли 3-го уровня зрелости, как показано на Рисунке 9. У нас есть дисциплина, чтобы не злоупотреблять WIP-лимитом, добавляя токены в ответ на тактические задачи и небольшой дискомфорт от принудительного выполнения рабочего процесса.
У нас есть клиентоориентированная и сервис-ориентированная система полного рабочего процесса, вытягивающая Канбан-система. Мы оставили мир прото-канбана позади. На этом уровне мы ожидаем, что в собраниях по пополнению будут участвовать клиенты; что на собрания по планированию поставки будут привлекаться последующие получатели продукта или сервиса, а также появится ревью поставки сервисов вместе с показателями для количественного управления потоком. Если эти атрибуты Канбан Метода присутствуют, то мы находимся на пути к уровню зрелости 4.

Виртуальные Канбан-доски

Как показано на Рисунке 10, сейчас мы находимся на среднем 3-м уровне нашей лестницы зрелости. У организации есть дисциплина, чтобы придерживаться WIP-лимитов и реагировать на небольшие стрессы улучшениями. Нам нравятся виртуальные Канбан-доски, потому что они легко и быстро меняются. У нас есть клиентоориентированная, сервис-ориентированная система, система полного рабочего процесса и вытягивающая Канбан-система. Мы действительно оставили мир прото-канбана позади. На этом уровне мы ожидаем, что в собраниях по пополнению будут участвовать клиенты; что на планирование поставки будут привлекаться последующие получатели продукта или сервиса, а также появится ревью поставки сервисов вместе с показателями для количественного управления потоком. Если эти атрибуты Канбан Метода присутствуют, то мы находимся на пути к 4-му уровню зрелости.

Классы обслуживания

В настоящее время наблюдается явное понимание потребностей, ожиданий клиентов и рисков, которыми клиент управляет. Чтобы обеспечить более качественный сервис, соответствующий рискам, которыми он управляет, мы предлагаем классы обслуживания, разделяя время выполнения заказа и ожидаемую предсказуемость по классам. Это позволяет клиенту запрашивать предлагаемый класс обслуживания на основе обоснования бизнес-риска. Собрания по пополнению теперь должны напрямую вовлекать клиента. Мы также ожидаем, что на собраниях по планированию поставки будут участвовать заказчики и заинтересованные стороны, ответственные за использование поставленного продукта. Мы также можем увидеть появление распределения мощности хеджирования рисков по классам обслуживания и, следовательно, появление методов количественного управления уровня зрелости 4. На Рисунке 11 показано, что Канбан-система рабочего процесса поставки сервисов с классами обслуживания находятся на пограничном уровне зрелости 4.

Агрегированные сервисные Канбан-доски

На Рисунке 12 показана более крупная система. Она представляет собой несколько сервисов или обслуживает несколько типов рабочих элементов, используя один и тот же пул людей и выполняя разные типы работы через идентичный или почти идентичный рабочий процесс. Агрегация обеспечивает большую ликвидность и даёт возможность управлять потоком по мере роста или падения спроса на различные типы работы. Используя распределение мощности, создавая WIP-лимиты в строках Канбан-доски, мы можем формировать спрос на данный тип работы, а также регулировать среднюю скорость выполнения работ данного типа.
Мы демонстрируем способность управлять потоком и внедряем некоторые количественные методы, чтобы гарантировать постоянное соответствие ожиданиям клиентов. Теперь у нас есть дисциплина для формирования спроса на разные виды работ. Это явное поведение уровня зрелости 4, как показано на Рисунке 12. Также возможно включить использование классов обслуживания в предоставление каждого сервиса. Следовательно, спрос может быть сформирован в двух измерениях, и сигнал к вытягиваю теперь является трёхмерным. При желании, есть возможность разделить каденции планирования, пополнения и поставки для разных типов работ (строки на доске). Уровень сложности совместной работы и управления рисками постоянно повышается по сравнению с менее зрелыми и мелкими реализациями Канбана.

Канбан-доски для оптимизации ликвидности

На Рисунке 13 показано, что, добавляя слой трудовых ресурсов на нашу Канбан-доску, мы повышаем свою зрелость. В настоящее время мы отображаем проблемы клиентов, такие как: наличие согласованного интерфейса для совместной работы и интеграция нашей потребности в управлении потоком, а также использование гибкой рабочей силы для адаптации к приливам и отливам спроса на работу определённого типа. Теперь мы интегрировали развитие и обучение персонала в нашу явную политику и нашу собственную стратегию управления рисками.
Такое поведение укрепит социальную сплочённость наших работников, улучшит сотрудничество и поможет нам управлять потоком на наиболее эффективном из уровней. Вероятно, такие Канбан-системы будут крупнее, а также будут включать большее количество людей — обычно от 25 до 50, хотя наблюдалось до 75 человек. Если в настоящее время присутствует большинство других аспектов Канбан Метода, таких как количественные показатели вместе с операционным ревью и ревью рисков, то, вероятно, у нас появляется организация уровня зрелости 5. Если в список входит «ревью стратегии», и используемые метрики являются явными критериями соответствия, основанными на понимании того, что делает наши сервисы «соответствующими предназначению» в глазах клиента, тогда у нас будет организация с прочным 5 уровнем зрелости, которая теперь оптимизирует свои экономические показатели, обеспечивает страхование её выживаемости, благодаря постоянному вниманию к цели и удовлетворённости клиентов.

Выводы

Итак, что мы узнали из соотнесения дизайна Канбан-досок с уровнями организационной зрелости?
Первое наблюдение заключается в том, что с публикацией Канбан Метода в 2010 году, основанного на работе 2007 года, мы начали с проектов уровня зрелости 4. Несмотря на то, что я и другие описали, как использовать Канбан поэтапно и начинать с более простых дизайнов, более простые версии всё ещё находились на границе 3-го уровня зрелости.
Реальность такова, что большая часть аудитории находится на гораздо более низком уровне организационной зрелости. А многие люди не были целевой аудиторией менеджеров среднего звена, подобно мне или Майку Борроузу. Когда мы увидели более низкое, низовое, восходящее внедрение, было неизбежно, что это было на более низком уровне организационной зрелости. Поэтому появление на рынке прото-канбанов было неизбежным. Это дань осознанному выбору, который я и другие сделали, чтобы определить метод в несколько свободных и двусмысленных терминах, таких как «WIP-лимит», а не явное и недвусмысленное «реализовать виртуальную Канбан-систему». Что мы получили — взрыв разнообразия и мутаций реализаций Канбана. Целая экосистема вариантов возникла из Personal Kanban и выше. Если бы метод был строго определён и недвусмыслен, у нас не было бы этого разнообразия и не было бы решений, способных помочь значительной части рынка.
Лидеры Scrum-сообщества предпочитают позиционировать Канбан как метод «только для экспертов» и «только для высокоразвитых организаций». Многие сообщили своим клиентам, что они «не готовы к Канбану». Это потому, что они рассматривали Канбан через свою собственную призму. Призму, в которой метод строго и однозначно определён. Кен Швабер совершенно ясно даёт понять, что Scrum — это определённый метод, предназначенный для реализации в том виде, в каком он написан. Скрам работает — и в этом я не сомневаюсь — в определённом контексте, и ваша задача — изменить свой контекст так, чтобы Скрам работал на вас.
Канбан же всегда был противоположностью этого. Канбан всегда был направлен на то, чтобы «начать с того места, где вы находитесь сейчас», и развиваться. Если вы собираетесь продвигать эволюционный метод, вы не можете продвигать строго определённый метод и открыто защищать его определение. Необходимо обозначить «скрам-бат», а в случае Кена Швабера — обозначить тех, кто отклоняется от точного предписания, как «скрам-бат», когда вы применяете «подход изменения контекста» для улучшения результатов предоставления сервисов. Когда вы выбираете противоположный подход, настраивая свои рабочие процессы так, чтобы обеспечить лучшее удовлетворение потребностей клиентов в существующем контексте, тогда вам придётся принять вариации и мутации.
Когда в 2008 году люди начали спрашивать: «Используем ли мы Канбан или нет?» Я всегда отвечал, что это не вопрос принятия практики, это вопрос намерения. Если у вас есть намерение «начать с того, что вы делаете сейчас», и постепенно совершенствоваться, используя визуализацию и WIP-лимиты в качестве катализаторов изменений, тогда «да, вы занимаетесь Канбан!». Если у вас просто есть несколько досок на стене со стикерами, визуализирующими задачи, и нет намерения стимулировать эволюционные изменения, тогда «нет, вы не используете Канбан».
В части 4 я исследую то, что нужно, помимо Канбан-доски и системного дизайна, для эволюционных изменений и улучшения организационной зрелости. На данный момент важно понимать, что Канбан-коучи рассматривают прото-канбан и поверхностные реализации, как необходимый инструмент для адаптации реализаций Канбан к существующим уровням зрелости организации. В методе, который действительно сосредоточен на том, чтобы «начать с того, что вы делаете сейчас», нам нужно использовать методы, которые позволяют нам делать это с минимальным сопротивлением или нарушением существующих процессов и практик.
Канбан Метод не только предназначен для эволюционных изменений в вашей организации. Он был определён таким образом, чтобы сделать возможным эволюционное изменение самого метода. Таким образом, за последние 9 лет мы стали свидетелями большого разнообразия и мутаций. Это позволило Канбану обратиться к гораздо более широкому кругу обстоятельств. Неправда, что «Канбан предназначен только для экспертов» или «только для высокоразвитых организаций».
Канбан достаточно гибкий: в руках профессионально подготовленного коуча он может быть использован в любой организации на любом уровне, Канбан может способствовать ускоренному совершенствованию организационной зрелости с соответствующими преимуществами или большей удовлетворённостью клиентов и лучшими экономическими показателями, за счёт согласованности результатов и количественного управления рисками для согласованности экономических результатов. На Рисунке 14 показано, что организации на уровне зрелости 1 получают выгоду от выраженной перегрузки. Это делает людей более счастливыми, и, как правило, приводит к повышению качества продукции или сервисов.
Удовлетворённость клиентов повышается до этой степени. На уровнях 2 и 3 мы видим переключение на поток и улучшение предоставления сервисов и соответствие ожиданиям клиентов в отношении времени выполнения заказа и предсказуемости. На уровне 4, основное внимание уделяется управлению рисками как внутри компании, так и такому обслуживанию клиентов, чтобы облегчить их собственное управление рисками. Мы видим, что стратегии хеджирования рисков появляются как способ повышения согласованности экономических результатов. При полноценном использовании Канбан Метода и достижении 5-го уровня преимущество заключается в постоянной пригодности для достижения цели, выживаемости перед лицом непостоянства, неопределённости рыночных, политических и экономических условий.
]]> Канбан-паттерны в продажах, маркетинге, финансах и HR http://neogenda.ru/blog/12lobj5391-kanban-patterni-v-prodazhah-marketinge-f http://neogenda.ru/blog/12lobj5391-kanban-patterni-v-prodazhah-marketinge-f?amp=true Wed, 20 Mar 2024 07:55:00 +0300 Артур Нек Перевод статьи Алексея Жеглова, размещённой на medium.com. Оригинал можно прочитать здесь. Люди часто обращаются ко мне за советом...

Канбан-паттерны в продажах, маркетинге, финансах и HR

Перевод статьи Алексея Жеглова, размещённой на medium.com.
Оригинал можно прочитать здесь.
Люди часто обращаются ко мне за советом по применению Канбан Метода или использованию Канбан-систем в корпоративных отделах и сервисах, таких как Продажи, Маркетинг, Финансы и Управление персоналом (HR). Я хотел бы собрать некоторые советы, которые я давал различным людям и компаниям, а также паттерны, которые я видел, и представить их в этой статье для более широкой аудитории.

В чём проблема?

Применение Канбана не только в IT-отделах вызывает смешанные чувства. С одной стороны, Канбан существует уже много лет, и это проверенный метод. С другой стороны, учитывая, что Канбан появился в процессе улучшения информационных технологий и разработки продуктов, а также учитывая распространённость опубликованных тематических исследований из контекстов IT, есть некоторая обеспокоенность по поводу его применения, например, в продажах. Это влияет на консультантов и менеджеров, пытающихся улучшить сервисы, за которые они несут ответственность, например, в финансовом отделе. Итак, эти менеджеры и консультанты спрашивают, есть ли какое-либо руководство по Канбану, подходящее под их контекст? Есть ли потенциальные ошибки, которых они должны остерегаться? Как они могут быть уверены, что применяют этот метод наиболее эффективно?
Иногда этот вопрос задают по-другому: «Где я могу найти примеры использования Канбана в продажах (HR и т. д.)?». В этом случае идёт вопрос за вопросом из абзаца выше. Я собираюсь поделиться некоторыми Канбан-паттернами, которые чаще встречаются именно в этих корпоративных отделах, чем в обычной среде Канбан-пользователей. Я думаю, что эти паттерны важны, и на них следует обратить внимание. Один или несколько из них могут быть важны в вашей конкретной ситуации. Но вряд ли мы встретим их все в одном примере.

Паттерны

Итак, вот несколько Канбан-паттернов, характерных для этих отделов.
Во-первых, это обычно более низкие уровни зрелости. Это один из полученных уроков из кейса Tupalo, которое мы обсуждаем на тренинге Kanban Coaching Professional (KCP). Это может повлиять на уровень применения Канбана (нижняя ступень прото-Канбана?), выбор управленческой повестки (больше устойчивости, чем сервисной ориентации) и выбор воркшопов (больше TKP, чем KMP I).
(Если вы менеджер, пользующийся советами консультанта по Канбану, маловероятно, что вы слышали о кейсе Tupalo. Вам не обязательно это знать, а ваш консультант обязан знать).
Во-вторых, обычно более низкая осведомлённость и понимание петель обратной связи. В отличие от мира ПО, где люди привыкли к различным петлям обратной связи в своих процессах за последние 20 лет. В продажах, маркетинге, финансах и т. д, я время от времени встречаю менеджеров, которые управляют всем без обратной связи. Они разрабатывают рабочие процессы, устанавливают правила для своих сотрудников, а затем просто предполагают, например, что все сводки будут отправлены клиентам до конца дня или все счета будут оплачены до конца недели. Они не привыкли к самому понятию механизма рефлексии, который может показать им, что фактическое время поставки намного дольше и менее предсказуемо.

Специфика Продаж

В-третьих, продажи могут быть одним из видов деятельности в гораздо более длительном рабочем процессе и включать в себя невидимую точку принятия обязательств. Сотрудничество в рамках всей организации (например, отдел продаж + R&D), чтобы чётко сформулировать это обязательство, может быть более важным, чем поверхностная Прото-Канбан доска, заполненная задачами, связанными с продажами.
В-четвёртых, отдел продаж также часто нанимает сотрудников для непосредственной работы с клиентами, которые являются источником информации о критериях соответстветствия клиентов и пороговых значениях для различных сервисов по всей компании.
Несколько лет назад я помогал компании решить проблему с простоями и координацией различных отделов и групп внутри компании. Мне пришлось делать что-то, чтобы предотвратить простои и восстановить работу сервиса. Я предпринял необычный шаг и посетил отдел продаж, чтобы поговорить с теми, кто общался с недовольными клиентами, которые, рассматривали возможность или угрожали перейти к конкуренту. Мы быстро выяснили, что MTTR (mean time to repair, среднее время ремонта), один из важнейших показателей в мире операций, не особо заботит клиентов. Их интересовало максимальное время ремонта. Им не поможет, если MTTR будет в среднем коротким, но непредсказуемым, что позволит максимальной продолжительности значительно превышать среднюю и, таким образом, превысить их порог удовлетворённости. Клиенты также не особо заботились и о другой заветной метрике — MTBF (mean time between failures, «наработка на отказ»). Пока простои не происходили слишком часто, клиенты не возражали, если ремонт был быстрым и достаточно предсказуемым, чтобы не поставить под угрозу их способность предоставлять услуги своим клиентам. Клиенты рассматривали время безотказной работы в основном как метрику тщеславия (показатель, который постоянно растёт, но не имеет смысла). Время безотказной работы 99,95% не помогло бы им, если бы 0,05% приходилось бы на крупный инцидент, который раз в год длится четыре часа. Понимание этих критериев соответствия клиентов помогло мне и моему клиенту выбрать наиболее эффективные варианты улучшения, выстроить ключевые рабочие группы и отделы, стоящие за ними, и отбросить варианты, которые не повлияли на удовлетворённость клиентов.

Специфика HR

В-пятых, моделирование вакансии как тип рабочего элемента в Канбан-системе приводит к упрощению дизайна, обслуживания, управления потоком и улучшения. Сделать кандидатов на вакансию типом рабочего элемента и смоделировать воронку рекрутинга с точкой принятия обязательств вниз по течению (письмо с предложением) — более сложный дизайн.
В-шестых, отдел кадров, в отличие от других отделов, продвигает и выполняет определённую политику компании. Допустим, существует служба, в которой отделы X, Y и Z сотрудничают в поставках клиентам. Мы применяем там Канбан и стараемся совершенствоваться. Тем временем отдел кадров запускает процесс оценки сотрудников, который вознаграждает людей за локальные или индивидуальные показатели эффективности в пределах X, Y и Z отдельно. Для руководителей отделов кадров может быть более важно осознать непреднамеренные последствия своей текущей политики и изменить их, чем иметь в своих отделах Канбан-доски, которые показывают HR-задачи.

Крупные сервисы

В некоторых сервисах есть большой объём относительно мелких задач. Например, сервис проценки или проведение сделки в отделе продаж или оплата по счёту в отделе финансов. Эти сервисы сталкиваются с уникальными проблемами при применении одной из основных практик Канбана — визуализации. Когда менеджеры таких сервисов начинают с Канбана, единственными примерами визуализации, на которые они могут взглянуть, являются Канбан-доски от IT-отделов и отделов разработки ПО.
Менеджеры считают такие примеры визуализации бесполезными по некоторым веским причинам. Канбан-практика визуализации — это не то же самое, что и Канбан-доски.
Если вы посмотрите на типичную Канбан-доску по разработке ПО, с несколькими десятками карточек, то поймёте, что это в некоторой степени точная, а с другой стороны — безусловно, неточная система записи. Вы примерно знаете, когда какой-то рабочий элемент начался, закончился и в каком состоянии он находится. Без этой несколько неточной системы записи, группа разработчиков ПО была бы в неведении. Доска помогает им показывать свою работу.
По долгу службы, сервисы с большими объёмами в области финансов и продаж имеют высокоточные системы учёта — CRM и ERP-системы, в которых каждое взаимодействие с клиентом регистрируется с отметкой времени. Но у сотрудников этих отделов часто возникают трудности, могут ли они, придя утром на работу, легко ответить на следующие вопросы:
· Сколько рабочих элементов в настоящее время выполняется (WIP)?
· Тенденция WIP повышается или понижается?
· Какие 3 самые «старые» задачи выполняются?
· Какие рабочие элементы заблокированы?
· Какие из них были заблокированы дольше всего?
В большинстве случаев у них нет простого способа получить эту информацию из своих CRM и ERP-систем. У них нет запроса или отчёта по этому поводу. Советовать им иметь Канбан-доску, как у других, бесполезно. Это похоже на заимствование ритуала одного племени от другого племени, что в итоге вызывает эмоциональную негативную реакцию. И выше я изложил чисто логические возражения, если они имеют значение.
Поэтому практика визуализации для таких групп должна быть направлена на то, чтобы помочь им увидеть, какие проблемы важно решить сегодня. Для этого потребуется определённая изобретательность, чтобы разработать решения, которые будут аналогичны доскам как у разработчиков ПО.
Приведу один пример: сервис-менеджер в одной из компании моего клиента, применил Microsoft Outlook и настроил в нём правила для обработки уведомлений о заказах по электронной почте. И теперь у них есть экран, на котором они могут легко ответить на пять вышеупомянутых вопросов. И они добиваются прогресса, сосредотачиваясь на «старых» элементах и блокерах и наблюдая за тенденциями WIP.

Сервисы с большим спросом на фиксированные даты

Это частая проблема в некоторых финансовых сервисах, которым приходится иметь дело с установленными извне сроками из-за таких вопросов, как налоги и нормативные требования.
Вот краткое описание того, как менеджеры компании моего клиента улучшили этот тип услуг. Я сосредоточусь на ключевых вещах, которые помогли им.
Во-первых, это помогло им увидеть, как Канбан-сортировка на этапе принятия обязательств увеличивает их возможности. «Сейчас-позже-никогда» предоставляет 3 варианта развития событий. Обязательное или дискреционное (на своё усмотрение) — представляет всего два варианта. Давайте уберём дискреционное, например, компания всегда должна подавать налоги, и они не могут выбирать, делать или не делать это. Удаление одного из двух вариантов не оставляет никаких вариантов. Всё обязательно, и люди воспринимают это как «начать сейчас». Запуск «всего и сейчас» быстро увеличивает незавершенную работу (WIP), сроки поставки также увеличиваются, становятся менее предсказуемыми и превышают установленные сроки. Однако, если вы удалите один из трёх вариантов в сортировке, останутся два варианта: сейчас и позже. Это открывает множество возможностей для принятия лучших решений.
3−1 = 2, но 2−1 = 0.
Во-вторых, это помогло им понять альтернативные издержки, связанные с решениями о рабочих элементах с фиксированной датой. Популярная игра GetKanban хорошо демонстрирует это с билетом F2 (для этой цели используйте GetKanban версии 5 и измените каденции первоначального пополнения на один раз в три дня). Если мы начнём его слишком рано, мы заплатим альтернативные издержки, не выполняя некоторые стандартные рабочие элементы раньше. Если большинство рабочих элементов являются стандартными, а некоторые — с фиксированной датой, сервис оплачивает альтернативные издержки из-за неоптимального начала рабочего элемента с фиксированной датой со стандартными рабочими элементами. Но когда большинство рабочих элементов с фиксированной датой, затраты должны оплачиваться элементами с фиксированной датой. Вот тогда сервис срывает сроки.
Осознав эти две идеи, менеджер последовал этому плану. Начните с максимальной прозрачности рабочих элементов и сроков их выполнения сразу после их обнаружения. Далее, частое пополнение запасов и осознанная практика принятия решений сейчас или позже. Несколько месяцев спустя показатели вовремя выполненной работы резко улучшились.

Выводы

Я благодарен читателям, которые дошли до этого места. Применение Канбан Метода в продажах, маркетинге, финансах и HR представляет не только уникальные задачи, но и уникальные возможности для их решения. И в этой статье перечислены некоторые важные закономерности, наблюдаемые в контексте этих отделов.
]]> Паттерны зрелости Канбана http://neogenda.ru/blog/jg1s8se2x1-patterni-zrelosti-kanbana http://neogenda.ru/blog/jg1s8se2x1-patterni-zrelosti-kanbana?amp=true Thu, 21 Mar 2024 07:59:00 +0300 Артур Нек Перевод статьи Дэвида Андерсона, опубликованной на djaa.com. Оригинал можно прочитать здесь. Это 2-я часть моей серии статей,...

Паттерны зрелости Канбана

Перевод статьи Дэвида Андерсона, опубликованной на djaa.com.
Оригинал можно прочитать здесь.
Это 2-я часть моей серии статей, посвященной Канбану, организационной зрелости и эволюционным изменениям. Ознакомьтесь с частью 1: Организационная зрелость и эффект J-кривой для понимания контекста.
Описанное ниже не является исчерпывающим набором дизайнов Канбан-досок. Кроме того, фундаментальные рабочие процессы, смоделированные на этих досках, никоим образом не предназначены для точного копирования. Это реальные примеры из реального мира, которые я видел за последние 10 лет. Каждый пример отражает разный уровень глубины и зрелости Канбана и может служить шаблоном или примером, вдохновляющим на создание Канбан-системы и дизайна доски.

Вступление

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

Персональный канбан

Рисунок 1. Персональный Канбан
Персональная Канбан-доска служит для отдельного человека. Использование столбца «Next» необходимо для избавления человека от чрезмерной нагрузки, связанной с размером бэклога, который может быть очень большим. Число в верхней части столбца — это WIP-лимит. Когда человек что-то завершает, он берёт работу из столбца Next. Затем он может пополнить столбец «Next», вытянув элемент из бэклога. Дисциплина пополнения может осуществляться по требованию или с определённой частотой. Вероятно, что большой бэклог может потребовать некоторое время для выбора того, что будет следующим, и, следовательно, каденция более вероятна при большом бэклоге. Если объём бэклога небольшой, то пополнение столбца «Next» по запросу вероятно тогда, когда элемент переведён в статус In-progress.
Персональный Канбан обычно ориентирован на задачу, а тикеты имеют особое значение для человека. Владелец доски обычно является и владельцем, и поставщиком сервисов, хотя существуют некоторые варианты, такие как доска в стиле Honeydue. Это список дел, который супруги могут составлять друг для друга, обычно список включает в себя рутинные или неприятные задачи по дому (прикрутить полку, вымыть посуду и т. д.), или задачи по вызову сантехника или электрика, которые приходится делать через силу.

Агрегированный Персональный Канбан

Персональный Канбан зародился в офисе примерно в 2008 году и вошёл в домашний обиход. Однако, это типично, что люди применяют его дома, а затем приносят идею в свой офис, как это произошло с Марицой Ван Ден Хевел в Южной Африке. Данный факт случайно принес ей прозвище «мать Канбана в Южной Африке». Если Персональный Канбан становится популярным в офисе, то приходит понимание, что общая доска имеет ценность — каждый в команде или отделе может видеть, что делают другие. Имеется документальное подтверждение этого кейса от Роба Фергюсона, ранее работавшего в Banfield Pet Hospital, компании Mars. Роб выиграл национальную премию за обеспечение качества, за улучшения, которые внесла в их работу агрегированная персональная Канбан-доска. Он отвечал за повышение осведомлённости об этой технике как о ценном шаге вперёд и за её последующее включение в учебную программу по Lean Канбан в качестве формы прото-канбана.
Рисунок 2. Агрегированный Персональный Канбан
На агрегированной персональной Канбан-доске каждый член команды получает строку для своего персонального Канбана. Вся команда и другие лица, например руководители отделов, видят задачи, находящиеся под управлением. Как и в Персональным Канбане, эти доски остаются сфокусированными на задачах. Подобная доска больше ориентирована на управление работниками и нарушает базовый принцип Канбан Метода, а именно принцип предоставления сервисов — «управление работой позволяет работникам самоорганизовываться вокруг неё». Это не ориентировано на рабочий процесс или сервис и, следовательно, считается формой прото-канбана.

Командный Канбан

Командный Канбан — это просто Персональный Канбан для маленьких групп: обычно от 2 до 4 человек, редко более 6. Часто он сосредоточен на задаче, но может существовать форма для представления запросов клиентов на доске. Он движется к принципу Канбан Метода — «управление работой позволяет людям самоорганизовываться вокруг неё», и вполне возможно, что команда представляет собой единый сервис, и такая простая доска ориентирована на сервисы. Если заказчик по запросу получает поставку напрямую от этой команды, мы будем рассматривать его как сервис-ориентированный дизайн и простую, но полную Канбан-систему. Чаще всего команда фактически является частью более крупного рабочего процесса, и / или элементы на доске не являются рабочими элементами, ценными для клиентов, а являются локальными задачами рабочего процесса. В этом случае Командный Канбан определённо является реализацией прото-канбана.
Рисунок 3. Командный Канбан
Командная Канбан-доска (Рис. 3) похожа на доску Персонального Канбана, но у каждого члена команды есть один или несколько аватаров, иллюстрирующих, какие рабочие задачи у них есть или над которыми они работают совместно. WIP-лимиты отображаются в верхней части столбцов и представляют собой лимит для всей команды. Наблюдается переход от управления отдельными лицами, к управлению работой как совместной деятельностью. Как и в случае с Персональным Канбаном, текущие элементы пополняются из стобца «Next». Пополнение столбца «Next» производится либо по требованию, либо в соответствии с каденцией, определённой для удобства команды.

Возникающие рабочие процессы

Когда процесс или поток работ плохо изучены или, возможно, только зарождаются в компании, возможно, это новый сервис, и люди всё ещё учатся его предоставлять, тогда стало обычным использование варианта Командной Канбан-доски. Такие примеры мы видели в отделе маркетинга и развития сообществ в Тупало (Вена), про что есть тематическое исследование. На подобных досках часто проводится качественная оценка на основе завершённости элемента. Такой дизайн используется для размещения элемента слева направо согласно его проценту завершённости В организациях с более высокой степенью зрелости количественная оценка завершённости может проводиться, даже если конкретный рабочий поток только зарождается и является недостаточно зрелым. Такая доска не является исключительной особенностью организации с низким уровнем зрелости, она скорее является индикатором зарождающейся природы рабочего процесса.
Рисунок 4. Доска зарождающихся рабочих процессов
Доски зарождающихся рабочих процессов похожи на Командный Канбан и используют аватары для членов команды для указания над чем они работают. Как правило, доски зарождающихся рабочих потоков сервис-ориентированы. Тикеты отражают работу, которую ценят клиенты. В целом уровень зрелости и сложности Канбана растёт, даже несмотря на то, что рабочий процесс находится на низком уровне зрелости и только появляется. Это всё ещё считается системой прото-канбана из-за зарождающегося рабочего процесса, но вполне вероятно, что она представляет собой систему вытягивания.

WIP-лимит на человека

Благодаря такому стилю доски, теперь у нас есть чёткое понимание рабочего потока по поставке сервисов. Однако организация эмоционально, психологически или социологически не готова к системе вытягивания. Люди ищут облегчения от перегрузки. Ответ здесь — это WIP-лимит на человека, как в Персональном Канбане, но реализованный в рамках совместных рабочих усилий. Лимит на человека реализован с помощью аватаров. В некоторых примерах, таких как кейс Тупало, мы видели такие инновации, как один большой аватар для основной задачи или рабочего элемента, где человек является его владельцем и несёт ответственность. В то время как два альтернативных аватара поменьше показывают, когда человек сотрудничает с другим человеком, помогает ему, но не является владельцем задачи и не несёт ответственности.
Рисунок 5. WIP-лимит на человека, Неограниченный рабочий процесс
На рисунке 5 незавершённая работа системы не ограничена, и в результате время выполнения заказа будет непредсказуемым. Подобная система может улучшить качество, избавить людей от чрезмерной нагрузки, но система может и дальше оставаться перегруженной. Как следствие, не удаётся обеспечить более быструю доставку и большую предсказуемость. Подобная система может быть реализована как система выталкивания. Эта система считается прото-канбан-системой, потому что есть реальные свидетельства её превращения в полноценную Канбан-систему, такую как Posit Science в Сан-Франциско — тематическое исследование, которое мы используем в нашем обучении специалистов по Канбан-менеджменту (KMPII).

Развязанные каденции & Постоянный WIP

Грант Аммонс недавно выявил этот паттерн, опубликовав несколько спорный пост «Отказ от Скрама в пользу Канбана — лучшее решение, которое мы приняли как команда». Рисунок 6 показывает интерпретацию Командного Канбана с развязанными каденциями и WIP-лимитами, охватывающим столбцы «Committed «и «In-Progress». Это слабо похоже на Скрам-доску, но без спринтов. Использование одного WIP лимита на несколько колонок известно как CONWIP («постоянный WIP»). CONWIP — это форма вытягивающей системы. Такой дизайн был кратко освещён в моей книге по Канбан в 2010 году. Таким образом, с CONWIP у нас есть система вытягивания, и это граничит с тем, будем ли мы считать её полноценной системой вытягивания или мы всё равно будем рассматривать её как прото-канбан. Я считаю, что решение зависит от двух других факторов: 1) это реализация на уровне команды? В основном это Канбан-команды с CONWIP; 2) или CONWIP — это зарождающийся рабочий поток? Если это один из этих вариантов, то полагаю, что это слишком просто для прото-канбана. Если бы CONWIP охватывал определённый рабочий поток по поставке сервисов, мы бы рассматривали его как полноценную систему вытягивания. Чтобы это произошло, рисунок 6 должен был бы больше походить на рисунок 10, но с одним CONWIP, охватывающим столбцы рабочего потока.
Рисунок 6. CONWIP для Командного Канбана

Агрегированный Командный Канбан

В течение многих лет мы думали о досках с Рисунка 7, как о вырожденных интерпретациях реальных Канбан-систем и назвали их в честь их неограниченных буферов «Выполнено» (Done). Эти неограниченные состояния делят систему и подсвечивают, что это не Канбан-система, и работа в системе не ограничена. Система не защищена от перегрузки. Это происходило в организациях, где понимали ориентацию на сервис и могли моделировать определённые рабочие потоки поставки сервиса, но не были достаточно зрелыми, чтобы справиться с использованием WIP-лимитов и вытягивающей системы в качестве фактора стресса для ускорения улучшений. Это стало распространённой формой прото-канбана даже среди организаций, прошедших базовый курс обучения по проектированию Канбан-систем (KMPI) в Lean Kanban University.
Осенью 2013 года мы с Майком Берроузом осознали: то, что на самом деле эти доски представляли из себя агрегированные, но разделённые командные Канбаны. Это стало частью нашего прозрения о свободного от масштаба подхода к масштабированию Канбан, что цель всегда состоит в устранении неограниченных буферов или очередей. Устраняя неограниченные буферы «Выполнено» на рисунке 7, вы масштабируете Командный Канбан до Канбана сервиса поставки. Это значительный шаг вперёд, так как он вызывает вытягивание со стороны клиента и изменяет фактор стресса для организации, поскольку первичная петля обратной связи переходит на собрание по пополнению. Эти концепции будут раскрыты в четвёртой статье этой серии.
Рисунок 7. Доска Агрегированного Командного Канбана
У каждой команды может быть своя собственная доска Командного Канбана. Тем не менее, существует ценность от объединения рабочих потоков сервиса поставки и визуализации сквозного процесса. Это похоже на объединение Персональной Канбан-доски в одну доску отдела, но в другом масштабе.

Прото-Канбан

Термин «Прото-канбан» был введён академическим инженером-программистом Ричардом Тёрнером из Института Стивенса. Ранее мы использовали термин «поверхностный канбан»(shallow Kanban) для частичных реализаций, но Ричард отметил, что эти поверхностные реализации часто вызревали и эволюционировали в нечто более глубокое, и появлялись системы полного вытягивания. Таким образом, «прото» относится к эволюционному предшественнику, где есть намерение продолжать использовать Канбан-системы и эволюционные изменения. Случайная доска на стене с несколькими стикерами на ней, визуализирующая какую-то работу или рабочий поток, не будет считаться прото-канбаном, если только нет намерения использовать визуализацию в качестве стрессора в преднамеренном стремлении к эволюционным изменениям. Без намерения — это просто доска на стене, визуализирующая что-то.

Полные Канбан-системы

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

Канбан в виде физических слотов

На рисунке 8 показан стиль Канбан-доски, который стал очень популярным в Бразилии, за который выступал Алиссон Вейл — один из первых последователей Канбана, лидер сообщества и лауреат премии Brickell Key Award за его достижения и вклад. Алиссон искал решение, которое помогло бы ускорить использование WIP-лимитов и обеспечить их принятие. Он искал что-то, что работало бы в условиях низкой дисциплины. Обратная сторона медали заключается в том, что этот стиль доски, как известно, тормозит инновации и эволюционные изменения. В физическом представлении доски слишком много инерции, и внесение изменений влечёт за собой слишком большие накладные расходы. Позже Алиссон признался, что сожалеет об этой инертности. Поэтому выбирайте этот стиль доски с осторожностью.
Рисунок 8. Канбан-доска, использующая физический слот для канбан-сигналов.
На доске с рисунка 8, пустой слот представляет собой Канбан-сигнал для вытягивания. Количество слотов представляет собой общий WIP-лимит для данного состояния или действия. Тикет I — это некая форма срочного запроса, которому разрешено отменять WIP-лимит. Маленький красный тикет, прикреплённый к A, означает, что A заблокирован, чтобы I мог работать. Тот, кто работал над A, будет обслуживать I. I ломает WIP-лимит. Временное превышение WIP-лимита разрешено до тех пор, пока вы знаете причины. Такой стиль доски не подходит для такого превышения. Это может быть хорошо, поскольку препятствует нарушению WIP-лимитов, но также может препятствовать тактическому использованию классов обслуживания, и это может создать сопротивление их принятию в неопределённых или сильно изменчивых средах.

Канбан-доска с подвижным токеном

На рисунке 9, Канбан — это физический токен, например магнит или скрепка. Этот стиль доски стал популярным в Европе, и впервые был замечен в таких местах, как ASR, голландская страховая компания, которую возглавляли Олав Маассен и Яспер Зонневельт. Очень хороший пример показан в тематическом исследовании Тупало. Здесь токены, такие как магниты, представляют собой WIP-лимиты. Можно делать интересные вещи, например использовать цвет для обозначения дополнительной информации, например, «вытягивается» или «заблокирован». Такой дизайн доски более гибкий и хорошо поддаётся инновациям, мутациям и эволюционным изменениям. Однако для этого требуется немного больше дисциплины и зрелости. Добавить новые токены несложно. Иногда нам это нужно, так как мы хотим временно нарушить WIP-лимит. Мы должны оставаться дисциплинированными, чтобы гарантировать, что это не станет постоянной практикой, а незавершённая работа не будет постепенно расти с течением времени.
Рисунок 9. Канбан-доска с подвижными токенами

Виртуальные Канбан-системы

На рисунке 10 показана доска, типичная для того типа, который использовался в Corbis в Сиэтле в 2007 году. Она служила вдохновением для создания Канбан Метода и стала основным стилем доски на Канбан-тренингах. Ещё с 2006 года я описывал такие системы как «виртуальные Канбан-системы», потому что в них нет физического сигнального токена. Сигнал вытягивания генерируется путём вычитания WIP-лимита, отображаемого в верхней части столбца, из количества рабочих элементов в этом столбце. Доска такого типа требует высочайшего уровня дисциплины для соблюдения WIP-лимитов и правильного использования вытягивающей системы. Кроме того, он наиболее гибок для изменения.
Рисунок 10. Виртуальная Канбан-доска

Добавление классов обслуживания

Любую из досок на рисунках 8, 9 и 10 мы можем начать приукрашивать дополнительными возможностями. Только в целях иллюстрации рисунки с 11 по 13 основаны на виртуальных Канбан-досках, подобно рисунку 10.
Классы обслуживания описывают, как следует обрабатывать рабочие элементы данного класса. В первую очередь, это используется для ускорения выполнения какой-либо работы по всем направлениям, обычно в ущерб другой работы. Использование классов обслуживания увеличивает общую вариабельность в системе и снижает предсказуемость при выполнении некоторых работ, чтобы повысить скорость и предсказуемость других элементов. Обычно это хороший компромисс в управлении рисками, и поэтому мы хотим визуализировать его, чтобы облегчить получение преимуществ.
Рисунок 11. Виртуальная Канбан-доска с классами обслуживания
На рисунке 11 показана доска, на которой тикеты рабочих элементов окрашены в соответствии с классом обслуживания, который они получают. Кроме того, элементы любого заданного класса обслуживания контролируются WIP-лимитом. Это означает, что теперь Канбан-сигналы имеют два измерения. «Входная очередь» на рисунке демонстрирует, что есть Канбан-сигналы для 4 элементов, один из которых должен быть оранжевым тикетом — по умолчанию это тикет с фиксированной датой поставки — а остальные три должны быть фиолетовыми тикетами — по умолчанию это нематериальный класс обслуживания, поскольку они имеют краткосрочные и среднесрочные стоимости задержки, которые не являются материальными или незначительными. Часто можно увидеть доску, где только самый низкий и самый высокий классы обслуживания имеют WIP-лимиты. Это «стратегия штанги», т. е. стратегия хеджирования рисков, при которой риск срочных элементов компенсируется ёмкостью, выделенной для несрочных элементов. В таких случаях другие классы обслуживания могут свободно занимать оставшуюся ёмкость независимо от конкретного типа.

Агрегированные сервисы

На рисунке 12 одна система рабочего потока и одна группа людей, работающих вместе, выполняют работу нескольких типов. Это можно рассматривать как предложение нескольких сервисов от одного поставщика. Каждый тип работы и, следовательно, каждый предлагаемый сервис моделируется с использованием разных строк на доске. В просторечии Agile-сообщества их часто называют свимлайнами («дорожками для плавания»). Также принято выделять пропускную способность для дорожки. Это ограничивает максимальную скорость поставки любого заданного типа и гарантирует, что все поддерживаемые типы получат обслуживание. Создавая WIP-лимиты для строк, мы также вводим двумерную Канбан-систему, в которой сигнал к вытягиванию может быть для элемента определённого типа. Если классы обслуживания также развёрнуты, то механизм вытягивающего сигнала может быть трёхмерным.
Рисунок 12. Виртуальная Канбан-доска с агрегированными сервисами
В этом примере показано, что общая незавершённая работа по столбцам равна пропускной способности Канбан-системы, как показано WIP-лимитами по столбцам. Однако, это может быть желательным дизайном, но не обязательным. Это возможно и часто необходимо, чтобы сумма WIP-лимитов для строк была больше, чем ёмкость всей системы. На рисунке 12 показаны карточки нескольких цветов, поэтому мы можем предположить, что классы обслуживания также развёрнуты, но не объясняются на этом рисунке.

Повышение ликвидности резерва рабочей силы

На рисунке 13 показана доска, которая иллюстрирует технику, появившуюся в компаниях Constant Contact и Ultimate Software примерно в 2010 году. За счёт объединения команд в более крупные отделы и обслуживания нескольких типов работы в единой системе, появилась возможность иметь небольшие выделенные группы для отдельных строк (или свимлайнов) на доске, сохраняя при этом около половины доступной рабочей силы в качестве гибких работников, которых можно было бы применить к любому сервису по мере необходимости. Это обеспечивало гибкость в реагировании на приливы и отливы спроса от одного типа рабочего элемента к другому.
Рисунок 13. Выделенные команды для каждой службы с гибким расширением штата
Как показано на рисунке 13, каждая строка предоставляет сервис для определённого типа рабочего элемента. В каждом сервисе есть специальная команда из 2 человек. В каждой команде есть старший участник — мастер, у которого есть ученик. Как правило, ученики будут сменяться каждые несколько месяцев. После прохождения срока работы над каждой строкой на доске под наблюдением руководителя группы, они могут быть переведены в гибкий пул работников. Гибким работникам предоставляется аватар. Аватар можно переместить в любое место на доске, чтобы увеличить доступную рабочую силу для этого сервиса по мере необходимости. Этот паттерн обеспечивает большую общую ликвидность системы, чем это было бы для отдельных частей, если бы у каждого была своя Канбан-доска и своя команда. Говорят, что гибкие работники являются универсалами или «T-образными» людьми, потому что они обладают глубокими знаниями по крайней мере в одной области и навыками во всех необходимых областях объединённого сервиса. На рисунке 13 не показаны классы обслуживания, но вполне возможно использовать все 3 стратегии с рисунков с 11 по 13 вместе.

Выводы

Этот сет из 13 дизайнов Канбан-досок не предназначен для того, чтобы быть исчерпывающим набором дизайнов, скорее он отражает образцы зрелости Канбан-системы и дизайна досок. В третьей части этой серии статей я исследую, как каждый из этих дизайнов соотносится с организационной зрелостью, и как Канбан-коучи могут использовать свою оценку зрелости и знания Канбан-паттернов, чтобы начать успешную Канбан-инициативу.
]]> Как оценить работу Скрам Мастера? http://neogenda.ru/blog/ojr39um371-kak-otsenit-rabotu-skram-mastera http://neogenda.ru/blog/ojr39um371-kak-otsenit-rabotu-skram-mastera?amp=true Fri, 22 Mar 2024 08:27:00 +0300 Алексей Пименов Этот вопрос часто возникает в тематических сообществах, посвященных Agile и HR. И на него нет однозначного ответа. Но проблема оценки Скрам Мастеров стоит и с каждым годом она становится всё сильнее и сильнее...

Как оценить работу Скрам Мастера?

Этот вопрос часто возникает в тематических сообществах, посвященных Agile и HR. И на него нет однозначного ответа. Но проблема оценки Скрам Мастеров стоит и с каждым годом она становится всё сильнее и сильнее. Дело в том, что с ростом Agile-движения в компаниях, очень сильно растёт потребность в Скрам Мастерах. Те, кто в профессии уже около 5 лет — нарасхват и на всех таких не хватает. Приходится компаниям готовить кадры, и многие энтерпрайзы делают у себя Школы Скрам Мастеров, которые в короткий срок призваны собрать кандидатов с рынка, обучить их, отсеять, проверить, хоть как-то, на практике и онбордить к себе. За последние несколько лет количество людей, вовлеченных в профессию Скрам Мастер, капитально выросло. Конечно у меня нет статистики и я пользуюсь здесь скорее своими ощущениями (от потока людей на конференции типа Agile Days, от постоянных запросов HR’ов в тематические сообщества, от притока людей в эти сообщества и т. п.).
И вот, теперь Скрам Мастеров много и надо понять, приносят ли они пользу вашей компании или нет — вполне легитимный запрос, на который сложно ответить. И в данной статье я постараюсь хотя бы задать направление, в котором стоит мыслить при выработке механизма оценки, ну и предложу от себя некоторую конкретику.
Итак, обратимся к первоисточнику, в котором прописана роль Scrum Master, его деятельность и ответственность — его величество Scrum Guide.
Первый вывод, который мы можем сделать из прочтения Scrum Guide:

Скрам Мастер не отвечает за деливери (поставку ценности клиенту).

И это может нас расстроить, т.к. всё хочется привязать к какому-то конечному результату. А здесь за поставку ценности отвечает Команда, а вот Скрам Мастеру остались кучи разных фраз, описывающих его деятельность. Но есть хорошая новость! В этих фразах есть глаголы и мы можем посмотреть, какие глаголы там применяют к Скрам Мастеру:
  • Ensuring
  • Finding
  • Helping
  • Understanding
  • Facilitating
  • Coaching
  • Leading
  • Planning
  • Causing
  • Removing
  • Working
Большинство глаголов из этого списка тяжело «оцифровать» или померить, такие вещи как Ensuring, Understanding, Coaching, Leading — они скорее про наблюдение и вдохновение и т. п., но есть глаголы, за которые хотелось бы уцепиться. Например: Removing, Working, Causing, Planning. Давайте посмотрим в контекст.
Working Полная цитата: «Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization». С налёту тут сложно что-то придумать, да ещё и деятельность тут не персональная, а группой Скрам Мастеров.
Causing Полная цитата: «Causing change that increases the productivity of the Scrum Team». О! А вот тут есть к чему привязаться, запомним этот глагол.
Planning Полная цитата: «Planning Scrum implementations within the organization». Ну тут хоть обпланируйся, имплементация может пойти не по плану, и это от качества плана зависеть, возможно, не будет. Поэтому я бы к этому глаголу не привязывался.
Removing Полная цитата: «Removing impediments to the Development Team’s progress». Это тоже классная цитата, давайте её используем.
Итак, что мы можем вытащить из Scrum Guide? Видимо чёткое понимание, что Скрам Мастер не отвечает за непосредственный Outcome Delivery команды, но благодаря глаголам Causing и Removing мы можем понять, что Скрам Мастер отвечает за то, чтобы устранялись препятствия на пути команды, и случались в команде прецеденты улучшения! А вот теперь от этого давайте построим некоторый ассессмент.
Итак, у вас раз в полгода проходит ассессмент Скрам Мастеров. Вызывается Скрам Мастер и ему задаются вопросы:

«Перечислите пожалуйста, какие улучшения произошли в команде за последние полгода?».

Это примерно 12 двухнедельных спринтов — по идее это хороший срок, чтобы что-то значительное произошло.

«Как эти улучшения повлияли на продуктивность команды?».

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

«Какую роль в этих улучшениях сыграли вы?».

Прямо нарратив о том как это всё было, что делал, куда ходил, с кем коммуницировал, какие прямо непосредственные проблемы решал и т. п. А ещё, ответы на вопросы хорошо бы дать послушать команде, чтобы они дали обратную связь — было такое или нет?
Такой ассессмент может вполне показать, как Скрам Мастер влиял на улучшения в команде, происходили ли улучшения, происходили ли благодаря, а не вопреки его действиям и обратная связь команды скажет, не слишком ли богатая фантазия у Скрам Мастера при описании своего вклада в улучшения.
Я этот механизм закидывал в FB, чтобы получить какой-нибудь фидбек от знакомых Agile-коучей. Были лайки, что говорит о справедливости и скорее всего действенности.
Остается вопрос, сколько Скрам Мастеров пройдут успешно такой ассессмент, и как интервьюер у себя в голове сопоставит те рассказы об улучшениях с теми затратами, которые идут у компании на этого Скрам Мастера — оно стоило того или нет.
P. S. Может быть такая ситуация, что развития у команды нет, но она деливерит (поставляет ценность), и этот процесс непосредственно зависит от деятельности Скрам Мастера, и потеря такого Скрам Мастера грозит развалом всего процесса. Конечно, такой Скрам Мастер ассессмент не пройдет и это правильно, ибо полгода — это неплохой срок для того, чтобы вырастить в команде хоть какую-то самоорганизацию и принятие ответственности, про которые много других, не попавших в ассессмент, глаголов.
]]> Организационная зрелость и эффект J-Кривой http://neogenda.ru/blog/4nafbknu51-organizatsionnaya-zrelost-i-effekt-j-kri http://neogenda.ru/blog/4nafbknu51-organizatsionnaya-zrelost-i-effekt-j-kri?amp=true Sat, 23 Mar 2024 08:29:00 +0300 Артур Нек Перевод статьи Дэвида Андерсона, опубликованной на djaa.com. Оригинал статьи можно прочитать здесь. Это первая из четырёх статей,...

Организационная зрелость и эффект J-Кривой

Перевод статьи Дэвида Андерсона, опубликованной на djaa.com.
Оригинал статьи можно прочитать здесь.
Это первая из четырёх статей, посвященных Канбан Методу, эволюционным изменениям и организационной зрелости. В ней я рассмотрю психологию и влияние традиционных крупномасштабных трансформаций, а также в чём состоит разница с эволюционными изменениями. Мы увидим, что организационная зрелость и терпимость руководителей играют большую роль в успехе или неудачи при традиционном управлении изменениями. Как следствие, эволюционные изменения с большей вероятностью будут успешными в организациях с более низким уровнем зрелости. За последние 6 лет это было одной из главных частей программы Kanban Coaching Professional. Все сертифицированные Канбан-тренеры знакомы с этими идеями и их применением. Если ваш Agile-тренер говорит, что он знает Канбан Метод, но не может объяснить вам как это работает, значит он не обладает достаточной компетенцией, чтобы консультировать в вопросах использования Канбан Метода или руководить эволюционными изменениями.

Модель организационной зрелости

За последние 17 лет постоянные читатели моего блога знакомы с моей работой с Институтом разработки ПО и с Capability Maturity Model Integration (CMMI, Интегрированная модель зрелости возможностей). Я был ключевым докладчиком на конференции Software Engineering Process Group. В один из прошлых годов я получил самые высокие оценки за доклад. Я стал соавтором технических заметок вместе с сотрудниками Института программной инженерии (ИМИ) Карнеги-Меллон, а также являюсь автором Microsoft Solutions Framework 2005 года для совершенствования процессов CMMI. Я заслужил уважение учёных в Институте Карнеги-Меллон, потому что я действительно понял основную идею, лежащую в основе Capability Maturity Model (CMM) для реализации идей Эдварда Деминга в разработке ПО. Следующая модель, которая вдохновила CMMI — Производственная Модель Зрелости (MMM) Филиппа Кросби. Тем не менее, те, кто знаком с CMMI, заметят, что я внёс некоторые незначительные изменения. Цель этой модели — предоставление сокращённого метода для оценки организационной зрелости в целом, для любого бизнеса и без какой-либо формальной оценки или формальной аттестации.

Оценка организационной зрелости профессиональных сервисов

На рисунке 1 показана модель PSOMM с использованием пяти уровней, аналогичных оригинальному МММ Корсби и CMMI/CM, которые последовали за ней. Пять уровней: Начальный, Определённый, Управляемый, Управляемый на основе количественных данных и Оптимизируемый. Хотя названия совпадают с CMMI, люди знакомые с ней заметят тонкую и намеренную перестановку Определённого и Управляемого уровней. Я считаю это изменение полезно по педагогическим причинам. Плюс это кажется более логичным, но я уверен, что некоторые учёные в Питтсбурге захотят поспорить об этом.

Уровень зрелости 1: Начальный

Уровень 1 описывает организации с возникающими процессами или воркфлоу предоставления сервисов. Как говорят в SEI: «уровень 1 очень глубокий». Модели уровня 1 останавливают хаос благодаря появлению зрелости почти полностью определённых процессов и воркфлоу. На первом уровне мы наблюдаем изменения от хаоса, когда «каждый сам за себя» через функциональную координацию команды, героические усилия, случайную удачу к справедливо определённым процессам и понятным воркфлоу в конечном счёте. Однако некоторые несоответствия сохраняются.
Все ещё есть элемент случайности в том, как обрабатываются запросы на сервис, и в результате нет ни целостности процесса, ни целостности результата. Энергия тратится впустую, решая проблему целостности процесса, а отсутствие целостности в том, как обрабатывается работа, приводит к отсутствию целостности результатов — как с точки зрения того, что доставлено, так и качества и согласованности, с которой оно доставлено. Нет целостности продукта/сервиса или целостности предоставления сервисов. Система хрупкая и подвержена катастрофическим сбоям. В низовьях уровня 1 он полностью неуправляем и нет никакой прослеживаемости или управления. Организация будет паниковать перед стрессом или возвращаться к поведению «каждый сам за себя», как следствие структуры, воркфлоу и процессы будут разрушены. Будет регресс к ремесленному стилю работы с героическими усилиями, иногда приносящими полезные результаты в небольшом масштабе. Координация больших групп людей становится невозможной.

Уровень зрелости 2: Определённый

На уровне 2 мы уже определили рабочие процессы. Существует целостность процесса для обработки запроса на сервис определённого типа. Если бы мы реализовывали рабочий процесс с использованием Канбан-системы или доски, мы могли бы определить Канбан-систему и использовать её целостно без переделок и обходных путей. На уровне 2 ожидается, что работа будет выполняться согласованно. Мы можем ожидать улучшения качества как продукта или сервиса, так и процесса предоставления сервисов, но будут нестыковки в том, что доставляется и как оно доставляется. Система остается хрупкой и подвержена сбоям. Теперь есть возможность отслеживать работу и сообщать о её состоянии. Как следствие, существует элементарное управление процессом — правильные вещи обрабатываются правильно. Но это не является гарантированным результатом. Ожидания клиентов не будут оправданы полностью и не будут удовлетворять основным критериям соответствия предназначению. В условиях стресса наблюдается тенденция к нарушению дисциплины и рабочие процессы будут неустойчивыми. Начнёт происходить откат до уровня зрелости 1.

Уровень зрелости 3: Управляемый

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

Уровень зрелости 4: Управляемый на основе количественных данных

На уровне зрелости 4 мы видим внедрение количественных методов управления рисками и их хеджирование. Мы не просто следим за процессом и выдаём целостный результат, теперь мы используем данные этого процесса, чтобы лучше понять его. Мы понимаем колебания в спросе, в предоставлении сервисов, качестве продукта/сервиса. Мы понимаем риски бизнеса, поставки и технических возможностей, которые влияют на результат. Мы понимаем, отслеживаем и управляем зависимостями в цепочке выполнения запросов на обслуживание. Мы применяем вероятностные прогнозы, математические формулы и методы регрессионного и итеративного математического моделирования, такие как GARCH и Метод Монте-Карло, чтобы обеспечить более глубокое понимание природы работы и способов управления для достижения целостных результатов и удовлетворённости клиентов.
В этот момент система устойчива к стрессам и бедствиям, потому что в основном предвидит проблемы. Когда происходит что-то непредвиденное, система продолжает демонстрировать устойчивость и восстановление до нормы. Восстановление часто происходит быстрее и негативное влияние неожиданного события или изменения внешних условий оказывает эффект слабее, чем мы видели на уровне 3. В условиях стресса организация остается стабильной. Процессы преследуют задачу, чтобы справиться со стрессовыми ситуациями и неожиданными событиями. Организация остается устойчивой и для клиентов сохраняется целостность результатов, если стресс не слишком серьёзный. В случае серьёзного стресса некоторая целостность результатов теряется, но организация становится устойчивой и быстро возвращается к нормальному уровню обслуживания и целостным результатам.

Уровень зрелости 5: Оптимизируемый

Уровень 5 — оптимизируемая организация. Уровень 5 может быть очень высок. Мы можем оптимизировать её разными способами: исключительно на уровне предоставления сервисов или мы можем расширить оптимизацию на уровне продукта, уровня обслуживания, стратегии рынка или уровня сегментации рынка, а возможно и на уровне всей бизнес-стратегии. На каждом уровне мы видими поведение, спроектированное для исследования сложных условий, осмысления изменяющихся условий и реагирования на них изменениями процессов, воркфлоу, сегментацией рынка и стратегического положения по мере необходимости. На этом уровне стресс активно стимулирует организацию улучшаться, мутировать и развиваться. На более высоких уровнях зрелости (выше 5-го) организация способна полностью изменить идентичность, отказаться от основного бизнеса и принять новую идентичность, перестроиться к новым бизнес-предприятиям. Организация является антихрупкой и можно сказать что она «постоянно соответствует предназначению».

Обучающиеся организации

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

Эффект J-кривой

Впервые я столкнулся с концепцией эффекта J-кривой, работая в Sprint около 15 лет назад и общаясь с руководителями со степенями бизнес-школ. Я знал концепцию во времена того, как Джерри Вайнберг адаптировал идеи Вирджинии Сатир об изменениях из семейной терапии и психологии, но я никогда не видел их эквивалентными. Ось Y на рисунке 2 показана как абстрактная концепция, но вы легко можете связать её с конкретной бизнес-метрикой. Ось Y на кривой Сатир метафорична и связана с поведением и личностью человека. В осязаемом, прагматичном, действенном, количественном мире Канбана мы не делаем метафор. Поэтому я не приписываю эту диаграмму Вайнбергу или Сатир.
На рисунке 2 ось Y показана как способность или соответствие предназначению, или как конкретная метрика соответствия предназначению, такая как время выполнения запроса. Текущая возможность или уровень соответствия показан как колеблющаяся кривая на графике. Этот уровень возможности достигается за счёт существующего процесса и этот процесс стабильный. Мы можем предположить по этому рисунку, что мы рассматриваем как минимум 2-й уровень организационной зрелости. Стабильность означает, что среднее значение стабильно и мы имеем некоторое естественное колебание в пределах известных границ. Либо это значит, что значение имеет тренд, но в стабильном виде, что означает, что показатель изменения является стабильным, и что мы по-прежнему имеем колебания в пределах известных границ. Это разумное утверждение для определённого рабочего процесса сервиса поставки и это подтверждается реальным набором данных в реальных компаниях. Возможности времени поставки или качества или срок исполнения или процент выполнения относительно SLA. Текущий уровень эффективности недостаточный и не соответствует целевому назначению, поэтому мы заинтересованы в улучшении. В традиционном управлении, инициируя изменения, мы проектируем новый процесс, направленный на достижение большего уровня возможностей — уровень который соответствует целевому назначению. Процесс может быть спроектирован или может быть адаптирован для набора процессов или определённых процессов. Если наш уровень зрелости повысился, уровень 4 или выше, мы вероятно имеем прогнозируемую модель результата для нового процесса. Иначе в меньшем уровне зрелости мы просто верим, что новый процесс принесёт результат, к которому мы стремимся. Мы можем даже рассмотреть установку нового процесса как эксперимент, но редко бывает так, что ты можешь «безопасно потерпеть неудачу», так как почти не бывает варианта откатить всё обратно к старому процессу, с учётом масштаба и величины изменений.
Как только мы начинаем инициировать изменения с коучинга или прохождения тренинга, а иногда с новыми инструментами, текущий уровень производительности падает пока сотрудники осваивают изменения. Мы можем оценить глубину падения как отрицательную дельту в производительности. Если дела пойдут хорошо, то мы начнём наблюдать улучшения. Постепенно мы наберёмся уверенности в том, что изменения сохранятся, затем мы вернёмся назад к нашему предыдущему уровню производительности, со временем мы можем достичь результатов и вернуть деньги за потерянный результат с нашим новым улучшенным уровнем производительности. Мы можем измерить время до каждого из этих событий с момента начала. Глубина и продолжительность возникшей просадки, вызванного инициативой изменений можно назвать болью изменений. В тоже время мы можем визуализировать это как область, мы должны также учитывать глубину и продолжительность как 2 различных параметра. Это падение в производительности и последующий подъём получил имя «эффект J-кривой»
Секрет управления изменениями в том, что терпение высшего менеджмента, который спонсирует все изменения, должно быть намного больше, чем ущерб от изменений. Если это не так или спонсоры не согласны с глубиной или временем восстановления, тогда они могут перестать доверять: паниковать, неверно направлять преобразования и увольнять агентов изменений, как «козла отпущения».
Есть поговорка: «никто никогда не был уволен при найме McKinsey». Его корни кроются в том, что компания McKinsey придумала этот стиль проектирования и управления инициативами изменений. Все хорошие консалтинговые компании знают, что их роль и вознаграждение базируются на факте, что они будут играть козла отпущения и возьмут на себя вину за неудачу. Каждый из конкурентов McKinsey прекрасно это знает. В ходе их учебного тренинга для новых кандидатов они учат, что их модель бизнеса заключается в том, чтобы «выполнить работу на 60% и не получить иск». Это значит, что клиент терпит до 60% выполнения работы, но если они не достигают точки доверия за это время, то тогда инициатива должна быть убита. Пока консалтинговой компании не нужно бороться с иском, её бизнес будет прибыльным.

Критерии успешного управления изменениями

Несмотря на очевидный успех крупных консалтинговых компаний, практикующих этот стиль управления изменениями, их показатели успеха низки. Как правило, около 30% терпят крах, прерываются или перезапускаются новыми инициативами. Джим Коллинс описал этот феномен в книге «How the Mighty Fall» («Как гибнут великие»), где они впадают в панику углубленной J-кривой, отменяют инициативы, неверно направляют реорганизацию, увольняют некоторых агентов изменений и начинают заново. Это ещё одно дополнительное доказательство того, что подобные изменения не могут «безопасно потерпеть неудачу» и не могут легко откатиться назад. Некоторые компании попадают из-за этого в смертельную спираль. Простыми словами они откусывают больше изменений, чем могут выдержать. Каждый раз они терпят неудачу, удваивая новые попытки, обычно во главе с другой консалтинговой компанией. Только порядка 10% такого рода больших инициатив изменений успешны и фактически оправдывают ожидания, остальные 60% — восстанавливаются обычно сверх уровня равных возможностей, но никогда фактически не оправдывают ожидания или не обеспечивают ожидаемого возврата инвестиций. Так почему степень этих неудач и трудностей так высока? Почему только около 10% кейсов успешны? Каковы критерии успеха?
Я вижу крупномасштабную работу по управлению изменениями. Здесь есть 5 элементов, которые последовательно появляются в историях:
  1. Высокий уровень терпимости руководства (терпеливое, внимательное, обоснованное и компетентное руководство)
  2. Высокая организационная зрелость (как правило, уровень 4 или выше)
  3. Долгосрочный капитал (обычно частные компании)
  4. Управляемое владение (лидеры с реальным погружением «с головой» как финансово, так и эмоционально)
  5. Менеджеры являются экспертами в области (обычно с 10-ти летним опытом бизнеса и глубоким пониманием того, как это работает)
Есть ли у вас эти критерии в вашей среде? Каковы шансы, что ваша организация увидит значительные инициативы изменений до завершения работы и оправдает ожидания? Если они все не так хороши, возможно вы хотели бы рассмотреть альтернативные эволюционные изменения?

Эволюционные изменения

Канбан Метод — это подход к изменениям, который предназначен для работы в организациях с низким уровнем зрелости и низким уровнем терпимости руководства. Это подход к изменениям с формулировкой «начните с того, что делаете сейчас». Зелёная линия на Рисунке 2 нарисована, чтобы показать начало J-кривой. Это представляет собой установку Канбан-системы. Идея применения самых изощрённых Канбан-систем разработана, чтобы вы могли избежать неприятностей без существенных сопротивлений изменениям. Это суждение преподают на мастер-классе Kanban Coaching Professional и любой КСР (Kanban Coaching Professional) может так рассуждать и уметь воплощать. Так называемые Прото Канбан-системы не переросшие в реализацию Канбан, где визуализируются функции и рабочие пространства, но без WIP-лимитов или вытягивающей системы представляют собой меньшую J-кривую с меньшим начальным влиянием. Смысл в том, чтобы инсталлировать эволюционный механизм, добавить эволюционную ДНК организации, после чего позволить этому работать. Ряд J-кривых представляют собой небольшие, эволюционные изменения или трансформацию процессов. Они известны в японском промышленном производстве как «Кайдзен». Культура Кайдзен — культура постоянной совершенствования. Это атрибут высокой организационной зрелости. В культуре изменений Кайдзен обычно экспериментируют, а эксперименты являются достаточно небольшими, чтобы «безопасно потерпеть неудачу». Изменения обычно можно вернуть назад, если они окажутся неудовлетворительными, произведут негативное влияние на возможности. Ряд эволюционных изменений обычно достигает больше за меньшее время, чем крупномасштабные трансформации и управления изменениями. У них гораздо больше шансов на успех в гораздо более широком спектре организаций.
]]> Оценка сервисов с помощью Fitness Box Score http://neogenda.ru/blog/ay7g62dp51-otsenka-servisov-s-pomoschyu-fitness-box http://neogenda.ru/blog/ay7g62dp51-otsenka-servisov-s-pomoschyu-fitness-box?amp=true Sun, 24 Mar 2024 08:39:00 +0300 Артур Нек Перевод статьи Дэвида Андерсона, размещённой на medium.com. Оригинал можно прочитать здесь. Когда вы используете эволюционный подход к улучшению...

Оценка сервисов с помощью Fitness Box Score

Перевод статьи Дэвида Андерсона, размещённой на medium.com.
Оригинал можно прочитать здесь.
Когда вы используете эволюционный подход к улучшению вашего продукта, сервиса или поставке сервиса, с помощью Lean-стартапа, Канбана и ESP, вам нужен метод, позволяющий оценить, действительно ли изменение дизайна обеспечивает улучшение. Соответствие продукта или сервиса предназначению и вероятность его выживания и процветания всегда видны глазами потребителя. Вам всегда решать, идти ли ва-банк, улучшать сервис или нужен пивот? А в какую сторону менять направление? Опросы Fit For Purpose и Fitness Box Scores призваны предоставить эту информацию и помочь принять важные решения о том, что предлагать и насколько хорошо это делать.
Традиционные подходы к исследованию рынка и опросам удовлетворённости потребителей не очень хорошо подходят для эволюционных подходов к рынку как к экосистеме. Важно, чтобы опрос не подвергал сомнению, как и почему потребитель использует продукт или сервис. Вместо этого лучше использовать опрос, чтобы понять их цель, потребности и ожидания.
Ещё в январе я опубликовал наше первое мнение о замене оценки Net Promoter Score для оценки предоставления сервисов на использование нашего нового метода опроса — Fit For Purpose (Соответствие предназначению).
С момента этой первоначальной публикации мы и другие участники сообщества экспериментировали с этой техникой. Во время нашей летней серии семинаров Kanban Leadership Retreat мы пересмотрели наши результаты и пересмотрели метод. Этот пост представляет собой официальную публикацию версии 2.0 опроса Fit For Purpose и нового метода отчётности Fitness Box Score.

Мотивация

Для начала, хотим напомнить о мотивации, лежащей в основе оценки Fit For Purpose, и о том, почему мы почувствовали необходимость внедрить новый метод оценки удовлетворённости клиентов:
Fit For Purpose был создан по двум причинам. Во-первых, необходимо было оценить, действительно ли продукт или сервис, которые разрабатываются и совершенствуются эволюционным и экспериментальным способом, улучшаются в глазах потребителя. Вторая, и не несвязанная с этим мотивация, проистекала из неудовлетворённости клиентов использованием показателя Net Promoter Score (NPS), который часто описывался как отсутствие действенного руководства. Net Promoter Score показывает бизнесу, стали ли его товары или сервисы более популярными или нет, но часто не даёт никакого представления о том, что можно сделать для улучшения ситуации. Мы также хотели связать результаты опросов клиентов напрямую с практическими показателями или Ключевыми показателями эффективности (KPI). Например, если клиенты оценивают время доставки, а их порог допуска составляет 2 дня, для них KPI для сервиса должно быть время выполнения с ожидаемым уровнем обслуживания (Service Level Expectation, SLE) в 2 дня. Когда показатели выражаются таким образом и напрямую связаны с ожиданиями клиентов, мы называем их метриками соответствия (Fitness Criteria Metrics), а уровень приемлемой производительности — Fitness Criteria Threshold Level (Пороговый уровень метрик соответствия) или просто «пороговое значение» (threshold value) для краткости. Между тем, мы хотели бы предоставить единственное число в качестве исполнительного отчёта, которое показывает, насколько тот или иной продукт или сервис «соответствует предназначению» и как воспринимается потребителями.

Опрос Fit For Purpose

Вопрос 1. Расскажите, почему вы выбрали наш [продукт или сервис]? Выберите до 3 причин или целей, которые у вас были при выборе нашего [продукта или сервиса].
(а) ________________________________________
(b) ________________________________________
(c) ________________________________________
Вопрос 2. По каждой причине/цели из Вопроса 1, пожалуйста, укажите, насколько наш [продукт или сервис] соответствовал предназначению и вашим ожиданиям. Оцените каждую причину или цель отдельно по следующей шкале:
5. Превзошёл ожидания
4. Мои ожидания полностью оправдались.
3. Мои ожидания в основном оправдались, но остались некоторые незначительные сомнения.
2. Некоторые существенные потребности остались без внимания.
1. Я получил некоторую выгоду, но большинство моих ожиданий не оправдались.
0. Ничего полезного не нашёл. Это не соответствовало предназначению.
Оценка (а) _______ (b) _______ (c) ________
Вопрос 3. Расскажите, почему вы поставили такую оценку (-и) в Вопросе 2:
(а) ________________________________________
(b) ________________________________________
(c) ________________________________________

Что мы узнали из использования опросов Fit For Purpose

Во-первых, мы узнали, что люди часто потребляют продукты или сервисы с несколькими целями или задачами. В настоящее время опрос был изменён, чтобы учесть это. Мы считаем, что достаточно указать до трёх причин, и это не будет избыточным. Ранее, когда мы использовали бумажные формы, мы обнаружили, что респонденты изменяли форму, чтобы описывать несколько целей. Учитывая относительно небольшую выборку опросов, собранных нами за последние 3 месяца, мы считаем, что оптимальным будет именно описание до трёх целей.
Во-вторых, мы обнаружили, что мы хотели бы отказаться от использования Net Fitness Score, т.к. этот способ скрывает жизненно важную информацию, необходимую для принятия мер. Net Fitness Score был заменён оценкой Fitness Box Score [см. Ниже].
В-третьих, мы обнаружили, что результаты опросов дают практические рекомендации. Они также предоставляли ценную информацию о том, почему люди потребляют продукты или сервисы, и это позволило улучшить сегментацию рынка, а маркетинговые сообщения сделать более целенаправленными. Мы обнаружили, что даже вручную можно сгруппировать ответы на Вопрос 1, чтобы указать цели, и сгруппировать ответы на Вопрос 3, чтобы получить полезную информацию. Мы также можем соотнести ответы на Вопрос 2 с заявленными целями, чтобы лучше понять поведение потребителей и то, что мы хотим усилить или ослабить с помощью нашего маркетинга.
В-четвёртых, для вычисления общей оценки мы в настоящее время берём лучший результат, указанный человеком. Мы рассматриваем возможность экспериментов с явным запросом общей оценки отдельно от конкретных причин, целей или задач. Мы также обнаружили, что люди не всегда откровенно объясняют свои причины. Некоторые цели могут быть неудобными, и люди не хотят их признавать. Например, люди, посещающие наши конференции, у которых на самом деле просто оплачиваемый отпуск за счёт своего работодателя, и которым неудобно в этом признаваться.
Наконец, хочу предостеречь, что этот подход всё ещё зарождается и развивается по мере того, как мы учимся и используем его. Недавний опрос, проведенный в Испании после учебного занятия, не дал результата лучше 3 с несколько философским ответом, что «никакая цель никогда не может быть по-настоящему и полностью достигнута». Являются ли эти испанские философы исключением и аномалией, ещё предстоит выяснить.
Кроме того, мы разработали этот опрос для использования с сервисами. Пока не ясно, как это будет происходить с физическими продуктами, такими как газонокосилки или зубные щётки. Несомненно, мы продолжим учиться на опыте использования опроса Fit For Purpose и мы ожидаем некоторых дальнейших усовершенствований в методе.

Fitness Box Score

Fitness Box Score заменяет Net Fitness Score. Оценки 4 или 5 считаются «соответствием предназначению». Оценка 3 считается «нейтральной», потому что потребитель, скорее всего, будет доволен тем, что сможет повторно обратиться к нам или рекомендовать нас, он определённо не будет плохо отзываться о нашем продукте или сервисе. Но это предлагает нам потенциальные способы улучшения наших продуктов или сервисов, если мы можем адекватно зафиксировать ответы потребителей на Вопрос 3. Оценка 2 или ниже считается «несоответствием предназначению».
Ранее Net Fitness Score была смоделирована на основе Net Promoter Score (индекс потребительской лояльности), где итоговая оценка — это процент ответов, указывающих на соответствие предназначению, минус процент, указывающий на несоответствие предназначению. Однако эти оценки скрывают ценную информацию. Чтобы проиллюстрировать это, рассмотрим вырожденный случай, когда 50% указывают на соответствие предназначению, а другие 50% указывают на несоответствие. Итоговая оценка = 0%. Это тот же результат, что и 100% нейтральных оценок 3 из 5. Но это не эквиваленты! 100% голосов за оценку 3 указывает на то, что наш продукт посредственный, но его можно улучшить. В то время как соотношение соответствия-несоответствия 50 на 50 указывает на то, что нам нужно лучше сегментировать рынок, а наш продукт уже вполне подходит для некоторых рыночных ниш. Один результат говорит нам, что мы должны улучшать продукт или предоставление сервиса, а другой говорит нам, что мы должны улучшить наш маркетинг. Поскольку это очень разные результаты, мы считаем, что net scores вводят в заблуждение. Показатели, предназначенные для использования руководителями, становятся опасными, когда они предоставляют вводящую в заблуждение информацию и неопределённые рекомендации. Таким образом, Net Fitness Score больше не используется, и его заменяет Fitness Box Score — система, вдохновлённая историческими подходами к освещению бейсбольных матчей.
Fitness Box Score записывается так…
[% Соответствие: % Нейтрально: % Несоответствие] (# ответы / генеральная совокупность выборки)
Например, общий балл Fitness Box Score для семинара по Канбан-лидерству в Азиатско-Тихоокеанском регионе на Бали (Индонезия), в июне…
[60:30:10] (18/20)
Было 20 платных участников. Из них 18 ответили на опрос — 2 человека покинули мероприятие раньше. Из 18 ответивших, 60% сочли мероприятие «соответствующим предназначению», 30% были нейтральными, но в основном удовлетворены, в то время как 10% пришли не на то мероприятие и были не довольны, для них мероприятие «не соответствовало предназначению».
В настоящее время мы рекомендуем округлять оценки до ближайших 5%, хотя в некоторых случаях это даёт возможность получать значения до 105%.
При детализации для конкретных целей мы сообщаем о генеральной совокупности выборки как о тех, кто действительно ответил на опрос. Вот полный набор аналитических материалов для Kanban Leadership Retreat на Бали…
Цель и оценка
Нетворкинг [85:15:0] (13/18)
Изучение Канбан [45:45:15] (7/18)
Обмен знаниями [50: 50:0] (6/18)
Обратная связь и валидация [75:25:0] (4/18)
Опыт Kanban Leadership Retreat [100:0:0] (2/18)
Канбан-маркетинг и стратегия продаж [0:50:50] (2/18)
Знакомство с Дэвид Дж. Андерсоном [50:50:0] (2/18)
Улучшение поставки проекта [0:0:100] (2/18)
Из этих результатов мы видим, что большинство участников приходят на Kanban Leadership Retreat по причинам, на которые мы надеемся, — нетворкинг, обмен знаниями, обратная связь и валидация. Это наше первое мероприятие в Азиатско—Тихоокеанском регионе, мы также привлекли людей, которым было бы лучше на более общей конференции Lean Kanban, про изучение Канбан и улучшение поставки проекта.
С помощью этого конкретного опроса мы узнали, как мы можем улучшить наше маркетинговое сообщение, и мы узнали, что нам следует рассмотреть возможность проведения конференции Lean Kanban в Юго-Восточной Азии, ориентированной на общую аудиторию Азиатско-Тихоокеанского региона.

Выводы

Опросы Fit for Purpose бывают весьма полезными. В целом, мы считаем, что высокий показатель «соответствия предназначению» будет коррелировать и являться ведущим показателем продукта или сервиса, которые будут процветать и выживать. В настоящее время мы будем продолжать использовать его в сочетании с другими методами опроса удовлетворённости клиентов. Например, в опросе Fit For Purpose прямо не задаётся вопрос «Понравилось ли вам место проведения конференции?» или «Понравился ли кейтеринг и сервис в месте проведения?». Но, если бы они были неудовлетворительными, мы ожидали бы, что они появятся в ответах на Вопрос 3. Однако бывают моменты, когда вы действительно хотите задать чёткие вопросы и получить конкретные ответы.
Как и во всех опросах клиентов, большой недостаток такого метода заключается в том, что он не опрашивает тех, кто не выбирал ваш продукт или сервис. У нас нет результатов опроса для тех, кто не выбрал тренинг по Канбан или конференцию по Lean Kanban Таким образом, мы не можем сказать, действительно ли наш маркетинг «соответствует предназначению» или он отпугивает потенциальных клиентов и посылает неправильные сигналы.
Таким образом, опрос Fit for Purpose — это не лекарство от всех болезней, но это полезный новый маркетинговый инструмент, хорошо совместимый с эволюционными подходами к улучшению продуктов или сервисов, такими как Lean- стартап, Канбан и ESP. Мы считаем, что анализ, проведённый в ходе этих опросов, значительно улучшит процесс принятия решений о том, когда следует придерживаться существующей концепции или бизнес-модели, а успех пивота будет значительно улучшен благодаря пониманию целей клиентов и вытекающей из этого сегментации рынка.
Книга, Fit For Purpose — How modern businesses find, satisfy & keep customers («Соответствие предназначению — Как современные компании находят, удовлетворяют и удерживают клиентов»), теперь доступна на Amazon и в других интернет-магазинах.
]]> Scrumsplaining #2: В Канбане нет ощущения срочности http://neogenda.ru/blog/1v8ogiji01-scrumsplaining-2-v-kanbane-net-oschusche http://neogenda.ru/blog/1v8ogiji01-scrumsplaining-2-v-kanbane-net-oschusche?amp=true Mon, 25 Mar 2024 09:23:00 +0300 Алексей Пименов Перевод статьи Дэвида Андерсона, размещённой на kanban.university Оригинал можно прочитать здесь. Перевод: Алексей Пименов Первую часть статьи читайте здесь....

Scrumsplaining #2: В Канбане нет ощущения срочности

Перевод статьи Дэвида Андерсона, размещённой на kanban.university
Оригинал можно прочитать здесь.
Первую часть статьи читайте здесь.
«Scrumsplaining» — это феномен, когда Скрам-практик пытается объяснить, что у вас нет никакой альтернативы Скраму, даже не пытаясь понять другие подходы, наличие другой точки зрения или парадигмы. В «scrumsplaining» всё объясняется с использованием Скрам-парадигмы.
Scrumsplainers — это, как правило, люди, которые уже давно используют Скрам, но производительность их команд упала, дальнейшие улучшения давно не происходят, и они ищут что-то новое и свежее, чтобы перезагрузить инновационное мышление и активировать дальнейшие улучшения. Зачастую Scrumsplainers являются консультантами, которые боятся потерять свой статус и авторитет в глазах клиентов и специалистов, которые боятся, что им рекомендуют использовать что-то, что разрушит их любимый Скрам-процесс.
Это второй пост из серии, где мы рассматриваем аргументы о необходимости механизма «давления равных», на котором базируется ощущение срочности работ в Скрам и мотивации довести дело до конца.

Scrumsplaining #2: Если мы начнём использовать Канбан, мы потеряем ощущение срочности

[Следующий диалог происходил с вице-президентом бизнес-подразделения крупного производителя интернет и телекоммуникационного оборудования. Нам дали возможность анонимной публикации этого диалога через 12+ месяцев. Компания американская. Бизнес-подразделение базируется в Новой Англии. Scrumsplainer отвечал за 600 человек бизнес-подразделения, частично укомплектованных в Индии.]
Без ежедневных Скрам-митингов и регулярного взятия на себя обязательств на Планировании Спринта мы потеряем ощущение срочности!
Ок. Почему ты так думаешь?
Нам необходимо, чтобы люди давали друг другу обязательство в выполнении какой-то части работы ежедневно, иначе они просто расслабятся и начнут играть в пинг-понг.
Ок. А почему?
Ну они по своей природе ленивы. Нам необходимо держать их под давлением обязательств иначе они ничего не сделают.
Вы действительно в это верите?
Да. Нашим ребятам слишком комфортно!
Сколько народу в вашем бизнес-подразделении?
Около 600!
Сколько из них новых, кто пришёл в компанию после вас?
Около 300!
Т.е. вы наняли 300 лентяев с тех пор как возглавили бизнес-подразделение? Вы специально отбирали ленивых людей на собеседованиях?
Нет, нет. Конечно нет.
Т.е. они стали ленивыми с тех пор как вы их наняли?
Нуууу…, они чувствуют себя очень комфортно. Никакого ощущения срочности.
Каждая Скрам-команда в вашем бизнес-подразделении не выполнила свои обязательства по последнему спринту. Каждая Скрам-команда в этом здании не выполняла свои обязательства по спринту за последние 22 спринта. В среднем они в 50% случаев нарушают свои обязательства по спринту. На сегодняшней ретроспективе ни один Скрам-Мастер не сказал об этом. Никто не хочет отвечать за нарушенные обязательства.
Точно! Никакого ощущения срочности!
Получается, что вы сейчас используете Скрам, но у вас все равно нет никакого ощущения срочности. Так скажите же мне ещё раз, почему вы потеряете ощущение срочности если будете использовать Канбан?
Нашим людям слишком комфортно и нам необходимо держать их под давлением обязательств.
Вы верите в Теорию Х Дугласа МакГрегора и то, что люди должны быть внешне мотивированы?
Нет. Я верю в Теорию Y. Людьми движет внутренняя мотивация.
И всё же вам необходимо держать их под давлением ежедневных и двухнедельных обязательств, чтобы они не расслабились? Где там внутренняя мотивация?
…
Вы действительно считаете, что сотни ваших людей ленивы по своей природе?
Нашим людям слишком комфортно и нам необходимо держать их под давлением обязательств.
Вы не думали, что отсутствие у ваших людей внутренней мотивации и ощущения срочности — это проблема лидерства?
В Канбане используют (как правило) ежедневное статусное собрание у доски. Это не Scrum-митинг. На Канбан-митинге вы проходите по запросам справа налево: от ближайшего к завершению до самого последнего начатого. Основное внимание уделяется потоку работ, а не управлению людьми или командами, заставляя их выполнять задачи.
Канбан не имеет механизма планирования порций работы, как спринт в Скраме. Вместо этого запросы втягиваются в работу индивидуально, и поставка измеряется в зависимости от ожидаемого уровня обслуживания или договоренности о времени выполнения.
Таким образом, элементы Скрама, которые предназначены для создания чувства срочности с помощью давления равных, действительно отсутствуют.
Канбан просто использует другую парадигму. Канбан сервис-ориентирован и моделирует рабочие процессы предоставления услуг от запроса до поставки ценности. Канбан делает запрос клиента/заказчика о решении бизнес-потребности или устранения бизнес-риска видимыми и прозрачными в течение всего рабочего процесса. Сотрудники, обслуживающие Канбан-систему, знают, для кого эта работа и почему они её выполняют. Они знают, какие бизнес-риски связаны с запросом, и понимают, почему ему предоставляется определённый класс обслуживания.
Здесь нет чувства срочности, есть чувство оказания ценной услуги. Существует коллективная гордость за качество предоставляемой услуги. Чувство гордости за качество предоставляемой услуги создает срочность, где и когда это уместно. Прозрачность и видимость, совместная работа и чувство гордости — вот что заставляет Канбан работать. Канбан основан на предположении, что работники умственного труда действительно соответствуют Теории Y: Они по своей сути мотивированы.
Чтобы Канбан работал, должно быть лидерство. Это лидерство должно ценить обслуживание клиентов и прививать чувство коллективной гордости за хорошее обслуживание клиентов. Когда вы слышите, как спорщик, утверждая, что Канбану не хватает срочности, вы на самом деле слушаете неверное утверждение. Scrumsplainer’у не хватает смелости и он не может проявить лидерство!
]]> WSJF: «Более важная и короткая работа в первую очередь» http://neogenda.ru/blog/9s1uzcpbl1-wsjf-bolee-vazhnaya-i-korotkaya-rabota-v http://neogenda.ru/blog/9s1uzcpbl1-wsjf-bolee-vazhnaya-i-korotkaya-rabota-v?amp=true Tue, 26 Mar 2024 09:28:00 +0300 Артур Нек Перевод статьи, размещённой на blackswanfarming.com. Оригинал можно прочитать здесь. Что такое WSJF? «Более важная и короткая работа...

WSJF: «Более важная и короткая работа в первую очередь»

Перевод статьи, размещённой на blackswanfarming.com.
Оригинал можно прочитать здесь.

Что такое WSJF?

«Более важная и короткая работа в первую очередь» (Weighted Shortest Job First) — это алгоритм планирования (или, если вы предпочитаете, метод расстановки приоритетов), который максимизирует количество того, что вы выбираете для «взвешивания» за определённый период времени с помощью ограниченного ресурса.

Откуда пришёл этот алгоритм?

Ещё в 1970-х годах, когда вычислительные ресурсы были чрезвычайно дорогими и сильно ограниченными, Кратчайшее оставшееся время (Shortest Job First) использовалось как способ планирования пакетных заданий так, чтобы максимально использовать ограниченный ресурс. Совсем недавно Дон Рейнертсен предложил и популяризировал принцип «Более важная и короткая работа в первую очередь» как способ максимизировать отдачу от инвестиций в команды разработчиков ПО.
Для WSJF требуются только два ингредиента: вес каждой работы и продолжительность каждой работы. Весом, который Дон специально рекомендует для разработки продукта, является Стоимость задержки (вот 3-х минутное видео, в котором объясняется Стоимость задержки). Другая часть, продолжительность означает насколько «коротка» каждая работа. Нам нужно знать: «Как долго эта работа будет блокировать пайплайн?» Для этого нам нужен некоторый прогноз продолжительности выполнения этой работы. Это важно, потому что пока он находится в процессе, он блокирует запуск другой работы. В течение этого времени мы платим Стоимость задержки. Дон конкретно предлагает особую форму WSJF: Стоимость задержки, делённая на Продолжительность.
Существуют и другие возможные формы WSJF — в зависимости от того, что вы пытаетесь оптимизировать. Вы можете выбрать взвешивание по техническому риску, рыночному риску, влиянию заинтересованных сторон, продолжительности ожидания или любому другому фактору или комбинации, которые вы, возможно, захотите максимизировать. Однако большинство организаций больше всего заинтересованы в увеличении своей экономической отдачи. В этом случае вам следует взвешивать стоимость задержки.

CD3: Стоимость задержки, деленная на Продолжительность

Говорить «Более важная и короткая работа в первую очередь» или, более конкретно, «Стоимость задержки, деленная на продолжительность утомляет. Для облегчения мы можем сократить это до CD3 — по крайней мере, для случая, когда мы взвешиваем Стоимость задержки. У этой формулировки есть преимущество, что она сообщает о более важном компоненте алгоритма: стоимости задержки.
При использовании CD3 порядок приоритета функций или проектов определяется путем деления расчётной стоимости задержки на расчётную продолжительность: чем выше итоговая оценка, тем выше приоритет.
Одним из преимуществ версии WSJF для CD3 является то, что она позволяет нам использовать общую меру для сравнения возможностей с разной ценностью и срочностью, а также учитывать ситуацию, когда продолжительность различается. CD3 оптимизирует окупаемость инвестиций за счёт минимизации общих затрат на задержку с учётом набора возможных вариантов. В большинстве случаев разработки продукта ёмкость относительно негибкая и её трудно масштабировать. Это означает, что понимание того, как долго заблокирован пайплайн, часто является весьма ценной информацией.
Поскольку CD3 использует в знаменателе длительность, то он имеет преимущество — он способствует разбивке работы на более мелкие партии. Разбивка работы — одно из самых простых и эффективных улучшений, которые мы можем сделать с точки зрения получения большей ценности, более быстрого выполнения и лучшего качества.

WSJF: Стоимость задержки, деленная на Продолжительность

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

Использование метода «Первым пришёл — первым ушёл» (First-in, First-out, FIFO)

Мы могли бы работать над этими функциями и предоставлять их по очереди в том порядке, в котором они поступили. A, затем B, затем C. Это называется «Первым пришёл — первым ушёл» (FIFO). Это распространённый подход к планированию в производстве. В конце концов, человек, запрашивающий функцию А, будет ждать дольше всех, поэтому для нас может иметь смысл сначала обслужить его. Затем мы перейдем к B, а затем C.
В течение 5 недель, когда мы работаем над функцией А, мы несём расходы на задержку всех трёх функций: $ 5000 в неделю + $ 4000 в неделю + $ 1000 в неделю. Это добавляет до $ 10 000 в неделю в течение 5 недель, что даёт нам затраты на задержку в размере $ 50 000.
Как только мы доставим функцию A, мы сможем перейти к разработке функции B. В течение 1 недели, которая потребуется нам для поставки, мы нёсем Расходы на задержку функций B и C: $ 4000 в неделю + $ 5000 в неделю = $ 9000 в неделю в течение 1 недели, т. е. дополнительные $ 9000, в результате чего общая сумма понесённых затрат на задержку составляет $ 59 000.
Наконец, мы можем начать работу над функцией C, понеся Расходы на задержку C во время её разработки в размере $ 5000 в неделю в течение 2 недель, необходимых для создания функции C. Таким образом, еще $ 10 000. Затраты на задержку должны быть добавлены к нашим предыдущим $ 59 000 в общей сложности $ 69 000 понесённых затрат на задержку.

Использование WSJ: Стоимость задержки, деленная на Продолжительность (CD3)

Давайте рассмотрим другой способ обработки этих функций. Если мы разработаем функции на основе того, у кого самый высокий балл CD3, мы сначала сделаем функцию B, затем функцию C и, наконец, функцию A.
В течение 1 недели, пока мы работаем над функцией B, мы несём расходы на задержку в размере ($ 4000 + $ 5000 + $ 1,000)/неделя. Стоимость задержки после 1 недели = $ 10 000.
В течение следующих 2 недель мы работаем над функцией C, мы несём расходы на задержку в размере ($ 5000 + $ 1000)/неделя. Стоимость задержки = $ 12 000.
В течение 5 недель, над которыми мы работаем над функцией А, мы несём расходы на задержку в размере $ 1000 в неделю. Стоимость задержки = $ 5000.
Общая стоимость задержки при использовании CD3 = $ 27 000

Сравнение

Использование FIFO привело к общей стоимости задержки в размере $ 69 000. Использование CD3 дало нам общую стоимость задержки в размере $ 27 000, т. е. на 61% меньше понесённых затрат на задержку. Как вы можете видеть, использование CD3-версии «Более важной и короткой работы в первую очередь» для упорядочения вашего бэклога может иметь довольно большое значение.
Однако, это простое сравнение не показывает влияние человеческого фактора, т. е. желания выполнять более мелкие задачи в первую очередь. А также не показывает влияние этого предпочтения на поток и сроки выполнения.
Как мы показали в нашем отчёте: использование CD3 также способствует разбивке пакетов, как способу влияния на приоритет. Это означает, что вместо того, чтобы вознаграждать более крупные партии, которые часто требуют более высоких выплат, мы призываем людей минимизировать размер того, что они просят. Это даёт огромные преимущества в ряде областей, не в последнюю очередь из-за значительно более быстрого выполнения заказов, а также повышения производительности, благодаря уменьшению вариабельности обрабатываемых рабочих элементов.

SAFe (Scaled Agile Framework), WSJF и Стоимость задержки

Большим преимуществом WSJF является то, что масштабированный гибкий фреймворк Дина Леффингвелла (SAFe) рекомендует использовать его для определения приоритетов. SAFe также подчёркивает, что WSJF следует применять на уровне функций, что также соответствует нашему опыту использования Стоимости задержки. Одна из самых разрушительных концепций, когда-либо существовавших в организациях, заключается в том, что крупносерийные проекты являются «локомотивом» разработки ПО. SAFe следует похвалить за поощрение организаций к дальнейшему развитию в обеих этих областях.
Нынешнее обучение WSJF в SAFe оставляет много возможностей для улучшения — в частности, как они относятся к стоимости задержки. В своей попытке упростить стоимость задержки, SAFe, возможно, непреднамеренно усложнила её и сделала бесполезной для большей части стоимости, которую может принести Стоимость задержки. Вот мои мысли о том, как SAFe интерпретирует стоимость задержки.
Моя главная просьба состояла бы в том, чтобы убедиться, что вы не сводите стоимость задержки к простому лучшему способу определения приоритетов — это гораздо больше!
]]> Scrumsplaining #1: Канбан — это Скрам без спринтов http://neogenda.ru/blog/4gg9fxc4u1-scrumsplaining-1-kanban-eto-skram-bez-sp http://neogenda.ru/blog/4gg9fxc4u1-scrumsplaining-1-kanban-eto-skram-bez-sp?amp=true Wed, 27 Mar 2024 09:32:00 +0300 Алексей Пименов Перевод статьи Дэвида Андерсона, размещённой на djaa.com. Оригинал можно прочитать здесь. Перевод: Алексей Пименов «Scrumsplaining» — это феномен, когда...

Scrumsplaining #1: Канбан — это Скрам без спринтов

Перевод статьи Дэвида Андерсона, размещённой на djaa.com.

Оригинал можно прочитать здесь.
«Scrumsplaining» — это феномен, когда Скрам-практик пытается объяснить, что у вас нет никакой альтернативы Скраму, даже не пытаясь понять другие подходы, наличие другой точки зрения или парадигмы. В «scrumsplaining» всё объясняется с использованием Скрам-парадигмы.
Scrumsplainers — это, как правило, люди, которые уже давно используют Скрам, но производительность их команд упала, дальнейшие улучшения давно не происходят, и они ищут что-то новое и свежее, чтобы перезагрузить инновационное мышление и активировать дальнейшие улучшения. Зачастую Scrumsplainers являются консультантами, которые боятся потерять свой статус и авторитет в глазах клиентов и специалистов, которые боятся, что им рекомендуют использовать что-то, что разрушит их любимый Скрам-процесс.
Это первый из серии блогпостов о Scrumsplaining.

Канбан — это Скрам без спринтов

Если вы уже работаете по Скраму, и отмените практику спринтов, то у вас вся работа будет одним нескончаемым спринтом, а значит вы начнёте практиковать Канбан.
Учитывая то, что отменять спринты плохо. Мы получим, что люди будут уставать от работы, т.к. они будут работать непрерывно все время. У них не будет времени для передышки. При работе спринтами у вас есть время для отдыха, когда один спринт заканчивается, а другой начинается. Ну и у вас не будет ритмичных точек в которые можно провести ретроспективу, а значит, что ваш производственный процесс не будет улучшаться.
Хммм. Понимаю. Итак, вам нужны спринты, чтобы люди отдыхали?
Да!
Вы серьёзно? Почему бы вам просто не останавливаться для того чтобы отдохнуть?
Люди забывают это делать. Без спринтов темп не будет устойчивым.
Понял. А что будет, если возникнет что-то очень большое, что невозможно сделать за спринт?
Ну, мы разобьем это на несколько частей. 2 или более.
Итак, вы начинаете работать над чем-то, и прежде чем закончить вы останавливаетесь в конце спринта чтобы немного отдохнуть?
Да.
А не лучше ли будет остановиться для отдыха, когда вы сделали что-то важное, но ещё не начали другую работу?
Нет. Лучше останавливаться на регулярной основе с жёстким ритмом.
Это не выглядит разрушительно? Разве нет издержек, чтобы потом вернуться к незаконченной работе?
Ну да, но это всё равно лучше, чем не останавливаться и постоянно усиленно работать.
Хммм. Скажи мне ещё раз, почему вы просто не останавливаетесь для отдыха, когда вам это нужно?
Это плохая идея.
Разве Канбан не предлагает ограничить незавершенную работу, чтобы держать устойчивый ритм?
Но многие запросы могут быть большими, и их решение потребует много времени, это не будет устойчивым.
Хммм. Разве Канбан не является эволюционным методом проведения изменений? Разве вы не должны улучшать свой способ работы? Почему бы вам просто не проводить регулярно ретроспективы, но не использовать спринты?
Это выглядит странно. Зачем так делать? Это не эффективно проводить ретроспективу без обзора сделанной работы или без собраний по планированию.
Канбан — это не Скрам без спринтов. Канбан появился из другой парадигмы и другой философии. Канбан использует парадигму ограничения незавершенной работы и концепцию систем, описывающих сервисы с ограниченной емкостью. Новая работа втягивается в систему, когда есть возможность. Ограничение незавершенной работы создаёт стресс, который стимулирует улучшение прохождения потока работ через систему, уменьшения время выполнения работ и увеличение предсказуемости. Ожидания Уровня Обслуживания (SLE) или Соглашения об Уровне Обслуживания (SLA) используются и сравниваются с Возможностями по Обслуживания (SLC) на регулярно планируемых ретроспективах, называемых Обзорами Сервиса.
Канбан использует сервис-ориентированный и эволюционный подход к проведению изменений. Вы начинаете с того, что делаете сейчас, и разрабатываете Канбан-систему, чтобы обернуть ею ваш рабочий процесс. Канбан адаптируется к вашему существующему контексту и помогает вам улучшаться. Канбан не является декларирующим, а является адаптивным и разработан для применения в вашем контексте. Вы ограничиваете незавершенную работы и втягиваете работу в вашу систему, когда есть свободное место, поскольку какая-то другая работа была завершена. Канбан-системы покрывают всю цепочку создания ценности, перекрывающую работу множества команд. Бывают Канбан-системы задействующие в работе до 100 человек, но более типично от 20 до 30. Прогнозирование завершения работы осуществляется с использованием вероятностного подхода и выработке Соглашений/Ожиданий об Уровне Обслуживания. Во всех отношениях это отличается от Скрам.
Скрам ожидает, что вы измените свой контекст, чтобы Скрам, как декларативный и предопределенный процесс, смог появиться и начать работать. Скрам ожидает, что вы внесете грандиозные революционные изменения в свою организацию, рабочий процесс, планирование и взаимодействие с клиентами. Скрам использует ежедневные и ежеспринтовые (обычно две недели) циклы принятия обязательств в качестве катализатора для улучшений. Скрам разбивает время на периоды, называемые Спринтами, он явно не ограничивает количество незавершенной работы и не использует вытягивание, когда есть ёмкость. Скрам использует пакетную передачу на каждом Спринте. Скрам использует детерминистическое планирование и конкретные детерминистические обязательства. Он не использует вероятностное планирование. Скрам предназначен для работы на командном уровне, где в команде по факту могут быть от 3 до 12 человек, чаще всего порядка 6 (как и пропагандируется).
Хотя механику Канбан-системы можно было бы в общих чертах описать как «Скрам без спринтов», а один из популярных трекеров задач, адаптированный для Скрам (Rally), вообще реализует Канбан-активность, как огромный непрерывный Спринт. Ошибочно описывать Канбан как «Скрам без спринтов», это мешает людям увидеть применимость, преимущества и возможности Канбана.
Когда вы смотрите на Канбан через призму Скрам-парадигмы, вы получаете «Scrumsplaining!».
]]> Модель Agile Fluency и Организационная зрелость http://neogenda.ru/blog/p9vdsv97a1-model-agile-fluency-i-organizatsionnaya http://neogenda.ru/blog/p9vdsv97a1-model-agile-fluency-i-organizatsionnaya?amp=true Thu, 28 Mar 2024 09:35:00 +0300 Артур Нек Перевод статьи David J Anderson, размещённой на djaa.com. Оригинал можно прочитать здесь. Однажды клиент попросил меня представить карту...

Модель Agile Fluency и Организационная зрелость

Перевод статьи David J Anderson, размещённой на djaa.com.
Оригинал можно прочитать здесь.
Однажды клиент попросил меня представить карту совместимости моей модели организационной зрелости и паттернов зрелости Канбан с моделью Agile Fluency™ Джима Шора и Дайаны Ларсен, усиленной при поддержке Мартина Фаулера. Запрос клиента был основан на простой потребности: его организация уже в некоторой степени была знакома с моделью Agile Fluency и, следовательно, он хотел, чтобы я мог объяснить его людям, как моя модель отображается в контексте, который они уже понимают. Я решил, что будет полезно поделиться своими мыслями по этому поводу с более широким кругом читателей.

Вступление

Если вы не знакомы с моделью Agile Fluency, то вы можете прочитать базовую статью здесь. Я знаю Джима Шора и Дайану Ларсен около десяти лет. Время от времени я встречаюсь с ними на конференциях. Самая последняя наша встреча была в Мальмё на Øredev в ноябре прошлого года, где я произносил вступительное слово на тему социальной инженерии.
Джим и я испытываем взаимное уважение, признавая, что у нас очень разные подходы к повышению гибкости. Как говорит Джим, он практикует «кайкаку» (большое управляемое изменение), а не эволюционное «кайдзен». Джим работает только с клиентами, желающими заменить существующую систему разработки программного обеспечения его Agile-методом. Поэтому мы находимся на двух разных концах спектра. Также Джим склонен работать в небольшом масштабе: в командах от 2 до 12 человек и в небольших отделах. Я же работал с клиентами, пытающимися выполнить планирование сервисов уровня предприятия (ESP) c намерением увеличить число сотрудников до 100 000 человек. Выявив различия, теперь можно составить некоторое представление о том, как можно сопоставить Agile Fluency с паттернами Канбан и организационной зрелостью.
На рисунке 1 показана модель Agile Fluency, воспроизведенная непосредственно с оригинального веб-сайта. На рисунке 2 показана моя недавняя модель Организационной Зрелости Профессиональных Сервисов (Professional Services Organizational Maturity Model, PSOMM).
Если бы мы смотрели только на слайды, то могли бы прийти к довольно быстрому и простому выводу — на каждом уровне есть соответствие:
  1. «Начало: создание кода» будет напрямую соответствовать 1-му уровню зрелости.
  2. «Фокус на ценности» — уровень Agile Fluency с одной звездой, по-видимому, соответствует уровню зрелости 2. Появляется способность распознавать клиента и ценность для клиента становится предметом работы, а также синхронизирует людей и команды на основании запросов клиента. Есть непрерывность процесса и элементов, которые ему сопутствуют. Подразумевается изменение культуры, направленное на то, чтобы быть более ориентированным на внешний мир и осознать, что существует клиент и концепция ценности клиента, которую можно уловить при определении запросов клиентов.
  3. «Поставка ценности» с 2-мя звёздами, по-видимому, соответствует уровню зрелости 3, потому что команда может создавать ценность в соответствии с ритмом рынка, и это звучит как «постоянство результата». Также подразумевается, что есть значительный рост навыков, чтобы обеспечить постоянство результатов.
  4. «Оптимизация ценности» с 3-мя звёздами в модели Agile Fluency, кажется, соответствует уровню зрелости 4, где основное внимание уделяется оптимизации экономических результатов и извлечению реальной выгоды для бизнеса от возможностей, достигаемых на более низких уровнях Agile Fluency.
  5. «Оптимизация для системы» с 4-мя звёздами в Agile Fluency Model, по-видимому, напрямую соотносятся с концепцией оптимизации организации и её возможностей по предоставлению сервисов и продуктов на уровне зрелости 5. Итак, вот оно, простое сопоставление один к одному!
Если бы это было так просто! Я считаю, что требуется более глубокий анализ. Я действительно считаю, что модель Шора и Ларсен по существу аналогична пяти уровням зрелости и что нам следует принять сопоставление один к одному за чистую монету. Однако требуется более глубокий анализ и осознание, чтобы увидеть пробелы, не просто с целью «докопаться», а для того чтобы создать практические, прагматичные, действенные рекомендации по совершенствованию и продвижению вверх, независимо от того, считаете ли вы это Agile Fluency или организационной зрелостью.

Проблема с «Ценностью»

Вероятно, я был первым членом Agile-сообщества, который написал что-либо по существу на тему «ценности» и оптимизации экономических показателей с помощью Agile-методов в форме книги из 63 000 слов, опубликованной в 2003 году. В то время Agile-сообщество не сильно интересовалось такими темами, как «определение приоритетов невыполненных итераций на основе ценности», поэтому моя заявка на конференцию Agile-2003 была отклонена. Самое современное на тот момент представление в сообществе экстремального программирования заключалось в том, чтобы определять приоритеты на основе технического риска. Agile был в значительной степени внутренне ориентированным движением. Да, в Манифесте Agile упоминалось о «ценности», но когда дело дошло до практического руководства, то её просто там не оказалось. В то время, когда я писал «Agile-менеджмент», я думал, что определить «ценность» легко.
Я был одержим литературой по оптимизации производственных процессов, такой как «Теория ограничений», и был убеждён, что всё, что нам нужно сделать, это определить ценность функций, а затем использовать эту информацию для определения приоритетов и, следовательно, оптимизации экономических показателей. Сейчас, 13 лет спустя, я могу сказать вам, что я менее уверен чем когда-либо, что мы знаем, как определить «ценность» каким-либо значимым способом, чтобы впоследствии это могло привести к детерминированному подходу по оптимизации экономических показателей.
Что означает «ценность»? Если вы прочитаете текст статьи Шора/Ларсен, то он подразумевает довольно простую концепцию: «Представляет ли эта история ценность для наших клиентов?». Ответить на этот вопрос довольно просто. Поэтому, если мы примем это на таком уровне, мы сопоставим с уровнем организационной зрелости 2: мы можем идентифицировать клиента; и мы понимаем, что может представлять значимую ценность для этого клиента; мы способны отсеивать задачи и другие элементы внутренней ценности, которые не имеют значения для клиента. Таким образом, наблюдается некоторое улучшение в согласовании и единстве целей.
У нас есть клиентоориентированность. Последователи Канбан Метода признают некоторую синергию с ценностями и принципами Канбан. «Проблема с ценностью» начинается, когда вы пытаетесь выйти за рамки понятия «является ли это ценным» и вместо этого пытаетесь количественно оценить ценность. В 2003 году я посвятил две главы книги «Agile-менеджмента» попыткам разобраться с этим. Честно говоря, в большинстве случаев вывод был бы таков: профессиональная сервисная работа не может быть сведена к количественной оценке ценности, в лучшем случае её можно свести к многомерной качественной оценке. Теперь я преподаю этот метод оценки в качестве учебного занятия от 1 до 1,5 дней в рамках мастер-класса по Канбан-коучингу в учебных программах по ESP.
Если мы посмотрим на определения Agile Fluency от 2-х до 4-х звёзд, то подразумевается, что нам нужен более сложный подход к определению и пониманию ценности. В оригинальной статье (при условии, что она датирована 2012 годом) заявляют, что эта проблема решена в Lean Startup или в Бережливой разработке ПО. Честно говоря, это нереально. Lean Startup поможет вам проверить гипотезу о том, что ценность может существовать. Я действительно не знаю ничего в области бережливой разработки ПО, что даёт конкретное представление об анализе ценности. Тем не менее, совокупность знаний по Бережливой разработке в книгах Райнертсена или Кеннеди, предоставляет некоторые методы. Стало довольно модным определять стоимость, используя варианты подхода Рейнертсена к «стоимости задержки». Я всё ещё считаю, что этот материал находится на начальной стадии и имеет проблемы, а анализ того, почему это так, является предметом ещё одной продолжающейся серии статей на этом сайте, которая началась со статьи «Что мы знаем о продолжительности: Часть 1».
Таким образом, переход от Agile Fluency к 2-звездочному уровню подразумевает, что нам нужны лучшие способы определения ценности. У нас есть некоторые методы для этого в базе знаний Канбан с 2007 года — например, качественная оценка стоимости задержки и присвоение классов сервиса рабочим элементам. Это согласуется с моим анализом того, что Канбан-система и доски могут вывести вас на 4-й уровень организационной зрелости, как описано в моей статье «Паттерны Канбан и организационная зрелость». Метод оценки рисков, который я сейчас формализовал в учебных планах ESP, вместо того, чтобы пытаться объединить его с Канбаном (как мы делали с 2009 по 2014 год), обеспечивает комплексный, хотя и, по общему признанию, качественный, сложный и недетерминированный метод как для оценки стоимости, так и для выбора, упорядочивания и планирования с использованием оценки стоимости. Большая часть этой работы была доступна публично в 2012 году, хотя она и не представлена в удобной книге, но значительная её часть появилась в моём выступлении на конференции Agile 2009.

Проблема с «Канбаном»

Читая статью про Agile Fluency, мы должны признать, что, когда Шор и Ларсен говорят «Канбан», они на самом деле имеют в виду «Командный Канбан». Это тема, считается настолько тривиальной в Канбан-сообществе, что Kanban University не потрудился преподавать её или иметь определённую учебную программу для неё до 2015 года с введением практикующего специалиста по командному Канбану. В статье «Паттерны Канбан и организационная зрелость» я определяю Командный Канбан как поведение 1-го уровня зрелости. Однако я отмечаю, что бывают случаи, когда одна команда предоставляет узнаваемый и атомарный сервис, а не просто является частью более широкого рабочего процесса, в котором участвуют несколько команд. В случае, когда команда предоставляет сервис и он самодостаточен для этой команды, мы рассматривали бы их как находящихся на уровне организационной зрелости 2, при условии, что рабочие элементы были бы ценными для клиентов.
Из этого анализа мы начинаем видеть размытие границ. 1-звездочная Agile Fluencyможет существовать на уровне организационной зрелости 1. Но по-видимому, существует неявное понимание того, что «команда» предоставляет сервис, ориентированный на клиента. Следовательно, имеется значение уровня организационной зрелости 2, но в небольшом масштабе команды, не включающем более сложный рабочий процесс. Возможно, даже существует более неявное предположение, что если бы требовался более длительный и сложный рабочий процесс, то люди с этими дополнительными навыками должны быть привлечены в команду для поддержания её целостности и инкапсуляции в качестве поставщика комплексных сервисов.
Жаль, что Шор и Ларсен, похоже, не знают о Канбане больше и что они предполагают, что Командный Канбан — это всё, что есть. На самом деле, за много лет до 2012 года мы в значительной степени решили, что Командный Канбан был настолько тривиальным явлением, что не стоил наших усилий даже документировать его, не говоря уже об обучении ему. Только в последние годы, когда стало известно, что большая часть рынка находится на уровне организационной зрелости 1, мы решили помочь в начальном освоении, определив Командный Канбан и связанное с ним обучение. В Lean Kanban University, практикующем Командный Канбан, мы не предполагаем уровень зрелости 2. Мы не предполагаем, что команда, работающая с клиентами, обладает всеми кросс-функциональными навыками, необходимыми для предоставления сервисов «под ключ» без зависимостей. Таким образом, для нас Командный Канбан находится на уровне «ниже уровня Agile Fluency».

Повышение технической компетенции

Хорошее согласие получается между моделью организационной зрелости уровня 3 и Agile Fluency с 2-мя звёздами. С помощью Канбан, а также в обучении специалистов по Kanban Management Professional (KMP), в 5 главе пособия «Канбан: Успешные эволюционные изменения для вашего технологического бизнеса», мы рассматриваем способы улучшения. Например, сокращение времени поставки. Модель Шора/Ларсен предполагает, что вы можете сделать это с помощью экстремального программирования, что является вполне обоснованным предположением, но оно сопровождается повесткой, что вы примете Agile-методологию. Канбан — это анти-методология. Это метод «начать с того, что вы делаете сейчас» и развить это. В Канбан мы учим практиков определять возможности для улучшения и внедрять конкретные методы, часто Agile, технические методы, чтобы стимулировать улучшения. Канбан использует улучшения на основе моделей. Он также не предполагает контекст разработки ПО. Независимо от контекста, например, от рекламных агентств или компаний, занимающихся исследованиями рынка, мы ожидаем, что технические компетенции улучшатся, чтобы перейти на третий уровень организационной зрелости.

Проблема с масштабированием

В моделе Agile Fluency с 3-мя звёздами есть стремление оптимизировать экономические результаты. Это явно прямое сопоставление с уровнем организационной зрелости 4. В чём я отличаюсь от Шора и Ларсен, так это в манере и стиле достижения этого. Их предлагаемый подход заключается в том, что вы начинаете добавлять бизнес-функции в команду, и команды становятся всё больше и больше и всё более кросс-функциональнее. Подход Канбан Метода отличается. Мы используем оценку рисков, чтобы обеспечить общий язык для коммуникации, сотрудничества и принятия решений. Мы считаем, что вам не нужно делать команды всё больше и более многофункциональными, чтобы добиться совместной работы. Мы считаем, что сотрудничество проистекает из общего чувства цели, единства, согласованности, общего языка и общей основы для принятия решений. С 2014 года я решил включить это в наш тренинг по ESP, а не рекламировать его как «Продвинутый Канбан», как это было в период 2012—2014 гг. Канбан способен выводить организации на 4-й уровень зрелости с 2007 года и, учитывая предоставленное описание, способен обеспечить 3-звездочную Agile Fluency в течение одного и того же периода времени не только командам, но и целым продуктам или бизнес-подразделениям. У нас уже было справочное тематическое исследование Канбана по проектам с участием более 50 человек в 2007 году. Канбан использовался в организации из 150 человек с годовым бюджетом около 17 миллионов долларов. Мы не играли с «командами», когда дело касалось Agile Fluency

Проблема с оптимизацией

Прочитав описание 4-звездочной Agile Fluency Шора и Ларсен, я согласился, что справедливо будет сказать, что Канбан не показал, что он может достичь всего этого уровня на момент написания статьи в 2012 году. Тем не менее, значительное количество описываемых ими атрибутов присутствовало и сообщалось в Канбан-сообществе и на конференциях Lean Kanban: использование Портфельного Канбана (для балансировки рисков и бизнес-инициатив); использование Восходящего Канбана (для управления продуктами и реальных опционов); Операционные ревью на уровне единицы продукта или бизнес-единицы, демонстрирующие понимание системы систем и того, как каждый независимый рабочий процесс или проект взаимодействовал и зависел от других. Тем более разочаровывает, что Джим Шор появился на одной из наших конференций до появления этой статьи 2012 года, и вокруг него было много таких доказательств, если бы он захотел их увидеть. Сейчас я могу сказать, что я вполне уверен, что целые организации могут достичь 4-звездочной Agile Fluency (и более), используя ESP.

Выводы

Оказалось важным, что я переупаковал множество передовых и периферийных практик Канбана в ESP, потому что слишком многие специалисты по управлению видят или позиционируют Канбан только как метод на уровне команды. Если бы более высокопоставленные руководители, и я включаю в эту категорию Шора и Ларсен из сообщества Agile, действительно потрудились понять Канбан и то, что мы делали в сообществе Канбан за последние 8 лет, то они могли бы понять, что у нас есть много ответов, много проверенных методов, и что большинство из этих концепций дополняют и не угрожают тому, что они уже делают. Канбан и ESP в сочетании с соответствующим внедрением Agile-практик может и приведёт вас к уровню гибкости бизнеса, который Шор и Ларсен называют «желательным». Если у вас есть стремление достичь 4-звездочного уровня Agile Fluency, мы можем доставить вас туда сейчас, в 2016 году. И мы можем сделать всё это, не реорганизуя ваш бизнес в крупные кросс-функциональные команды. Канбан никогда не разделял Agile-повестку кросс-функциональных команд. Мы верим в достижение сотрудничества с помощью других средств — общего языка, прозрачности, наглядности, общих рамок принятия решений, основанных на фактах, методов качественного анализа, которые способствуют достижению консенсуса, ориентации на клиента, единства целей и согласованности.
Я хотел бы поблагодарить клиента, который попросил провести эту оценку и анализ, это было полезное и стоящее занятие.
]]> Управление проектированием работ с помощью Discovery Kanban в Optimizely http://neogenda.ru/blog/ep7aa7d101-upravlenie-proektirovaniem-rabot-s-pomos http://neogenda.ru/blog/ep7aa7d101-upravlenie-proektirovaniem-rabot-s-pomos?amp=true Fri, 29 Mar 2024 09:38:00 +0300 Артур Нек Перевод статьи Jeff Zych, размещённой на medium.com. Оригинал можно прочитать здесь. В моей предыдущей статье я описал, как мы трансформировали наш процесс гибкой...

Управление проектированием работ с помощью Discovery Kanban в Optimizely

Перевод статьи Jeff Zych, размещённой на medium.com.
Оригинал можно прочитать здесь.
В моей предыдущей статье я описал, как мы трансформировали наш процесс гибкой разработки в Optimizely, чтобы включить исследования и проектирование, внедрив наш собственный Discovery Kanban. Этот процесс даёт исследователям и тем, кто проектирует, пространство для понимания проблем наших клиентов и поиска решений, прежде чем мы приступим к поставке новых функций. В этой статье я пройду на уровень глубже, чтобы описать все этапы, через которые проходят исследовательские и проектные работы в процессе поиска новых решений.

Предпосылки

Discovery Канбан-доска основана на модели «двойного алмаза», которая визуализирует процесс проектирования в виде двух связанных алмазов. Первый алмаз представляет собой понимание проблемы, а второй — решение проблемы. Алмазы используются для сообщения о том, что работа чередуется между расходящимися фазами, в которых идеи широко исследуются, и конвергентными фазами, в которых идеи фильтруются и уточняются. Питер Мерхольц, партнер-основатель UX-консалтинговой компании Adaptive Path, даёт хороший обзор модели «двойного алмаза».
Алмазы представляют собой различные виды работ с определёнными входами и выходами, поэтому я адаптировал каждый алмаз в Канбан-доску. Канбан-доска — это просто серия этапов, представленных в виде столбцов, через которые проходит работа, с критериями принятия, которые определяют, когда элементы переходят на каждый этап.
Первая Канбан-доска — это Понимание проблемы, где мы собираем информацию, чтобы понять и сформулировать проблему. Вторая Канбан-доска — это Исследование решений, где мы берём результаты понимания проблемы и решаем конкретную проблему, которую мы определили. Вместе они составляют процесс Discovery Канбан в Optimizely.

Понимание проблемы

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

Бэклог

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

Нужно сделать (To do)

Каждую неделю мы вытягиваем элементы из «Бэклога» и перемещаем их в столбец «Нужно сделать». Обычно мы расставляем приоритеты в зависимости от того, насколько серьёзны проблемы для клиентов (с учётом видения продукта, дорожной карты и приоритетов компании), но это не строгое правило. Например, нам могут потребоваться некоторые данные для принятия стратегического решения, даже если это не самая большая проблема.
После того, как элемент был расставлен по приоритетам, мы составляем план исследования, чтобы решить этот вопрос. Это включает в себя выбор методов исследования, которые лучше всего подходят для ответа на этот вопрос. Не существует установленного формата для плана исследования, но он как минимум указывает, на какой вопрос мы отвечаем, и какой метод исследования следует использовать.
Метод исследования может представлять собой качественный метод, такой как интервью с клиентами или контекстный запрос. Или количественный метод, такой как отправка опроса, анализ журналов сервера или запрос хранилища данных. Для некоторых задач мы используем комбинацию разных методов.

Исследование

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

Синтез

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

Социализация

После того, как исследование синтезировано, оно переходит в фазу «Социализации». Основная часть работы сделана, но результат доводится до сведения команды или компании. Это принимает форму встреч, презентации, письменного отчёта, оценки возможностей или любого другого формата, подходящего для изучаемой проблемы. По крайней мере, команде предоставляется ссылка на план исследования и собранные данные.
Иногда мы узнаем, что проблема особенно сложна, и что план исследования недостаточен для её понимания. В таком случае, мы можем провести дополнительные исследования (если эта проблема достаточно важна) или просто принять лучшее решение на основе имеющихся у нас данных.
После изучения конкретной проблемы работа либо заканчивается здесь (в случае работы с персоналиями или данными для разработки продуктовой стратегии), либо превращается в проблему, которую должно решить проектирование. В последнем случае работа переходит в Бэклог «Исследование решения».

Исследование решений

Как только мы поймём проблему, мы сможем приступить к её решению. Мы отслеживаем эту работу на доске Исследование решения (она же второй алмаз модели «двойного алмаза»). Проблема может иметь трудности с UX и технические проблемы, которые нужно решить (т.е. возможно ли это построить?) или и то, и другое. Результатом этапа исследования решения является готовое решение для построения. Решение представляет собой либо полный пользовательский интерфейс, такой как макеты или прототип, либо техническое решение, такое как проектная документация или технический прототип, которое может быть реализовано в производственной среде.
На этом этапе работа также проходит по 5 столбцам: Бэклог, Нужно сделать, Исследование & Размышления, Итерация & Принятие решений, и Готово к построению.

Бэклог

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

Нужно сделать (To do)

Каждую неделю мы расставляем приоритеты по пунктам в Бэклоге и перемещаем их в раздел «Нужно сделать». Это значит, что у нас есть чётко сформулированная проблема, основанная на данных (обычно генерируемых при «Понимании проблемы», но может поступать из других источников), для которой команда разработает решение. Для большинства проблем мы формально пишем, в чём заключается проблема, почему её стоит решать, для кого мы её решаем и в каких масштабах (посмотрите шаблон на Google Диске).
Описание проблемы перед тем, как перейти к решениям, гарантирует, что команда будет согласна тем, что мы решаем. Это предотвращает напрасную работу и изменение направления после начала проекта. Это также выявляет предположения или неполные данные, которые у нас могут быть, что означало бы, что нам нужно вернуться к этапу «Понимание проблемы», чтобы собрать больше данных.

Исследование & размышления

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

Итерация & Принятие решений

Как только будет изучен широкий спектр решений, мы перейдём к этапу «Итерация и принятие решений». Это означает, что потенциальные решения оцениваются и уточняются. Компромиссы и подходы обсуждаются с соответствующими группами. Этот этап является конвергентным, т. е. идеи дорабатываются до единого готового решения.
Нет строгих критериев для определения того, находится ли элемент в «Исследовании и размышлении» или «Тестировании и итерации». Творческий процесс несколько хаотичен, и люди часто переключаются между «исследованием» и «очисткой» мышления на протяжении всего проекта. Но, как правило, есть точка перегиба, в которой мы больше занимаемся уточнением, чем изучением. Точная работа с колонкой зависит от человека, который её выполняет.
Наличие 2-х столбцов может показаться ненужным, но это полезно по двум причинам. Во-первых, это помогает понять, где находится работа в творческом процессе (особенно на ранней стадии по сравнению с поздней стадией). Это помогает проектировщикам, инженерам и руководителям проектов лучше обсуждать изучаемые решения. Во-вторых, это побуждает людей отделять дивергентное мышление от конвергентного мышления. Легко и просто согласиться с первой идеей, но это редко бывает лучшим решением. Поощряя исследования, мы увеличиваем шансы на то, что выберем лучшее решение.

Готово к построению

После того, как мы сделали несколько итераций, у нас остается одно готовое решение, которое готово к созданию и отправке клиентам. «Готовое решение» — это решение, для которого все крайние случаи были продуманы, оно было проверено соответствующими сторонами, и нет никаких серьезных открытых вопросов, которые могли бы замедлить разработку. Готовые решения представлены в виде макетов или прототипа, если это UX-решение, или документ о техническом проектировании или подтверждение концепции, если это решение технической осуществимости. Затем готовое решение перемещается в бэклог инжиниринга, где оно получает приоритет по сравнению со всеми другими потенциальными работами, которые необходимо выполнить.
Вместе, Канбан-доски Понимание проблемы и Исследование решений и составляют Discovery Канбан. Определение каждой колонки может показаться обязательным, но на самом деле это рекомендуемый процесс, которому можно следовать. Работа не всегда проходит линейно по каждой колонке, и мы не сторонники соблюдения точных критериев приёмки для продвижения работы вперёд. Важно, что мы работаем вместе, чтобы решить самые большие проблемы наших клиентов, в конечном счёте повышая ценность клиентов и ценность бизнеса.

Итог

С момента внедрения этого процесса мы стали лучше определять приоритеты для понимания самых больших проблем клиентов. У нас есть пространство для поиска решений этих проблем, и мы регулярно отправляем работу клиентам. Ни один процесс не идеален, но мы всегда стараемся улучшить нашу работу, чтобы постоянно поставлять нашим клиентам отличные продукты.
]]> Канбан не разделяет идею Agile-реструктуризации в кросс-функциональные команды http://neogenda.ru/blog/nmk1m52ma1-kanban-ne-razdelyaet-ideyu-agile-restruk http://neogenda.ru/blog/nmk1m52ma1-kanban-ne-razdelyaet-ideyu-agile-restruk?amp=true Sat, 30 Mar 2024 10:19:00 +0300 Артур Нек Перевод статьи Kanban Does Not Share Your Agile Cross-Functional Team Agenda от David J Anderson В ноябре 2013 года сообщество...

Канбан не разделяет идею Agile-реструктуризации в кросс-функциональные команды

Перевод статьи Kanban Does Not Share Your Agile Cross-Functional Team Agenda от David J Anderson
В ноябре 2013 года сообщество Канбан-коучей выработало 3 ключевых повестки, которые адресованы имплементации Канбана: повестка устойчивости, повестка сервис-ориентации, повестка выживаемости. Первая из этой троицы разделяется гибкими подходами, вторая и третья — являются совершенно уникальными и сосредоточены на улучшении качества предоставляемого сервиса и эволюционных изменениях. Гибкие методологии разработки программного обеспечения имеют чёткую повестку работы кросс-функциональными командами, которую Канбан не разделяет и в которой он не нуждается, чтобы получать серьёзные результаты улучшения рабочих процессов. Канбан — это про визуализацию, повышение прозрачности и понимание того, как вы работаете и уменьшения координационных издержек за счёт использования досок. Визуализируйте, а не реорганизуйте!
Консультанты по гибким методологиям любят много говорить о командах. Я тоже очень много говорил о командах в моей книге о Канбане, и это было моей ошибкой. Я использовал слово «команда» для обозначения «группы людей, работающих совместно, для достижения общей цели». А в гибких подходах команда — это уже организационная единица, которая построена так, чтобы иметь общую цель или предназначение, например разработку программного обеспечения. Консультанты по гибким методологиям обычно реорганизуют вас в «команды», и когда у работы есть вариативность и разнообразие, которые требуют людей с разными навыками, тогда эти команды называют кросс-функциональными командами — командами, содержащими людей, являющихся специалистами разной функциональной направленности. Цель дальнейшего командообразования состоит в том, чтобы в конечном итоге переквалифицировать людей состоящих в команде, чтобы они были универсальными специалистами, которые могут выполнять всё, или чтобы оны были Т-shaped специалистами, т. е. специалистами, которые обладают широким набором навыков на слабом уровне компетентности и высоким уровнем компетенции в своей специализации.
Трюк такого Agile-преобразования заключается в том, что боль реорганизации окупится при старте работ этих новых кросс-функциональных команд, что они достигнут высокой эффективности, устранив задержки в коммуникациях между функциональными подразделениями, и устранив накладные расходы на координацию межфункциональной деятельности. Если в одной организационной единице содержится всё, что вам нужно для производства продукта, вам не придётся беспокоиться о внешних зависимостях. Если эти организационные единицы могут быть небольшими, скажем, по 6 человек, тогда накладные расходы на координацию должны быть минимальными или не существовать вовсе.
И давайте просто скажем, что это работает. Давайте не будем даже оспаривать эту теорию с любыми метриками производительности или наблюдениями о том, что Agile-организации, на самом деле тратят много времени на координацию, определение зависимостей, выявление недостающих навыков и доступности общих ресурсов. Давайте проигнорируем частую нехватку квалифицированных людей, споры, борьбу за идеи и влияние на Agile-собраниях. Давайте проигнорируем всё это и просто предположим, что это работает.
Что я хотел бы, чтобы вы обдумали читая этот пост, так это то, насколько дорого во времени, деньгах, стрессе и тревоге проходит реорганизация в эти кросс-функциональные команды. Я бы хотел сказать, что большая часть боли в Agile-реорганизации и большое количество часов коучинга, необходимых для новых Agile-команд, вызваны стрессом реорганизации в кросс-функциональные команды. Другими словами, одна из причин, по которой Agile стоит так дорого, связана с кросс-функциональной повесткой.
Канбан не разделяет повестку кросс-функциональных команд. Вместо этого Канбан решает эту проблему по-другому. И размещённый выше рисунок объясняет как. Верхняя половина рисунка показывает упрощенную функциональную организационную структуру, разделенную на 8 функциональных подразделений с названиями от A до H. Каждое из этих функциональных подразделений представляет собой группу специалистов с определённым навыком или профессией.
Клиент делает запрос, который предусматривает привлечение 7 из этих подразделений. При Agile-подходе нам надо было бы реорганизовать эти подразделения в команды с представителями всех 7 навыков. Канбан использует другой подход. Канбан — это «начнем с того, что вы делаете сейчас», и это означает, что вы начинаете с организационной структуры, которая у вас сейчас есть. Вместо реорганизации Канбан просит вас смоделировать рабочий процесс для обработки запросов клиентов. Мы будем делать это с использованием инструмента STATIK (системный подход к представлению Канбана), который преподается на двухдневных тренингах Дизайнер Канбан Систем (Kanban Systems Design) аккредитованных Lean Kanban University. Применение STATIK даст нам Канбан-доску, изображенную в нижней части рисунка. Канбан-доска будет «сервис-ориентированной», поскольку на ней моделируется требуемый сервис с точки зрения клиента. Доска позволяет членам из всех 7 команд взаимодействовать для обработки запросов клиента.
Эта доска упрощена для целей демонстрации. В реальной жизни дизайн доски может не иметь соответствия один к одному от функциональной команды к колонке на доске. Некоторые этапы работ могут выполняться параллельно или в неопределённой последовательности. Мы можем спроектировать доску и тикеты (элементы идущие по доске) так, что этапы работ отражались не колонками на доске, а чекбоксами на тикетах. Существует много тонкостей, и большинство этих тонкостей охвачены обучающими программами. Квалифицированный Канбан-коуч может помочь с дизайном и моделированием содержимого доски и тикета.
В Канбане мы тоже пользуемся термином «команда» и я в своей книге дал ей определение: «группа людей, работающая совместно, чтобы достичь общей цели». Общая цель — удовлетворить запрос клиента. Это цель ориентированная на сервис. Дизайн доски и дизайн тикета обеспечивают визуализацию и понимание цели. У нас есть много примеров, которые показывают, что этот подход работает. Многие Канбан-практики сообщают о повышении уровня сотрудничества (коллаборации) в своих компаниях и что это было достигнуто без болезненной реорганизации или выделения какой-либо новой роли, ответственности или должности. Канбан улучшает сотрудничество посредством визуализации, ориентированной на клиента, и создает общие цели для динамически сформированных групп людей, привлечённых из разных функциональных подразделений. При правильном дизайне доски он работает для разделяемых ресурсов, разделяемых служб, групп разделенных по функциональному признаку и, конечно же, всегда будет работать для существующих кросс-функциональных команд.
Результаты от использования Канбана впечатляют с самого начала. В 2005 году первая Канбан-система охватывала три функциональных подразделения и обеспечила рост производительности на 230%, на 90% сократилось время выполнения запросов, с 0% до 98% улучшилась предсказуемость. И эти цифры теперь являются обыденностью. Чаще сообщается о 400%. Были даже цифры в 800%. Сокращение времени производства в 50% — 90% — это обыденность. Все это достигается без болезненной реорганизации в кросс-функциональные команды; без болезненных Agile-преобразований; без затрат на Agile-преобразования и затрат на Agile-коучинг.
Таким образом, даже если кросс-функциональные команды действительно значительно сокращают накладные расходы на управление, и даже если это делает их «потрясающими» и «гиперпродуктивными», и, откровенно говоря это ещё вопрос для обсуждения и исследования, но давайте представим, что всё это правда. Учитывая всё это, вам не кажется, что быстрее, проще, дешевле и лучше сделать прирост производительности на 200−800% и сократить на 50−90% время производства начав с того, что есть у вас сейчас и выполнив канбанизацию? Визуализируйте, а не реорганизуйте!
]]> Вероятно, ваши KPI – не те! Но почему? http://neogenda.ru/blog/740gonrhf1-veroyatno-vashi-kpi-ne-te-no-pochemu http://neogenda.ru/blog/740gonrhf1-veroyatno-vashi-kpi-ne-te-no-pochemu?amp=true Sun, 31 Mar 2024 10:25:00 +0300 Андрей Сидоренко Перевод статьи David J Anderson, размещённой на djaa.com. Оригинал можно прочитать здесь. Это вторая часть моей статьи «Определение ключевых показателей...

Вероятно, ваши KPI – не те! Но почему?

Перевод статьи David J Anderson, размещённой на djaa.com.
Оригинал можно прочитать здесь.
Это вторая часть моей статьи «Определение ключевых показателей эффективности при планировании корпоративных сервисов».
Выполнение обучающих заданий с частными клиентами за последние 18 месяцев показало мне, что у большинства компаний есть KPI, которые на самом деле не являются критериями соответствия. Другими словами, их KPI не являются показателями эффективности и, конечно же, не являются ключевыми показателями или ключевыми показателями эффективности. Я думаю, что эти KPI на самом деле следует классифицировать как метрики здоровья, а иногда как метрики, способствующие конкретным улучшениям.
Так что же такое метрики здоровья?

Метрики здоровья

Если мы говорим о человеке, то метриками его здоровья принято считать: пульс, вес, давление и уровень холестерина. Если речь идет о спортсмене, то он вряд ли ставил бы своей целью, например, достичь определённого показателя кровяного давления или определённой частоты пульса, но он знал бы нормальные диапазоны значений этих показателей и отслеживал бы их. Также спортсмен может отслеживать, например, время восстановления, т. е. время, необходимое восстановления ускоренного сердечного ритма, до нормального уровня после стресса.
То, приходят ли к вам ваши клиенты — это метрика здоровья. Это похоже на пульс. Их покупки, положительная маржа при этих продажах и наличие свободных денежных средств — всё это тоже метрики здоровья.
Для сравнения, удовлетворённость клиента, вероятность повторной покупки и его рекомендации вас своим коллегам или друзьям — это уже показатели эффективности. Есть много прибыльных предприятий, но цена на их акции невысока. В то же время есть другие компании, у которых наблюдается рост, но при этом отрицательный денежный поток, и которые имеют повышенный коэффициент P/E (т.е. соотношение Цена/Прибыль). Они всегда могут привлечь капитал, потому что их эффективность на рынке улучшается.
В Agile-подходе к разработке программного обеспечения, производительность команды (скорость) — это индикатор здоровья (скорее всего, вы бы хотели иметь какую-нибудь скорость), но вряд ли это показатель эффективности. Причина в том, что объём или скорость производства не являются критериями соответствия для ваших клиентов и редко являются ценными критериями даже для внутренних заинтересованных сторон. Клиенты ценят такие вещи, как время поставки, качество, полезный функционал. Вы можете верить, что скорость — это показатель времени поставки, но это может быть не так. У вас может быть большая скорость, но одновременно и хроническая системная проблема с растущей незавершённой работой и всё более продолжительными сроками доставки. В таком случае, вы похожи на пациента у которого есть пульс, но давление отклоняется в неправильном направлении, ваш холестерин повышается, и это сказывается на вашей способности выполнять повседневные задачи. Возможно, ваша печень работает не так, как должна? Если вы установите целевое значение для своего давления, возможно, вы сможете достичь его с помощью лекарств — это известно как симптоматическое лечение, но это не позволяет найти первопричину. В результате проблемы сохраняются, и в конечном итоге вы вернетёсь туда же, где вы были, но только спустя несколько месяцев. То же самое и с компаниями. Многие показатели здоровья могут быть «метриками тщеславия», например, похвастаться своим пульсом «в состоянии покоя» — это не всегда критерий соответствия!
Конечно, если у вас нет достаточного рабочего капитала, если у вас нет маржи, прибыли и свободных денежных средств, ваше корпоративное здоровье в опасности, но, как сказал Ричард Брэнсон: «Люди думают, что компании существуют для того, чтобы получать прибыль. Неправильно! Они получают прибыль, чтобы существовать!». Когда вы станете думать как Брэнсон, вы начнёте видеть общие метрики здоровья такими, какие они есть, и перестаете называть их «ключевыми показателями эффективности».

Метрики, способствующие улучшениям?

Реже, но все же в наше время ещё легко обнаружить менеджера с KPI из автономной системы показателей, который по праву следует классифицировать как метрики, способствующие улучшению.
Например, у нас низкая удовлетворенность клиентов и низкий индекс потребительской лояльности (NPS), потому что наши сроки поставки слишком длинные. Другими словами, клиент рассматривает время выполнения заказа как ключевой критерий выбора. Время выполнения заказа является критерием соответствия, и, следовательно, время выполнения заказа должно быть одним из наших KPI.
Чтобы сократить время выполнения заказа, мы решили автоматизировать тестирование, поскольку после анализа мы обнаружили, что значительная часть времени выполнения заказа приходится на ожидание ручного тестирования.
Соответственно, мы устанавливаем цель для улучшения — автоматизировать тестирование нашего приложения на 85%. Или другими словами, нам нужно выполнить 85% тестирования с помощью автоматизации. Итак, мы начинаем измерять и составлять отчёты о том, какой процент кода покрыт автоматизированными тестами. Возможно, мы даже поместили этот показатель в SMART-цели для менеджера. Однако же, это не делает автоматизацию тестирования «ключевым показателем эффективности». Напротив, это всего лишь производная от KPI. Истинный KPI — это время выполнения заказа. Мы уверены, что улучшив автоматизированное тестирование, мы сократим время выполнения заказа. У нас может существовать причинно-следственная связь, чтобы знать это наверняка, или это может быть просто постулат и эксперимент. Истинным KPI остаётся критерий соответствия для клиента — время выполнения заказа. Таким образом, процент автоматизированного покрытия кода — это метрика, способствующая улучшению.

Классифицируйте ваши метрики

На наших семинарах по планированию сервисов уровня предприятия (ESP) мы предлагаем серию упражнений по метрикам. И отдельное упражнение по классификации существующих KPI особенно поучительно для слушателей. Они обнаруживают, что большинство (если не все их существующие) KPI на самом деле являются метриками здоровья и метриками, способствующими улучшению. Часто слушатели не измеряют вообще ничего, что влияет на удовлетворенность потребителей. Поэтому совсем неудивительно, что они оказываются недовольны значениями индекса потребительской лояльности (NPS).

А как насчёт показателей, которых нет ни в одной из категорий?

Во время упражнения слушатели часто находят существующие метрики, которые они измеряют и о которых отчитываются, которые нельзя классифицировать как критерии соответствия, метрики, способствующие улучшению, или метрики здоровья. Реальность такова, что это метрики, которые скорее всего не нужны, и от них следует избавиться. Часто это унаследованные метрики, которые направляли предыдущие улучшения, или, возможно, критерии соответствия, которые больше не применяются, потому что компания больше не обслуживает этот сегмент рынка, или клиенты в этом сегменте изменили своё мнение о том, что приемлемо, и что «соответствует предназначению. В некоторых случаях показатели — это просто вещи, которые бизнес смог увидеть и измерить. Они не служат никакой полезной цели.
Чтобы выяснить, есть ли у метрики полезная цель, спросите себя: «На какие решения эта метрика влияет? Что бы мы сделали по-другому, если бы этот показатель вырос, упал или достиг некоторого порогового значения?». Если вы не можете определить действие или результат, который вы ожидаете после получения отчёта о метрике, то она вам не нужна.
Когда слушатели проходят наш семинар, они часто обнаруживают, что им нужно гораздо меньше показателей, чем они уже собирали и включали в отчёты. Но в то же время им потребуются и новые инструменты, чтобы улавливать критерии соответствия, которые они обнаружили, размышляя о сегментах рынка по-новому и видя свой продукт или услугу глазами клиентов.
]]> Agile и Agility. Что там с вашей трансформацией? http://neogenda.ru/blog/c5xgk54af1-agile-i-agility-chto-tam-s-vashei-transf http://neogenda.ru/blog/c5xgk54af1-agile-i-agility-chto-tam-s-vashei-transf?amp=true Mon, 01 Apr 2024 10:27:00 +0300 Алексей Пименов Последние два года можно чётко назвать годами крупных Agile-трансформаций. Трансформации плотно захватили умы людей: сейчас всё что ни попадя называют трансформациями...

Agile и Agility. Что там с вашей трансформацией?

Последние два года можно чётко назвать годами крупных Agile-трансформаций. Трансформации плотно захватили умы людей: сейчас всё что ни попадя называют трансформациями (наверное даже дома, процесс мытья посуды называют трансформацией к чистоте тарелок), под это собираются огромные форумы, этому посвящены десятки статей и выступлений, куча бизнес тренеров на этом делает свой бизнес… но не будем об этом. Нам (или мне) больше интересны Agile-трансформации, в результате которых должны (видимо) появляться Agile-организации. Об этом и поговорим.
Итак, начнем с Agile-организаций. Что это? На этот вопрос, порой, нет ответа у самих лидеров Agile-трансформаций и владельцев бизнеса. Задайте им вопросы:
  • Что такое Agile-организация?
  • Как мы поймём, что процесс трансформации закончен и мы уже Agile?
На эти вопросы, зачастую, вы не получите прямого ответа, в худшем случае будет абстрактная болтовня, в самом неэкологичном случае, вам эти вопросы просто вернут (типа сами и говорите, что это такое). В идеальном случае нам скажут, что это организации, которые все разделяют Agile-ценности, а может даже и пользуются Agile-принципами.
Посмотрим поглубже. Если вам просто ответили какими-то абстрактными речами про то как: «Корабли бороздят…» то это у вас в организации так называемый Bandwagon Effect — термин, который в русском языке имеет аналог: «Все пацаны с крыши прыгнули, ну и я тоже». Чем это чревато? Да просто тем, что это усиливающаяся петля. Количество организаций, которые хотят идти в ногу со временем и быть модными, смотря на другие организации, которые пошли путем трансформаций, затевают трансформации у себя. Что мы после этого наблюдаем? Ну, чтобы говорить об экономическом эффекте должно пройти больше времени, но пока мы можем наблюдать различные выступления на профильных и непрофильных конференциях об эпичных результатах, борьбе и светлом будущем, которое практически наступило, а если пообщаться с людьми в этих организациях — видим, что не всё так красиво и картинка с выступления вообще не бьётся с реальностью.
Если ответ на вопрос вам просто вернули — то тут тоже ничего хорошего. Ну представьте себе, вы инженер или скрам-мастер или аджайл-коуч организации и вам вот так ответили на вопрос, а вас таких (инженеров, скрам-мастеров и т. п.) в организации много и каждый должен сам себе придумать своё определение Agile-организации. Это попахивает тем, что у вас нет простого выравнивания (alignment) к цели, это ведёт к броуновскому движению в поисках того самого Agile или вообще к реализации басни Крылова про лебедя, рака и щуку.
Ну и третий ответ — все в организации должны разделять Agile-ценности и возможно следовать Agile-принципам (про принципы говорю «возможно» исходя из того, что принципы они более IT-шные и продуктовые, а Agile сейчас стараются применить в разных контекстах). Ну come on, вы реально считаете, что вся организация, от охранника и уборщицы должны жить согласно Agile-ценностям? И ваш охранник на ресепшене, пользуясь ценностью «люди и их взаимодействие над процессами и инструментами» должен в вашу организацию пропустить человека, не пользуясь пропускным режимом и инструкциями, а потому что с ним можно договориться? Ну таких абсурдов можно предложить очень много. Да! да! да!, меня можно закидать аргументами типа: «Ну ты перегибаешь», но я задамся ещё одним вопросом: «А как, вы поймете, что все разделяют эти Agile-ценности? А не мимикрируют под них или саботируют их целыми подразделениями?» Люди — это очень сложные существа и они могут легко эксплуатировать ситуацию в свою сторону и для своих целей и они не поделятся всем этим ни с вами, ни с «командным психологом», потому что это в их интересах — выживать в компании и мимикрировать под среду. Получается очень сложная ситуация, надо всё делать прозрачным, надо очень много контроллеров (в нашем случае в виде аджайл-коучей) которые будут эти вещи выявлять и проводить работу — кого-то «поломать» коучинговой палкой, а кого-то просто уволить из компании, за несоответствие Agile-ценностям (и это будет не зависеть от профессиональных навыков специалиста). Это всё попахивает определённой Agile-диктатурой и классовым разделением, а также огромными расходами на коучей и консультантов, при уходе из компании которых начинается возврат к предыдущему состоянию.
Но не будем о плохом. Если уж я рассказал про то, как неправильно, то надо бы рассказать и о том, как правильно.
Давайте посмотрим на ваш бизнес. Если вы живете в реальном мире, то для выживания и развития вашему бизнесу нужно:
  • Иметь какие-то продукты или услуги, которые просто генерируют cash за счёт которого компания существует. Эти продукты вы делаете давно, делаете эффективно и с ними у вас все понятно.
  • Иметь какие-то инициативы по развитию продуктов или услуг, которые должны дифференцировать вас от ваших конкурентов. И тут как раз идут кучи разных экспериментов и гипотез, направленных на удовлетворение клиентских потребностей.
  • Иметь какие-то инициативы по созданию новых продуктов или услуг, которые вообще могут иметь disruptive (разрушительную) природу для вашей бизнес-модели и вообще сегмента бизнеса, но они могут породить новое поколение продуктов и услуг и вообще сделать разворот (то что мы называем словом pivot) компании в сторону каких-то новых вещей, что будет двигать бизнес вперёд в новое качество
  • Иметь смелость отстреливать продукты, которые пусть еще и генерируют cash, но тянут на себя очень большие затраты на поддержание и сохранение лояльности клиентов.
Если у вас нет первого, вы можете остаться без штанов. Если у вас нет второго, то вас сожрут конкуренты. Если у вас нет третьего, вы просто можете вылететь из бизнеса из-за того, что мир движется вперёд (ну это примеры типа того, как вылетел Kodak и т. п.). Если у вас нет четвертого, то вы просто не можете нормально работать над первыми тремя пунктами и идти вперед, потому как четвёртый пункт — это гиря, привязанная к вашим ногам.
Теперь посмотрим, с точки зрения того, кто должен работать над этими четырьмя пунктами и как это должно осуществляться. Достаточно очевидно, что с первым пунктом очень хорошо работа пойдёт с тем, что мы привыкли называть регулярным менеджментом и управлять тут эффективнее всего будут именно менеджеры. Работа может идти как поточно, так и в проектной модели, и тут очень хорошо работает инструментарий наработанный за последние 100 лет эволюции менеджмента.
Второй пункт выглядит как поиск решения в комплексной среде (по модели Кеневин), здесь мы работаем с гипотезами и пытаемся их проверить быстро и дешёво, чтобы в конечном случае найти те вещи, которые отзовутся в сердцах потребителей и мы начнём на них зарабатывать. Вот тут как раз очень хорошо подходят Agile-подходы. Работа строится мотивированными профессионалами, им даётся большая свобода действий и они уже не управляются, а направляются согласно стратегии компании.
Третий пункт — это вообще, по сути, внутренние стартапы. Здесь нужны интрапренеры (внутренние предприниматели), люди с очень нестандартным мышлением и инструменты генерации и быстрой валидации гипотез. Думаю сюда хорошо зашли бы Design Sprint, Design Thinking и т. п.
Четвёртый пункт — тут нужны хладнокровные и расчётливые люди, которые понимают когда надо сказать «Стоп!» и умеют это делать хладнокровно.
Очень интересная картинка получается. На неё можно наложить ещё и разные механизмы финансирования деятельности, разный фокус на этапы работы с воронкой, или даже разные сегменты потребителей, на которые идёт фокус (энтузиасты, ранние последователи, раннее большинство, позднее большинство, отстающие). Это и интересно, и логично, и это посложнее будет, чем предложение добиться успеха, реорганизовав вашу компанию в самоорганизующиеся команды. Но самое главное я ещё не сказал.
А самым главным будет то, что это всё должно как-то управляться. Продукты должны находиться, доводиться до состояния, когда они удовлетворяют потребность клиента, зарабатывать деньги компании и убираться для того, чтобы открыть дорогу новым продуктам. С какой скоростью это должно происходить? Как часто это всё должно пересматриваться? Как должны быть распределены ресурсы компании по этим четырём пунктам? А вот это уже Стратегический Менеджмент.
Стратегия компании определяется, учитывая текущий портфель продуктов и услуг и изменения внешней среды бизнеса. Согласно стратегии мы пересматриваем этот портфель и перебалансируем ресурсы компании для соответствия возможностей по реализации портфеля с потребностью. А если посмотреть на то, как меняется в современном мире внешняя среда бизнеса, то мы заметим, что скорость пересмотра этой стратегии начинает расти и фокус стратегии начинает уходить от классической Портеровской модели, связанной с позиционированием, на другую модель — клиентоцентричную. И я бы даже сказал больше — на модель создания восторга у клиентов. И именно это, друзья, называется термином Business Agility.
Business Agility — это способность компании реагировать на изменения внешней среды. Это инструменты стратегического менеджмента XXI века, направленные на получение восторга у клиентов, и как результат — долгая и счастливая жизнь компаний, мешок денег у стейкхолдеров, прекрасные рабочие места у сотрудников.
А вы всё про ценности, да про ценности…
Резюмируем: Прежде чем затевать Agile-трансформацию, приведите в порядок стратегию (а если она в порядке, то проведите её обзор), найдите те места в организации, где по контексту хорошо подойдут Agile-подходы. Определитесь с целями и показателями (и обязательно замерьте текущие показатели эффективности, чтобы потом было с чем сравнить) и только тогда начинайте. Вот тогда всё будет хорошо.
]]> ESP. Построение информационного потока. Часть 4 http://neogenda.ru/blog/femtehhup1-esp-postroenie-informatsionnogo-potoka-c http://neogenda.ru/blog/femtehhup1-esp-postroenie-informatsionnogo-potoka-c?amp=true Tue, 02 Apr 2024 10:30:00 +0300 Артур Нек Перевод выступления Janice Linden-Reed. Оригинал видео на английском языке можно посмотреть ниже. Итак, нам осталось...

ESP. Построение информационного потока. Часть 4

Перевод выступления Janice Linden-Reed. Оригинал видео на английском языке можно посмотреть ниже.
Итак, нам осталось рассмотреть два собрания — Операционное ревью и Ревью рисков. Прочитайте предыдущие части статей — 1 часть, 2 часть, 3 часть.

Операционное ревью

Во время этого собрания мы собираемся рассмотреть целую группу Канбан-систем.
Цель: Обзор уровня «Системы для системы». Дисциплинарный анализ спроса и возможностей каждой Канбан-системы с особым вниманием к зависимостям и зависимым эффектам.
Каденция: ежемесячно.
Длительность: 2 часа
Участники: в собрании должны участвовать менеджер доставки сервиса и менеджер сервиса запросов для каждой Канбан-системы, а также высшее руководство, владельцы бизнеса или представители клиентов, downstream-менеджеры среднего звена. Должны присутствовать функциональные менеджеры и ключевые специалисты, представляющие каждую Канбан-систему. Плюс ко всему позовите менеджера по продукту, портфельного менеджера и проджект-менеджера.
Входные данные: соберите сводку данных с Ревью сервисов поставки для всех Канбан-систем в сети. Также понадобится информация об эффективности бизнеса с Ревью стратегии, например финансовые отчеты и опросы об удовлетворенности клиентов. С Ревью рисков возьмите текущие инициативы по улучшению в отношении общесистемных изменений.
Итоги: мы должны составить список предложений по улучшениям/действиям/решениям/ или необходимым изменениям в стратегии с ответственными исполнителями, и отправить его на Ревью сервисов поставки и Ревью стратегии. Зависимое влияние на хвостовой риск для распределения времени выполнения заказа отправляется на Ревью рисков, для информирования о приоритетных рисках или планирования на случай непредвиденных обстоятельств.
Что происходит на операционном ревью?
  • Смотрим на производительность, возможности и зависимости между несколькими Канбан-системами.
  • Понимаем зависимости, выявляем взаимозависимые эффекты
  • Обсуждаются мероприятия кайдзен, предложенные участниками.
  • Последним пунктом обсуждаются возможности улучшения, назначенные менеджерам.

Ревью рисков

В начале я говорила, что управление рисками очень важная часть в ESP (планирования сервисов уровня предприятия, Enterprise Services planning). На самоме деле, под риском мы имеем ввиду всё, что вызывает какую-либо проблему или может вызвать её. Риск — это то, что может поставить под угрозу наши возможности поставки. В первую очередь, мы заботимся об удовлетворении потребностей клиентов. Но я часто сталкиваюсь с группами, которые говорят: «Да ладно, цель — это становится всё быстрее и быстрее». Или говорят, что цель — это перейти к непрерывному потоку. Нет. Главная цель — удовлетворить потребности клиентов из каждого сегмента.
Цель: посмотреть на проблемы, которые ставят под угрозу возможности поставки.
Каденция: ежемесячно
Длительность: 1−2 часа
Участники: ревью проводится при содействии менеджера поставки сервиса или Канбан-коуча. На собрание нужно пригласить любого, у кого есть информация или опыт решения по недавними блокерами; остальных менеджеров поставки сервиса, проектных и программных менеджеров. По желанию могут быть приглашены менеджеры по работе с клиентами. Также могут присутствовать менеджеры из зависимых сервисов.
Входные данные: нужно собрать проблемы из сети Канбан-систем с Операционного ревью и отдельных Канбан-систем с Ревью сервисов поставки, а также нужны решения с Собрания планирования поставки.
Итоги: информация с Ревью рисков может сообщаться при планировании доставки, так как неразумно утверждать, что элемент будет готов для поставки и брать обязательство, если есть хвостовой риск, которым нельзя легко управлять и эффективно избежать для конкретного рабочего элемента.
Действия, согласованные на Ревью рисков, в частности планы снижения рисков, планы смягчения рисков или планы на случай непредвиденных обстоятельств, могут позволить внести изменения в предоставление сервисов и дизайн Канбан-систем, и, следовательно, запросы на изменение перетекают из Ревью рисков на Ревью сервисов поставки и Операционное ревью.
Что делать на Ревью рисков?
  • Кластеризуем заблокированные тикеты за последний месяц
  • Кластеризуем блокеры, основанные на историях, в которых произошли задержки
  • Каждый кластер представляет собой риск
  • Анализируем вероятности и воздействия
  • Определяем риски, которые больше всего влияют на хвост распределения времени выполнения заказа, и фокусируемся на них.
  • Обозреваем политики управления рисками
  • Определяем вероятности и воздействия
  • Анализируем коренные причины
Вопросы для Ревью рисков:
  • На какой риск мы готовы пойти?
  • Есть ли у нас правильная система оценки рисков?
  • Правильно ли мы определили размеры рисков?
  • Предоставляют ли наши оценочные таксономии для размеров рисков полезную информацию? Они нуждаются в доработке?
  • Какие риски мы хотим хеджировать? Как мы должны распределять наш портфель или ассортимент продуктов в соответствии с этими рисками? В каком процентном соотношении для каждой категории?
Типы заблокированных элементов
  1. Блокировка из-за проблем внутри нашей системы (и в рамках нашей внутренней политики)
  2. Блокировка из-за проблем за пределами нашей системы, но внутри нашей фирмы (для решения понадобится сотрудничество, и возможно, переговоры на высшем уровне).
  3. Блокировка из-за проблемы, внешней по отношению к нашей фирме, как правило с поставщиком, регулятором, клиентом. Возможны и политические причины, например, предстоящие выборы.
Пример Ревью рисков
Возможно, нам потребуется понять, где хвост распределения времени выполнения заказа наиболее сильно влияет на неспособность удовлетворить потребности клиентов и низкую производительность по сравнению с ожиданиями уровня сервиса.
Действие, которое обрезает хвост распределения времени выполнения заказа, приведёт к сокращению среднего времени выполнения заказа и его смещению влево на кривой распределения. Вследствие этого может появиться возможность изменить выделение мощности для данного типа работы или изменить выделение мощности для определенного класса сервиса.

И ещё о Ревью рисков

Рассмотрите классы услуг
  • Они всё ещё уместны? Используются ли они? Были ли сделаны какие-либо исключения? Есть ли новая закономерность? Вам нужен новый класс сервиса?
Обзор блокеров
  • Определите приоритеты мер по смягчению и сокращению на основе кластеризации блокеров.
  • Пересмотрите политик хеджирования рисков
  • Рассмотрите, соответствует ли недавно наблюдавшийся спрос историческим моделям и по-прежнему ли уместно распределение мощностей.
Пересмотр политики формирования спроса
  • Должны ли мы корректировать политику, которая раздваивает спрос на зависимые или общие сервисы.

Итоги

Вот мы и прошли все каденции и узнали всё о построении информационного потока. Если вы настроите всё правильно, то это будет работать как единая система. Информация должна передаваться плавно. Помните, что ежедневно вас ждёт Канбан-митинг, у вас несколько еженедельных встреч, таких как например Собрание по пополнению и встреча раз в 2 недели. У вас есть ежемесячное и ежеквартальное собрание. Все встречи немного разбросаны по времени, поэтому вы не будете всё своё время проводить на митингах, как это может показаться изначально.
]]> ESP. Построение информационного потока. Часть 3 http://neogenda.ru/blog/aojacczkr1-esp-postroenie-informatsionnogo-potoka-c http://neogenda.ru/blog/aojacczkr1-esp-postroenie-informatsionnogo-potoka-c?amp=true Wed, 03 Apr 2024 11:24:00 +0300 Артур Нек Перевод выступления Janice Linden-Reed. Оригинал видео на английском языке можно посмотреть ниже. Прочитайте предыдущие части...

ESP. Построение информационного потока. Часть 3

Перевод выступления Janice Linden-Reed. Оригинал видео на английском языке можно посмотреть ниже.
Прочитайте предыдущие части статей — 1 часть, 2 часть.
Теперь давайте поговорим о следующей группе совещаний — совещаниях по улучшению: Ревью стратегии, Ревью сервисов поставки, Операционное ревью и Ревью рисков. Первым обсудим Ревью стратегии.

Ревью стратегии

Цель: понять находимся ли мы в бизнесе, которым хотим заниматься, и имеем ли возможность заниматься этим бизнесом? Достижимы ли наши цели?
Каденция: ежеквартально
Продолжительность: половина рабочего дня
Участники: персонал, работающий с клиентами; высшее руководство; менеджеры проектов и портфельный менеджер.
Входные данные: вам необходимо собрать информацию о текущих возможностях из Ревью сервисов поставки и Операционного ревью. Также необходимы данные c Собраний по пополнению, которые, скорее всего, связаны с бизнес-рисками, распределением мощностей или политикой формирования спроса. Ещё понадобятся данные от сотрудников, работающих с клиентами.
Итоги: полученная новая информация и решения вносятся в Операционное ревью и Ревью сервисов поставки в соответствии с информацией о цели и KPI.

Примеры Ревью стратегии

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

Ревью сервисов поставки

Поставка сервиса — это по сути, наше обещание клиентам. И вопрос, который возникает здесь — было ли это обещание правдивым или ложным. Поэтому во время Ревью сервисов поставки мы должны понять, насколько наша работа соответствует ожиданиям клиентов.
Цель: посмотреть, соответствуем ли мы ожиданиям клиентов. На этом митинге смотрят на единственную Канбан-доску, т. е. для каждой Канбан-доски мы проводим отдельную встречу.
Каденция: дважды в месяц
Длительность: 30 минут
Участники: ревью проводится менеджером доставки сервиса (SDM), часто при участии менеджера сервиса запросов (SRM), клиентов и других стейкхолдеров вместе с представителями команды доставки.
Входные данные: нужно собрать прогресс и данные с Ежедневного Канбан-митинга; Решения с Операционного ревью и действия с Ревью рисков.
Итоги: о полученных результатах нужно отчитаться на Операционном ревью.
Что происходит на Ревью сервисов поставки?
  • Фокусируемся на возможностях системы.
  • Проверяем на соответствие метрикам критериев пригодности, например соответствуют ли наши текущие возможности сроку выполнения заказа в соответствии с Соглашением об уровне сервиса (SLA) с 60-дневным сроком выполнения 85%.
  • Обсуждаем недостатки в сравнении с ожиданиями (клиентов). Анализируем назначаемую/особую причину по сравнению со случайной/обычной причиной.
  • Обговариваем варианты смягчения и снижения рисков или изменения конструкции системы для улучшения наблюдаемых возможностей по сравнению с ожиданиями.
  • Нужно понять, какие сервисы мы предоставляем в настоящее время? Какие типы запросов на обслуживание/рабочие элементы мы принимаем?
  • Каковы ожидания уровня сервиса для каждого типа рабочего элемента?
Вопросы, которые необходимо озвучить на Ревью сервисов поставки:
  • Каковы наши текущие возможности по доставке каждого типа?
  • Каково распределение времени выполнения заказа?
  • Какова скорость поставки?
  • Уровень ликвидности системы.
  • Объём транзакций, волатильность, оперативность.
  • Эффективность потока
  • Качество
  • Риск задержки (от блокера) как вероятность и влияние.
  • Ожидаемый уровень обслуживания, выполнение в срок.
  • Вопросы, касающиеся улучшения процессов.
  • Чего достигла ваша команда с момента последней встречи?
  • C чем вам нужна помощь коллеги?
  • С чем вам нужна помощь от коллеги-руководителя или менеджера доставки сервиса? Нужна ли эскалация?
Открытие из Ревью сервисов поставки.
Если было много элементов с фиксированной датой, и при этом длинный хвост в распределении времени выполнения заказа, то заказчик мог бы запланировать элементы с фиксированной датой раньше или уменьшить количество элементов с фиксированной датой, изменив свою стратегию.
Продолжение читайте в 4-й и последней части серии статей «Построение информационного потока».
]]> ESP. Построение информационного потока. Часть 2 http://neogenda.ru/blog/640lmi7k81-esp-postroenie-informatsionnogo-potoka-c http://neogenda.ru/blog/640lmi7k81-esp-postroenie-informatsionnogo-potoka-c?amp=true Fri, 05 Apr 2024 11:30:00 +0300 Артур Нек Перевод выступления Janice Linden-Reed. Оригинал видео на английском языке можно посмотреть ниже. Предыдущую статью можно прочитать здесь...

ESP. Построение информационного потока. Часть 2

Перевод выступления Janice Linden-Reed. Оригинал видео на английском языке можно посмотреть ниже.
Предыдущую статью можно прочитать здесь.
Хорошо, теперь опираясь на термины из предыдущей статьи, давайте перейдём к разговору о конкретных Канбан-митингах. Я собираюсь показать вам их типичные конфигурации. Возможно, вы захотите начать (использование Канбан) именно с таких конфигураций. Важно отметить, что с точки зрения каденций, продолжительности собраний, участников собраний — всё это определяется индивидуально для каждой организации. Более того, вам скорее всего придётся перенастраивать всё это со временем под себя.

Набор поставки сервиса

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

Собрание по пополнению

Во-первых, давайте поговорим о пополнении. Мы называли это «встреча первой десятки», и на ней мы решали, получив всю информацию от заинтересованных сторон из всей компании, над чем работать дальше или, что следует рекомендовать делать группе разработчиков.
Цель собрания: решить, что выбрать из пула опционов, что делать следующим, и пополнить входной буфер для Канбан-системы.
Каденция: еженедельно
Продолжительность: от 20 до 30 минут
Участники: менеджер поставки сервиса или лицо, ответственное за фасилитацию встречи по планированию; вместе с персоналом по поставке сервиса, который может оценить технический риск и риск зависимости, а также дать совет по составлению графика, последовательности и группировке товаров.
Входные данные: 1. Наблюдения на Канбан-митингах и Ревью сервисов поставки могут привести к изменениям в поведении на собраниях по пополнению. 2. Решения из Ревью стратегии, такие как изменения политики и изменения портфеля.
Итог: решения о том, что делать дальше, а также системные изменения отправляются на Ежедневный Канбан-митинг.
Какие проблемы и вопросы обсуждаются на собрании по пополнению?
  • Обсуждаем что нового произошло с последней встречи?
  • Проверяем все представленные материалы в пуле вариантов/идей или буфере «Готово к доставке».
  • Убеждаемся, что элементы, доступные для выбора, правильно классифицированы по риску и запрошенные классы услуг соответствуют требованиям. Исправляем любые ошибки.
  • Считаем сколько Канбан-слотов доступно и какого типа/класса? Какие Канбан-сигналы у нас есть?
  • Фильтруем доступный пул опционов по типу, классу, окну в расписании, чтобы получить первоначальный список кандидатов для отбора.
  • Просим заинтересованные стороны сформировать шорт-лист кандидатов на основе первоначальной фильтрации.
  • Думаем, возможно ли сформировать консенсус по наиболее важным пунктам для отбора, учитывая ожидаемое время выполнения заказа?
  • Если не договорились, голосуем, чтобы выбрать.
Приведём пример
Наблюдения на Канбан-митингах и Ревью сервисов поставки могут привести к изменениям в поведении на собраниях по пополнению. Решения из Ревью стратегии, такие как изменения политики и изменения портфеля.
Например, было показано, что высокая скорость отбраковки, приводящая к перемещению рабочих элементов в корзину, изменяет поведение заинтересованных сторон и приводит к ужесточению «определения готовности», используемого для утверждения, что работа доступна для выбора на Собрании по пополнению.
Переходим к следующему важному собранию — Канбан-митингу.

Канбан-митинг

Цель: Наблюдать и отслеживать состояние работы (а не работников!). Наблюдать за ходом работы.
Каденция: ежедневно
Продолжительность: 10−20 минут
Участники: группа непосредственного обслуживания или команда, выполняющая работу (4−50 человек). При содействии менеджера доставки сервиса.
Входные данные: необходимо собрать решения, принятые на Собрании по пополнению и на Собрании планирования поставки, а также решения и новые инициативы, вытекающие из Ревью Стратегии.
Итоги: нужно получить отчёт о прогрессе на Собрании планирования поставки и Ревью сервисов поставки.
Что происходит на Канбан-митинге?
  • Менеджер доставки сервиса будет «проходить по доске» справа налево.
  • Доска покажет состояние работы и то, активно ли она выполняется, стоит ли в очереди, заблокирована или ждёт по какой-либо другой причине.
  • Менеджер поставки сервиса может запросить обновление статуса тикета. А также спросить, есть ли какая-либо дополнительная информация, которой нет на доске, и которая может быть неизвестна команде.
  • Внимание уделяется заблокированным или элементам с риском просрочки. Команда кратко обсудит, кто работает над проблемой и когда она будет решена. Также появляется запрос на другие блокировки, которых нет на доске, и возможность высказаться тем, кому нужна помощь.
Кстати, более зрелые команды могут обсуждать только заблокированные элементы, а не каждый тикет на доске. Менеджер доставки сервиса должен взять на себя ответственность за решение проблем с блокировкой — он спросит, кому поручено решить эту проблему и когда она будет решена. Для нерешённых проблем важны чётко определённые пути эскалации и политика.
После встречи участники спонтанно обсуждают и ищут решение проблемы или вопросов, затронутых во время Канбан-митинга. Это происходит сразу после Ежедневного Канбан-митинга.

Собрание по планированию поставки

И наконец, поговорим о третьем важном собрании, на котором мы должны запланировать наши поставки.
Цель: запланировать последующую поставку и сформировать манифест поставки.
Каденция: варьируется в зависимости от каденции поставки
Продолжительность: 1−2 часа
Участники: при участии человека, который играет роль менеджера поставки сервиса. Также должны быть приглашены любые другие заинтересованные стороны, включая тех, кто получает и принимает поставку, а также всех, кто участвует в логистике. Специалисты присутствуют из-за своих технических знаний и возможностей оценки рисков. Менеджеры присутствуют для принятия решений.
Входные данные: соберите информацию с ежедневного Канбан-митинга о том, какие элементы потенциально доступны для доставки. Также возьмите на митинг соображения о рисках, вытекающих из Ревью Рисков, которые могут повлиять на решения о поставке.
Итоги: вы должны получить решения о том, какие элементы должны быть поставлены (сообщить это нужно на ежедневном Канбан-митинге), а информацию о проблемах с доставкой направить на Ревью рисков.
Вопросы, которые нужны на собрании по планированию доставки:
  • Какие элементы в системе готовы (или будут готовы) к выпуску?
  • Что требуется для фактического выпуска каждого элемента в производство?
  • Какое тестирование потребуется после выпуска для проверки целостности производственных систем?
  • Какие риски связаны с этим?
  • Как можно снизить эти риски?
  • Какие планы на случай непредвиденных обстоятельств необходимы?
  • Кто должен участвовать в выпуске и присутствовать во время запуска в производство (или другого механизма доставки)?
  • Сколько времени займет релиз?
  • Какая ещё логистика будет задействована?
От планирования поставки к Ежедневному Канбан-митингу
Вам нужно задаться вопросом о том, какие элементы (с Канбан-доски), по нашему мнению, будут выполнены вовремя для поставки (дата доставки). Это можно сделать с помощью моделирования методом Монте-Карло, встроенного в программные Канбан-инструменты, или сделать это более качественно, спросив членов команды о ходе дел.
В этой ситуации все элементы, зафиксированные для поставки на Планировании поставки, фактически становятся элементами классов сервиса с фиксированной датой поставки. В идеале это должно быть явным и соответствующим образом визуализированным. Как следствие, нарушается порядок очередей на Канбан-доске. То, ЧТО и КАК выбирают на Канбан-доске работники, будет изменено в течение временного периода, пока не будет произведена доставка из системы клиенту/клиентам.
Продолжение читайте в следующей статье!
]]> ESP. Построение информационного потока. Часть 1 http://neogenda.ru/blog/xxxb4dses1-esp-postroenie-informatsionnogo-potoka-c http://neogenda.ru/blog/xxxb4dses1-esp-postroenie-informatsionnogo-potoka-c?amp=true Sat, 06 Apr 2024 11:32:00 +0300 Артур Нек Перевод выступления Janice Linden-Reed. Оригинал видео на английском языке можно посмотреть ниже. Сегодня мы более...

ESP. Построение информационного потока. Часть 1

Перевод выступления Janice Linden-Reed.
Оригинал видео на английском языке можно посмотреть ниже.
Сегодня мы более конкретно поговорим о каденциях, но прежде, чем углубляться в понятие ESP, поговорим о Канбан, потому что Канбан действительно лежит в основе планирования сервисов уровня предприятия (ESP — Enterprise Services planning). Канбан — это способ организовать работу и управлять ею. Канбан-система предназначена для уравновешивания спроса (это запросы на выполнение работы) и возможности (способность выполнить эту работу).
Как это происходит: вы наблюдаете за выполняемой вами работой и тем, КАК вы её выполняете, вы определяете риски и болевые точки, а также возможности для улучшения, а затем вы применяете методы. Есть много различных методов, которые мы используем, начиная с WIP-лимитов, классов обслуживания, распределения мощностей, и множество показателей, которые вы измеряете, таких как, например, управление временем производства (Lead Time).
Планирование сервисов уровня предприятия (ESP) — это полная система управления с Канбаном в центре. ESP будет координировать стратегические инициативы с текущими возможностями их реализации. Это то, что мы называем «воплотить в жизнь». Речь идёт о постановке целей, которые соответствуют тому, что мы на самом деле можем достичь, и, конечно, всегда стараемся сделать.
Вот элементы, которые действительно являются ключевыми для планирования сервисов уровня предприятия (ESP):
  • Канбан
  • Петли обратной связи или каденции
  • Вероятностное прогнозирование
  • Управление рисками
  • Формирование спроса и улучшение возможностей
Если вы посмотрите на ESP-каденции и как на самом деле работает ESP, то это может показаться вам немного знакомым:
  • Мы берём данные и другую собранную информацию из каждой Канбан-системы.
  • Наблюдаем за сигналами о необходимости настройки системы:
а) вы не выполняете работу, как обещали.
б) у вашего клиента есть неудовлетворённость или новый запрос.
Или
  • Рассматриваем текущий статус и решаем, как двигаться дальше:
а) какая работа в действительности будет выполнена? Что нужно вытянуть дальше?
б) как мы можем справиться с новыми конкурирующими продуктами?
  • Обсуждаем и принимаем решение о действиях:
а) меняем политику
б) применяем методы для формирования спроса или изменения мощности и т. д.
  • Сообщаем решения.
На самом деле это тот же процесс, который мы использовали для Канбан, но он выполняется в более широком масштабе сети. Ещё одна вещь о ESP, которую следует иметь в виду — многие люди говорят, что это просто масштабируемое решение. И это так. Но большая часть ценности ESP заключается в том, что оно улучшает общение и сотрудничество. И это снова выводит его на другой уровень, так что речь идёт не только о том, чтобы стать больше и масштабнее. Речь идёт о более скоординированном общении, в том числе с Upstream. Мы собираемся рассматривать каждую службу отдельно в ESP.
Мы не собираемся создавать для этого огромную «доску для досок». Мы говорим, что каждый сервис является самостоятельным, имеет свои отдельные потребности и будет иметь отдельную Канбан-систему. Но тогда, чтобы объединить их в одну сеть, мы будем использовать ESP. Петли обратной связи (ESP-каденции) дадут нам механизм, позволяющий взглянуть на наши существующие результаты и сравнить их с нашими желаемыми результатами. Для таких вещей, как наши стратегические инициативы, одна из самых важных задач в ESP — это поиск соответствия целям, и это говорит о том, удовлетворяем ли мы наших клиентов во всех сегментах нашего рынка. Когда мы говорим «клиент», мы говорим о внутреннем и внешнем потребителе, ведь вы можете получить заказ от людей внутри вашей компании. И, конечно же, у вас есть сторонние клиенты. И, конечно, достигаем ли мы наших стратегических целей.
Повторю, что сказал Дэвид Андерсон о принципах масштабирования: «Используйте Канбан-каденции в качестве системы управления, которая уравновешивает все эти различные Канбан-системы в вашей организации и приводит к более качественной поставке сервисов».

Принципы масштабирования

  1. Проектируйте сервисно-ориентированно по одному сервису за раз.
  2. Проектируйте каждую Канбан-систему используя STATIK, не пытайтесь разработать грандиозное решение в масштабе предприятия.
  3. Используйте Канбан-каденции в качестве системы управления, которая уравновешивает все эти различные Канбан-системы в вашей организации и приводит к более качественной поставке сервисов
Рассмотрим подробно Канбан-каденции. На первый взгляд кажется, что они состоят только из митингов. Но мы не проводим их непрерывно и каждый день. Мы рассмотрим все виды митингов и точно определим, как они работают, зачем они, и как взаимодействуют.
Верхняя часть диаграммы о том, как «делать вещи лучше». А нижняя часть относится к тому, как «завершать работу». Часть слева, которая включает обзор стратегии и митинг по пополнению запасов — это о том, как «делать правильные вещи», а именно: выбор, планирование и последовательность работы. Один из ключей к пониманию — расшифровать слово «Ревью» (Review). Если мы говорим о «митинге», то это на самом деле относится к той работе, которую мы выполняем сейчас, которая сейчас находится в стадии разработки, или вот-вот должна была быть поставка. Когда мы говорим «обзор», то это больше похоже на: «Эй, давайте сделаем шаг назад и посмотрим на систему. Посмотрим, как всё идет. Давайте посмотрим, как мы могли бы настроить эту систему». В Канбан мы часто говорили о наличии рычагов или о том, что вы можете немного изменить что-то, улучшить свою производительность и улучшить свои результаты. Именно на этих ревью мы говорим об этом.
Другой способ взглянуть на это: у нас есть «набор поставки сервиса», и «набор улучшений или эволюции». Ревью полагаются на улучшения и эволюционные изменения, с которыми они очень связаны. Мы просто продолжаем сохранять поток работы. Давайте разберёмся в значении стрелок.
Зеленая стрелка —это наш поток информации. Это как раз то, что мы хотим сказать: «Эй, примите во внимание эту информацию, эти данные или эту обратную связь, когда вы принимаете решения». Красная стрелка — это поток изменений — место, где мы приняли решения. У нас есть рекомендуемые действия, чтобы что-то изменить, и это, конечно, основано на этой информации о потоке.
Я также собираюсь сказать кое-что о ролях (участников в Канбан-системе). Поскольку это довольно новая и несколько спорная вещь. Так, например, если мы посмотрим на Канбан-доску ниже: у нас есть роли на восходящем потоке (upstream) и на нисходящем (downstream), а также у нас есть центральный пункт принятия обязательств.
Все используют разные термины. Так, некоторые организации обычно используют термин «менеджер поставки сервиса» (SDM). Есть много разных ролей в нисходящем потоке, которые вы можете назвать как «менеджер поставки сервиса». В восходящем потоке у нас есть «менеджер сервиса запросов» (SRM). Я полагаю, вы могли бы перевести его как «владелец продукта», но в основном они собираются принять то, что они будут иметь дело с различными опционами, которые поступают, которыми вы управляете на более высоком уровне. Соответственно, далее я буду использовать именно эти термины, чтобы вы понимали, о чём речь.
Продолжение читайте во второй части серии статей «Построение информационного потока».
]]> Анализ диаграммы распределения времени выполнения заказа http://neogenda.ru/blog/pbynijkt11-analiz-diagrammi-raspredeleniya-vremeni http://neogenda.ru/blog/pbynijkt11-analiz-diagrammi-raspredeleniya-vremeni?amp=true Sun, 07 Apr 2024 11:37:00 +0300 Артур Нек Перевод статьи Алексея Жеглова, размещённой на connected-knowledge.com Оригинал статьи можно прочитать здесь. Эта статья посвящена одному из ключевых показателей...

Анализ диаграммы распределения времени выполнения заказа

Перевод статьи Алексея Жеглова, размещённой на connected-knowledge.com
Оригинал статьи можно прочитать здесь.
Эта статья посвящена одному из ключевых показателей потока, которые мы используем в Канбан — времени выполнения заказа (Lead time). Мы немного поговорим о том, как его измерить, а также проанализировать и использовать полученные результаты.
В широком смысле, время выполнения заказа — это то, сколько времени требуется рабочему элементу, чтобы пройти через систему. Есть несколько вариантов этого определения. Клиентское время выполнения — это по сути время от формулирования концепции до получения денег. В Канбан-системах, связанных с интеллектуальной деятельностью (непроизводственных), мы также используем время выполнения заказа в Канбан-системе, которое измеряется от первой точки принятия обязательств в Канбан-системе до первого бесконечного выходного буфера.
Мы также используем термин время цикла. В Канбан-системах, связанных с интеллектуальной деятельностью, этот термин всегда является локальным и пригодным только там, где применяется. Нет никакого общего «времени цикла». У этих определений есть интересные корни, но они выходят за рамки этой статьи.
Измерить время выполнения заказа очень просто. Все, что требуется — это отметить, когда рабочий элемент был запущен, когда он был доставлен, а затем вычислить разницу. Мы можем сделать это, используя временны́е метки из электронных систем управления. Если мы используем физические Канбан-доски, мы можем сделать это, отметив даты начала и окончания в нижних углах карточки. «Метод Робинзона Крузо», когда необходимо ежедневно ставить отметку на карточке, оказался неэффективным в современном офисе.
После доставки нескольких элементов у нас есть набор данных о времени выполнения заказа. Теперь мы можем построить гистограмму и проанализировать распределение.

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

Это не редкая форма распределения времени выполнения, со смещенным влево асимметричным «горбом» и длинным толстым «хвостом». Лучше всего для описания этого набора данных подходит так называемое распределение Вейбулла с параметром формы 1,62 (это двухпараметрическое семейство абсолютно непрерывных распределений. Изменение параметра формы преобразует кривую распределения в несколько различных форм. Но это тема для другого поста).
Доставка занимает в среднем 34 дня. 85% проектов доставляются за 61 день, 98% занимают до 96 дней. И мы знаем эти вероятности, даже если больше ничего не знаем о проекте.

Углубление в данные

Проекты этой организации не все одинаковы. Они предлагают решения нескольких различных типов. На следующей гистограмме показано распределение времени выполнения заказа по четырем основным типам проектов (по соображениям анонимности эти типы проектов идентифицируются только с помощью цветовой кодировки).
На этой диаграмме мы видим, что каждая категория проектов имеет разное распределение. Реализация голубых проектов обычно занимает больше времени, чем реализация зеленых проектов. В хвосте распределения есть несколько, непропорционально много, красных отчётов, даже несмотря на то, что их пик распределения смещён влево. Фиолетовые интеграции занимают довольно много времени даже в лучшем случае.
Первая информация, которую мы получаем о каждом проекте — это то, к какой из категорий он относится. В Канбане мы называем эти категории — «типы рабочих элементов». Эта информация ясна, однозначна и не требует ни времени, ни усилий для её получения. Давайте углубимся в данные о времени выполнения по типу рабочего элемента.
Вот гистограмма времени выполнения для «зелёных» проектов, на которые приходится чуть более половины всех поставок.
Зелёные проекты доставляются немного быстрее, чем в среднем все проекты, за 30 дней против 34-х. 85-й процентиль поставок также занимает меньше времени, 54 дня против 61; и 98-й процентиль занимает 85 дней против 96.
Лучшим распределением, подходящим для зелёных проектов, опять же, является Вейбулл с формой 1.62. Одним из важных качеств этого распределения является то, что процентили (85-й, 98-й и другие) зависят только от среднего значения и параметра формы. Любой может рассчитать среднее значение. Поиск параметра формы требует некоторых статистических навыков, но благо он не сильно меняется со временем. Зная параметр формы и среднее значение, мы можем вычислить 85-й, 98-й и любой другой процентиль, который нам нужен. Конечно, мы также можем взять эти процентили из набора данных.
Давайте теперь взглянем на красные отчёты.
Процесс доставки, используемый компанией для этого типа проектов, отличается, и это видно по параметру формы наиболее подходящего распределения. Это снова Вейбулл, но параметр формы намного меньше — 1.23. Средняя доставка занимает 35 дней, мода (наиболее распространенное время выполнения заказа) намного меньше, 85% поставок занимают 61 день, 98% — 96 дней.
Рассматривая другие типы рабочих элементов мы видим, что синие проекты по внедрению следуют распределению, аналогичному зелёным проектам: параметр формы 1.65, среднее 40 дней, 85% выполнено за 66 дней, 98% за 81 день.
Организационный процесс для фиолетовых интеграционных проектов является наиболее регламентированным и реализуется в несколько этапов. И это также видно по форме распределения времени выполнения заказа (параметр формы — 3.22). Он более симметричен, с небольшим количеством «маленьких» (коротких по времени выполнения) проектов. Средний срок доставки составляет 56 дней, 85% за 70 дней, 98% за 100 дней.

Установление ожидаемого уровня сервиса

Теперь мы можем установить ожидаемый уровень сервиса для различных типов рабочих элементов, предоставляемых этой организацией. В следующей таблице приведены сводные данные по четырём типам рабочих элементов. Для сравнения я включил оценки процентилей, полученные с использованием параметризованных распределений. *Маленький секрет: у меня есть «навигационные таблицы» с предварительно рассчитанными коэффициентами для всех распространенных форм распределения, поэтому я просто взял среднее время выполнения заказа и умножил его на цифры из моей таблицы, используя калькулятор на моём телефоне.
Обратите внимание, что оценки 98-го процентиля, полученные с использованием параметрических распределений, довольно консервативны. Это уместно, поскольку небольшие наборы данных (в наборе данных было всего 19 красных и 14 синих рабочих элементов) плохо отражают вероятности редких событий.

Выводы

Время выполнения легко измерить. Есть несколько определений, и важно понимать, откуда и до какого момента проводить измерения. Многие сервисы поставляют различные типы рабочих элементов. Поэтому важно углубляться в данные о времени выполнения заказа по типу рабочего элемента, чтобы для каждого можно было установить отдельный ожидаемый уровень сервиса. Свойства общих распределений времени выполнения хорошо изучены и могут использоваться для поддержки SLE (service level expectations) и прогнозирования.
]]> Что такое точки принятия обязательств? http://neogenda.ru/blog/rtn1naeug1-chto-takoe-tochki-prinyatiya-obyazatelst http://neogenda.ru/blog/rtn1naeug1-chto-takoe-tochki-prinyatiya-obyazatelst?amp=true Mon, 08 Apr 2024 12:14:00 +0300 Артур Нек Перевод статьи Mila Chervenkova, опубликованной на kanbanize.com Оригинал можно прочитать здесь Одна из основных концепций Канбана заключается в том, что...

Что такое точки принятия обязательств?

Перевод статьи Mila Chervenkova, опубликованной на kanbanize.com
Оригинал можно прочитать здесь
Одна из основных концепций Канбана заключается в том, что работа должна обрабатываться небольшими партиями, чтобы оптимизировать поток и удовлетворить конечного потребителя за счёт непрерывной доставки ценности.
Но у нас есть одна большая проблема. Как мы можем разработать хорошо отлаженную систему, чтобы команды могли выполнять свою работу с большей предсказуемостью? Чтобы решить эту проблему, в Канбан мы используем специальные точки обязательств в нашем рабочем процессе.
В этой статье мы определим, что же такое точки принятия обязательств в Канбан-системе, и как мы можем визуализировать их на Канбан-доске.

Что такое точки принятия обязательств в Канбан?

На каждой Канбан-доске вы найдете колонку «Нужно сделать», которая, по сути, является бэклогом в Канбане. Это место, где члены команды собирают свои идеи для различных рабочих элементов или запросы от клиентов. Когда вы вытаскиваете задачу оттуда, то вы обязуетесь работать над ней и успешно её выполнить.
Поскольку Канбан основан на потоке, обязательство — это точка в рабочем процессе, когда рабочий элемент готов к вводу в систему и прохождению через неё. Существуют политики процессов и WIP-лимиты (т.е. незавершенная работа), которые управляют потоком и определяют максимальный объём работы, который может существовать в каждом состоянии рабочего процесса. На фундаментальном уровне, чёткое установление WIP-лимитом поощряет культуру «доведения дел до завершения».
Крайне важно понимать, что в Канбане обязательство — это не просто обещание определённого момента в будущем. Наоборот, это факт, что рабочий элемент будет выполняться в соответствии с политиками процесса и в конечном итоге будет доставлен конечному заказчику в рамках данного SLA (Соглашения об уровне сервиса). В Канбане это обычно представляет собой временные рамки цикла, в течение которых мы соглашаемся раскрыть ценность для клиента.

Почему мы используем точки принятия обязательств?

Мы часто эмоционально привязаны к идее сказать «да», особенно нашим клиентам. Поэтому мы склонны брать на себя больше рабочих обязательств, чем можем выполнить. Обратной стороной совершения слишком большого количества работы является то, что это может привести к перегрузке, снижению внимания к деталям и, в конечном итоге, к необходимости дополнительной доработки.
Другая возникающая проблема — это слишком раннее принятие идей, о которых у нас недостаточно информации. В этом случае велика вероятность отказа от работы. Чтобы не тратить время на рабочие элементы, которые мы не сможем успешно завершить после того, как уже начали, мы можем реализовать процесс «предварительной фиксации». Идея здесь состоит в том, чтобы собрать больше информации о наших опционах работы и, таким образом, уменьшить их неоднозначность.
Использование точек принятия обязательств даёт нам ясность в отношении нашего рабочего процесса: когда конкретная задача будет запущена, готова ли она к запуску, когда она будет выполнена и т. д. Это делает нашу работу более предсказуемой, а наш процесс более ясным, ведь команда точно знает, над какими задачами они должны работать дальше, а какие готовы к отправке заказчику.

Визуализация и реализация точек принятия обязательств

До сих пор разделяли мысль, что делая точки принятия обязательств явными, мы вносим бОльшую ясность и прозрачность в процесс принятия решений и, возможно, это способствует постепенному улучшению рабочего процесса.
При построении нашего рабочего процесса в Канбане у нас может быть процесс Discovery (upstream/течение вверх/восходящий поток) и Delivery (downstream/течение вниз/нисходящий поток). По сути, Восходящий Канбан (Upstream Kanban) — это этап предварительной фиксации, о котором мы упоминали ранее. Его цель состоит в том, чтобы управлять потоком входящих запросов, прежде чем брать на себя обязательство работать над ними. Кроме того, здесь мы берём на себя обязательство лучше понять, что мы хотим построить, и оценить наши идеи.
Рассматривайте процесс Discovery, как этап доработки, на котором у нас есть идеи или запросы клиентов, которые команда должна будет проверить. Как только это будет сделано, команде будет ясно, чего нужно достичь путём реализации конкретной идеи или запроса клиента.
После прохождения процесса Discovery мы можем определить, какие рабочие элементы выполнять дальше. Для этого нам нужно вовлечь членов нашей команды на собрание по пополнению/по принятию рабочих обязательств, которое является одной из 7-ми Канбан-каденций.
После того, как мы доработали наши идеи, запросы клиентов, а также провели встречу по их пополнению — фактическая работа над элементами может быть начата в процессе поставки.
Сейчас самое время объяснить, что для хорошо оптимизированного рабочего процесса с применением Канбан, вы должны сформировать две точки обязательств: во-первых, обязательство по работе (на старте) и во-вторых, обязательство по доставке. На Канбан-доске вы можете визуализировать их с помощью столбцов «Готово к запуску»/»Выбрано» и «Готово к доставке/Готово к развёртыванию».
Как только член команды получает возможность начать работу над задачами (представленными Канбан-карточками), он переводит её в стадию «Выполняется». По мере того, как рабочие элементы становятся всё ближе к доставке конечному потребителю (вторая точка принятия обязательств), вероятность выполнения обязательств к конкретной дате доставки возрастает.
Подумайте о точках обязательств «Готово к запуску» и «Готово к доставке» как о заказе из интернет-магазина. Когда вы что-то покупаете, вы обычно получаете письмо на почту, в котором сообщается, что магазин получил ваш заказ и уже работает над его упаковкой и отправкой вам. Это первый пункт обязательства: «Готовы начать». Интернет-магазин взял на себя обязательство выполнить работу, но ещё не указал точную дату.
Затем вы получите ещё одно письмо, в котором говорится, что ваш заказ должен быть доставлен в течение десяти дней. Затем, по мере приближения и большей определённости доставки, вы получите ещё одно письмо о том, что ваш заказ будет доставлен в определённую дату и время. Это второй пункт обязательств — «Готов к доставке». Интернет-магазин завершил работу над вашим заказом и назначил конкретную дату доставки.
Можно сказать, что доставка в Канбан (downstream или нисходящий поток) — это производственная линия, на которой мы в основном заботимся о сокращении времени цикла, повышении эффективности нашего процесса и постоянном повышении качества продукта или сервиса. Следует пояснить, что элемент может быть отброшен, если он не пересёк границу между графами «Запрошено» и «В процессе», но это не должно случаться часто, поскольку это будет сигналом для неэффективного процесса восходящего потока.
Итого, вот некоторые из основных принципов и практик в рамках Канбан Метода, которые помогают усилить обязательство:
  • Мы должны внедрить Upstream Канбан (Восходящий Канбан) — способ проверки рабочих элементов до принятия обязательств.
  • Мы должны чётко определить точки принятия обязательств.
  • Нам нужны двухэтапные обязательства — обязательство о работе и доставке.
  • Мы должны ограничить объём работы в нашей Канбан-системе, чтобы не брать на себя обязательств, которые могут превысить возможности команды и сделать доставку непредсказуемой.
  • Нам нужно визуализировать ход нашей работы и политику, связанную с этой работой, чтобы позже, когда мы возьмем на себя обязательство, мы могли выполнить обещание выполнить работу.
]]> Возникающие роли в Канбане http://neogenda.ru/blog/2dk7xt5ys1-voznikayuschie-roli-v-kanbane http://neogenda.ru/blog/2dk7xt5ys1-voznikayuschie-roli-v-kanbane?amp=true Tue, 09 Apr 2024 16:58:00 +0300 Артур Нек Перевод статьи Дэвида Андерсона, опубликованной на djaa.com. Оригинал можно прочитать здесь. Канбан Методу всегда было свойственно «начинать с того,...

Возникающие роли в Канбане

Перевод статьи Дэвида Андерсона, опубликованной на djaa.com.
Оригинал можно прочитать здесь.
Канбан Методу всегда было свойственно «начинать с того, что есть уже сейчас» и не создавать «новых ролей, ответственностей или должностей», по крайней мере в начале применения. Несмотря на это, сейчас становится понятно, что некоторые роли возникают на практике в ходе применения метода. Таким образом, полезно отметить этот факт, хотя они и остаются предложениями, опциями или идеями, а не предписанными ролями в применении Канбана. Это пост продолжает мою предыдущую статью о том, что Канбан не разделяет идею Agile-реструктуризации в кросс-функциональные команды, и всегда был кросс-командным, кросс-функциональным решением для рабочих процессов предоставления услуг. Следовательно, в контексте такого процесса, который включает функции и команды и (в большинстве случаев) ортогонален от организационной структуры предприятия, бизнес- или продуктового подразделения.

Менеджер сервиса поставки (SDM)

С первых дней создания Канбан Метода мы говорили о необходимости менеджеров брать на себя ответственность за поток работ. Очевидно, подражая концепции скрам-мастера, в некоторых имплементациях роль ответственного за поток стала называться менеджер потока или иногда «Флоу-мастер». Это прилипчивый, даже мистический и племенной титул. В нашей официальной литературе я бы хотел использовать нечто более дружественное корпоративной среде и обладающее широкой направленностью. «Менеджер потока» имеет узкую направленность и фокусируется на процессных проблемах. Я предпочитаю наименования, которые фокусируются на более широких аспектах и соотносятся с потребностями клиентов. Это соответствует ценности Канбана «Фокус на клиенте».
В Канбане есть прецедент переименования концепции в целях сосредоточения фокуса на клиенте. Вдохновившись Катой улучшений в Кате Тойоты, мы определили и назвали встречу Обзор мощности системы в 2012 году. Позднее она была переименована в Обзор сервиса. Смена названия произошла с целью направить фокус внимания встречи на потребности клиента, а не делать внутренний фокус на производительность процесса. Сохраняя наименования, язык и ценности, сфокусированные на внешних факторах, мы подтверждаем, что правильные метрики используются для проведения релевантных, ценных улучшений. Фокус на внешние факторы жизненно необходим для подтверждения «соответствия предназначению и для поставки в рамках повестки выживаемости организации в Канбан.
Так, «менеджер потока» стал называться «Менеджер сервиса поставки» (Service Delivery Manager, SDM). В первую очередь речь идет о роли, которую играет существующий сотрудник, а не о новой должности или позиции. При этом, создав роль менеджера сервиса поставки, мы ослабили утверждение о том, что никто не получает новых обязанностей, в действительности кто-то их получит — тот, кто возьмет на себя эту роль.
Роль SDM существовала еще в 2007 году в нашей первой полномасштабной имплементации Канбан-метода. Обычно эту роль выполнял проектный менеджер из Проектного офиса. Он отвечал за проведение встреч по пополнению, планированию поставки, эскалацию по блокирующим стикерам и за мероприятие, которое сегодня мы называем встречей по обзору рисков. Встречи по пополнению, планированию поставки и обзору рисков являются тремя каденциями в Канбан.
В более поздних имплементациях SDM также фасилитировал ежедневный Канбан митинг. В 2007 году эту роль выполнял один из линейных менеджеров, участвовавших в процессе. Роль SDM обычно выполнялась кем-то из проектного офиса.

Менеджер запросов для сервиса (SRM)

На протяжении нескольких лет возникал вопрос, что вы делаете с посредниками в потоке? Как правило, мы стремимся убрать не добавляющие ценности позиции посредников из потока. Однако, мы также стремимся избежать сопротивления изменениям. Это два основных постулата Канбан-коучинга и основные цели, которые могут стоять перед нами при управлении изменениями во время применения Канбана в организации. При этом следующая инструкция существует с 2009 года: мы ищем возможность поднять роль менеджеров-посредников над потоком работ и вывести за рамки потока создания ценности. Наиболее общий пример таких действий приведен на рисунке, «Что Вы делаете с Владельцами продукта?»
Цель состоит в том, чтобы репозиционировать роль владельца продукта в качестве риск-менеджера или фасилитатора: человека, который владеет правилами системы, обобщает решения и фасилитирует механизм принятия решений. Роль, которая обладает большей ценностью, прозрачна и открыта к детальной проверке, избавляет нас от риска появления «Владельца продукта — супергероя», который магическим образом понимает, где искать наилучшую бизнес-ценность.
Подобные, возвышенные над потоком, риск-менеджмент и владение политиками улучшают корпоративное управление, консистентность процесса и сокращают персональные риски, связанные с отдельными личностями. Тем не менее, человек, позиционирующий себя как «Владелец продукта — супергерой», будет сопротивляться такому изменению. Профессиональные Канбан-коучи (KCP) учатся управлять таким сопротивлением в ходе мастер-класса по Канбан-коучингу.
Когда репозиционирование владельца продукта над потоком во владельца политик по оценке рисков, формированию графика, приоритизации и отбору задач успешно завершено, он успешно переходит в роль менеджера запросов для сервиса (Service Request Manager, SRM)
И вновь мы ослабляем принцип «никто не получает новых обязанностей», но такая трансформация осуществляется управляемо и в течении определенного периода времени и не предполагает обязательных выпадов в сторону отдельных лиц на старте применения Канбана.
Когда появляется роль SRM, выполняющие эту роль принимают на себя ответственность за встречу по наполнению очереди и принимают участие во встречах по стратегии и встрече по обзору рисков.
]]> Как провести Канбан-митинг (Kanban meeting)? http://neogenda.ru/blog/co5hxrs8o1-kak-provesti-kanban-miting-kanban-meetin http://neogenda.ru/blog/co5hxrs8o1-kak-provesti-kanban-miting-kanban-meetin?amp=true Wed, 10 Apr 2024 17:01:00 +0300 Андрей Сидоренко Наверное всем знакома ситуация, когда утренняя летучка затягивается на часы, а после неё есть стойкое...

Как провести Канбан-митинг (Kanban meeting)?

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

Выгоды Канбан-митинга:

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

Проход по доске (Walking The Board)

Формат проведения митинга называется Walking The Board, потому что мы начинаем «идти» по нашей Канбан-доске справа налево — от самой правой колонки, которая ближе всего к колонке «Готово» и двигаемся налево. Фокусируемся на работе, на том, что нужно сделать, чтобы завершить эту работу или передвинуть на следующий этап, какие есть проблемы и кто может помочь в их решении.
«Проходя» справа налево по доске, мы затрагиваем каждую задачу и всей командой понимаем реальное состояние дел. Если, какая-то задача остаётся без сотрудника, например из-за того, что он отправился в правую часть доски помогать кому-то с задачей или завершать начатое, то такая задача может быть заблокирована. Информацию об этом мы начинаем копить, ведь она пригодится в будущем, чтобы обсудить с командой, а не слишком ли много задач вы берёте в свою систему.

Топ-5 вопросов на Канбан-митинге

Подходим к самому важному — вопросам, которые необходимо задавать на таком митинге.
1 вопрос. Что нужно сделать, чтобы закончить работу над этой задачей или переместить на следующий этап?
2 вопрос. В случае блокировки, может ли кто-то из участников помочь? Здесь нужно внимательно посмотреть, чем занимаемся выбранный для помощи сотрудник, может ли он помочь, отложив свои текущие задачи без потерь. При выборе чем заняться: «Взять задачу слева или помочь справа, ответ всегда один — мы перемещаем человека слева направо».
3 вопрос. К кому в компании можно обратиться за помощью, чтобы снять блокировку? Если во время Walking The Board мы находим блокировки, мы начинаем обсуждать кто из команды или за её рамками может помочь их снять. Если мы находим такого человека, то обсуждение того, чем именно он может помочь выносим за рамки Канбан-митинга, чтобы не растягивать встречу.
4 вопрос. Укладывается ли текущее ожидание по зависимости от задачи в наши договорённости с отделом, от которого мы зависим? Часто бывают взаимозависимости с другими отделами, например другой отдел должен проверить вашу работу. У вас есть договорённости и сроки. И если задача заблокировалась на такой проверки у другого отдела и все сроки уже прошли, то это сигнал пойти и проверить её состояние, предложить помощь или принять какое-то решения для скорейшего завершения задачи.
5 вопрос: Есть ли у нас элементы на доске, по которым есть риск не выполнить SLA, где таймер их пребывания в колонке начинает сигнализировать возникновения риска.
6 вопрос. Есть ли ещё работа, которая делается, но не отражена на доске? Таким образом, мы актуализируем текущее состояние системы.

Чек-лист итогов

По итогам встречи у вас:
  1. Есть оптимальное распределение между задачами в потоке работ. В конце встречи мы должны понимать, что у нас не осталось нерешённых вопросов, которые будут мешать выполнять задачи далее.
  2. Есть решения, предотвращающие риски.
  3. Известны владельцы критичной информации. Это люди внутри группы или нашей компании, которые могут помочь разблокировать ту или иную задачу.
  4. Есть договорённость о коллаборации, т. е. о взаимодействии участников команды или отдела внутри между собой. Иногда такой договорённости может быть — всё зависит от контекста работы. Но если у вас есть возможность достичь взаимодействия, то используйте её, ведь это поможет «прокачать» компетенции сотрудников, а также положительно повлияет на поток.
Частота проведения Канбан-митингов зависит от контекста: если работа высокодинамичная и быстро меняется в течение нескольких часов, то митинг можно проводить несколько раз в день. Если работа меняется в течение недели, то проводите встречу каждый день. Еженедельные встречи подойдут в больших проектах, где крупные изменения происходят редко.
Оптимальная длительность Канбан-митинга — 15−20 минут (для отдела из 10−12 человек и 15 задачами).
]]> Гибкость бизнеса не имеет ничего общего с масштабированием Agile http://neogenda.ru/blog/i2ky8t5n61-gibkost-biznesa-ne-imeet-nichego-obscheg http://neogenda.ru/blog/i2ky8t5n61-gibkost-biznesa-ne-imeet-nichego-obscheg?amp=true Thu, 11 Apr 2024 17:03:00 +0300 Артур Нек Статья Мартина Азиза, опубликованная на medium.com. Оригинал статьи Развитие Agile-подхода стало очень популярным за последние годы. И вполне заслуженно —...

Гибкость бизнеса не имеет ничего общего с масштабированием Agile

Статья Мартина Азиза, опубликованная на medium.com.
Оригинал статьи
Развитие Agile-подхода стало очень популярным за последние годы. И вполне заслуженно — это было реакцией на неустойчивые методы в индустрии разработки ПО. В свою очередь Agile привёл к значительным улучшениям в поставке ПО. С таким успехом вполне естественно стремиться к расширению Agile-практик на всех уровнях предприятия. Такой подход упростил бы ситуацию, но столкнулся с некоторыми фундаментальными проблемами, если учесть, что цели на разных уровнях организаций существенно различаются. Давайте рассмотрим гибкость с точки зрения трёх уровней абстракции внутри организаций: Предприятие, Сервис (Продукт) и Команда.

Гибкость предприятия — выживаемость

Вы можете вернуться на несколько тысячелетий назад, чтобы понаблюдать за предприятиями и сделать вывод — их главная цель на самом деле не в том, чтобы иметь лучший продукт или услугу для своих клиентов, а просто выжить. Предприятия стремятся осуществлять деятельность, которая приведёт к той или иной форме отдачи — прибыли, избегая при этом негативных последствий в виде убытков. Поскольку выгоды и последствия не могут быть гарантированы, деятельность, которую ведут предприятия, по сути, является риском. И предприятие продолжает выживать до тех пор, пока различия между доходами и последствиями позволяют ему иметь возможность (доступ к ресурсам) продолжать принимать на себя будущие риски. Предприятия, которые достигают точки, когда они больше не могут эффективно принимать будущие риски, находятся на «абсорбирующем барьере», или в более привычным нам термине — в состоянии банкротства.
Учитывая, что предприятия занимаются бизнесом, чтобы брать на себя риски в пределах зоны выживаемости, бизнес-стратегию теперь можно рассматривать как выражение того, какие допустимые риски может принять предприятие для поддержания выживания. Хорошие стратегии идут на риски приносящие большую отдачу и в то же время ограничивают воздействие негативных результатов.
Зная это, компании могут предпринять действия, чтобы расширить влияние положительных аспектов риска и ограничить подверженность отрицательным — это бизнес-стратегия.
Но как это сделать? Всё начинается с лучшего понимания ваших клиентов — достаточно ли вы понимаете их цели? И каковы критерии соответствия, которые заставят их выбрать ваше предложение по сравнению с предложением другого бизнеса? Знание факторов, влияющих на выбор вашего клиента, имеет большое значение для выбора стратегии, которая принесёт организации положительные результаты. Это помогает лучше определить ваши сервисы: каким бизнесом мы должны заниматься, какие функциональные и нефункциональные особенности необходимы и какие из них влияют на какие части нашего рынка?
Частично ограничивая воздействия негативных последствий означает, что ваша стратегия жизнеспособна, если она соответствует возможностям ваших предприятий. Таким образом, компании с ограниченными возможностями имеют ограниченный выбор стратегий, которые они могут использовать. Расширение возможностей организации расширяет диапазон возможных стратегий, из которых она может выбирать. И наоборот, недостаток возможностей может сузить их. Возможно, даже до такой степени, что никакие доступные стратегии не подойдут компании для выживания.
Гибкость предприятия означает способность постоянно согласовывать свою стратегию с вашим рынком и соответствующими возможностями.
Это можно выразить как форму ликвидности: можем ли мы преобразовать идеи в жизнеспособные опционы по курсу, который соответствует нашей стратегии, и как быстро мы можем затем преобразовать эти опционы в готовые рыночные поставки.

Гибкость продукта и сервиса — сервисная ориентация

Результат компании, ищущей правильную стратегию — это выполнение стратегии с помощью набора продуктов и / или сервисов. Услуги — это просто акт предоставления чего-то ценного другой стороне, и поэтому полезно думать обо всех вещах, как о сервисах. Продукты можно рассматривать, как конструкцию состоящую из набора сервисов, которые были упакованы определённым образом.
Чтобы предприятие было конкурентоспособным, его услуги должны соответствовать своей цели. Например, кофейня должна предоставлять кофе, который находится в пределах приемлемого порога вкуса, температуры и времени ожидания. Этими критериями соответствия сервиса необходимо управлять — это повестка сервисной ориентации на данном уровне организации.
Распознаваемость клиентом
Аспекты этой сервисной повестки могут включать в себя обеспечение понимания целей клиента во всей организации. Знает ли каждая группа/отдел/команда предназначение того, над чем они работают? Выражается ли работа в терминах цели заказчика или как нечто совершенно неузнаваемое заказчиком? Без этого знания, решения и вытекающие из них действия могут сильно расходиться, что приводит к неприемлемым срокам поставки или несоответствию другим критериям соответствия.
Поток
Сервисы в самых сложных организациях требуют значительного сотрудничества между командами и отделами. Учитывая, что большинство команд не сидят сложа рук в ожидании запросов от других групп, запросы между группами являются источниками очередей и ожидания. Обращая внимание на чрезмерно высокий коэффициент утилизации (и многие другие источники задержек), сервисы могут значительно улучшить свой поток. А это улучшает их предоставление с точки зрения времени, качества и предсказуемости.
Неоднородность клиентов
Сервисы также понимают, что у клиентов есть несколько целей, и поэтому критерии соответствия могут варьироваться в зависимости от категории клиентов. Затем сервисы могут достичь баланса, избегая предоставления чрезмерного сервиса в одних областях, чтобы они могли привлечь ресурсы на недостаточный сервис в других. Вы можете увидеть повседневные примеры этих классов обслуживания в находящихся по соседству сетях быстрого питания, просто отметив разницу в скорости обслуживания, сделав заказ через окно из автомобиля и внутри ресторана. Гибкость на этом уровне связана с сервисной повесткой: понимание цели клиента и формирования потока для её достижения.

Гибкость Команды — практики устойчивости

Когда мы начинаем понимать команды и отдельных людей, это возвращает нас к первоначальной Agile-повестке. Именно здесь устойчивость выражается как в человеческих, так и в технических практиках. Независимо от того, использует ли команда Scrum, Командный Канбан, XP или что-то ещё, они пытаются прийти к способам стабильной работы. Команды избегают чрезмерную нагрузку, достигая правильного баланса работы при ограничении объёма работы, которую они берут на себя. Прозрачность поощряется для улучшения циклов обратной связи и обеспечения децентрализованного принятия решений. Распространённые задержки и источники сбоев также устраняются с помощью современных технических практик. Я не собираюсь заходить слишком далеко в этом вопросе, так как существует множество отличных ресурсов по Agile и командам.

Agile на всех уровнях, но без масштабирования

Бизнес-гибкость — это достижение нужной гибкости на всех уровнях организации. На уровне предприятия она должна способствовать повышению выживаемости. На уровне сервисов она должна способствовать ориентации на сервисы. А на уровне команд — должна способствовать устойчивости. Компаниям требуются все три повестки. Но, учитывая разные потребности на каждом уровне, они не смогут удовлетворить их, пытаясь воспроизвести и расширить подходы Agile-разработки в масштабах всей компании.
]]> Время в процессе: что мы реально о нём знаем? http://neogenda.ru/blog/y6bnant0g1-vremya-v-protsesse-chto-mi-realno-o-nyom http://neogenda.ru/blog/y6bnant0g1-vremya-v-protsesse-chto-mi-realno-o-nyom?amp=true Fri, 12 Apr 2024 17:24:00 +0300 Артур Нек Перевод статьи Alexei Zheglov, опубликованной на squirrelnorth.com Предыдущий пост, «Время в процессе и энтропия», был несколько техническим. Однако, его концепции...

Время в процессе: что мы реально о нём знаем?

Перевод статьи Alexei Zheglov, опубликованной на squirrelnorth.com

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

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

Во время изучения поступающей информации можно задать несколько хороших вопросов: 1) достаточно ли хороша информация?; 2) хватает ли её нам?; 3) мы действительно знаем, что происходит?; 4) откуда мы это знаем?

В своей книге «Черный лебедь» Нассим Николас Талеб описал две вымышленные страны — Среднестан и Экстремистан. Среднестан населён такими явлениями, что наши наблюдения за ними никогда не смогут отклониться слишком далеко от среднего показателя. Экстремистан же населён явлениями, которые допускают вероятность, пусть и небольшую, экстремальных событий — чёрных лебедей. Если бы самый большой или самый маленький человек в мире вошёл на стадион, где уже сидело 50 000 болельщиков, как бы это изменило средний рост или вес этих людей? Никак. А что, если Билл Гейтс войдёт на этот стадион? Как говорится в анекдоте, средний болельщик на стадионе стал бы миллионером. Это потому, что размер человека относится к Среднестану, в то время как богатство живёт в Экстремистане (кстати, если рассказывать эту шутку как «Билл Гейтс входит в бар…», то не совсем верно она отразит крайность). Иногда люди описывают Среднестан как распределение Гаусса, а Экстремистан как распределение Парето, имея в виду два популярных технических термина.

Суть как Среднестана, так и Экстремистана состоит в том, что требуется очень много наблюдений для того, чтобы достоверно хоть что-то узнать. В гауссовом мире вы увидите что-то за пределами типичного доверительного интервала величиной плюс-минус три сигма, в среднем, 1 раз за примерно 370 наблюдений. В Экстремистане вы можете встретить тысячи наблюдений белых лебедей, прежде чем увидеть первого чёрного лебедя.

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

Время в процессе (Time-in-Process, TiP) и время выхода на рынок (Time-to-Market, TTM) живут в этом приграничном регионе. И это хорошие новости, если вы менеджер, отвечающий за поставку продуктов или сервисов вашим клиентам! Вы можете создать очень хорошую модель того, что происходит в вашем бизнесе, с очень небольшим количеством данных. Вам нужно меньше данных, чем вы думаете!
]]> Время в процессе и энтропия http://neogenda.ru/blog/9kh6up76b1-vremya-v-protsesse-i-entropiya http://neogenda.ru/blog/9kh6up76b1-vremya-v-protsesse-i-entropiya?amp=true Sat, 13 Apr 2024 17:26:00 +0300 Артур Нек Перевод статьи Алексея Жеглова Time-in-Process and Entropy, опубликованной на medium.com. Концепция энтропии в теории информации — это количество информации, которое...

Время в процессе и энтропия

Перевод статьи Алексея Жеглова Time-in-Process and Entropy, опубликованной на medium.com.
Концепция энтропии в теории информации — это количество информации, которое мы ожидаем получить, наблюдая за некоторым вероятностным явлением.
Если нам случится наблюдать очень редкое событие, наше наблюдение несёт в себе огромное количество информации. Если нам случится наблюдать более обычное, частое событие, количество информации будет намного меньше. Если мы наблюдаем что-то, что обязательно произойдёт (с вероятностью 100%) — количество информации равно нулю.
Теперь мы можем вычислить энтропию, суммируя количество информации, полученной в результате наблюдения всех возможных исходов с весовыми коэффициентами равными вероятностям этих исходов. Если исходы представляют собой не дискретный набор, а непрерывный диапазон, то интегрирование — это математический аппарат, который мы можем использовать для решения этой задачи.
Оказывается, что из всех возможных распределений вероятностей, определённых в области от 0 до плюс-бесконечности (то есть всех положительных действительных чисел), экспоненциальное распределение имеет максимальную энтропию.
Что интересно, время-в-процессе (time-in-process, TiP), которое мы наблюдаем во многих творческих и наукоёмких производствах, часто имеет распределение вероятностей, достаточно близкое к экспоненциальному.
И это хорошие новости.
Каждый раз, когда мы завершаем рабочий элемент и поставляем что-то заказчику, мы фиксируем время его выполнения. Это одно наблюдение. Поскольку мы работаем в области высокой энтропии, мы можем ожидать, что наши наблюдения дадут много информации. Поэтому нам не нужно много наблюдений, чтобы создать надëжную модель.
Менеджер в примере на графике выше обнаружил, что они неправильно посчитали вторую справа точку данных (84 дня). Однако вскоре они поняли, что исправление этой неточности любым способом или даже полное удаление этой точки данных из набора не изменит ни одного из нескольких важных фактов, о которых эта модель сообщает менеджеру:
  1. Среднее время в процессе, которое вы можете использовать для своих целей планирования, все ещё почти такое же.
  2. Процентиль времени в процессе, которое вы бы использовали, чтобы предложить клиентам соглашение об уровне услуг (SLA), остаётся прежним.
  3. Худший наблюдаемый случай всё тот же. («Хвост» распределения всё ещё находится там). Если у вас была идея для улучшения, чтобы устранить основную причину этой задержки, она, вероятно, всë ещё действительна.
]]> Формат OKR: как создать свои собственные OKR? http://neogenda.ru/blog/dnfebing21-format-okr-kak-sozdat-svoi-sobstvennie-o http://neogenda.ru/blog/dnfebing21-format-okr-kak-sozdat-svoi-sobstvennie-o?amp=true Sun, 14 Apr 2024 17:28:00 +0300 Андрей Сидоренко Перевод статьи, размещённой на okrexamples.co Оригинал статьи можно прочитать здесь. Этот сайт предлагает примеры OKR (Objectives and Key...

Формат OKR: как создать свои собственные OKR?

Перевод статьи, размещённой на okrexamples.co
Оригинал статьи можно прочитать здесь.
Этот сайт предлагает примеры OKR (Objectives and Key Results) для ознакомления и вдохновения при размышлениях о ваших собственных OKR. Вы не сможете выбрать OKR с этого сайта (или любого другого сайта вообще) и применить их непосредственно к своей компании или команде. Вам нужно изучить подход OKR, чтобы получить от него истинную пользу. В противном случае вам будет не хватать OKR.
Давайте посмотрим на базовый пример для успешного создания своих собственных OKR.

Что такое цели?

Цель (Objective) — это буква O в OKR. Это направление и цель на один квартал или по-другому — ваша квартальная цель.
Цели должны стимулировать рост, изменения или инновации в вашей компании или команде. Они должны быть мотивирующими, направляющими и обеспечивать достаточную ясность. Цели не должны содержать в себе чисел — для этого существуют ключевые результаты.
Важно! Полезно, если ваша цель будет начинаться с глагола, например, «УЛУЧШИТЬ межгрупповое взаимодействие».

Что такое ключевые результаты?

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

OKR-формат для компаний

Большинству компаний следует иметь хотя бы одну или две глобальных цели, чтобы обеспечить направление для командных OKR. Но крупной компании может понадобиться больше.
Цели на уровне компании НЕ должны иметь ключевых результатов.
Что?!? Да, мы знаем, что просто взорвали ваш мозг:)
Цели компании обеспечивают согласованность для всех команд в вашей компании (даже если функциональная команда состоит только из одного человека). Они следят за тем, чтобы все OKR, которые пишут ваши команды, были в одном направлении (с целями вашей компании). Команды будут продвигать цели вашей компании вперёд с помощью своих OKR.

OKR-формат для команд

Базовый формат OKR для команд таков:
O: [Укажите направление роста, изменений или инноваций, которое продвигает цели вашей компании вперёд]
KR 1: [вставьте измеримый результат 1, который доказывает, что вы достигли своей цели.]
KR 2: [вставьте измеримый результат 2, который доказывает, что вы достигли своей цели.]
KR 3: [вставьте измеримый результат 3, который доказывает, что вы достигли своей цели.]
Важно! Команды могут иметь до 5 ключевых результатов в рамках одной цели. Минимальная рекомендация — 2−3 ключевых результата.
При создании OKR подумайте о цели компании и о том, как ваша команда может помочь в достижении этой цели.
А затем задайте себе два вопроса:
  1. Что мы можем создать, исправить или улучшить?
  2. Какую проблему нам нужно решить в первую очередь?
Договоритесь об одной-двух целях. Если у вас большая команда, то может быть и три цели, но прежде подумайте, чего вы реально можете достичь за один квартал. Затем придумайте от 3-х до 5-ти измеримых результатов, которые докажут всем в вашей компании, что вы достигли своей цели.

OKR-формат — простой, но не лёгкий

Формат OKR простой.
Компания: 1−2 цели компании, которые будут направлением и целью на один квартал. Они должны стимулировать инновации, рост или изменения. Они обеспечивают направление для всех целей команды.
Команда: 1−2 цели для каждой команды, которые будут определять направление и цель на квартал. Они должны стимулировать инновации, рост или изменения. Это должно помочь достижению целей компании.
Каждая цель будет иметь 3−5 ключевых результатов, которые доказывают (с цифрами), что вы достигли своих целей.
OKR направлены на улучшение вашей организации, и никто не может написать их за вас. Именно поэтому важно изучить процесс постановки целей OKR и его основные принципы.
Подробнее о процессе постановки целей OKR и его основных принципах читайте в бесплатной электронной книге Weekdone «Пошаговое руководство по OKR», а также в книге «OKR для начинающих».
]]> Насколько инновации связаны с хорошими идеями? http://neogenda.ru/blog/j8tjjrxva1-naskolko-innovatsii-svyazani-s-horoshimi http://neogenda.ru/blog/j8tjjrxva1-naskolko-innovatsii-svyazani-s-horoshimi?amp=true Mon, 15 Apr 2024 17:31:00 +0300 Артур Нек Перевод оригинальной статьи Мартина Азиза, опубликованной на SquirrelNorth. Давайте придумаем больше идей! Я вспоминаю разговор с одним директором,...

Насколько инновации связаны с хорошими идеями?

Перевод оригинальной статьи Мартина Азиза, опубликованной на SquirrelNorth.

Давайте придумаем больше идей!

Я вспоминаю разговор с одним директором, который хотел получить мой совет о том, как повысить уровень инноваций в их компании. Я спросил её, в чём проблема, и она без колебаний ответила: «ни одна из наших новых идей не получает одобрения команды исполнителей». Она была разочарована в себе — она думала, что если бы у неё были идеи получше, то в её организации было бы больше инноваций.
Я спросил, что она думает делать дальше для решения этой проблемы. Было две вещи, которые, по её мнению, действительно решат эту проблему: ежемесячный хакатон, который будет источником идей для новых продуктов, и регулярная питч-сессия, на которой сотрудники со всей компании получат доступ к руководителям и поделятся своими идеями. Казалось, что оба пути — это отличные способы генерации новых идей. Но я попросил посмотреть идеи, которые уже были сформулированы. Их и так было в изобилии, многие казались вполне жизнеспособными и интересными. Было странно, что ни одна из них не продвинулась дальше. Решит ли эту проблему генерация ещё более хороших идей? У меня были подозрения.
Пытаясь глубже понять проблему, я ответил: «Хорошо, допустим, вы создаёте огромный конвейер новых идей для инноваций. Как будут приниматься решения об их реализации?» Это вызвало паузу у директора. Конечно, у команды исполнителей не существовало метода принятия решений, а даже если он и существовал, то директор о нём не знала. Затем я спросил: «Не кажется ли вам, что рискованно тратить всю эту энергию на генерацию идей, если мы не знаем, как будет принято решение?» Кивок в знак согласия означал, что мы должны решить проблему по-другому.

Что такое инновации?

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

Конгруэнтность стратегии

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

Как принимаются решения?

Во время разговора с директором мне вспомнилась речь, которую я слышал от одного бизнесмена. В решающий момент он повернулся к аудитории и сказал: «нам просто нужна одна или две замечательные идеи».
По моему опыту, у большинства компаний есть более чем достаточно отличных идей. Идеи — это не проблема, реальная проблема заключается в том, чтобы превратить эти идеи в опционы, а затем — в результаты на рынке.
Так почему же так трудно начать что-то инновационное? Инновация обычно имеет профиль риска, который выглядит совсем иначе в отличии от инициатив на рынке, с которым вы уже знакомы. Вам может быть трудно определить размер выигрыша, это может уничтожить существующие предложения, или вам может потребоваться создать новые возможности. Это большой риск с неопределенным выигрышем. С другой стороны, улучшения на существующем рынке имеют гораздо меньше абстрактных рисков и поэтому способствуют принятию более хороших решений. Конечно, во многих случаях они скрывают риск инвестирования в сокращающийся рынок.
Мои вопросы к директору состояли в том, чтобы понять, где инновации вписываются в заявленную стратегию организации и могут ли они быть реализованы в рамках существующего процесса принятия решений. Возможно, организация была не в состоянии пойти на тот риск, который предлагала заявленная стратегия. Я дал совет, что возможно лучше потратить время на понимание этой мысли, чем на разработку ещё большего количества идей.

Визуализация измерения рисков

Итак, как мы можем построить основание, которое поможет нам принимать решения, соответствующие нашей стратегии? Один из подходов состоит в том, чтобы попытаться сформулировать бизнес-стратегию в форме измерений рисков, которыми бизнес должен управлять. Я предложил директору рассмотреть две категории рисков и определить некоторые моменты по ним.
Упорядоченные риски — некоторые размеры рисков могут иметь порядок. Например, на шкале размера риска при определении «Целевой Аудитории» ваша стратегия может установить предпочтение «миллениалам из центра города» над «пенсионерами с фиксированным доходом». Сделав эти риски явными, мы теперь можем противопоставить им любую инициативу. Инициативы, которые находятся выше по шкале, желательно начинать раньше, чем те, которые находятся ниже по шкале. Таким образом, упорядоченные риски позволяют нам определить, начнём ли мы что-то раньше или позже.
Номинальные риски — некоторые измерения рисков могут быть связаны с достижением баланса. Порядок не обязательно важен, но суть заключается в достижении подходящего размещения для вашей бизнес-стратегии. Возвращаясь к примеру с инновациями, можно сказать, что устоявшаяся организация может не захотеть направлять все свои ресурсы на новые рынки, но может захотеть иметь некоторый объем размещений. Номинальные риски связаны с достижением правильного баланса портфеля.
Каждая организация должна определить свои собственные измерения стратегических рисков. Когда будет ясно, каков их размер, организация сможет принимать хорошие и своевременные решения, согласованные со стратегией. Это также позволяет принимать децентрализованные решения, поскольку вся организация имеет общий набор критериев для их принятия. Вы можете нарисовать несколько измерений рисков в виде диаграммы Кивиата и разместить свои возможности в этих координатах.
Делая это, вы достигаете двух важных вещей: чётко формулируете свои критерии, что позволяет проверять их, оспаривать и улучшать. Их визуализация позволяет быстро сортировать и фильтровать информацию для поддержки принятия решений.
Обычно это приводит к трем возможным результатам:
  • улучшенные и быстрые решения
  • корректировка модели, если она не точно отражает стратегию
  • или корректировка заявленной стратегии, поскольку она не соответствует фактической терпимости организации к риску.
Этот подход ответил на несколько вопросов директора, которого я консультировал: должен ли я продолжать инвестировать время в разработку идей, которые могут привести к вариантам инноваций? И если да, то как я могу преобразовать идеи в варианты, которые соответствуют терпимости к риску организации? Ответ на этот вопрос — ключ к открытию канала поставки инновационных возможностей.

Инновации — это результат того, как вы принимаете решения

Я не хочу, чтобы вы усвоили из этой статьи то, что вам не нужны хорошие идеи для инноваций. Просто высока вероятность, что идеи у вас уже есть. Для того чтобы внедрять инновации, вам нужно убедиться, действительно ли открытие вашей организации для новых рынков это часть вашей стратегии. И если это так, вам нужно будет найти путь для внедрения инноваций, а это начинается с того, как принимаются решения.
]]> Достоинства метода «5 Почему». Часть 3 http://neogenda.ru/blog/gsanz9t7i1-dostoinstva-metoda-5-pochemu-chast-3 http://neogenda.ru/blog/gsanz9t7i1-dostoinstva-metoda-5-pochemu-chast-3?amp=true Tue, 16 Apr 2024 18:13:00 +0300 Артур Нек Оригинал статьи Автор: Alan J Card Читайте первую и вторую части статьи. Простота Простота — сложное достоинство, когда речь идет...

Достоинства метода «5 Почему». Часть 3

Оригинал статьи
Автор: Alan J Card
Читайте первую и вторую части статьи.

Простота

Простота — сложное достоинство, когда речь идет о фреймворках, инструментах и методах QI. Например, концептуальная простота структуры планирование-действие-проверка-корректировка (PDSA) является одним из её основных преимуществ. Но с другой стороны, она может привести к недооцениванию организациями беспорядочной работы, которая связана с применением PDSA к реальным проблемам.
Но, как показано в этой статье, подход «5 Почему» явно вышел за рамки нормы: он не простой, а упрощенный. Это, как описывает Левесон, «…возможно, самый упрощенный [метод анализа аварий] и… приводит к наименьшему количеству извлечённых уроков из событий».
Чарльз Винсент, как известно, призвал RCA служить «окном в систему». Если это цель, то «5 Почему» обречены на провал, ведь метод намеренно отбрасывает подавляющее большинство того, что можно было узнать о запрашиваемой системе.
Реальность большинства медицинских процессов и систем такова, что мы сталкиваемся с классическими проблемами проектирования: проблемами, которые сильно зависят от контекста и часто «плохо определены, плохо структурированы или «порочны». Анализ «5 Почему» это игнорирует. Большинство причинных путей, которые привели к событию, ампутируются с самого начала, а рассмотрение оставшихся ограничивается единственной основной причиной.
Реальность большинства медицинских процессов и систем такова, что мы сталкиваемся с классическими проблемами проектирования: проблемами, которые сильно зависят от контекста и часто «плохо определены, плохо структурированы или «порочны». Анализ «5 Почему» это игнорирует. Большинство причинных путей, которые привели к событию, ампутируются с самого начала, а рассмотрение оставшихся ограничивается единственной основной причиной.

Происхождение

Положительная репутация TPS / Lean создаёт ауру доверия к методу «5 Почему». Но насколько это применимо к рассматриваемому вопросу? Репутация TPS / Lean создавалась в совершенно другом контексте. И использование «5 Почему» в качестве инструмента RCA отнюдь не то же самое, что использование полной методологии TPS / Lean.
Организации здравоохранения — это не автомобильные заводы. И хотя можно многому научиться у автомобильной промышленности и других высоконадёжных организаций (High Reliability Organizations, HROs), медицинские услуги никогда не будут по-настоящему сопоставимы с производством автомобилей. Несмотря на усилия, предпринимаемые в сфере здравоохранения по внедрению принципов HROs, нынешняя практика предоставляет рекомендованную помощь только примерно в 70% случаев. И процент пациентов, у которых возникло нежелательное событие может достигать 25−33%.
HROs обычно нацелены на уровень надёжности «Шесть Сигм» (три ошибки на миллион возможностей). С помощью этих мер здравоохранение изо всех сил пытается выйти за пределы двух сигм (308 500 ошибок на миллион возможностей, или 30,85% ошибок).
Надёжность в сфере здравоохранения может стать лучше, и она действительно улучшилась. Но здравоохранение гораздо сложнее, чем автомобильное производство, и происходит среди процессов и систем, которые недооцениваются по сравнению с современным заводом. Кроме того, рабочая сила в области безопасности и качества в здравоохранении только начинает двигаться в направлении профессионализации и зачастую не имеет формальной подготовки в области инженерии, человеческого фактора, эргономики или аналогичных областях.
В результате подходы, разработанные для решения проблем в области автомобилестроения, могут оказаться не столь эффективными в сфере здравоохранения. И действительно, доказательная база использования Lean/TPS в здравоохранении слаба и всё более негативна.
Также важно различать использование метода «5 Почему» в качестве метода QI и использование Lean/TPS в качестве QI-методологии. Хотя эти два понятия иногда смешиваются в литературе и практике, они ни в коем случае не равноценны. И использование «5 почему» в здравоохранении, как правило, не является частью полномасштабного подхода к бережливому управлению.
Если использование «5 Почему» не подразумевает принятия Lean, и если имеющиеся на сегодняшний день доказательства не подтверждают эффективность Lean в здравоохранении в любом случае, нет никаких оснований поддаваться аргументу происхождения.

Использование «5 Почему» подрывает и без того слабый процесс RCA

В недавней статье Пиралли и др. описывается ряд важных недостатков в практике RCA в здравоохранении. Некоторые из них были рассмотрены выше, например, сосредоточение внимания на одной основной причине или небольшой группе из них; и низкое качество расследования. Но это также поднимает ряд других проблем, таких как неправильное использование процесса RCA для достижения (или избегания) других повесток дня; неспособность поддерживать петли обратной связи и двойную петлю обучения; ориентация на отдельные и изолированные инциденты; запутанный подход к виноватым; «проблема семи нянек» и недостатки ретроспективного подхода.
Авторы также отмечают, что RCA часто приводит к плохо спроектированным и/или плохо реализованным средствам управления рисками. В то время как цель извлечения уроков из инцидентов — снизить риск и предотвратить будущий вред, фактические инструменты и методы текущей практики сосредоточены исключительно на диагностике проблем; они не обеспечивают прямой поддержки для назначения и лечения выявленных патологий организации.
Некоторые организации приняли подход PDSA к постоянному совершенствованию своих планов действий по контролю рисков. Но это структура высокого уровня, сродни научному методу. И, как и научный метод, он должен быть реализован с помощью соответствующего набора инструментов и методов для получения надежных результатов. Хотя в последние годы было введено несколько таких инструментов, но они ещё не приняты в качестве действующих стандартов. Возможно, в результате этого существует так мало доказательств того, что нынешняя практика RCA улучшает исходы.
Эти проблемы не означают, что RCA не имеет смысла; он безусловно, может быть источником важных знаний и улучшений. Но это означает, что мы не можем позволить себе усугублять эти проблемы с помощью инструмента RCA, который так глубоко и фундаментально ошибочен. Вместо этого следует рассмотреть другие, более ориентированные на системы методы, такие как Метод Fishbone или диаграммы Lovebug, древовидные диаграммы, причинно-следственный анализ, основанный на теории систем (CAST) или даже подходы к перспективной оценке риска.

Заключение

При осторожном использовании метода «5 Почему» он может сыграть важную роль в обучении. Он может проиллюстрировать, как потребность в глубине (как положительный пример), так и потребность в широте (как отрицательный пример) при анализе сложных проблем.
Однако в качестве инструмента для проведения RCA, особенно в области безопасности пациентов, следует отказаться от использования данного метода. Как гласит (апокрифическая) цитата: «На каждую сложную проблему есть ответ, ясный, простой и неправильный». Когда дело доходит до расследования несчастного случая, то метод «5 Почему» — это тот самый неправильный ответ.
]]> Проблема метода «5 Почему» в анализе коренных причин RCA. Часть 2 http://neogenda.ru/blog/6c3zjyloi1-problema-metoda-5-pochemu-v-analize-kore http://neogenda.ru/blog/6c3zjyloi1-problema-metoda-5-pochemu-v-analize-kore?amp=true Fri, 19 Apr 2024 18:15:00 +0300 Артур Нек Оригинал статьи Автор: Alan J Card Первую часть статьи читайте здесь. «5 Почему» было предметом критики....

Проблема метода «5 Почему» в анализе коренных причин RCA. Часть 2

Оригинал статьи
Автор: Alan J Card
Первую часть статьи читайте здесь.
«5 Почему» было предметом критики. Например, Миноура, один из преемников Тайити Óно в Toyota, подчёркивал, что при разработке ответов, пользователи могут полагаться на выводы без подготовки, вместо ситуативного наблюдения при генерации ответов. А также сказывается сложность выявления приоритетов причин, если используется сразу несколько «5 Почему».
Марк Грабан — идейный лидер в сообществе Lean, отмечает, что «5 Почему» — это лишь один из компонентов комплексного процесса решения проблем. Оливер Серрат поясняет, что пользователи не должны чувствовать себя ограниченными произвольным числом в название инструмента: может потребоваться больше или меньше пяти «почему».
Но настоящая проблема с методом заключается не в том, как он используется в RCA, а в том, что он настолько упрощает процесс исследования проблемы, что его не следует использовать вообще. Он вынуждает пользователей идти по единственному аналитическому пути для любой проблемы. А также настаивает на единственной основной причине в качестве цели для решений, и предполагает, что наиболее отдалённое звено на причинном пути (пятое «почему») — самое эффективное и действенное место для вмешательства.

Единственный причинный путь

Правдоподобный подход «5 Почему» на примере неправильного лечения пациента может выглядеть следующим образом:
Инцидент: Пациент принял неправильные лекарства.
Почему? Браслет не проверен (имеется в виду медицинский браслет пациента с информацией о нём).
Почему? Браслет отсутствует.
Почему? Принтер сломался на печати данного браслета.
Почему? Этикетку зажевало принтером.
Почему? Плохой дизайн этикетки.
Но другая команда могла бы легко придумать пять совершенно разных и одинаково обоснованных «почему». И любая отдельная цепочка «5 почему» может дать только ограниченное представление о сложном причинно-следственном пути, который привёл к инциденту. Это проиллюстрировано на рисунке 1. Это древовидная диаграмма причинно-следственных связей (или, точнее, «древовидная диаграмма причинно-следственных и сопутствующих факторов»), на которой показаны основные проблемы, которые привели к нежелательному явлению.
Из диаграммы видно, что причинный путь, связанный с принтером этикеток, не является ни единственной причиной инцидента, ни бесспорно самой важной причиной. Серьёзные усилия по решению бесчисленного множества проблем, которые привели к этому инциденту, должны были бы затронуть и ряд других причинно-следственных связей.
Они могут включать в себя пути, связанные с организацией рабочего места, подбором медицинского и IT-персонала, отсутствием принудительной идентификации пациентов до введения лекарств. Также туда мог бы входить фокус на инфекционном контроле и повышении готовности к вспышкам инфекционных заболеваний. Решения, основанные на «5 Почему» в приведённом выше примере, оставят все эти вопросы без внимания.
Кроме того, поскольку нет объективного или надёжного способа построить всю карту причинных путей, то исследование только одного пути является критическим недостатком. Рассмотрим вариант ниже, который следует по существу тем же причинным рассуждениям, что и первый пример:
Инцидент: Пациент принял неправильные лекарства.
Почему? У него не было специального браслета.
Почему? Принтер, который печатал браслет сломался.
Почему? Система здравоохранения приобрела ненадёжный принтер.
Почему? Плохой процесс оценки и покупки «неклинического» оборудования.
Почему? Оборудование, которое считается «неклиническим», не считается критически важным для безопасности.
В этой версии пропущен шаг с вопросом, почему браслет не был проверен, и сразу переходит к вопросу, почему его там нет. Он также касается общей проблемы поломки принтера, не вдаваясь в подробности о том, что этикетка от браслета застряла. «Пропуск» этих вопросов позволяет углубить анализ, поскольку оставляет больше «почему» доступными. В этом примере также делается акцент на проблемах внутри организации, а не на конструкции принтера. Это привело бы к очень разным решениям.
Так как этот подход пропускает вопрос о том, почему браслет не проверили, то здесь уже нельзя задать вопросы о причинах отсутствия проверки. На рис. 1 это будет включать отсутствие функции принуждения. Но в другом сценарии это может включать:
  • нежелание будить пациента;
  • нечитаемый браслет (например, смазанный шрифт, помятая этикетка и т. д.);
  • отсутствие этикетки на лекарстве;
  • путаница, вызванная несколькими браслетами;
  • отсутствие доверия к данным браслета из-за частых ошибок
  • или по любой из ряда других.
Пользователи также могут пойти по совершенно другому пути. Не менее разумные «5 Почему» для этого инцидента могут выглядеть так:
Инцидент: Пациент принял неправильные лекарства.
Почему? В одной палате находились пациенты с похожими именами.
Почему? Нет возможности распределять пациентов по разным палатам.
Почему? Недостаточно медсестер, чтобы справиться с наплывом пациентов.
Почему? Медсестры пострадали от вспышки вируса.
Почему? Плохое соблюдение трудоёмких мер инфекционного контроля.
Почему? Процветание культуры «просто делай свою работу».
Есть много условно «правильных» способов, которыми команда может использовать «5 Почему», чтобы оценить даже этот единственный инцидент. И маловероятно, что две команды независимо друг от друга могли бы достичь абсолютно одинаковых результатов. Эта субъективность критически важна, потому что «5 Почему» фокусируются только на одной первопричине в конце одного причинного пути.
Более изощренная практика использования метода «5 Почему» может привести к двум причинным путям и сосредоточить внимание на обнаруженных основных сбоях в обслуживании, а не на самом событии. Но в отрасли здравоохранения этому инструменту обычно учат не так. И даже этот необычайно тщательный подход выявит только 2 из 30 причинно-следственных связей, показанных на древовидной диаграмме.

Единственная основная причина

Принуждение пользователей к использованию единственной причинно-следственной связи само по себе должно приводить к дисквалификации. Но метод ещё больше сужает возможности для улучшений, ведь он настаивает на том, что усилия по контролю риска должны быть сосредоточены на единственной основной причине для каждого причинного пути. Например, в первом примере со здравоохранением, приведённом выше, первопричиной может быть «плохой дизайн продукта», и он будет служить единственной целью для усилий по улучшению.
Но несчастные случаи редко являются результатом единственной первопричины. Поэтому сосредоточение внимания исключительно на одной (или даже нескольких) произвольно определённых «первопричинах» — ненадёжный метод улучшения, особенно в такой сложной системе, как здравоохранение. Как писали Томас и Эрик Виман: «К сожалению… ограничение количества [рассматриваемых] переменных в сложной системе приводит только к увеличению вероятности ошибок упущения».
Что можно пропустить при использовании метода «5 Почему»? Древовидная диаграмма для нашего примера раскрывает более 75 причин и способствующих факторов, каждая из которых является потенциальной целью для действий по снижению риска повторения. Подход «5 Почему» позволит определить только одну (или, возможно, две) первопричины в качестве цели для действий. В лучшем случае это составляет менее 3% возможностей для улучшения, определённых с помощью древовидной диаграммы.

Ориентация только на самую отдалённую причину

Те, кто использует «5 Почему» не только ограничены одной основной причиной для каждого каузального пути, но и выбором только самой отдалённой причины (обычно пятого по счёту «почему»). Однако нет никаких логических оснований полагать, что это всегда самая эффективная или наиболее действенная цель для вмешательства.
На самом деле, если можно бы было волшебным образом разместить 100% эффективный контроль риска в любой точке древовидной диаграммы, его лучше всего использовать на ближайшей причине. Например, если сделать невозможным введение лекарств без проверки браслета, это сделает все более отдалённые причины спорными с целью предотвращения рецидива.
Конечно, 100% эффективный контроль рисков редко доступен. Но если в план действий по решению инцидента внести хорошо спроектированный считыватель штрих-кода с функцией принудительной идентификации пациента, то с большей вероятностью ошибка приёма неправильных лекарств будет предотвращена. Этот способ с большей вероятностью поможет в ситуации, нежели хороший принтер для браслетов.
Это не означает, что более отдалённые причины не являются подходящими целями для улучшений. В примере на рис. 1, очевидно, что существует глубокая необходимость изменить культуру с целенаправленной и порой враждебной, на культуру, ориентированную на результат и психологическую безопасность. Всепроникающее воздействие такого культурного изменения было бы гораздо более важным, чем просто снижение риска того, что этот конкретный инцидент может повториться. Это повлияет почти на все вопросы качества и безопасности в организации.
В отличие от этого мощного, но трудного рычага для изменения результатов, иногда более отдалённые причины лежат прямо под рукой, и с ними можно бороться, пока в разработке находится более близкое решение. На рис. 1 есть ответвление, которое было бы далеко не надёжным: разъяснение пациентам, почему врачи будут постоянно просить их называть свои ФИО. Но это было бы быстро, дёшево и легко. И это могло бы снизить важный барьер на пути к передовой практике вербальной идентификации.
Соответствующие цели для вмешательства могут возникать где угодно в причинном континууме и на любом причинном пути. А усилия по повышению безопасности и качества часто требуют более одного вмешательства, направленного на более чем одну основную опасность. Полезно идентифицировать все ключевые опасности, которые привели к инциденту, и гарантировать, что каждая из них либо устранена, либо намеренно принята. Но использование методики «5 Почему» делает это невозможным.
«5 Почему» было предметом критики. Например, Миноура, один из преемников Тайити Óно в Toyota, подчёркивал, что при разработке ответов, пользователи могут полагаться на выводы без подготовки, вместо ситуативного наблюдения при генерации ответов. А также сказывается сложность выявления приоритетов причин, если используется сразу несколько «5 Почему».
Марк Грабан — идейный лидер в сообществе Lean, отмечает, что «5 Почему» — это лишь один из компонентов комплексного процесса решения проблем. Оливер Серрат поясняет, что пользователи не должны чувствовать себя ограниченными произвольным числом в название инструмента: может потребоваться больше или меньше пяти «почему».
Но настоящая проблема с методом заключается не в том, как он используется в RCA, а в том, что он настолько упрощает процесс исследования проблемы, что его не следует использовать вообще. Он вынуждает пользователей идти по единственному аналитическому пути для любой проблемы. А также настаивает на единственной основной причине в качестве цели для решений, и предполагает, что наиболее отдалённое звено на причинном пути (пятое «почему») — самое эффективное и действенное место для вмешательства.
]]> Метод «5 Почему» как обучающий инструмент. Часть 1 http://neogenda.ru/blog/p228lu1a61-metod-5-pochemu-kak-obuchayuschii-instru http://neogenda.ru/blog/p228lu1a61-metod-5-pochemu-kak-obuchayuschii-instru?amp=true Sat, 20 Apr 2024 18:17:00 +0300 Артур Нек Оригинал статьи Автор: Alan J Card В сущности Метод «5 Почему» — один из наиболее...

Метод «5 Почему» как обучающий инструмент. Часть 1

Оригинал статьи
Автор: Alan J Card

В сущности

Метод «5 Почему» — один из наиболее популярных подходов к анализу коренных причин (Root Cause Analysis, RCA) в здравоохранении. Его использование поощряет ВОЗ, Национальная служба здравоохранения Англии, Институт улучшения здравоохранения, Объединённая комиссия и многие другие организации в области качества и безопасности здравоохранения. Однако, как и большинство таких инструментов, его популярность не доказывает эффективности метода. Вероятнее всего, что метод заслужил своё место в учебной программе и практике RCA, благодаря своей простоте, происхождению и педагогичности.

Что касается происхождения, то «5 Почему» уходит своими корнями в производственную систему Toyota (TPS). Ещё он играет ключевую роль в Lean (общая версия TPS) и Six Sigma — методологии, направленной на улучшение качества работы организации. Тайити Оно отводит методу «5 Почему» центральное место в методологии TPS:
«Основа научного подхода Toyota состоит в том, чтобы задавать вопрос «почему» 5 раз, когда мы обнаруживаем проблему… Если повторить «почему» 5 раз, становится ясна природа проблемы, а также её решение. Решение или инструкция обозначается как «1H». Таким образом, «5 Почему» равны одному «Как» (5W = 1H).».
Эта цитата также свидетельствует о простоте метода. Если спросить «почему» 5 раз, то использующие этот подход могут прийти к единственной основной причине, которая с самого начала могла бы быть неочевидной. Также это может вдохновить на поиск единого решения для устранения этой первопричины (хотя неясно, была ли принята сторона уравнения «1H» так же широко).

«5 Почему» как обучающий инструмент

Педагогический аргумент в пользу «5 Почему» заключается в том, что он создает вау-эффект. В итоге выявляется скрытое влияние отдалённой причины, а это демонстрирует важность более глубокого изучения причинно-следственных связей. Этот быстрый и лёгкий опыт обучения может стать мощным уроком в области безопасности систем и обеспечения качества.
Возможно, самый известный пример из практики «5 Почему», который можно использовать таким образом, сосредоточен на усилиях по сохранению памятника Вашингтону. Есть немного разные версии примера, но обычно это выглядит примерно так:
Проблема: Памятник Вашингтону приходит в упадок.
Почему? Для очистки памятника используются слишком жёсткие химические вещества.
Почему? Памятник покрыт голубиным помётом.
Почему? Голубей привлекает большое количество пауков у памятника.
Почему? Пауков привлекает большое количество мошек у памятника.
Почему? Мошкару привлекает тот факт, что памятник зажигают ночью.
Решение: включить освещение на 1 час позже.
Это отличный обучающий пример, потому что «первопричина» была настолько не интуитивно понятна. Кто бы мог подумать, прежде чем углублённо изучить вопрос, что выбор освещения может поставить под угрозу мраморный памятник? Но, как это часто бывает, реальность запутана больше, чем этот простой и наглядный пример.
Джоэл Гросс исследовал основу этого примера и обнаружил, что многие детали неверны. И, что весьма важно, более широкая история, которую он рассказывает, тоже является неполной.
С точки зрения исторических деталей, памятник, о котором идёт речь, на самом деле был мемориалом Линкольна. Он не был повреждён в результате использования агрессивных химикатов. Настоящим же виновником была просто вода. Голуби вообще не были проблемой, и хотя на мемориале были «крошечные пауки», они тоже не были большой проблемой. Вместо этого постоянная уборка была нужна, потому что стаи мошек, ослеплённые огнями, на большой скорости влетали в стены мемориала и оставляли после себя пятна.
Но это касается только тех деталей, которые были описаны. Анализ также является неполным по ряду более важных аспектов. Например, он касается только одного потенциального источника ухудшения качества — воды для очистки.
Первое «почему» могло быть легко связано с другими причинами, такими, как дождь или кислотный дождь (серьёзная проблема в то время), повышение влажности, эрозия от переносимых ветром частиц или ущерб от циклов замораживания-оттаивания. А если бы целью было предотвратить вред будущим памятникам, первое «почему» могло бы быть сосредоточено на использовании мрамора в качестве строительного материала, выборе строительной площадки и т. д.
Но самая важная проблема с этим примером заключается в том, что, хотя решение было «эффективным» в каком-то смысле, оно всё же потерпело неудачу:
«Мессерсмит — консультант-энтомолог, работавший над этим проектом — полагал, что, поскольку насекомые роятся только на закате, задержка включения света на 1 час решит проблему. Это сработало, уменьшив количество мошек на памятниках примерно на 85 процентов».
Но туристы, которые проехали сотни миль, чтобы сфотографироваться у монумента, были недовольны», — сказал он. Они жаловались каждый день, и свет снова включили».
Логика решения была разумной. Но она была основана на неполном понимании более широкой системы, её участников и цели самого памятника. Во всяком случае, это окно, посвящённое сложности решения реальных проблем, добавляет ценности этому обучающему примеру. Если за первым вау-эффектом последует второй, слушатели не только узнают, что отдалённые причины могут иметь неожиданные последствия, но и что системное мышление требует, как глубины, так и широты анализа.
Продолжение читайте в следующем материале «Проблема «5 Почему» в анализе коренных причин RCA».
]]> Кластеризация блокеров http://neogenda.ru/blog/hb8jed7gy1-klasterizatsiya-blokerov http://neogenda.ru/blog/hb8jed7gy1-klasterizatsiya-blokerov?amp=true Sun, 21 Apr 2024 18:18:00 +0300 Артур Нек Перевод статьи, опубликованной на https://kanbanize.com Оригинал статьи Это относительно новый метод выявления идентичных блокеров в вашем...

Кластеризация блокеров

Перевод статьи, опубликованной на https://kanbanize.com
Оригинал статьи
Это относительно новый метод выявления идентичных блокеров в вашем рабочем процессе и эффективный способ для улучшения рабочего процесса.
5 принципов бережливого управления позволяют определять ценность, организовывать непрерывный рабочий процесс и выявлять ненужные действия. С их помощью вы можете создать бережливый рабочий процесс и легко обнаруживать и устранять проблемы.
Однако, единожды избавиться от проблемы недостаточно. Вам нужно найти её причину, чтобы защитить ваш рабочий процесс от повторяющихся происшествий.
Среди наиболее распространенных причин повторяющихся проблем — блокеры, т. е. вещи, которые мешают команде выполнить определенную задачу. Но часто, когда блокер преодолён, команда просто продолжает работать над задачей, и причина блокера вскоре забывается, пока он не появится снова.
Чем чаще появляется блокер, тем бОльшее влияние он оказывает на среднее время цикла. Поэтому лучше собирать блокеры со всеми возможными деталями и анализировать их.
Есть относительно новая методика, разработанная доктором Клаусом Леопольдом (автором книги «Практический канбан»), которая касается именно этой темы. Она называется кластеризацией блокеров. Давайте изучим её.

Техника кластеризации блокеров

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

Сгруппируйте блокеры

Первое, что вам нужно сделать после того, как вы собрали определенное количество блокеров, — это разделить их на 2 основные группы:
  • внешние
  • внутренние
Очень важно рассчитать общее время блокировки для каждой сформированной вами группы, чтобы вы могли расставить приоритеты. Общее время блокировки — это метрика, с помощью которой можно определить, какие типы блокеров являются наиболее критичными.
После того, как вы разделили блокеры по внешним и внутренним факторам, вам нужно сформировать более мелкие группы. Они должны состоять из блокеров с одинаковыми отличительными признаками.
Например, отсутствующая информация, ожидание проверки, ожидание тестирования и т. д. После этого вам необходимо рассчитать общее время блокировки для каждой подгруппы, чтобы вы могли определить приоритет блокеров.
Когда вы выявили наиболее вредные блокеры, пора определить первопричину каждого из них и найти решения. Вы можете применять различные методы анализа первопричин, например, «5 почему».
Этот метод позволит вам обнаружить настоящую причину проблемы, задавая последовательные вопросы «почему» столько раз, сколько необходимо.
командой для поиска решения. Обязательно проинформируйте все заинтересованные стороны, когда у вас будет готово решение.
Таким образом, вы сможете предотвратить повторение блокеров в рабочем процессе или, по крайней мере, значительно сократить время блокировки.
Также важно поэкспериментировать с различными решениями, если это необходимо. Иногда первое решение, которое вы применяете, может не работать должным образом. Так что будьте готовы проверять различные идеи, пока не найдете оптимальную. В конце концов, минимизация негативного воздействия блокеров поможет вам устранить узкие места в вашем рабочем процессе.

Структура блокеров

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

В итоге

Кластеризация блокеров — это простой и эффективный метод, который поможет вам:
  • Определить эффективные блокеры в своём рабочем процессе.
  • Устранить повторяющиеся блокеры или сократить время блокировки.
  • Увеличить производительность и уменьшить среднее время цикла.
]]> Накопительная диаграмма потока: как управлять большим количеством задач и отслеживать прогресс http://neogenda.ru/blog/kydje50s61-nakopitelnaya-diagramma-potoka-kak-uprav http://neogenda.ru/blog/kydje50s61-nakopitelnaya-diagramma-potoka-kak-uprav?amp=true Mon, 22 Apr 2024 18:21:00 +0300 Артур Нек Перевод статьи, опубликованной на https://kanbanize.com Оригинал статьи Когда нужно визуализировать и оптимизировать работу в управлении проектами...

Накопительная диаграмма потока: как управлять большим количеством задач и отслеживать прогресс

Перевод статьи, опубликованной на https://kanbanize.com
Оригинал статьи
Когда нужно визуализировать и оптимизировать работу в управлении проектами и разработке программного обеспечения, диаграммы играют ключевую роль. Популярные инструменты, такие как канбан-доска и Swimlane-диаграмма, помогают командам эффективно распределять задачи и отслеживать прогресс. Однако, для более глубокого анализа производительности, особенно если в проекте фиксированный бюджет и ограниченные ресурсы, нередко используется накопительная диаграмма потока (Cumulative Flow Diagram, CFD).
Этот инструмент позволяет увидеть как задачи перемещаются через различные стадии процесса. Помогает команде лучше управлять нагрузкой, предотвращать увеличение времени поставки и избегать возможных блокировок. Расскажем как именно накопительная диаграмма потоков помогает оптимизировать рабочие процессы и что следует учитывать, когда решите ее использовать.
А чтобы внедрить передовые методы стратегического управления в свой бизнес, обратитесь в консалтинговую компанию Neogenda. Нам доверяют Сбер, Яндекс, Точка, X5 Group и другие компании. Обучаем сотрудников, проводим реорганизацию и предлагаем еще более 100 услуг. Бизнес, который работает на результат, начинается с бесплатной консультации от специалистов Neogenda.

Что такое накопительная диаграмма потока

Накопительная диаграмма потока (от англ. Cumulative Flow Diagram, CFD) — одна из самых продвинутых диаграмм Канбан и Agile-аналитики. График потока помогает наглядно увидеть три наиболее
  • важных показателя ваших проектов:
  • время цикла;
  • пропускную способность;
  • работу в процессе.
Основная цель диаграммы — показать общее количество задач в разных статусах, темп выполнения работы, стабильность потока. И помочь понять, на чем нужно сосредоточиться, чтобы процесс стал более предсказуемым. Она дает количественное и качественное представление о прошлых и существующих проблемах и помогает визуализировать огромные объемы данных.

Как читать накопительную диаграмму потока

Нужно увидеть, какие задачи в разработке и сколько выполнено работы? Эту информацию можно найти на изображении диаграммы потоков, — она показывает как задачи меняют состояние в зависимости от стадии рабочего процесса. Обычно задачи проходят через следующие этапы: «Запланировано», «В работе», «Готово к тестированию», «Тестирование» и «Завершено».
Стадия «Готово к тестированию» играет важную роль. Она обозначает завершение разработки и подготовку задачи к следующему шагу — проверке качества. Этот этап помогает команде отслеживать, сколько задач ожидают тестирования и предотвращает накопление задач, которые могут замедлить общий процесс.
Горизонтальная ось Х — это ось времени. Показывает временной интервал, например, спринт, для которого график отображает данные. Вертикальная ось Y показывает различные статусы совокупного количества задач в рабочем процессе.
Разноцветные полосы, которые разделяют участки восходящего потока — это разные этапы вашего рабочего процесса в том виде, в котором они отображаются на канбан-доске. Полосы всегда идут вверх или в сторону параллельно оси X —в зависимости от количества заданий, которые вы выполняете.
Верхняя граница каждой полосы на накопительной диаграмме потока — это точка входа для задач на соответствующем этапе. Нижняя граница показывает в какой момент эти задачи переходят дальше.
Если линия становится горизонтальной, значит на соответствующую стадию ничего не приходит или ничего не выходит из нее.
С помощью CFD можно понять сколько длятся циклы задач. Для этого нужно измерить расстояние по горизонтали между верхней границей первой стадии на диаграмме потока и нижней границей последней стадии «Завершено». Количество прошедших дней, недель, спринтов — это приблизительное среднее время такого цикла.
Расстояние между линиями накопительной диаграммы потока покажет проблемы вашего рабочего процесса.

Как понимать данные на диаграмме

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

Полосы развиваются параллельно

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

Какие преимущества у Flow Diagram

Кумулятивная диаграмма — мощный инструмент, благодаря ему можно визуализировать работу в процессе и анализировать состояние потока задач в Agile. Вот ее основные преимущества:
  • Полная прозрачность процесса. CFD позволяет видеть все этапы работы и количество задач на каждом из них. Это дает возможность команде и заинтересованным сторонам легко отслеживать текущую загруженность, находить проблемные места и контролировать выполнение задач в реальном времени.
  • Предсказуемость и планирование. Диаграмма показывает, как задачи перемещаются через этапы работы. Анализ графика помогает предсказывать когда получится выполнить задачи и оценивать скорость работы команды. Это упрощает планирование и позволяет не строить иллюзий по поводу сроков.
  • Идентификация узких мест. Накопительная диаграмма потока наглядно показывает, на каких этапах происходит рост количества задач. Это позволяет быстро находить проблемы с производительностью или задержками в процессе.
  • Мониторинг производительности команды. CFD позволяет измерять ключевые показатели эффективности (KPI) команды, такие как время выполнения задачи (Lead Time) и пропускную способность (Throughput). Это помогает руководителям и команде оценить динамику работы и понять за счет чего можно улучшить процессы.
  • Адаптивность к изменениям. Диаграмма позволяет оперативно оценивать эффект от изменений в процессе. Если команда внедрила новые практики или изменила приоритеты задач, CFD покажет как это влияет на скорость и качество работы.
  • Улучшение коммуникации. Визуализация данных с помощью накопительной диаграммы потока делает сложные процессы более понятными для всех участников проекта. Информация становится доступнее даже для тех, кто не погружен в детали разработки. Благодаря этому взаимодействие с клиентом становится лучше, а участникам команды проще понимать друг друга.
Таким образом, накопительная диаграмма потока помогает не только следить за тем, как выполняются задачи, но и повышать эффективность команды, процессов и планирования.

Какие ограничения есть у накопительной диаграммы потока

Кроме преимуществ у CFD есть и ограничения, о которых нельзя забывать при работе с ней:
  • Недостаточная детализация причин блокировок. Хотя диаграмма позволяет увидеть задержки и области где процесс тормозится, она не дает подробной информации о причинах этих блокировок. Чтобы найти источники проблем и способы их решения, нужны дополнительные аналитические инструменты или процессы, например, ретроспективы или более детализированные отчеты.
  • Неэффективна без качественных данных. CFD отражает реальную картину только когда команда своевременно и правильно обновляет задачи в системе трекинга. Если этого не делать, данные на диаграмме будут искажены и тогда становится сложнее сделать верные выводы о текущем статусе проекта.
  • Не отображает взаимозависимости задач. Диаграмма фокусируется на общем прогрессе и изменениях в статусе задач, однако она не отображает взаимосвязи между ними. Это может создать иллюзию, что задачи движутся независимо друг от друга. На самом деле все не так, — некоторые задачи могут блокировать выполнение других.
  • Ограниченная способность прогнозирования. CFD помогает визуализировать текущее состояние проекта, но ее возможности прогнозирования ограничены. Например, диаграмма может показать, что темпы завершения задач замедляются, но она не позволяет точно предсказать когда именно завершится проект.
  • Отсутствие контекста для количественных изменений. Накопительный график четко фиксирует изменения в количестве задач на разных стадиях, но он не предоставляет контекст. Если, например, количество выполненных задач резко увеличилось, это может быть результатом новых требований, сбоя в распределении ресурсов или других факторов, которые диаграмма не отражает напрямую.
  • Сложности при использовании на крупных проектах. Для больших проектов с множеством задач накопительная диаграмма может стать перегруженной и сложной для восприятия. В таких случаях визуализация не всегда дает четкое понимание хода работы. Команде придется делить диаграмму на отдельные компоненты или использовать дополнительные инструменты.
Эти ограничения делают накопительную диаграмму потока полезной лишь при условии, что ее будут правильно применять и комбинировать с другими аналитическими методами. Когда команда понимает сильные и слабые стороны инструмента, она способна лучше настраивать процессы и вовремя корректировать работу.

Какие ошибки может допускать команда, которая использует накопительную диаграмму

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

Ошибка 1

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

Ошибка 2

Команда не ввела ограничения на количество задач. Участники могут неправильно интерпретировать диаграмму, если нет никаких ограничений на количество задач в работе. В этом случае задачи копятся на этапе выполнения и диаграмма «раздувается». Но это не помогает выявить проблемы с производительностью команды.
Пример. Команда одновременно начала 20 задач, но из-за перегрузки ни одну из них не завершила в течение спринта. На диаграмме заметен быстрый рост количества задач на этапе «В работе», поэтому появляется ложное впечатление активности, тогда как в реальности эффективность команды страдает.
Как исправить. Ввести четкое ограничение на WIP. Необходимо установить максимальное количество задач, которые команда может выполнять одновременно. Это позволит контролировать нагрузку и поддерживать производительность на уровне. CFD должна показывать стабильное движение задач через этапы, а не их бесконечное накопление.

Ошибка 3

Команда игнорирует проблемные места в процессе. Неправильный анализ диаграммы может привести к тому, что узкие места останутся незамеченными. Это происходит, когда руководители не обращают внимания на то, что ширина полос на графике резко меняется. А это означает, что задачи копятся на каком-то определенном этапе.
Пример. В команде разработки со временем значительно увеличилось количество задач на этапе «Тестирование». Однако, диаграмму не анализировали внимательно. В итоге проект начал задерживаться, так как задачи не могли перейти на этап «Завершено», пока не закончится тестирование.
Как исправить. Постоянно следить за шириной полос на диаграмме. Если на одном из этапов накапливаются задачи, нужно понять почему это происходит. Например, можно перераспределить ресурсы, добавить людей на проблемный этап или пересмотреть процесс работы.

Ошибка 4

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

Ошибка 5

Команда не учитывает срочные или внеплановые задачи. Они, как правило, возникают внезапно и требуют немедленного внимания. Если такие задачи не попадают в Cumulative Flow Diagram, это искажает реальную картину работы команды и может создать иллюзию, что процессы идут медленнее.
Пример. В течение недели команда срочно исправляла ошибки, но не добавляла эти задачи на канбан-доску. На диаграмме потока это выглядело как остановка работы, хотя фактически производительность была на высоком уровне, просто ее не фиксировали.
Как исправить. Любые внеплановые задачи нужно добавлять в систему и отображать на графике. Это позволяет руководителям получать полную картину того, как распределяются ресурсы и время команды, и не думать напрасно, что производительность падает.
Накопительная диаграмма потока — одна из самых передовых аналитических схем в Agile-управлении проектами.
CFD позволяет получить краткую визуализацию метрик потока, показывает стабильность процессов, помогает понять, на чем нужно сосредоточиться, чтобы сделать работу более предсказуемой. Все это требует грамотных методов управления. Чтобы внедрить их в свой бизнес, обратитесь за бесплатной консультацией в Neogenda.
]]> Мультимодальные данные. Разговор с Алексеем Жегловым http://neogenda.ru/blog/s51v838z91-multimodalnie-dannie-razgovor-s-alekseem http://neogenda.ru/blog/s51v838z91-multimodalnie-dannie-razgovor-s-alekseem?amp=true Tue, 23 Apr 2024 18:34:00 +0300 Артур Нек Одной из сильных сторон Канбан Метода считается статистика потока работ. На стриме с Алексеем Жегловым...

Мультимодальные данные. Разговор с Алексеем Жегловым

Одной из сильных сторон Канбан Метода считается статистика потока работ. На стриме с Алексеем Жегловым мы поговорим про одну из главных метрик — «Время производства». Как эту метрику можно отслеживать и трактовать на спектральной диаграмме. Что такое моды и почему они важны для управленческих решений. Как можно понять с чем связан тот или иной всплеск на графике.

Алексей Жеглов – один из лидеров мирового Канбан-сообщества, основатель Lean A-to-Z, партнёр Squirrel North. Специализируется на Канбан Методе и планировании корпоративных сервисов (ESP). Свою карьеру он начал в 90-х годах в качестве инженера-программиста и хорошо знаком с проблемами компаний, связанных с поставкой в профессиональных сервисах и продуктах.

Алексей внёс большой вклад в развитие Канбана и ESP, в области метрик и прогнозирования, создания Fit-for-Purpose. Также он является соавтором книги Дэвида Андерсона «Соответствие предназначению: как передовые компании находят, удерживают и удовлетворяют потребности клиентов», а ещё одна книга сейчас находится в разработке!

За долгое время работы советником коучинговой программы Lean Kanban University (LKU), Алексей Жеглов подготовил множество менеджеров и лидеров. Сейчас он преподаёт все классы учебной программы Канбан, включая Канбан – альтернативный путь к бизнес-гибкости, ESP, KCP и Train-the-Trainer.
]]> Из чего состоит Канбан Метод? http://neogenda.ru/blog/0plxgujud1-iz-chego-sostoit-kanban-metod http://neogenda.ru/blog/0plxgujud1-iz-chego-sostoit-kanban-metod?amp=true Wed, 24 Apr 2024 19:03:00 +0300 Артур Нек Вокруг терминологии и самого метода Канбан существует недопонимание – кто-то говорит, что это...

Из чего состоит Канбан Метод?

Вокруг терминологии и самого метода Канбан существует недопонимание – кто-то говорит, что это Agile, а кто-то, что это метод только для IT. Будем разбираться, начнём с самого начала – истории.
Вокруг терминологии и самого метода Канбан существует недопонимание – кто-то говорит, что это Agile, а кто-то, что это метод только для IT. Будем разбираться, начнём с самого начала – истории.
Само слово Канбан тоже может запутать, ведь есть два значения этого слова, имеющие похожие, но всё же разные смыслы. С канджи, китайских иероглифов, используемых в японском языке – 看板 (канбан) – большая визуальная доска, а по японской языковой азбуке харагане カンバン (канбан) – сигнальная карта. Самым первым «канбаном»называли вывеску-щит над баром, который показывал что заведение, было открыто и ждало гостей. Это было приглашение и сигнал людям. Далее это понятие трансформировалось, не без участия компании Тайота, которая популяризировала это слово. В итоге Канбан стал означать «сигнал».
Производственный канбан – понятие, которое вышло как раз из компании Тойота. Канбан здесь рассматривался как система сигнализации о том, что необходимо выполнить какую-то работу на предыдущем этапе. Для этого были заведены специальные карточки, которые и называли канбан. Таким образом, компания боролась с потерями, связанными с перемещением товаров и их перепроизводством.
Но есть ещё одно понятие – Канбан Метод или Канбан с большой буквы, который придумал Дэвид Андерсон и начал его популяризировать с 2007 года. Канбан Метод – метод управления, менеджерский подход. Он работает не как фреймворк или формат организации труда, которое можно разом внедрить в любую компанию. Его можно сравнить с кейсом с инструментами, в котором есть инструменты под различные задачи. В разных руках они работают по-разному, но всё равно дают эффект. Метод предполагает улучшение предоставления сервиса, эволюцию компании, достижение соответствия предназначению.

Что внутри Канбана?

Канбан состоит из 4-х больших блоков:
  • основные практики
  • принципы управления изменениями
  • принципы оказания сервиса
  • ценности Канбан
Начинается всё с принципов оказания сервиса. Канбан говорит вам – сфокусируйтесь на том, что хочет получить ваш клиент! Попробуйте организовать работу так, чтобы она соответствовала ожиданиям клиента (по качеству/временным рамкам), а также, чтобы клиент получил максимальное удовольствие от процесса. Под клиентом мы понимаем, как внешнего клиента компании, так и внутреннего – например, другой отдел компании. В любом случае вы выстраиваете некий сервис.
Канбан фокусируется не на менеджменте людей, не на микроменеджменте, когда мы следим за каждым человеком. Канбан рассматривает производственную систему компании как систему: в ней есть сложившиеся правила, структуры обмена информации между людьми. Используя Канбан, вы должны фокусироваться на том, как выстроена эта система. Она может быть нелогичной, исторически сложившейся. даже система может вам не нравится. Но главное, думая о клиенте, сосредоточьтесь на том, как течёт поток работы в этой системе. Ваша задача – визуализировать в этом потоке проблемы и подводные камни, давая людям возможность решить их самим и организоваться вокруг потока.
Регулярно пересматривайте эту систему и правила для улучшения результатов. Зачастую компания – это не один сервис, а целая сеть взаимодействующих сервисов. И чтобы конечный клиент получил свою услугу, задача проходит через всю цепочку сервисов. Иногда обнаруживается, что цепочка не работает так, как планировали и рисовали на управленческих диаграммах. Поэтому нужно анализировать и оптимизировать систему.
Когда мы разобрались с сервисом, мы начинаем пытаться улучшить эту систему. На помощь приходит тот чемоданчик с инструментами Канбан, позволяющие изменять и улучшать процесс, делать его более предсказуемым и более соответствующим желанию клиента. Это и есть отличительная черта Канбан Метода – ни в одном другом подходе вы не встретите такого.
Канбан говорит нам: «Не пытайтесь реорганизовать всю структуру и построить идеальную модель!». Проанализируйте то, как это работает в данный момент. Ведь если ваша компания существует не 5 минут, то поток задач уже как-то течёт, вы каким-то образом уже обслуживали клиентов, у вас есть опыт, есть практики. Поэтому вам нужно разобраться как протекает уже существующий поток задач, какие есть проблемы в движении потока, как можно сделать его шире. Поэтому начните с того, что есть сейчас:
  • изучите текущие процессы так, как они работают;
  • уважайте существующие роли и должности. Не пытайтесь переназначать людей, давать новые должности и названия. Работайте с людьми так, как работали ранее – тем самым вы получите поддержку людей, и они не уволятся из-за больших трансформационных изменений.
Договоритесь с сотрудниками о том, что будете улучшать ситуацию. Ведь Канбан Метод считает, что нет идеальных систем и нет идеального качества. Мы всегда находимся в процессе улучшения и перестроения. Поэтому обратитесь к своим людям и предложите изменить вашу систему таким образом, чтобы это было идеалом для вашего клиента – в этом закладываются эволюционными изменения.
Поощряйте сотрудников за новые предложения, поддерживайте проявления лидерства – это то, на чём вы можете базироваться и сделать систему лучше. Люди, работающие руками, всегда ярче представляют некоторые проблемы. Когда вы научитесь их слышать, ваша компания станет сильнее, устойчивее в любые моменты нестабильности рынка.

Основные практики Канбан

Теперь рассмотрим основные практики Канбан Метода. Их шесть:
  1. Визуализируйте. Визуализация – одна из самых популярных практик Канбан, ведь многие начинают именно с неё. Она нужна для наглядности текущей ситуации.
  2. Ограничивайте незавершённую работу. Чем меньше одновременных задач у вас находится в работе, тем быстрее клиент получит выполненную задачу. Это не парадокс, а факт, вполне доказанный математически.
  3. Управляйте потоком. Помогайте людям организоваться вокруг работы, тем самым управляя потоком.
  4. Сделайте правила явными.
  5. Используйте петли обратной связи. Так вы получите информацию о том, как работает поток, и используете её для развития.
  6. Улучшайте совместно, развивайтесь экспериментально (используя модели и научный подход).
Нужно отметить – нет правильной очередности применения практик. Всё сильно зависит от самой компании, от процесса, который мы рассматриваем. Но, как мы уже говорили, чаще всего все начинают с визуализации: строят доски, системы аналитики и статистики. Но это вовсе не обязательно! Вы можете начинать с любой из практик и она даст свои плоды.
]]> Рентабельность инвестиций в Канбан. Часть 3 http://neogenda.ru/blog/i2ddltan11-rentabelnost-investitsii-v-kanban-chast http://neogenda.ru/blog/i2ddltan11-rentabelnost-investitsii-v-kanban-chast?amp=true Thu, 25 Apr 2024 19:06:00 +0300 Артур Нек Перевод оригинальной статьи Мартина Азиза, опубликованной на SquirrelNorth. Если вы не читали 1-ю и 2-ю части этой серии статей, пожалуйста, прочтите...

Рентабельность инвестиций в Канбан. Часть 3

Перевод оригинальной статьи Мартина Азиза, опубликованной на SquirrelNorth.
Если вы не читали 1-ю и 2-ю части этой серии статей, пожалуйста, прочтите их и возвращайтесь!
Третья часть будет посвящена экономическим результатам, которые появляются при переходе на Канбан с точки зрения сервисно-ориентированного подхода.
В первой части этой серии статей мы рассмотрели экономические преимущества перехода от отслеживания индивидуального вклада к сотрудничеству в команде. Во второй части мы увидели более ощутимую экономическую отдачу от осознания того, что командам также необходимо сотрудничать между собой.
Третья часть будет посвящена экономическим результатам, которые появляются при переходе на Канбан с точки зрения сервисно-ориентированного подхода. Т.е. ориентации на то, что что организация – это сервис для конечного клиента, в который входит сеть взаимодействующих сервисов, которые и составляют компанию. Многие считают, что именно здесь начинает проявляться «настоящий» Канбан: т. к. он оказывает наибольшее влияние на соответствие организаций ожиданиям клиентов и связанные с этим экономические результаты. Сервисно-ориентированный подход — это завершающий штрих в Канбан Методе как с точки зрения масштабирования экономического роста, так и с точки зрения его использования.
«…даже если вы считаете себя „продуктовой компанией», это результат работы сервисов производящих, обслуживающих и доставляющих этот продукт».
Первое препятствие на пути к принятию Канбана — признание того факта, что все компании, работающие с умственным трудом, относятся к сервисным компаниям. Даже если вы считаете себя «продуктовой компанией», то на самом деле ваша работа — это результат взаимодействия между собой ваших команд или отделов, которые предоставляют друг другу сервис, что в конечном итоге является одним сервисом для ваших клиентов.

Поставьте себя на место клиента

Этот уровень Канбана начинается с более глубокого понимания ваших клиентов и того, какой сервис вы им предоставляете. Если раньше подход заключался просто в улучшении потока задач внутри одной команды и между командами, то теперь у нас есть конкретная цель — сделать сервисы для клиентов, которые максимально соответствуют их ожиданиям.
Такой подход даёт нам способность принимать правильные решения. Вполне вероятно, что на данном этапе производительность нашей команды недостаточна для выполнения всего спектра запросов. Это приводит к признанию ограниченности наших возможностей — существует дисбаланс между нашими возможностями и спросом клиентов.
По опыту, мне ещё не приходилось встречать компанию, в которой было бы стабильное соответствие между спросом клиентов и возможностью их удовлетворить. Это, как минимум, предполагает статический мир, в котором потребности клиентов никогда не меняются. Не всегда, но чаще всего, спрос превышает возможности организации. Это осознание меняет правила игры — мы признаем, что необходимо принимать компромиссные решения при работе с потребностями наших клиентов. Можно управлять обеими чашами этих весов — формировать спрос и совершенствовать наши возможности в отношении сервисов, которые мы предоставляем клиентам.
В попытке уравновесить эти две силы мы понимаем, что потребительский спрос и наши возможности объединяются в форме сложного рабочего процесса внутри нашей организации. Канбан предоставляет инструменты для управления этим процессом. Сервисно-ориентированный подход показывает, что нашим услугам приходится пробираться через организационные структуры, которые построены чаще всего функционально, а не оптимизированы для предоставления сервисов. Если коротко: нам нужно проложить себе путь через организационную диаграмму!
Применение инструментов Канбан, описанных ниже, имеет смысл только в контексте сервисно-ориентированного подхода (данная тема детально разбирается в тренингах программы Kanban Management Professional).
Хотя это и не исчерпывающий список (всего инструментов более 150), давайте посмотрим на базовый набор:

Инструменты формирования спроса

Стоимость задержки. Мы начинаем считать, каким будет бизнес-эффект у клиента, в случае, если мы задержим реализацию его запросов. Классы обслуживания. Мы можем поставить задачу по-разному, в зависимости от потребностей клиентов. Отложенное обязательство. Необходимо, чтобы запросы оставались необязательными до тех пор, пока не появится возможность и подходящие бизнес-условия для принятия этих обязательств и старта работ. Дизайн доски. Организовать таким образом, чтобы все потребности клиентов, которыми нужно управлять, были визуализированы; также входит в набор для улучшения наших возможностей. Распределение мощностей. Предложение сервисов разного масштаба на основе заданной бизнес-стратегии.

Инструменты улучшения возможностей

Выявление задержек и управление ими. Задержки характеризуют то, как вы организовали процесс поставки. Отслеживание времени выполнения. Это необходимо, чтобы лучше понять ваши фактические возможности поставки. А также, чтобы количественно определить, какие из сервисов лучше других. Управление вариативностью. Помогает вам лучше обещать; возможно, даже сформировать договоренности об уровне сервиса (SLA)ь. Устранение узких мест процесса, влияющих на время и возможность выполнения работы. Позволяет выяснить, в каких точках процесса поставки вы имеете наибольшее ограничения, и спроектировать процессы так, чтобы работа продолжалась независимо. Несвязные каденции поставки. Необходимо разработать соответствующую стратегию гибкости для ваших сервисов, т. е. насколько быстро нужно реагировать на новую информацию о спросе клиентов. Петли обратной связи. Даёт понимание, как работают ваши сервисы, позволяет разрабатывать планы улучшения и подстраивать под стратегию и минимизацию реальных рисков.

Бизнес-преимущества от Канбан с сервисно-ориентированным подходом

На этом уровне зрелости Канбан нужно отвлечься от мысли об улучшениях производительности отдельных людей и команд, несмотря на то, что это очень полезно. Такие улучшения не гарантирует, что ваши клиенты получат сервис более высокого качества. Этот уровень Канбана о том, как объединить два в одном: вы определили сервисы, которыми пользуются ваши клиенты, и именно их предоставление — это то, что требует улучшения.
«Клиенты, которые своевременно получают то, что им нужно, как правило, чаще выбирают вас»
Клиенты, которые своевременно получают то, что им нужно, как правило, чаще выбирают вас. Поэтому вы можете ожидать, что спрос на ваши услуги будет как минимум сохранён. И скорее всего он увеличится. Вы можете продать больше и, что не менее важно, выполнить уже взятые на себя обязательства по поставке, потому что незаконченная работа не копится долгое время в ожидании.
Используя инструменты формирования спроса и улучшения возможностей, вы также не начинаете работу, которая никогда не завершится по ряду возможных причин:
  • реализация заняла слишком много времени и это больше не актуально
  • реализация заняла слишком много времени, и ваш клиент запросил её у кого-то другого
  • это оказался плохой выбор по сравнению с вариантами, которые появились в будущем
Такую незавершенную работу называют «отказом от работы», часто наблюдается, что многие сервисы имеют высокий процент отказа (до 50%). Избавившись от этой отказной работы, вы могли бы практически удвоить свои возможности поставки, не наняв ни одного человека!
Увеличение пропускной способности — сокращение количества отказов от работы вместе с увеличением количества запросов на обслуживание приводит к повышению производительности: как по объёму, так и с точки зрения экономических показателейвыполняемой работы. Вы можете прогнозировать увеличение пропускной способности более чем вдвое, если вы перешли на эту форму Канбан в течение 12 месяцев после вашего первоначального знакомства с Канбан.
Сокращение времени реализации запроса для клиента компании (Time2Market) — сокращение времени производства ещё более впечатляющее, чем раньше. Если раньше улучшение скорости поставки было внутри команд и между ними, то теперь мы наблюдаем улучшенную скорость оказания услуги в рамках всего сервиса. При рассмотрении процесса от начала до конца следует ожидать ускорение времени выполнения заказа в диапазоне от 50 до 90%. Помимо этого, вы скорее всего, ощутите повышение предсказуемости сроков доставки; что ещё более увеличивает ваше соответствие ожидания клиентам как организации, которая может не только давать обещания, но и выполнять их.

Преимущества в течение первых 24 месяцев

«… это реальный рост выручки, представляющий организацию с более качественными сервисами»
Теперь, когда мы определили преимущества из частей 1 и 2, мы можем добавить следующую группу преимуществ для дальнейшего построения нашей бизнес-модели. Итак, мы снова рассматриваем отдел стоимостью 20 млн долларов с доходностью 10%, вот где мы пока находимся:
Наше экономическое обоснование сейчас прогнозирует 8,6 млн долларов экономической выгоды в течение 2-х лет после начала использования Канбана, если организация перейдёт на сервисно-ориентированную модель Канбан. Теперь, когда пропускная способность и время выполнения заказа являются основными преимуществами, мы видим реальный рост выручки, соответствующий организации с более качественными сервисами, более лояльными клиентами и в целом более здоровым присутствием на рынке.
«Мы знаем, что клиенты не всегда правы, но они всегда делают выбор».
Мы знаем, что клиенты не всегда правы, но они всегда делают выбор. Канбан на этом уровне делает ваших клиентов более счастливыми, он позволяет вам брать на себя обязательства и выполнять их. Это увеличивает вероятность, что ваши клиенты выберут вас!
Надо отметить, что организация редко достигает сервисно-ориентированного подхода Канбан без помощи аккредитованного консультанта по Канбан или без обучения, например KSD (KMP1). Обычно, организации, которые зашли так далеко, делают и то, и другое. Чтения книг и статей, подобных этой, будет недостаточно, подробнее об этом мы расскажем в последней пятой части этой серии статей.
Увидимся в четвёртой части статьи, где исследуем ещё более зрелые практики Канбан, для построения нашего экономического обоснования после второго года.
]]> Рентабельность инвестиций в Канбан. Часть 2 http://neogenda.ru/blog/lebx84c8f1-rentabelnost-investitsii-v-kanban-chast http://neogenda.ru/blog/lebx84c8f1-rentabelnost-investitsii-v-kanban-chast?amp=true Fri, 26 Apr 2024 19:08:00 +0300 Артур Нек Перевод оригинальной статьи Мартина Азиза, опубликованной на SquirrelNorth. Если вы не читали первую часть этой серии статей,...

Рентабельность инвестиций в Канбан. Часть 2

Перевод оригинальной статьи Мартина Азиза, опубликованной на SquirrelNorth.
Если вы не читали первую часть этой серии статей, сначала прочтите ее здесь и возвращайтесь.
Основная причина задержки работы возникает во время передачи задач между командами. С введением агрегированного командного Канбан источник большинства задержек и сопротивления выполнению значительно сокращается.

Пересмотр преимуществ Части 1

В первой части статьи в результате применения базовых форм Канбан Метода мы получили бизнес-результаты, которые привели к снижению общих затрат на координацию. Вы можете возразить, что большинство организаций и так интуитивно понимает, что их затраты на координацию составляют значительную часть их совокупных затрат на предоставление какой-то услуги или продукта. Но они зачастую не понимают, насколько велик их процент. Другой неинтуитивный факт — затраты на координацию растут быстрее (в процентах от общей работы), чем количество конкурирующих задач, которыми необходимо управлять. Иными словами: затраты на координацию растут не линейно по отношению к работе.
В приведенной ниже экономической модели координации показано, как затраты падают быстрее, чем количество конкурирующих задач, которыми необходимо управлять.
Предполагая, что ежегодный бюджет отдела составляет 20 млн долларов, можно составить базовый план экономии на издержках, как показано ниже.
Хотя этот отчёт показывает значительную прибыль, он неполон, так как в течение того же периода времени выгода будет увеличиваться по мере дальнейшего совершенствования инструментов Канбан. Давайте рассмотрим это далее.

Помимо непосредственной команды

Использование Канбан Метода внутри одной команды в течение некоторого периода времени может иногда вызывать у команды мысли вроде: «Что если бы люди, которые с нами работают, тоже использовали Канбан?».
Это пример раннего осознания того, что в большинстве организаций для выполнения работы необходима поддержка других людей. По сути, работа должна переходить от одной команды к другой. Если цель стоит в сохранении непрерывного потока работы в компании, то взаимодействие команд друг с другом очень важно!
Обычно мы видим это в двух сценариях.
В процессе работы:
Переход с одного этапа на другой:
Получается, что задача в статусе «Выполнено» для одной команды, для другой команды является задачей в статусе «Нужно сделать». Эту ситуацию можно визуализировать с помощью шаблона доски которая называется Агрегированный командный Канбан (Aggregated Team Kanban). При таком подходе на одной доске отображаются две или более досок команд, чтобы лучше понять задержки при координации.
Использование Канбан в разных командах дает ряд преимуществ:
Видимость между командами — команды имеют возможность наблюдать, как их работа влияет на другую команду, и вносить коррективы в свой процесс.
Сотрудничество между командами — аналогично, как в первой статье, при сотрудничестве между отдельными членами команды, совокупное представление даёт возможность командам работать совместно. Это приводит к тому, что несколько команд работают так, как если бы они были одним целым.
Перегрузка команд — совместная работа помогает сотрудникам работать более устойчиво, ведь скорость работы между командами может быть согласована. Например, Команда 1 не перегружает Команду 2 новой работой, так как они несут общую ответственность. В Канбан Методе мы называем это неравномерностью потока, и как только вы это смогли это визуализировать, вы сможете управлять этим.

Бизнес-преимущества видимости и сотрудничества между командами

Если вы изучите работу многих компаний, то обнаружите, что основная причина задержки работы возникает во время передачи задач между командами. Эта точка передачи обычно не управляется напрямую, но с введением Агрегированного командного Канбан теперь это возможно. Источник большинства задержек и сопротивления выполнению значительно сокращается.
Таким образом, бизнес-результаты можно представить в трёх дополнительных категориях:
Увеличение пропускной способности. Пропускная способность — объём завершенной работы, а не количество задач со статусом «В работе». С уменьшением количества «застрявших» задач количество работы со статусом «Выполнено» начинает увеличиваться. Наблюдая за использованием Канбан Метода на этом уровне от 6 до 12 месяцев, мы видим удвоение пропускной способности!
Сокращение времени вывода продукта на рынок — благодаря сокращению задержек, время, необходимое для создания продукта сокращается. На этом уровне использования Канбан сокращение времени выполнения заказа составляет от 10% до 50%. Например, если раньше на выполнение чего-либо требовалось 30 дней, то теперь это займет от 15 до 27 дней.
Повышение уровня удовлетворения клиентов — предоставление более быстрого обслуживания не оценивается в этой статье, но необходимо признать его выгоду для бизнеса. У клиентов всегда есть какой-то временной порог, до которого они готовы ждать. Используйте это и вы сможете повлиять на их выбор в положительную сторону.
Преимущества в течение первых 0-18 месяцев
В первой части статьи мы определили выгоды от снижения затрат на координацию. Теперь мы можем добавить следующую группу преимуществ для того, чтобы достроить экономическое обоснование.
Итак, мы имеем отдел стоимостью 20 млн долларов с доходностью 10%, вот где мы находимся на данный момент:
Итого: мы видим выгоду размером 4,7 млн долларов, благодаря усовершенствованиям процессов. Рост выручки — основной источник выгод.
Параметр повышения уровня удовлетворения клиентов, который мы не рассматривали количественно, может согласовываться со стратегиями повышения финансовой устойчивости и устойчивости организации к настроениям рынка.
В следующих статьях мы увидим, как этот набор преимуществ сохранится и будет расти по мере повышения зрелости организации!
Читать дальше:
3-я часть
4-я часть
]]> Рентабельность инвестиций в Канбан. Часть 1 http://neogenda.ru/blog/1o2mki3361-rentabelnost-investitsii-v-kanban-chast http://neogenda.ru/blog/1o2mki3361-rentabelnost-investitsii-v-kanban-chast?amp=true Sat, 27 Apr 2024 07:37:00 +0300 Артур Нек Перевод оригинальной статьи Мартина Азиза, опубликованной на SquirrelNorth. «Они хотят увидеть экономическое обоснование, прежде чем мы сможем...

Рентабельность инвестиций в Канбан. Часть 1

Перевод оригинальной статьи Мартина Азиза, опубликованной на SquirrelNorth.
«Они хотят увидеть экономическое обоснование, прежде чем мы сможем приступить?!» — это слова главы отдела, которую я обучал в рамках запланированного внедрения Канбан. У неё были смелые планы по улучшению показателей своего подразделения, но этот вопрос заставил её задуматься.
Команда управленцев хотела знать, какова будет плата за внедрение. Могут ли они позволить себе инвестировать в Канбан? Когда произойдет возврат инвестиций?
До этого мы уже потратили некоторое время на изучение того, как в настоящее время проводится работа, так что в действительности вопрос звучал как: «можем ли мы не использовать Канбан?
Мы были прагматичны, «засучили рукава» и приступили к разработке модели того, как Канбан метод позволяет получить измеряемый успех в бизнесе. Я надеюсь, что эти разработки помогут в стремлении использовать Канбан для улучшения вашего бизнеса.

Дисбаланс окупаемости инвестиций (ROI)

Первые несколько статей о рентабельности инвестиций будут сосредоточены на экономических выгодах от использования Канбан. Как только мы позаботимся о верхней части уравнения окупаемости инвестиций, мы обратим наше внимание на нижнюю половину — стоимость реализации. Что касается стоимости реализации, то команда в SquirrelNorth экспериментировала с различными моделями, чтобы обеспечить оптимальную комбинацию обучения, коучинга и консультирования для достижения долгосрочных результатов, о которых я расскажу в заключительных частях этой серии статей. Есть причина рассказать об этом в конце, это связано с большой разницей между инвестиционными затратами и экономическими результатами. Инвестиционные затраты — сравнительно небольшая сумма по сравнению с выгодами: не сосредотачивайтесь слишком сильно на знаменателе, числитель — вот где происходит самое интересное!

Ранние и непрерывные выгоды!

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

Ранние формы Канбан

В Канбан методе не существует такого понятия, как «правильный Канбан», только применения различных инструментов Канбан, соответствующие разному уровню зрелости организации. Этот подход был систематизирован в модели, известной как Модель зрелости Канбан (Kanban Maturity Model — KMM), которая классифицирует организационную зрелость по 7 уровням: от 0 до 6.
На каждом уровне появляются более продвинутые инструменты, имеющие смысл только на данном уровне. Поэтому использования Канбан метода в целом нужно рассматривать как повышения организационной зрелости компании, проходящей серию улучшений, и применение согласованных практик на каждом этапе взросления. К сожалению, нет кратчайших путей к повышению зрелости организации, то есть прямого перехода со 2 на 4 уровень; каждый уровень необходимо проживать по очереди, закрепляя новые ценности и практики, прежде чем можно будет подумать о переходе на следующий уровень.
С учётом этого пути повышения зрелости, большинство внедрений Канбан начинаются с низкого уровня зрелости (уровни от 0 до 1), что раньше до введения KMM называлось Прото-Канбан. Также следует отметить, что большинство организаций так и остаются на этом низком уровне зрелости, если они не вкладывают средства в получение квалифицированной внешней помощи в форме коучинга и обучения (подробнее об этом в следующей статье, посвященной инвестиционной стороне вопроса).
Несмотря на низкую зрелость этих методов, они всё же приносят пользу. Давайте рассмотрим некоторые ранние формы Канбан:
Видимость — работа теперь отображается в виде тикета на физической или цифровой доске. Как минимум, мы теперь знаем, каков статус выполняемой работы: она начата, завершена или ещё не начата. Становится намного проще увидеть, над чем работают, и получить базовую информацию о состоянии.
Сокращение количества конкурирующих задач — внедрение доски может показать, насколько все заняты, и помочь в принятии решений о том, на чём сосредоточить усилия ваших сотрудников. Этот фокус потенциально может увеличить количество завершенных работ по сравнению с наличием значительного объёма со статусом «в работе».
Сокращение индивидуальной перегрузки — повышенное внимание к сокращению числа конкурирующих задач даёт возможность избежать перегрузки ваших сотрудников слишком большим количеством действий. Такой подход поможет снизить количество непродуктивных и дорогостоящих сверхурочных работ и позволит лучше управлять качеством.
Расширение сотрудничества в команде — прозрачность, предоставляемая доской, также поможет улучшить сотрудничество между исполнителями. Сотрудники могут собраться за доской, увидеть, кому нужна помощь, и увеличить шансы на совместную работу.

Нам нужно меньше управлять, не сбавляя обороты!

Благодаря повышенной прозрачности и ограниченному количеству конкурирующих задач, обеспечиваемой этими базовыми формами Канбан, мы обычно видим первые преимущества для бизнеса в виде сокращения накладных расходов, необходимых для управления статусом и отслеживания большого объёма работы. В частности, резко сокращаются «затраты на координацию» организации.
Цифровые календари становятся всё более скудными без необходимости бесконечных статус-митингов, а потребность в армиях project-менеджеров становится всё меньше, поскольку накладные расходы управления оказываются под контролем. Все эти дополнительные возможности, высвободившиеся в организации, могут быть сосредоточены на других инициативах, улучшении результатов текущих инициатив и развитии квалификации ваших сотрудников.

Количественная оценка прибыли от внедрения ранних форм Канбан

Наши наблюдения показывают, что при самых скромных сокращениях сверхурочных и транзакционных издержек можно привести к снижению затрат на управление с использованием Канбан на 5-10% в течение 6 месяцев после начала использования Канбан.
Теперь мы можем использовать эту цифру в качестве первой части раздела «прибыль» для нашего расчёта окупаемости инвестиций. Для примера возьмем ежегодные операционные расходы большого отдела в 20 миллионов долларов, что даёт выигрыш в 1 миллион долларов к концу первого года. Это все равно что получить целую дополнительную команду бесплатно! Это уже вполне ощутимая выгода, имеющая материальную ценность. Что ещё может предпринять организация, высвободив 1 миллион долларов? Отличная новость состоит в том, что до конца года мы успеем ещё больше улучшить зрелость нашей организации и наши практики Канбан метода!

Дальше – больше!

В следующей статье я исследую преимущества перехода на уровни зрелости 2+ и дам количественную оценку прибыли от использования Канбан в следующие 6–12 месяцев.
]]> Что такое Канбан? Руководство для новичков http://neogenda.ru/blog/2t0rsnnvj1-chto-takoe-kanban-rukovodstvo-dlya-novic http://neogenda.ru/blog/2t0rsnnvj1-chto-takoe-kanban-rukovodstvo-dlya-novic?amp=true Sun, 28 Apr 2024 07:42:00 +0300 Артур Нек Если вы хоть раз сталкивались с управлением проектом или командой, то знаете, что это нелегко....

Что такое Канбан? Руководство для новичков

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

Что такое Kanban

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

Как появился Kanban

Kanban как термин появился в 1940-х годах в компании Toyota. До этого времени производители автомобилей часто придерживались метода Генри Форда: производилось большое количество деталей, которые использовались по мере необходимости. Каждый цех изготавливал детали с разной скоростью. Как итог каких-то деталей всегда не хватало, а каких-то было слишком много.
То есть такой подход приводил к большим издержкам и требовал авансового капитала. Чтобы избежать перепроизводства, главный инженер Toyota Тайити Оно (Taiichi Ōno) ввел новую систему, которая подразумевала, что детали должны изготавливаться только по запросу.
Тайити Оно
«To produce only what is needed, when it is needed and in the amount needed» —
производите только то, что необходимо в определенный момент и в нужном количестве.
Как же цеха обменивались заказами? Для этого они использовали обычную доску, которая висела на стене, и систему карточек. Бумажные карточки висели на доске. На них было написано, сколько и каких деталей потребуется в ближайшее время. Только после того, как появлялась карточка с требованием произвести детали, запускался производственный процесс.
Так выглядели карточки на изготовление деталей
Само слово «Kanban» состоит из двух иероглифов:
  • 看 — «Кан» означает «знак»,
  • 板 — «Бан» значит «доска».
Kanban-доска в Toyota
В 2000-х годах на Канбан обратил внимание Дэвид Дж. Андерсон — разработчик и менеджер компаний Motorola и Microsoft. Идея выполнять работу по запросу показалась ему применимой не только на производстве автомобилей, но и при разработке программного обеспечения.
Так началась история Kanban как метода управления рабочим процессом. Андерсон поделился результатами внедрения Канбана на Agile-конференции, что способствовало его популяризации. Уже в 2007 году Андерсон выпустил книгу «Канбан: альтернативный путь в Agile». В ней он рассказал об основных принципах и элементах Kanban method, которые мы знаем сейчас.

Принципы Канбан

Основные принципы Канбан-метода.
1. Начните с того, что есть сейчас.
Метод Kanban не требует кардинальных изменений в процессах. Внедрение начинается с анализа текущей ситуации и работы с уже существующими процессами.
2. Договоритесь об эволюционном развитии.
Изменения в рабочих процессах должны происходить постепенно, на основе данных и обратной связи. Канбан помогает совершенствовать процессы шаг за шагом, не создавая стресс для команды.
3. Поощряйте развитие лидерства на всех уровнях.
Ответственность за улучшение работы должна быть распределена между всеми участниками процесса. Важно поддерживать инициативность и стремление к изменениям на всех уровнях команды.

Сервисные принципы Канбан

1. Выясните потребности и ожидания заказчика.
Канбан направлен на эффективное удовлетворение запросов клиентов. Команда должна четко понимать, что важно для заказчика и какие ожидания он предъявляет.
2. Управляйте работой, дайте людям организоваться вокруг нее.
Фокус на управлении работой, а не людьми. Это значит, что команда сама определяет, как лучше организовать процесс выполнения задач.
3. Развивайте правила, чтобы улучшить показатели.
Достичь успеха с первого раза в любом деле почти невозможно. Также всегда есть внешние факторы, которые вносят свои корректировки в бизнес. Kanban-метод призывает быть гибкими. Нужно собирать обратную связь от коллег и пользователей продукта. Эти данные помогут найти путь для развития.

Элементы Kanban-системы

Kanban-доски

Умственная работа не видна так же очевидно, как физическая: нельзя просто взглянуть и понять, на каком этапе находится задача. Поэтому первое, с чего начинается внедрение Канбан-метода, — это визуализация. Именно она помогает сделать рабочий процесс прозрачным. Раньше сотрудники Toyota использовали физические доски для заказов деталей, а сейчас есть множество сервисов с виртуальными досками.
На Канбан-доске есть 3 важных элемента: колонки, строки (их также называют дорожками) и карточки.
Карточки — основной рабочий элемент, а колонки — этапы, которые должна пройти задача, пока ее не выполнят.
Количество колонок может быть любое — зависит от жизненного цикла карточки. Главное — все этапы должны быть учтены. Редко, когда хватает 3 колонок «Очередь», «В работе» и «Готово». Чем точнее колонки будут отражать жизненный процесс, тем проще в будущем выявить, какие проблемы возникают и на каком этапе.
Исполнители двигают карточки по колонкам слева направо. То есть, как только выполнен очередной этап работы, карточку перемещают в следующую колонку. Так делают до тех пор, пока задача не окажется в последней колонке, где хранятся завершенные дела.
Kанбан: пример доски

Командные встречи, или Kanban-каденции

Для Kanban очень важно, чтобы все члены команды были вовлечены в рабочий процесс. Чтобы этого достичь, необходимо постоянно общаться как внутри команды, так и с руководителями и заказчиками. Поэтому Kanban предусматривает встречи, или каденции (Kanban Cadences). Это цикл мероприятий, который обеспечивает обсуждение работы на разных этапах.
Каждая встреча связана с предыдущей. Циклы собраний сменяют друг друга и формируют единый поток коммуникации. Важно проводить Канбан-каденции регулярно.

7 видов Канбан-каденций

1. Ежедневная встреча (Daily Meeting, Standup Meeting)
Проходит ежедневно и длится не более 15 минут. Цель встречи — подготовить план работы на день.
На собрании каждый член команды должен ответить на 3 вопроса:
  1. Какими задачами планирует заняться?
  2. Сталкивается ли с проблемами и блокировками при выполнении задач?
  3. Нужна ли помощь от коллег?
Особое внимание уделите проблемным задачам и блокировкам. Важно понять, повлияют ли они на сроки подготовки проекта.
Если вы работаете офлайн, можно проводить собрание стоя. Долго стоять трудно, поэтому каждый, рассказывая о своих задачах, будет стараться доносить информацию быстро и кратко.
👍 Как провести Канбан-митинг?
2. Встреча по пополнению очереди (Replenishment Meeting)
Проходит еженедельно или 1 раз в 2 недели. Частота зависит от команды и ее задач. Длительность — от 30 минут до 1 часа. Поток входящих задач — важный элемент Kanban. Чтобы в бэклоге карточки лежали по приоритетам и было понятно, что необходимо сделать в ближайшее время, нужно собираться на небольшую встречу по пополнению очереди задач.
В рамках этой встречи:
  • решается, какие задачи важны на данный момент и есть ли у команды ресурсы на их выполнение;
  • распределяются исполнители, чтобы нагрузка на каждого сотрудника была сбалансирована.
3. Собрание по планированию поставки (Delivery Planning Meeting)
Частота встреч зависит от потока задач. Встреча длится 1–2 часа. Заказчику важно знать сроки выполнения работы. Например, вы разрабатываете внутренний корпоративный портал для компании. Клиент должен знать, когда он запустится, чтобы подготовить информационную кампанию для сотрудников и собрать команду, которая будет готовить новости для него.
Планировать сроки реализации проекта нужно с опорой на данные прошедших проектов. Соберите информацию о продуктивности команды за предыдущие периоды и посчитайте, за сколько вы выполните аналогичные задачи.
4. Обзор поставки (Service Delivery Review)
Эта встреча проводится раз в две недели и длится 30 минут. Ее цель — проанализировать, насколько эффективно выполняются задачи, выявить точки улучшения и минимизировать риски задержек.
Важный фокус — соответствие сроков выполнения задач ожиданиям заказчика. На встрече оцениваются ключевые показатели работы команды, выявляются возможные узкие места и принимаются решения, которые помогут оптимизировать процесс.
В обсуждении участвуют только представители команды, а не вся команда целиком. При анализе важно учитывать не только скорость выполнения задач, но и удовлетворенность заказчиков качеством работы.
5. Анализ рисков (Risk Review)
Эта встреча проводится ежемесячно и длится 1–2 часа. Если вы хотите сделать проект в срок, важно, чтобы команда не сталкивалась с проблемами или хотя бы помнила, что они могут быть, и знала, как действовать. Чтобы у команды был план действий на разные ситуации, нужно изучать предыдущий опыт и совершенствовать процессы. Для этого раз в месяц встречайтесь всей командой и изучайте блокировки и возникшие на пути проблемы.
6. Обзор операций (Operation Review)
Проводится ежемесячно и длится примерно 2 часа.
На встрече присутствуют только менеджеры разных команд. Цель — проанализировать работу всех отделов, их коммуникацию с заказчиками и друг с другом. Для выявленных проблем нужно придумать решения.
В отличие от остальных встреч, обзор операций призван повысить эффективность всей организации в целом, а не отдельных команд.
7. Обзор стратегии (Strategy Review)
Проводится раз в квартал и длится долго — от 4 часов. В нем участвуют топ-менеджеры и руководители команд. Цели встречи:
  • проследить, движется ли компания к целям;
  • соответствуют ли цели ситуации на рынке;
  • эффективны ли созданные бизнес-процессы.
Если проблемы есть, необходимо скорректировать курс.
Встреча требует масштабной подготовки. Нужно изучить рынок и изменения, которые на нем происходят, проанализировать достижения компании и отдельных команд, сравнить компанию с конкурентами.

Ограничение незавершенной работы

Для Канбана важно, чтобы задачи завершались как можно быстрее. Если сотрудник работает над несколькими задачами одновременно, он отвлекается. Чтобы сотрудник был сосредоточен на ограниченном количестве работы, вводятся WIP-лимиты. Work in progress, или лимиты незавершенной работы, — это правила, которые ограничивают количество задач на каждом этапе рабочего процесса. За счет этого сотрудники не хватаются за все задачи подряд, а фокусируются на одной или двух.
Например, редактор берется за статью и пишет половину текста. Как только ему надоедает тема, он бежит писать новую. В итоге ни одна из статей не дописана. Результата нет. Именно в таких случаях помогают WIP-лимиты. Сотрудник вынужден дописать предыдущую статью, чтобы взяться за новую. «Прыгать» между статьями не получится.
WIP-лимиты разные для всех. Понять, какое количество задач в работе приемлемо для каждого сотрудника, можно только путем исследования. Проанализируйте предыдущие задачи и установите примерные лимиты. Поработав несколько итераций, обсудите с командой выполненные задачи, было ли удобно так работать. Если нет — скорректируйте ограничения.

Классы обслуживания

Классы обслуживания (Classes of Service) — правила, по которым разделяются все задачи команды. Это помогает приоритизировать их и не упустить особенно важные.
В Kanban обычно выделяют 4 класса задач:
  1. Срочные. Их необходимо сделать быстро. Например, перестал работать сервер и нужно бросить все силы на его воскрешение.
  2. С фиксированной датой. Задачи с конкретным дедлайном. Например, пост о запуске акции должен выйти 1 марта.
  3. Стандартные. Большинство задач в рабочем процессе должны быть стандартными. В этом классе находятся задачи с умеренными затратами на задержку и есть много времени на выполнение.
  4. Нематериальные. Задачи этого класса можно назвать бытовыми делами. Их нужно выполнить, но спешить с ними не обязательно.
Классы обслуживания могут быть другими. Всё зависит от специфики вашей команды.

Важные метрики для Kanban

Чтобы знать, есть ли проблемы в рабочем процессе, в Kanban необходимо отслеживать метрики эффективности работы. Например, в команде разработчиков в колонке «Тестирование» копятся карточки. Дело в том, что в команде не хватает тестировщиков. Исправить это можно, найдя еще одного тестировщика.
Во многих таск-трекерах инструменты для отслеживания эффективности команды встроены в программу. То есть делать вручную ничего не нужно. Вы просто оцениваете собранные программой данные.
Итак, какие метрики нужно отслеживать в Kanban:
Скорость поставки задач
Сколько времени проходит с момента, как задача появляется на доске команды до ее полного выполнения. Этот показатель помогает ответить на вопрос, когда заказчик получит готовую работу.
Время цикла
Время от взятия задачи в работу до поставки. Показывает, сколько времени команда активно работает над задачей. То есть отсчет идет не с попадания карточки на доску, а с момента, как команда взяла задачу в работу. Помогает увидеть проблемы. Например, одна задача неожиданно выполнялась дольше, чем обычно. Стоит изучить ее. Может быть, ТЗ было сделано неправильно, не хватало информации.
Пропускная способность
Сколько задач выполнила команды за определенный промежуток времени. Например, писатели готовят в неделю пять статей. Если заказчик захочет узнать, когда вы сможете взять его задачу в работу, посмотрите на пропускную способность и рассчитайте примерную дату.
Стоимость задержки
Это последствия, к которым может привести задержка выполнения задачи. Например, если дизайнер не сделает макет, разработчики не смогут приступить к созданию интернет-магазина и бизнес не запустит онлайн-продажи. Каждый день задержки — упущенная прибыль, которая может достигать нескольких сотен тысяч.

Отличие Scrum от Kanban

Scrum и Kanban нужны для разных целей.
  • Kanban-методология стремится улучшить рабочий процесс: увеличить скорость работы над задачами, уменьшить количество блокировок и визуализировать всю работу команды.
  • Scrum помогает сосредотачиваться на постоянном выпуске нового элемента продукта (инкремента). В конце спринта команда ставит себе цель — создать что-то новое для потребителя. Такой подход способствует активному росту бизнеса.
Для наглядности отличие Kанбан от Скрам собрали в таблицу.
Параметр
Kanban
Scrum
Суть подхода
Визуализация рабочего процесса и достижение максимальной эффективности
Деление работы на итерации (спринты). Ориентируется на постоянный выпуск элементов продукта и быстрый сбор обратной связи от пользователей
График
Непрерывный процесс
Вся работа поделена на спринты — итерации от 1 недели до месяца
Роли
В команде нет обязательных ролей
Владелец продукта (Product Owner), Scrum-мастер и команда разработчиков
Элементы
Kanban-доска, WIP-лимиты, классы обслуживания
Бэклог продукта, бэклог спринта, инкремент продукта
Скорость изменений
Можно вносить изменения в любой момент
Изменения проходят только между спринтами на основе ретроспективы, которая проходит в конце каждой итерации
У Scrum и Kanban также бывают пересечения. Команды, которые работают по Scrum, используют Kanban-доски для визуализации задач и отслеживания прогресса. В свою очередь, Kanban-команды могут иметь Product Owner, который помогает им развивать продукт. Для такого комбинированного подхода придумали название — Scrumban. Но об этом поговорим подробнее в будущей статье.

Преимущества и недостатки Kanban

Kanban помогает сделать рабочие процессы и ошибки в них наглядными, а также балансирует нагрузку сотрудников.
Но, как и у многих методологий, у него есть недостатки. Собрали для вас все минусы и плюсы в таблице.
✅ Преимущества
❌ Недостатки
Прозрачность рабочего процесса
Карточки на доске в режиме реального времени показывают, чем занимается каждый член команды. Вы легко можете оценить вклад каждого сотрудника в проект, найти проблемные места и не давать работникам перегружаться
Методология Канбан подходит не всем
Он дает большую гибкость команде. Это может быть плюсом. Но, если в организации есть квартальные отчеты, жесткие KPI и OKR, то гибкость Канбана может усложнить задачу
Подробная аналитика
Вы можете проследить каждый этап работы. Если что-то пойдет не так, вы сразу это заметите и сможете скорректировать процесс
Не дает планировать на годы вперед
Суть Kanban framework — быстро реагировать на изменение приоритетов задач. Если в вашей компании привыкли планировать на 1–2 года вперед, Канбан будет для вас неудобным. Вы не сможете в полной мере использовать его преимущества
Внедрение Канбан происходит легко
В Scrum нужно нанять Владельца продукта и Scrum-мастера, рассказать про четкие правила спринтов и т. д. Система Канбан — это эволюция рабочего процесса. Создайте рабочую доску, попробуйте проводить некоторые встречи, например Daily Meeting, затем выявите удобные WIP-лимиты. Вот так, шаг за шагом, вы придете к идеальному для вас рабочему процессу
Вся команда вовлечена в улучшение процессов
На Канбан-встречах команда активно обсуждает все неудобства или, наоборот, хорошие практики, решает проблемы. Это способствует вовлеченности в улучшение работы. Каждый член группы видит, как к его идеям и неудобствам прислушиваются

Вместо итога

Методика Канбан подходит не всем, поэтому использовать его или нет — решать вам. При выборе любой методологии задавайте себе вопрос, что необходимо вашей команде. Если вам нужна активная разработка, то лучше обратить внимание на Scrum. Его цель — настроить постоянный релиз новых функций продукта. Если вам важно поработать над потоком работы: сделать его предсказуемым, сбалансированным по нагрузке и понятным, — выбирайте Kanban.
]]> Майки, деньги, два тортa: как мы разучились оценивать задачи. http://neogenda.ru/blog/bnt0ja7vr1-maiki-dengi-dva-torta-kak-mi-razuchilis http://neogenda.ru/blog/bnt0ja7vr1-maiki-dengi-dva-torta-kak-mi-razuchilis?amp=true Mon, 29 Apr 2024 07:45:00 +0300 Артур Нек Привет! Меня зовут Артём и я тимлид в Skyeng. У моей команды разработки есть заказчик,...

Майки, деньги, два тортa: как мы разучились оценивать задачи.

Привет! Меня зовут Артём и я тимлид в Skyeng. У моей команды разработки есть заказчик, он же продуктовый менеджер, он же просто Ваня. Ваня считает, что наша схема с оценкой задач не идеальна. Например, оценка в 2 дня ничего ему не даёт. Свою задачу на проде он увидит через неделю или дней 10. Или больше. Или меньше.
Это происходит не потому, что мы фейлим задачи, а потому что c традиционным Estimate в реальности мы оцениваем лишь время написания кода разработчиком. А ведь есть еще тестирование и код-ревью. Ок, заложим это всё в оценку. Но ведь ещё:
  • у нас есть очередь непосредственно перед разработкой и тестированием,
  • возникают доработки, мы не без греха,
  • влетают срочные задачи,
  • когда реализация затрагивает несколько сервисов, мы ждем ревью от смежных команд.
Как научиться отвечать на вопрос «Когда?», если о предсказуемости речи не идёт?

Как мы усомнились в Estimate

В нашей команде, как и у многих в компании, есть очень полезная встреча — техническое ревью (или, сокращенно, техревью). Она требует приличного количества времени и сил, зато добавляет предсказуемости: мы заранее расписываем техническое решение задачи, а заодно оцениваем ее.
Так как мы всегда на удаленке, всё происходит в JIRA: есть доска, на которой визуализированы этапы работ. Карточка покидает статус «Техревью» и перебирается в «Готово к разработке» после того, как мы все описали и оценили. Именно в этот момент мы берем на себя обязательства выполнить работу.
У «Готово к разработке» стоит WIP-лимит — больше 8 задач одновременно быть не может. Есть и обратное правило: как только задач в колонке становится мало, мы инициируем новое техническое ревью.
Факт: мы тратим заметное время на оценку. Техревью обычно проходит два раза в неделю, на 4 задачи с детальной проработкой и оценкой может уйти 1,5-3 часа. Но! Затем мы еще можем потратить время, чтобы разобраться, почему Estimate таки был превышен.
При этом ни оценка, ни разбор полетов не добавляют ценности нашему продукту. Скорее, на них мы теряем время. И деньги. Я долго сомневался в необходимости этих процедур, а в один момент дозрел до серьезного разговора с продактом. И мы оба признали проблему.

«Футболка сухая и совсем…» не XS

Решили: давайте экспериментировать с подходами к оценке. Я предложил остановиться на T-Shirt Size — в качестве единицы измерения в этой технике используются размеры футболок. Нужно найти самую маленькую задачу, которую приходилось делать, и принять ее за XS. После этого остальные задачи оцениваются по принципу «насколько они больше XS» — и в зависимости от этого им присваивается размер S, M, L или XL.
Подкупила возможность оценивать «на глазок». Идея была проста: накопим статистику, за сколько разработка выполняет задачу той или иной размерности, посчитаем среднее и сможем предсказывать сроки.
Погрешность в день-два заказчик нам простит — значит, никаких больше разборов полетов. А на техревью не надо будет тратить время на интерактивы и тайные голосования. Все гладко!
Работаем так несколько месяцев, собираем статистику. И только Иван на нас косо смотрит.
Выяснилось, что XS, как и S, мы делаем то за 1 день, то за 10. А на L тратим то 5, а то 15 дней. Потому что по факту какую-то работу мы берем в первую очередь, какую-то во вторую, а какую-то в пятую — и задачи одинаковой размерности проводят в статусах ожидания разное время. Упс, вот тебе и средние.
Короче говоря, тут разброс не в пару дней — и для Вани мало что поменялось. Мы признали эксперимент неудачным, но всё-таки идея о том, что задачи можно как-то категоризировать, засела в голове. И я стал думать в эту сторону дальше.

«Все любят тортики. Слоёные!» Осел из Шрека

И я люблю. К тому же, день рождения ребенка это отличный повод! Захожу на свой любимый сайтик и начинаю выбирать:
  • можно такой, а можно и не такой,
  • можно украсить, а можно не украшать,
  • можно на 2кг, а можно и на 5кг.
Не буду раскрывать свои вкусовые предпочтения, а тортик я выбрал. И привезли его к назначенной дате. Далее пойдет философия объевшегося торта тимлида.

Я, разумеется, не Ньютон, а тортик не яблоко, но озарение пришло.

Я мог выбрать из множества вариантов, но что бы я ни выбрал, дата доставки не менялась. Мне нужен был торт через неделю. И мне были готовы оказать эту услугу. А размер торта, вес и всякие прибамбасы не сильно влияли на конечный результат — точнее, в данном случае, вообще не влияли. Дело не в размере, как говорится. А в чем? В цене.
Например, у ребят был экспресс-заказ: за дополнительную плату мне привезли бы тот же навороченный торт всего через пару дней, а не через 5. Мой заказ, как наиболее ценный по сравнению с другими, пошел бы вне очереди. По сути, у кондитерской есть два SLA: для обычного заказа и для VIP. Тут есть над чем подумать.

Идея с SLA триггернула, потому что я читал про это в Канбан-гайде.

С точки зрения Канбан-метода всё есть сервис. И несмотря на то, что мы поставляем не тортики, а наш продукт нельзя пощупать или съесть – разработка тоже сервис. И мы также по-разному относимся к задачам.
Вспомним нашу доску:
Сервис состоит из нескольких этапов (разработка, код-ревью, тестирование), а колонка «Готово к разработке» — это наша точка коммита перед заказчиком.
Какие-то вещи мы делаем в своем обычном ритме, но когда прилетают горящие задачи, мы бросаем всё. Остается понять, какие у нас SLA, — и можно будет заключить соглашение с Ваней.

Как оценить SLA своей команды: строим спектральную диаграмму (это просто)

Чтобы разобраться с тем, какие классы обслуживания у нас есть и какие у них SLA, Канбан предлагает построить следующий график:
По оси Х фиксируем Lead Time (LT) — время производства задачи. В нашем случае это время от «Готово к разработке» до «Готово».
По оси Y откладывается частота — сколько задач мы сделали за LT1, LT2, LT3 и т.д.
Мы взяли закрытые за последние несколько месяцев задачи и получили следующее:
Мы закрыли 3 задачи за день, 6 — за два, больше всего — за 5, а где-то бились над таской больше двух недель…
Ну а теперь время анализировать. Что это за задачи? Почему они попали именно сюда? Почему мы делаем в определенный LT больше, чем в другие, что там? Копать можно вплоть до заказчиков и исполнителей, а также изучать комментарии к таске.
Вот что получилось раскопать нам. Это наша регулярная работа.
Разброс довольно большой, но он поддается анализу.
В целом, основная масса задач распределилась в промежутке 7-14 дней, а парочка улетела совсем далеко — в этом хвосте было несколько задач (не все) с PR в другие сервисы. Те задачи, что завершились за 3-4 дня, скорее исключение, чем правило.
Итак, я уже могу сказать заказчику, что если задача проходит как регулярная работа, с вероятностью 75% она доедет до прода за 10 дней.
А с вероятностью 90% это займет 14 дней. Ну а если разработка затрагивает другие сервисы компании, ждать придется немного дольше, — нам нужен код-ревью от другой команды и потом еще деплой.
Поехали дальше. Мы назвали этот класс «Важный».
По каким-то причинам эти задачи берутся в работу раньше других: там или больше ценности, или цена задержки выше.
И тут мы также можем озвучить SLA: с 75% вероятностью задача попадет на прод за 5 дней, с 90% вероятностью за 7. Продолжим?
Те самые задачи, ради которых мы бросаем всё и пилим, пилим, пилим — блокеры.
В 100% случаев это мелкие доработки, которые мы не учли при реализации основной фичи, либо баги, которые аффектят жизненно важный функционал на проде.
Несмотря на то, что все подобные ситуации нам удалось разрешить за 2 дня, всё равно озвучим 90’ый процентиль. Во-первых, не стоит обещать 100% — никому и никогда ???? Во-вторых, нужно закладывать вариабельность: вспомним случай с регулярной работой, когда несколько задач улетело за 20+ дней, потому что появилась зависимость от других команд.
Готово! Можем согласовать с Ваней SLA по всем классам обслуживания:

Вместо заключения

— А что мешает Ване набирать только важные задачи или блокеры?
— Горизонтальные WIP-лимиты.
Мы договорились на ограничение по количеству задач в классе обслуживания: нельзя взять больше двух блокеров, нельзя взять больше двух важных задач. У вас могут быть другие числа — это вопрос договоренностей с заказчиком. В JIRA без плагинов такие лимиты не поставишь, так что устная договоренность точно нужна. Инструменты инструментами, но без взаимодействия с людьми никуда.
Спасибо за внимание и успешного вам планирования!
]]> История о Story Points http://neogenda.ru/blog/gm5hjzn2b1-istoriya-o-story-points http://neogenda.ru/blog/gm5hjzn2b1-istoriya-o-story-points?amp=true Tue, 30 Apr 2024 10:42:00 +0300 Артур Нек Перевод статьиGil Zilberfeld, опубликованной на http://www.gilzilberfeld.com Я не люблю стори поинты. Я думаю, что это часть моего...

История о Story Points

Перевод статьиGil Zilberfeld, опубликованной на http://www.gilzilberfeld.com

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

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

Помните спецификации на сто страниц и подробные описания функций? С появлением Agile-манифеста, мы решили, что нам больше нравится сотрудничество с клиентами, чем всё это. В XP (Extreme Programming) заказчик находится на 1-м месте, поэтому время не тратилось на написание этих документов, на их чтение, неправильное толкование и разработку неправильных вещей.

Вот так пользовательские истории заменили набор функций. Это больше не было «чем-то, что позволяет делать приложение», но обрело элемент «Зачем?». В XP эта история воплотилась в тесты TDD (Test Driven Development). Спустя годы истории заменят собой спецификации BDD (Behavior-driven development). Фактические примеры того, КАК пользователь будет использовать систему и ПОЧЕМУ именно так.

Когда ещё не было Agile (хотите верьте, хотите – нет, но иногда даже сегодня), как только у нас появлялась история, сразу должен был возникнуть вопрос – когда это будет сделано?

Разработчики ненавидят этот вопрос. Существует целое движение#NoEstimates, построенное только вокруг него (вы можете прочитать кое-что об этом здесь , здесь и здесь)

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

Стори поинты – это абстракция, решившая все проблемы сразу. У неё нет единиц измерения, поэтому её нельзя привязать к каким-либо обязательствам. И если вы зададите правильные вопросы, например: «Насколько это сложно по сравнению с тем, что мы сделали в прошлый раз», то это сэкономит кучу времени на процессе оценки. Вы просто сравниваете вещи, пока они в основном похожи, вместо того, чтобы анализировать каждую историю отдельно.

Казалось, что все наши проблемы решены!

Да, но не совсем. Бизнесмены всё ещё хотели знать, сколько времени займёт история. И не только она, но и весь бэклог. Ответ был очень прост: сопоставьте часы (или дни) и стори поинты. Таким образом, стори поинты станут очередной единицей измерения. Это похоже на измерение в градусах Цельсия и Фаренгейта в одном проекте.

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

Мы также выстроили отдельные процессы с новыми единицами измерения. Используя покер планирования (Planning Poker), мы оперировали числами Фибоначчи для оценки историй. Это была другая шкала единиц измерения. Это похоже на преобразование шкалы Цельсия в нелинейную шкалу.

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

Стори поинты не спасли разработчиков от ответа на страшный вопрос «когда это будет сделано?». Но теперь от них требовалось дважды выполнить перевод между системами и всё равно дать ответ в единицах времени. На сопоставление просто потрачено больше времени.

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

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

Недавняя цитата Рона Джеффриса: «Я не уверен, был ли я изобретателем стори поинтов, но если да, то мне очень жаль».

Раньше стори поинты казались хорошей идеей. Но они стали более сложными и захватили нашу жизнь, сделав её тяжелее. Если вы используете стори поинты, вы делаете это неправильно.
]]> Об обязательствах в Канбане http://neogenda.ru/blog/xe044mo1x1-ob-obyazatelstvah-v-kanbane http://neogenda.ru/blog/xe044mo1x1-ob-obyazatelstvah-v-kanbane?amp=true Wed, 01 May 2024 10:43:00 +0300 Артур Нек Перевод оригинальной статьи James Steele, опубликованной на SquirrelNorth. Когда ситуация складывается неоднозначно, люди предпочтут придерживаться определённой позиции (даже...

Об обязательствах в Канбане

Перевод оригинальной статьи James Steele, опубликованной на SquirrelNorth.
Когда ситуация складывается неоднозначно, люди предпочтут придерживаться определённой позиции (даже ошибочной), нежели занимать позицию неопределённости и избегать обязательств при этом.
Наш типичный порядок предпочтений: № 1 — быть правым, № 2 — ошибаться и № 3 — оставаться неуверенным. Почему 1 и 2? Потому что мы зависимы от ложного чувства безопасности, которое дают нам эти обязательства.
«Большинству людей легче занять ошибочную позицию, чем сомневаться».
Организации из областей с высокой неопределенностью, таких как умственный труд или профессиональные сервисы, заплатят слишком дорого, если примут такой подход к обязательствам, «что и когда» выполнять по запросам клиентов.
Принятие слишком большого количества обязательств приводит к непредсказуемым срокам поставки. У нас так много работы в системе, что мы понятия не имеем, когда что-то будет доделано. Возникает слишком много потенциальных результатов (вариативность), появляющихся из-за неконтролируемых уровней незавершенной работы (WIP). К сожалению, даже несмотря на то, что клиенты скорее всего будут разочарованы, мы же чувствуем себя хорошо, потому что обещали многое сделать. Это ложное чувство безопасности.
Мы эмоционально привязаны к идее просто сказать «да»! Однако многие идеи, которые изначально казались хорошими, часто отвергаются, при получении большей информации. По факту, обычно отбраковывается 50% идей! Поэтому мы должны стремиться к тому, чтобы запросы клиентов оставались необязательными как можно дольше. Мы также должны ограничить количество времени, которое тратится на эту необязательную работу — тем более, если 50% этого времени скорее всего будет потрачено зря.
Ещё одним недостатком чересчур поспешного принятия обязательств является то, что мы, скорее всего, прервём работу, хотя уже потратили время и деньги на её начало. Почему? Если вы говорите «да» на всё подряд или говорите «да» слишком рано, то вы, скорее всего, соглашаетесь на множество плохих идей! Часто мы настолько сильно эмоционально привязываемся к своим обязательствам, что нам бывает трудно отказаться от них. Выбирайте с умом!
«Идеально, чтобы работа оставалась необязательной и неприоритетной как можно дольше. Вариативность имеет ценность в областях с высокой неопределённостью».
Разработка возможных опционов до их принятия (фиксации) — важная стратегия снижения рисков. Это стоит денег. Но воспринимайте это как покупку страховки, которая защитит вас от гораздо больших негативных последствий в будущем. Как, например, если вы всё-таки возьмётесь за работу, которую не хотели выполнять изначально, и в итоге прервёте её, затратив много средств. Чем неопределённее окружающая среда, тем вероятно больше страховки вы захотите.
Хорошо! Таким образом, слишком рано принять обязательство начать работу (или взять на себя слишком много работы) и не оставлять возможных опционов, может оказаться дорогостоящей стратегией в областях с высокой неопределённостью. Мы должны стремиться откладывать обязательства и оставлять запросы клиентов необязательными так долго, насколько это возможно!

Как мы это делаем?

Канбан Метод поощряет отложенное обязательство и предоставляет набор принципов и практик, которые способствуют разработке подхода к управлению рисками. Это позволяет работе оставаться необязательной. При этом обслуживание запросов клиентов становится более предсказуемым и надёжным. Это также повышает вероятность, что мы работаем над правильными вещами в нужный момент.
Конструкции в рамках Канбан Метода, которые помогают использовать отложенное обязательство:
Восходящий Канбан — способ упорядочивания опционов до того, как будет принято обязательство. Чёткое определение точек принятия обязательств.
Двухэтапные обязательства: обязательство начать работу и обязательство выполнить задачу. Механизмы распределения опционов (оплата нашей страховки) до того, как мы решим их преобразовать.
Формирование спроса — способ уравновесить спрос и наши возможности путём распределения мощности для определённых типов работы и рисков.
Обеспечение ответственного подхода к отказу от плохих опционов, чтобы мы могли избежать прерывания работы после принятия обязательств.
Практика ограничения объёма работы в системе, чтобы мы не брали на себя обязательства, превышающие наши возможности и делающие нашу поставку непредсказуемой.
Визуализация потока работы и политик, связанных с нашей работой — когда мы взяли на себя обязательства, мы можем следить за их выполнением. Наглядно продемонстрированные прерывания потока в системе с уменьшенным объёмом работы побуждают нас к обсуждениям.
]]> Рентабельность инвестиций в Канбан. Часть 4 http://neogenda.ru/blog/bom3aiask1-rentabelnost-investitsii-v-kanban-chast http://neogenda.ru/blog/bom3aiask1-rentabelnost-investitsii-v-kanban-chast?amp=true Thu, 02 May 2024 10:45:00 +0300 Артур Нек Перевод оригинальной статьи Мартина Азиза, опубликованной на SquirrelNorth. В первой части этой серии статей, посвященной базовым формам Канбан, мы рассмотрели...

Рентабельность инвестиций в Канбан. Часть 4

Перевод оригинальной статьи Мартина Азиза, опубликованной на SquirrelNorth.
В первой части этой серии статей, посвященной базовым формам Канбан, мы рассмотрели экономические преимущества перехода от отслеживания индивидуального вклада к сотрудничеству в команде. Во второй части мы увидели более ощутимую экономическую отдачу от осознания того, что командам также необходимо сотрудничать между собой. В третьей части рассмотрели сервисно-ориентированный подход Канбана, который является «золотой серединой» для достижения существенных и устойчивых бизнес-результатов. Если вы не читали первые 3 части, то, пожалуйста, прочтите их и возвращайтесь!
Успех сервисно-ориентированной модели Канбан, описанный в третьей части — хорошее достижение, ведь более сложный Канбан, который разобран в этой статье, поддастся немногими компаниями. Это связано с тем, что выход на такой уровень ограничен зрелостью культуры лидерства в организации. Необходимые характеристики должны включать:
  • Фокус на долгосрочном выживании бизнеса, а не на временном тактическом преимуществе.
  • Успех, который измеряется удовлетворением потребностей клиентов, а не позиционированием по отношению к конкурентам.
  • Любопытство, чтобы понять, как выполняется работа, а также желание что-то сделать с любыми обнаруженными пробелами.
  • Терпение, чтобы доводить начатое до конца, потому что не всё возможно исправить быстро.
  • Готовность переосмыслить структуру организации и принять решения для минимизации рисков предоставления качественных сервисов.
Именно последний момент, касающийся принятия решений, добавляет некоторую иронию к этой серии про возврат инвестиций. Практика Канбана на этом уровне деловой зрелости быстро сводит на нет использование ROI в качестве механизма принятия решений. Организации на этом уровне не принимают решения, опираясь только на быстрый возврат инвестиций. Их цель — стать лидерами рынка в предоставлении своих услуг, а также в сохранении этого статуса.

Хеджирование рисков и новые способы принятия решений

«Очень просто использовать ROI, чтобы отличить плохое решение от хорошего — ограничения ROI становятся более очевидными, когда вы пытаетесь использовать его для различения нескольких хороших возможностей».
Не надо сразу отказываться от расчёта рентабельности инвестиций, в конце концов, это дает возможность выбирать между разными вариантами предоставления сервисов. Долгосрочное предоставление сервисов с низкой рентабельностью инвестиций — маловероятно.
Очень просто использовать ROI, чтобы отличить плохое решение от хорошего — ограничения ROI становятся более очевидными, когда вы пытаетесь использовать его для различения нескольких хороших возможностей. Наличие большого количества хороших возможностей для рассмотрения — более реалистичный сценарий для многих компаний. Поэтому рентабельность инвестиций — неполный способ принятия лучших решений. Особенно на этом уровне зрелости, когда мы уже согласились с тем, что будем работать в пределах наших возможностей: мы не можем сказать «да» всем возможностям одновременно.
Рентабельность инвестиций, как механизм принятия решений, также является препятствием для инноваций, потому что новые предложения редко имеют выигрышные ROI по сравнению с расширением существующих предложений. Покойный Клейтон Кристенсен задокументировал эту проблему в своей книге «Дилемма новатора».
Принятие решений на этом уровне зрелости больше касается обеспечения того, чтобы предлагаемые сервисы были: соответствующими, хорошо согласованными с чётко определенной стратегией, придерживались распределения мощностей и хеджировали любые риски для организации. Смысл в том, что эти решения являются многомерными по своей природе в попытке достичь правильного баланса между широким спектром потребностей организации. Неполный набор факторов принятия решения может включать:
  • Распределение мощностей. Имеет ли организация избыточную или недостаточную мощность в определенных областях?
  • Риски задержки (стоимость задержки). Чем откладывание этой возможности отличается от откладывания другой?
  • Целевые рынки. Есть ли рынки, на которые компания ориентирована больше?
  • Горизонт инноваций. Каков баланс между текущими потребностями, будущими возможностями и развитием новых рынков
Более подробно я рассказываю об этом ранней статье под названием «Насколько инновации связаны с хорошими идеями?».

Количественный анализ

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

Организационные петли обратной связи

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

Выгоды

Прочитав прошлые части этой серии статей, возможно некоторые из вас ищут количественный пример, который продемонстрировал бы преимущества на данном этапе. Однако вы его не найдете, и в этом суть.
На этом уровне зрелости нас не слишком беспокоит рентабельность инвестиций. Для организации стало очевидно, что ведение бизнеса связано с рисками. Бизнес сосредоточен на управлении рисками, так чтобы организация стремилась к большим рискам своего роста (увеличение прибыли) и уменьшала свою подверженность рискам ослабления (разорение). Бизнес сосредоточен на том, чтобы организация как минимум продолжала выживать, а желательно сохраняла и приумножала своё богатство. Если вам всё ещё нужна модель рентабельности инвестиций, я предлагаю сосредоточиться на первых трёх статьях из этой серии, их уже более чем достаточно для вашего бизнес-кейса.
На этом уровне зрелости, помимо сервисов, предоставляемых компанией, возникает новая способность — быстро адаптироваться к изменениям на рынке. Она позволяет организации быстро ограничивать риски, которые могут привести к разорению, а также использовать новые возможности, которые возникают в результате изменений. Это может быть выражено в быстром выводе на рынок новых услуг/продуктов и/или увеличении или уменьшении объёма существующих услуг.
Результат этой способности — не только сервисы, которые в данный момент соответствуют запросам клиентов, а возможность поддерживать постоянное их соответствие, даже в условиях непредсказуемых и быстрых изменений.
В части 3 мы увидели впечатляющую отдачу от использования Канбана для того, чтобы ваши услуги соответствовали требованиям. В части 4 мы пошли ещё дальше, признав, что поддержание этого соответствия — это ещё одна способность, которую нам необходимо развивать. Именно так мы выходим за рамки прибыльности и создаём организацию, которая вполне может быть «построена на века».
Увидимся в следующий раз в пятой заключительной части. В ней мы завершим рассмотрение вопроса о расходах на использования Канбана в вашей организации.
]]> Что такое роадмап проекта, как его сделать и в чем его отличие от продуктового роадмапа http://neogenda.ru/blog/yb2g3bjcg1-chto-takoe-roadmap-proekta-kak-ego-sdela http://neogenda.ru/blog/yb2g3bjcg1-chto-takoe-roadmap-proekta-kak-ego-sdela?amp=true Fri, 03 May 2024 10:48:00 +0300 Дмитрий Кустов Люди, которые слабо представляют разницу между проектом и продуктом, часто путаются в понятиях. Те же...

Что такое роадмап проекта, как его сделать и в чем его отличие от продуктового роадмапа

Люди, которые слабо представляют разницу между проектом и продуктом, часто путаются в понятиях. Те же дорожные карты применяют и там и там, но из-за разных подходов их содержание будет различаться. Несмотря на то, что мы специализируемся на внедрении гибкого подхода к разработке и работе над продуктом, мы расскажем о проектном роадмапе. Так вы поймете, чем проектная дорожная карта отличается от продуктовой.
Дорожная карта или роадмап (англ. roadmap) проекта – это план действий, которые нужно сделать для выполнения проекта в рамках бюджета, требований и времени, согласованных с заказчиком.
Пример дорожной карты проекта, выполненной в сервисе GanttPRO. В качестве проекта здесь указана статья, которая пишется прямо сейчас
Далее в статье:
  • чем отличается проект от продукта и чем отличаются их роадмапы;
  • какие задачи решает дорожная карта проекта;
  • что должно быть указано в роадмапе проекта;
  • как сделать дорожную карту проекта;
  • пример дорожной карты проекта.
Если вам необходимо внедрение современных управленческих практик – обратитесь в Neogenda. За нами более 100 успешных управленческих кейсов и 5 000 обученных сотрудников в таких компаниях, как Tinkoff, Яндекс, Авито, Сбер, Билайн, Skyeng и так далее. Оставьте заявку на бесплатную консультацию в Zoom – мы предложим индивидуальное решение, с которым ваша команда достигнет лучших результатов.

В чем разница между проектом и продуктом и чем отличаются их дорожные карты

Прежде чем говорить о различиях в дорожных картах, нужно рассказать о том, чем отличаются проекты от продуктов.
Проект – это активность, которая заканчивается после выполнения всех запланированных работ. При работе над проектом исполнитель может проявлять инициативу, но в первую очередь он выполняет требования заказчика. К требованиям относятся цели проекта, техническое задание, а также бюджетные и временные рамки. За счет конкретных требований работы по проекту имеют низкую степень неопределенности, благодаря чему их можно предварительно спрогнозировать.
Пример: проектом может быть интернет-магазин, который подрядчик должен разработать для заказчика по его требованиям.
Продукт – это товар, услуга или платформа, которая закрывает потребности своих пользователей и за счет этого для них ценна. Продуктовые работы сфокусированы не на выполнение требований заказчика, а на повышение ценности продукта для его пользователей. Работы по улучшению продукта ведутся до тех пор, пока продукт приносит ценность клиентам и бизнесу, либо пока бизнес видит в этой работе смысл.
Пример: интернет-магазин тоже может быть продуктом, но тогда работа будет вестись над ним постоянно. Продуктовая команда постоянно генерирует и проверяет гипотезы по росту ключевых метрик продукта за счет выполнения тех или иных задач. Поскольку команде точно неизвестно, приведут ли работы к улучшению ключевых метрик, работа над продуктом имеет высокую степень неопределенности. Скажем, команда может внедрять на сайт дополнительные функции, чтобы поднять количество продаж, но в ходе работ выясняется, что эти функции неэффективны. Тогда работы остановятся, а ресурсы команды будут направлены на тестирование других гипотез, призванных увеличить ключевые метрики.
Свои продуктовые команды есть у множества ведущих компаний, таких как Магнит, МТС, Росбанк, Азбука Вкуса, Raiffeisen и так далее. Благодаря этому компании постепенно улучшают свой продукт, принося большую ценность для клиентов и повышая свою выручку. Именно мы помогли внедрить продуктовый подход в эти компании. Если хотите так же – обратитесь в Neogenda
Исходя из разницы между проектом и продуктом, их дорожные карты тоже будут отличаться.
Дорожная карта проекта будет состоять из проектных задач, их дедлайнов, контрольных точек проекта и планируемого бюджета на выполнение задач. Такая дорожная карта чаще всего выполнена в виде диаграммы Ганта. Как правило, роадмап не является детализированным и в нем могут меняться сроки. По завершению работ проектная дорожная карта прекращает действие.
Дорожная карта (roadmap) – это план действий, который определяет направление и последовательность развития продукта на протяжении определенного временного периода: например, квартала. Продуктовый роадмап может включать цели, бизнес-показатели, метрики, а также discovery и delivery задачи. В отличие от проектного роадмапа, продуктовый может в какой-то момент полностью поменяться: например, если выяснилось, что на рынке сильно изменились условия. Также продуктовую дорожную карту составляют на следующий период – она обновляется, пока над продуктом ведутся работы.
Так выглядит публичный продуктовый роадмап сервиса GitHub. С его помощью команда делится планами по развитию своего продукта с его пользователями. Поскольку это публичная дорожная карта, здесь нет ключевых целей и показателей метрик
Мы объяснили разницу между проектом, продуктом и их картами, поэтому теперь можем сосредоточиться на проектном роадмапе. Расскажем, какие цели он выполняет.

Цели дорожной карты проекта

  • Документирование рабочих процессов.
Дорожная карта фиксирует запланированные работы. Это удобный инструмент, чтобы согласовать их с заказчиком и закрепить договоренности с проектной группой.
  • Координация работы разных членов команд и отделов компании.
Роадмап синхронизирует действия всех сопричастных департаментов: отделов разработки, продаж, маркетинга, юридического отдела и так далее. Например, маркетинговый отдел знает, что у продукта выйдет крупное обновление – он готовит к этому случаю рекламную кампанию.
  • Обеспечение прозрачности выполняемых процессов.
По мере работ над проектом, данные в дорожной карте будут обновляться. За ними смогут наблюдать заказчик и участники проектной группы.
Теперь разберем, какие данные должна в себя включать дорожная карта проекта, чтобы эффективно выполнять свои цели.

Что должно быть указано в дорожной карте проекта

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

Основные данные

Задачи

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

Крайние сроки

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

Исполнитель

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

Второстепенные данные

  • Веха (Milestone).
Так называют контрольную точку, значимый этап в работе над проектом. Например, вехой может быть дата сдачи прототипа будущего сайта.
На том же роадмапе указаны вехи проекта, они выполнены в виде звездочек
  • Шкала приоритизации.
У каждого элемента работ может быть указана оценка, которая будет обозначать его приоритетность.
  • Бюджет задачи.
Его определяют, исходя из сложности и объема работы, необходимых для выполнения конкретных работ.
  • Взаимосвязи между работами.
Бывает, что одни работы над проектом нельзя сделать, пока не выполнены другие – это тоже можно и нужно указывать в дорожной карте проекта.
Так выглядят связи между задачами в роадмапе
Теперь вы узнали, из чего состоит дорожная карта проекта. Осталось всего-ничего: расскажем, как ее создать.

Как сделать дорожную карту проекта

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

1 этап. Определение направлений работ и ключевых целей проекта

Прежде чем планировать проектные работы, команда с заказчиком должна сформулировать ключевую цель или цели, которые нужно выполнить.
Ключевая цель – это глобальная задача, которую закрывает команда в ходе работ над проектом. Например, такой целью может быть создание мобильного приложения. Цель может быть и SMART: например, создать приложение и привлечь 10 000 пользователей до конца года. Но это возможно лишь в том случае, если команда точно знает, как достичь такого количества подписчиков в рамках проекта. В противном случае такая цель будет не проектной, а продуктовой.
У проекта в рамках роадмапа может быть несколько ключевых целей и они могут быть своими у разных команд. Например, целью маркетинговой команды может быть повышение количества регистраций, а целью команды разработчиков – релиз какой-нибудь новой функции продукта. Поэтому дорожная карта может быть разделена на отдельные сегменты, каждый из которых будет относиться к определенной команде.

2 этап. Декомпозиция ключевых целей на отдельные работы

Работу над проектом нужно декомпозировать на отдельные задачи, чтобы после рассчитать сроки и ресурсы, нужные для достижения ключевой цели.
Как это делается:
  1. Проектный менеджер должен пообщаться руководителями всех команд, которые будут задействованы в проекте. Он составляет с ними поверхностный план мероприятий по работе над продуктом.
  2. Каждый из руководителей декомпозирует работы своей команды на еще более мелкие задачи и уточняет у своей команды, какие сроки и бюджет нужны на их выполнение. Для этого применяют различные методы оценки задач: например, по аналогии, с помощью параметрической оценки или оценки по трем точкам (методу PERT).
  3. Менеджер возвращается к руководителям команд, чтобы собрать их данные и внести их в дорожную карту.
Важно: при составлении роадмапа, хороший менеджер учитывает возможные риски в работе над проектом и закладывает дополнительный буфер, чтобы работы закончились в срок.

3 этап. Составление и обновление роадмапа

В отличие от плана проекта, дорожная карта не содержит полную детализацию всех отдельных задач, которые будут делать исполнители. Поэтому менеджеру достаточно указать отдельные массивы работ и их крайние сроки. Например, в роадмапе необязательно расписывать все задачи по составлению дизайн-макета сайта. Достаточно просто создать задачу «составление дизайн-макета». Более детальные данные будут в таск-трекере, в котором будет работать проектная команда.
После того, как дорожная карта сформирована с учетом рисков, ее можно согласовать с заказчиком. Если в ходе работ над проектом происходят какие-либо изменения, проектный менеджер указывает их в дорожной карте.
А теперь перейдем к самому главному – примеру дорожной карты проекта, которую вы сможете использовать в качестве основы для своих целей.

Пример дорожной карты проекта

Мы сделали несложный образец дорожной карты проекта в гугл-таблицах на основе одного из готовых шаблонов, которые там есть. Вы можете скопировать его себе, внести туда свои данные и работать. Но все же мы рекомендуем использовать для серьезных работ специализированные сервисы, такие как Roadmunk, Jira или Venngage. С ними в разы удобнее, а еще там есть огромное количество функций, которых нет в гугл-таблицах.
Так выглядит наш шаблон дорожной карты проекта
При том, что мы специализируемся на внедрении гибкого подхода к управлению, мы разбираемся и в классическом подходе. Более того, мы не видим ничего плохого в Waterfall – если у работ можно рассчитать время и сроки, то внедрять Agile и не нужно. Но если у вас другой случай – оставьте заявку на бесплатную Zoom-консультацию от Neogenda. Мы поможем вашей компании выйти на новый уровень с помощью современных управленческих практик.
]]> Постигаем гибкие методологии: что такое Agile и почему все хотят по нему работать http://neogenda.ru/blog/9rithnedd1-postigaem-gibkie-metodologii-chto-takoe http://neogenda.ru/blog/9rithnedd1-postigaem-gibkie-metodologii-chto-takoe?amp=true Sat, 04 May 2024 11:21:00 +0300 Артур Нек Представьте: вы с командой долго работали над сложным проектом и приближаетесь к финишу. Но вдруг...

Постигаем гибкие методологии: что такое Agile и почему все хотят по нему работать

Представьте: вы с командой долго работали над сложным проектом и приближаетесь к финишу. Но вдруг клиент выходит на связь и говорит, что разрабатываемые функции больше не актуальны и нужно всё переделать. Скорее всего, команде придется пройти через такие стадии принятия, как гнев, отрицание, торг, депрессия и увольнение. Но подобных неприятных ситуаций можно избежать, если использовать Agile-подход.
Что еще за Agile? Давайте разбираться. Подготовили для вас небольшой гайд про гибкие методологии разработки, в котором рассказали, в чем суть Agile, для каких проектов подойдет метод и как использовать его для создания клиентоориентированных продуктов.

Что такое методология Agile

Agile (Аджайл) — это философия и семейство гибких методологий для управления проектами и разработки ПО.
Главные особенности подхода:
  • гибкость;
  • скорость;
  • прозрачность рабочих процессов;
  • постоянное общение: с заказчиком, клиентом и сотрудниками внутри команды.
Суть Agile в том, чтобы разбить всю работу на небольшие временные промежутки (их еще называют спринтами или итерациями). Во время каждого спринта команда разрабатывает продукт или его часть. Это помогает чаще проводить тестирование и быстрее выпускать продукт на рынок, чтобы собирать обратную связь от клиентов.
Как правило, итерации длятся 2–3 недели и разделяются на пять этапов:
  1. Анализ.
  2. Планирование.
  3. Выполнение.
  4. Тестирование.
  5. Релиз продукта.
После каждого спринта команда проводит встречу, на которой анализирует проделанную работу и собранный фидбек от клиентов, чтобы улучшить следующий цикл работы.
Этапы разработки по Waterfall

История появления метода Agile

Чтобы лучше разобраться в методологии Agile, важно узнать историю ее появления.
Метод Agile — достаточно молодой. Он появился в начале 2000-х годов. До этого широко использовалась каскадная методология разработки ПО — Waterfall.
Чтобы понять суть Waterfall, можете представить водопад. Вода (задачи проекта) стекает вниз по ступеням водопада (этапам проекта) и в финале попадает в водоем (созданный продукт).
Обычно работа по Waterfall состоит из таких этапов:
  1. Анализ требований.
  2. Проектирование.
  3. Разработка.
  4. Тестирование.
  5. Поддержка созданного ПО.
Этапы разработки по Waterfall
Отличительная фишка каскадного метода — в раннем планировании. Все этапы проекта обсуждаются и фиксируются в документах. Выполнять этапы нужно в строгой последовательности. Также нельзя возвращаться к прошлым этапам, чтобы переделывать задачи.
С одной стороны, кажется, что такое скрупулезное планирование и строгая документация — классное решение. Сотрудники четко понимают, что, как и когда делать, а у руководства есть определенность в бюджете и сроках.
Но так ли это хорошо, как звучит? На деле каскадный метод больше подходит для проектов, в которых важно четко следовать ТЗ и не отступать ни на шаг от плана. Например, нельзя построить дом и ежедневно менять что-то в плане — в конце всё просто рухнет.
Но если говорить о разработке полезного и инновационного ПО, то всё не так радужно.
Ожидание и реальность разработки ПО
Внезапные препятствия могут изменить сроки, бюджет, количество задач и даже суть проекта, из-за чего работа по каскадной модели превращается в ад, потому что:
  • нельзя быстро реагировать на изменения рынка. План создается заранее и менять его нельзя. А риски и проблемы практически невозможно предугадать;
  • тестирование — один из последних этапов работы. Из-за этого тяжело заметить ошибку, допущенную на ранних этапах. А откатиться к прошлому этапу нельзя — вода не течет наверх;
  • продукт получается не ориентированным на заказчика или клиента — их просто не подпускают к процессу разработки. А значит, нет никакой обратной связи.
  • команды зависят друг от друга. Каждый смещенный дедлайн по задаче отразится на следующей команде. Из-за этого проект может растянуться.
Разработчики посовещались и поняли — хватит это терпеть. Чтобы создать альтернативу традиционной модели, в 2000 году в штате Юта собрались 17 разработчиков и сделали Agile-манифест.

Принципы и ценностиAgile

Основные принципы Agile отражены в специальном манифесте — всего их 12.
  1. Клиент всегда на первом месте. Главная задача Agile-команды — удовлетворить потребности заказчика. Делается это благодаря быстрой и частой поставке ПО на рынок.
  2. Положительная реакция на изменения продукта. Важно понимать, что рынок постоянно меняется. Чтобы создать инновационный продукт, команда может изменять ПО на любом этапе разработки.
  3. Продукт стоит выпускать регулярно. Это нужно для сбора фидбека от целевой аудитории и постоянного совершенствования ПО. Частота выпуска может варьироваться, но классикой для Agile считается срок от 2 недель до 2 месяцев.
  4. Разработчики и заказчики работают вместе. Постоянное общение помогает оперативно решать проблемы и находить неожиданные функции. Для этого в Аджайл есть специальные встречи — каденции.
  5. Над проектом должны работать мотивированные профессионалы. Простая истина: чтобы работа была сделана хорошо, нужно нанять не просто экспертов своего дела, но и предоставить им комфортные условия, инструменты и оплату.
  6. Лучший способ передать информацию — пообщаться. В Agile стараются свести на минимум общение через менеджеров и владельцев продукта. Лучше всего общаться друг с другом напрямую и решать вопросы по мере их возникновения.
  7. Главный показатель успеха — работающий продукт. Agile-разработка — не про строгую документацию. Самое главное — быстро предоставить клиенту продукт с нужным ему функционалом. Приведем пример. Представьте, что команде нужно сделать крабовый салат, но у сотрудников закончилась кукуруза. Согласно Agile, лучше отдать клиенту салат без кукурузы, чем не отдать вовсе.
  8. Гибкие методологии разработки программного обеспечения помогают поддерживать ритм. Проще говоря, команда будет постоянно развиваться и только наращивать темп работы.
  9. Важно уделять внимание технической стороне проекта. Agile — про постоянное движение. Поэтому каждый новый проект — это возможность попробовать что-то новое и улучшить рабочий процесс или продукт.
  10. Чем проще, тем лучше. Не нужно усложнять и пытаться вместить в продукт всё и сразу. Возвращаясь к примеру с крабовым салатом, в него, как и в ПО, можно добавить огурец, рис, капусту и красную икру. Но нужно ли это вашему клиенту? Лучше сделать простой вариант и добавить новые фишки позже.
  11. Лучшие команды — самоорганизованные команды. Сработанная команда профессионалов может предложить более качественные решения, чем эксперты извне.
  12. Сила в аналитике. Этот принцип заключается в постоянном совершенствовании. Работая по Agile, стоит всегда задавать вопрос «А можно ли сделать еще лучше?». Ответить на него и подлатать слабые места помогут отчеты о выполненных задачах.
Чуть позже разработчики объединили смысл манифеста и выделили 4 ценности Agile.
4 ценности Agile
  1. Люди и взаимодействие важнее процессов и инструментов. Конечно, хорошие условия для работы также важны, но на первом месте всегда будет общение и сплоченность команды.
  2. Работающий продукт важнее строгой документации. Это не значит, что в Agile нет документов. Но если сотрудник стоит перед выбором доработать ПО или заполнить отчет, приоритет всегда будет отдаваться первому.
  3. Общение с заказчиком важнее четкого ТЗ. На встречах в приоритете будет обсуждение продукта и его функционала, а не условий договора и прописывания каждого шага в техническом задании.
  4. Открытость к изменениям важнее начального плана. Гибкость и адаптивность — ключевые качества Agile-команды.

Agile-менеджмент: преимущества и недостатки

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

Плюсы

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

Минусы

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

Где используются гибкие методологии

Хоть изначально Agile использовался в разработке ПО, игр и интерфейсов, сегодня методологию можно применять где угодно: для работы HR, SEO-специалистов, копирайтеров, бухгалтеров, фотографов, парикмахеров, маркетологов и др.
Если говорить о случаях, в которых Agile покажет себя лучше всего, то это проекты с высокой неопределенностью. В них сам заказчик не знает, каким получится конечный продукт.
Чтобы понять, подойдет ли Agile вам, посмотрите в таблицу:

Инструменты гибкого управления проектами

Прежде чем перейти к Agile-инструментам, стоит разграничить термины «философия», «методология» и «фреймворк».
  • Философия — это способ мышления и набор ценностей, которые помогают решать разные бизнес-задачи.
  • Методология — это набор правил, ролей и основных задач, которыми руководствуются при создании ПО.
  • Фреймворк — это набор инструментов, с помощью которых можно организовать работу проекта от начала до его завершения и выполнять задачи.
Сами по себе гибкие методологии не дают алгоритмов, инструментов и приемов. Поэтому Agile — это философия, которая отвечает на вопрос «Что важно?». В основе Agile лежат 12 принципов из манифеста.
Методология отвечает на вопрос «Как применить философию на практике?», чтобы добиться результата в установленный срок. Здесь учитываются: способ управления проектом, работа команды, коммуникация, общение с заказчиком и т. д. Но для методологии не важны технические детали, например, где команда отслеживает задачи — в таск-трекере или Excel-таблице.
Можно сказать, что это база любого проекта. Agile тоже считается методологией, но помимо гибкой методологии существуют и другие модели, например, традиционная модель Waterfall.
Фреймворки же отвечают на вопрос «Как именно сотруднику выполнить задачу?». Проще говоря, как применить философию и Agile-ценности на практике. Для этого можно использовать специальные инструменты и шаблоны.
Таких фреймворков достаточно много, поэтому мы расскажем про самые популярные: Скрам, Канбан и Скрамбан.

Scrum и Agile

Scrum (Скрам) — это фреймворк, с помощью которого можно реализовать Agile-философию. В основе метода — разделение работы на небольшие порции — спринты, они же итерации. Обычно спринты длятся 2–3 недели. Они нужны для быстрой поставки продукта клиенту.
Обычно Scrum используют в небольшой команде, а участникам присваиваются специальные роли, например:
владелец продукта — заказчик или его представитель;
scrum-мастер — сотрудник, связующий заказчика и команду. Именно он выстраивает процесс работы и контролирует соблюдение Agile-принципов;
разработчики — команда с различными навыками, которая формируется для проекта.
Спринты планируются заранее, а каждый этап итерации сопровождается специальными встречами и совещаниями. В конце спринта команда проводит ретроспективу — собрание, на котором обсуждает проделанную работу, анализирует сильные и слабые места.

Kanban и Agile

Kanban (Канбан) — это Метод, с помощью которого можно визуализировать рабочие процессы с опорой на Agile-ценности. В основе метода — непрерывная работа и улучшение процесса.
Суть в том, чтобы перенести этапы работы, которые проходит задача, на Канбан-доску. На ней сотрудники создают карточки — задачи, которые двигаются по колонкам и дорожкам — этапам рабочего процесса.
Такая визуализация помогает достичь полной прозрачности, грамотнее приоритизировать задачи, делегировать работу, ограничивать количество карточек, которые могут одновременно находиться в работе у сотрудников. Также Канбан-метод помогает находить и исправлять слабые места в рабочем процессе.
👉 Подробнее про Канбан-метод.

Scrumban и Agile

Некоторым командам не подходят перечисленные фреймворки в чистом виде. Поэтому разработчики берут нужные элементы из Scrum и Kanban, чтобы «смиксовать» их между собой. Так и появился фреймворк Scrumban (Скрамбан).
Например, команда может работать по Скрам и разделять работу на итерации, но визуализировать их на Канбан-доске.

Главное про Agile

  • Agile — это философия о гибкой разработке продуктов.
  • В 2000-х годах разработчики создали Agile-манифест, в котором собрали 12 принципов. Позже появились 4 ценности.
  • Agile-модель была создана в противовес таким традиционным, линейным моделям, как Waterfall.
  • Отличительные особенности Agile: гибкость, скорость, прозрачность рабочих процессов и общение.
  • Agile отлично подойдет для проектов с высокой неопределенностью.
  • Для повторяющихся проектов, в которых важно строго придерживаться ТЗ, гибкие методологии не будут так эффективны.
  • Изначально Agile использовался для разработки ПО, интерфейсов и игр, но сегодня может применяться в любой отрасли.
  • У Agile есть множество фреймворков. Самые популярные из них: Scrum, Kanban и Scrumban.
  • Чтобы успешно внедрить Agile в работу, главное — разделять его философию.
]]> Agile, Scrum, Kanban и Waterfall – что выбрать вашему бизнесу http://neogenda.ru/blog/0j9gmp9p31-agile-scrum-kanban-i-waterfall-chto-vibr http://neogenda.ru/blog/0j9gmp9p31-agile-scrum-kanban-i-waterfall-chto-vibr?amp=true Sun, 05 May 2024 11:33:00 +0300 Артур Нек Начнем с того, что Agile и Waterfall – подходы к управлению разработкой, Scrum – это...

Agile, Scrum, Kanban и Waterfall – что выбрать вашему бизнесу

Начнем с того, что Agile и Waterfall – подходы к управлению разработкой, Scrum – это Agile-фреймворк, а Kanban – метод. При этом мы собрали все сущности в одну статью и сравнили их между собой, потому что на это есть спрос.
Рекомендуем дочитать до конца – мы не только объясняем термины, но и отвечаем на интригующие вопросы:
  • в чем сила – в Agile или Waterfall и почему их любят сравнивать;
  • почему Waterfall – мифический подход к управлению разработкой;
  • насколько корректно сравнивать между собой Scrum с Kanban и можно ли их использовать вместе.
Прежде чем начнем, не можем не рассказать о себе. Neogenda – это консалтинговая компания. Мы помогаем компаниям освоить современные подходы и методы менеджмента. На нашем счету более 100 управленческих кейсов, 5 000 учеников и 40 лет практики. Наши клиенты – это Сбер, МТС, Тинькофф, Билайн, Raiffeisen Bank, Магнит, Яндекс, Авито, Азбука Вкуса и другие компании, которые вам скорее всего тоже известны. Если вы считаете, что ваш бизнес может стать прибыльнее за счет грамотного внедрения современных управленческих практик – обратитесь за бесплатной консультацией в Neogenda.
А теперь начинаем.

Waterfall

Waterfall – это подход к управлению разработкой, при котором все работы поделены на отдельные этапы. Waterfall с английского переводится как «водопад», также этот подход называют классическим или каскадным. Его отличительная черта в том, что каждый из его этапов может стартовать только после завершения предыдущего.
Этапы работы над проектом по разработке программного обеспечения (ПО). Иллюстрация взята из статьи «Managing the Development of Large Software Systems» 1970 года. Эту статью считают родоначальницей подхода, на нее даже ссылаются в Википедии. Интересный факт: слово Waterfall в ней ни разу не упоминалось – оно придумалось кем-то позже
Если слегка упростить схему, разработка по Waterfall делится на 6 основных этапов:
  1. Определение требований. Сюда относится подготовка проектной документации, в которой будет указано, каким будет ПО. В документации будут определены его функции, технические характеристики, требования к внешнему виду и так далее.
  2. Проектирование. Здесь подразумевается работа над дизайном: оболочкой будущей программы, от которой будет зависеть код. Это может быть варфрейм, прототип или дизайн-макет ПО.
  3. Реализация. Под этим этапом подразумевается написание кода.
  4. Тестирование. Сюда относятся проверка кода на ошибки и их устранение.
  5. Развертывание. В этот этап входит загрузка онлайн-приложения на сервер. Скажем, если речь идет о сайте, то это его загрузка на хостинг, чтобы его могли посещать пользователи.
  6. Техническое обслуживание. Сюда относится поддержка: устранение ошибок, не выявленных при тестировании, модернизация и так далее.
А теперь к самому интересному: почему столь известный Waterfall не то, что не работает, а вообще, – миф?
Waterfall был гипотетическим подходом к разработке, который использовали в качестве примера того, как делать не надо. Его образ был взят из классической модели производства, которая хорошо работает в других отраслях: например, строительстве. Тогда все становится яснее: например, если строить дом, не получится строить крышу параллельно с фундаментом.
Например, в той же «Managing the Development of Large Software Systems», Уинстон Ройс заявляет, что работа по такому подходу может послужить причиной 100 % перерасхода ресурсов, моделируя подобную ситуацию. Если вам знаком английский, можете прочесть работу и убедиться в этом сами. Забавно, что некоторые люди считают Уинстона основоположником каскадного подхода.
Иллюстрация из той же статьи, которая подсвечивает момент, где автор демонстрирует инкрементальный(!) подход к разработке. Здесь Уинстон представляет принцип «Сделай дважды», говоря о том, что перед релизом финальной версии ПО нужно заблаговременно создать ее рабочий прототип, чтобы не столкнуться с неприятностями при сдаче финальной версии
Еще более интересный пример. Еще раньше, в 1956 году Гербер Беннингтон выступил с докладом «Production of Large Computer Programs». В докладе рассказывается о том, что команда Гербера занималась тестированием при разработке ПО параллельно с кодингом. Выходит, что итеративный подход к разработке стали использовать в работе чуть ли не над первыми программами.
Иллюстрация из доклада Гербера, которая показывает взаимосвязь между этапом разработки и тестирования
В общем, каноничного Waterfall не существовало даже в «древние» времена – это был «козел отпущения», которого первые программисты разносили в своих работах в пух и прах.
Но это не значит, что строгое планирование не подходит для управления проектом. Работа над ПО вполне может быть поделена на этапы и ограничена временными рамками, если ее этапы и исход можно точно просчитать. Например, если веб-студия делает очередной интернет-магазин для заказчика с таким же функционалом, как и в прошлые разы, точность прогнозирования будет очень высокой. Но это все равно нельзя назвать Waterfall – тестирование всегда должно идти параллельно с кодингом, иначе дефекты можно обнаружить слишком поздно и из-за этого придется потратить много времени на переработку приложения.
Подытожим. Waterfall стоит рассматривать как полную противоположность гибкой разработке, хотя полноценный каскадный подход никто и не использует. Существуют различные методологии, которые в той или иной степени склоняются больше к гибкому или каскадному подходу к разработке. Ближе к Waterfall находятся V-Model, PMBOK, PMI и PRINCE2, которые тоже критикуют за излишние ограничения. Но они отлично подходят для управления проектами, которые легко довести до конца в запланированных бюджетных и временных рамках.
А теперь расскажем о полной противоположности Waterfall – Agile.

Agile

Agile – это гибкий подход к управлению разработкой, к которому принадлежат разные Agile-фреймворки, такие как Scrum. Нельзя сказать, что Agile – это конкретная методология, скорее это набор принципов, которым следуют те самые фреймворки.
Несмотря на то, что такие Agile-фреймворки, как Scrum, Crystal Clear, RAD и XP появились в двухтысячных годах, принято считать, что Agile окончательно сформировался в 2001 году. Именно тогда был опубликован Agile-манифест, который включает в себя четыре ценности и двенадцать принципов Agile.
Скриншот для тех, кто поленился открыть ссылку на Agile-манифест
Если сильно упростить, то манифест говорит о том, что качество ПО важнее предписаний. В Agile изменения в процессах наоборот поощряются, если они приведут к лучшему результату. А в современном мире с постоянно меняющимся рынком, работа в жестких рамках будет заведомо провальным выбором.
Если охарактеризовать Agile-подход в двух словах, можно сказать, что он итеративный и инкрементальный. Согласно Agile работа над ПО ведется итерациями – многократными цикличными процессами, которые позволяют достичь лучшего качества. Итерации заканчиваются инкрементами – новыми версиями ПО, в которых появляются дополнительные функции или оптимизируются старые.
Работая над ПО в рамках Agile, команда будет регулярно выпускать его обновленные версии, которые будут лучше соответствовать потребностям пользователей.
Теперь вы можете подумать: зачем нужны более жесткие и более гибкие фреймворки? Неужели мировое IT-комьюнити светлых и дотошных умов не выявило опытным путем лучшее решение? Ответим ниже.

Гибкий VS жесткий подход: что выбрать вам

Гибкий подход оптимален в работе над продуктом.
Продуктом будет ПО, над которым постоянно ведутся работы по его улучшению. Скажем, сайт ВКонтакте – большой продукт, над которым трудится несколько продуктовых команд, благодаря чему пользователи ВКонтакте часто получают обновления соцсети (читай, добавочную ценность продукта).
Работать над продуктом в жестких рамках неэффективно, потому что лишь малая часть идей продуктовой команды принесет ценность для пользователей, а значит, и для бизнеса. Только одно из 10 решений приводит к росту бизнеса – это конвенциональная мудрость мирового комьюнити продакт-менеджеров. Любое решение стоит ресурсов – часов работы продуктовой команды, которые могли бы заниматься чем-то более полезным или не работать вообще, не сжигая бюджет бизнеса.
Для того, чтобы определить верное решение, которое принесет выгоду, используют разные методы: например, А/Б-тестирование. Грубо говоря, это сравнение двух равнозначных вариантов: скажем, двух страниц сайта, чтобы посмотреть, на какой странице пользователи чаще оформляют заказы. По данным блога VWO, только один из восьми А/Б-тестов заканчивается успехом – остальные не выявляют статистически значимый результат. На один тест может уйти 10, 20, 30 и больше часов работы продуктовой команды – представьте, сколько это в деньгах.
А теперь вопрос: как представить работу над продуктом в рамках жесткого фреймворка? Обновления продукта еще можно подогнать под жесткий подход, где вместо требований заказчика будут гипотезы, основанные на продуктовых метриках. Но работа над продуктом с нуля обернется эпичным провалом. Гипотезы команды и заказчика, указанные в требованиях, будут не более, чем гипотезами: а значит, тратой бюджета в никуда.
Иногда пользователям нужно всего-ничего: поэтому лучше стартовать с MVP, постепенно добавляя новые функции
Жесткий подход оптимален в работе над проектом.
Проектом будет ПО, работа над которым закончится после ее успешного выполнения: сдачи согласно требованиям, а также в рамках бюджета и сроков. Например, проектом может быть интернет-магазин, который веб-студия делает для заказчика.
Студия прикинет, сколько времени и денег надо на выполнение проекта и согласует это с заказчиком. Есть риск, что интернет-магазин не выстрелит, но тут уж все зависит от компетенции студии и ее желания помочь заказчику, подсказав ему оптимальное решение на этапе инициации проекта.
В этом случае гибкий подход не нужен: если студия уже делала похожие интернет-магазины и может определить, сколько ресурсов нужно на его разработку, то лучше все тщательно распланировать и утвердить план с заказчиком.
А теперь рассмотрим фреймворки, с помощью которых можно систематизировать гибкий подход к разработке – Agile и Scrum.

Scrum

Scrum – это фреймворк для организации работы продуктовой команды согласно подходу Agile. Это фреймворк, а не методология, потому что методологию можно внедрять частично, а у Scrum есть официальное руководство с условиями – все из них нужно соблюдать, иначе процесс нельзя будет назвать Scrum. При этом фреймворк достаточно «просторный»: его можно использовать совместно с другими методами и практиками, если те не будут противоречить условиям, описанным в руководстве.

Что нужно, чтобы внедрить Scrum

Команда специалистов, а также заказчик или его доверенное лицо. Команда должна быть кросс-функциональной «боевой единицей», поскольку она будет обновлять продукт исключительно своими силами. Поэтому в команде могут быть не только разработчики, но и дизайнеры, тестировщики, продуктовые аналитики и так далее.
Спасибо, что не суисайд-сквад
Поскольку Scrum во многом нацелен на укрепление отношений между членами команды, она не должна быть большой. По нашим наблюдениям, в Scrum-команде должно быть от 3 до 7 специалистов. Для меньшего числа участников внедрять Scrum неэффективно, а если их будет больше, улучшить взаимодействие людей в команде будет невозможно. Просто не получится уделять достаточно внимания каждому из участников команды и его взаимоотношениям с другими участниками. А организация сплоченной, открытой и самоорганизующейся команды – одна из ключевых целей Scrum.

Как устроен Scrum

По сути, фреймворк нужен, чтобы команда за счет грамотной организации процессов регулярно обновляла продукт, с каждым разом делая его ценнее для пользователей. Этому служат все цели, что преследует Scrum.
Работа команды делится на циклы, которые называются спринтами (Sprint). У каждого спринта формируется цель (Sprint Goal), которая является релизом новой или улучшенной функции продукта. Чаще всего спринты длятся от 2 до 8 недель. Если сделать их дольше, они больше подвержены рискам, таким как невыполнение цели.
Участники Scrum-команды относятся к одной из трех ролей:
  • Разработчики (Developers) – специалисты, которые работают над продуктом. Несмотря на название роли, у них может быть любая специальность.
  • Владелец продукта (Product Owner) – чаще это доверенное лицо со стороны владельца продукта. Дело в том, что вряд ли настоящий владелец сможет активно вовлекаться в работу – не хватит времени. Роль выполняет строго один человек, который при необходимости будет представлять интересы возможных стейкхолдеров. Он приоритизирует задачи команды и следит за тем, чтобы продукт развивался в нужном направлении.
  • Скрам-мастер (Scrum Master) – специалист, ответственный за внедрение Scrum, а через это – за формирование самоорганизованной эффективной команды. Скрам-мастером часто является специалист извне, потому что перейти на Scrum своими силами непросто. Если команда долго работает по Scrum, роль скрам-мастера может взять на себя один из разработчиков. При этом он должен четко разделять две выполняемые роли и ответственно относиться к каждой из них.
В руководстве по Scrum описано пять событий, одно из которых – спринт, а четыре других – встречи скрам-команды, которые проходят в рамках одного спринта.
Какие события входят в спринт:
  • Планирование спринта (Sprint Planning). Это встреча, в рамках которой определяется цель спринта. Цель – это новая функция, которую планируется добавить в продукт с его обновлением после завершения спринта. В рамках планирования скрам-команда определяет, какие задачи нужно выполнить в рамках спринта, чтобы достичь цели.
  • Ежедневный скрам (Daily Scrum). Это ежедневная короткая встреча, на которой команда «сверяет часы». На ней участники команды поочередно говорят, какие задачи планируют в этот день и с какими рисками при их выполнении они могут столкнуться.
  • Обзор спринта (Sprint Review). Так называют встречу, которой завершается спринт. На ней скрам-команда делится результатами работы с заинтересованными лицами со стороны заказчика. Команда анализирует ход спринта, определяя: чего получилось достичь, какие изменения произошли в рамках спринта и над чем планируется работать дальше.
  • Ретроспектива спринта (Sprint Retrospective). Это встреча, которая проходит следом за обзором спринта. На ней команда детально анализирует ход завершенного спринта: взаимодействие участников команды и проблемы, которые возникли в ходе спринта. Также изучаются попытки решения проблем: вне зависимости от того, сработали они или нет.
  • Уточнение или груминг беклога (Product Backlog Refinement). Это событие отсутствует в руководстве по Scrum, но оно стало популярным среди скрам-команд. На нем участники оценивают трудоемкость и важность задач, которые хранятся в беклоге продукта (Product Backlog). Также команда помогает владельцу продукта сформировать условия задач, чтобы в будущем им было понятно, что именно нужно сделать.
  • Если в компании много сотрудников, которые работают над продуктом, формируется несколько скрам-команд. У них даже может быть вертикальная иерархия – одна команда может управлять другими. В этом случае скрам-мастеров недостаточно – внедрение Scrum контролирует более опытный Agile-коуч. Также у Scrum есть аналоги для больших команд, такие как фреймворк LeSS – но об этом расскажем в другой раз.
А теперь рассмотрим Kanban.

Kanban

Kanban – это метод, главная цель которого – визуализация рабочего процесса для его непрерывного улучшения. В отличие от фреймворка, метод можно внедрять выборочно, используя только те инструменты, что подходят конкретно вам. Kanban перекочевал в IT из автомобилестроения – метод придумали в 1960-х годах в Японии, в компании Toyota.
Позже опыт переосмыслил Дэвид Андерсон – признанный эксперт, который внедрял Kanban в такие компании, как Microsoft. Он адаптировал Kanban для интеллектуального труда: когда не видно производственного процесса и он находится в головах людей. Современный Kanban уже сформировал свою инструментальную модель, отличную от когда то сформированных концепций Toyota.
Главный инструмент метода – канбан-доска, которая позволяет отследить статус выполнения задач. Доска состоит из столбцов с различными статусами: например, «Ожидает», «Прототипирование», «Разработка», «Тестирование», «Верстка» и «Выполнено». По доске слева-направо перемещают задачи, размещая их в зависимости от статуса в том или ином столбце. Прелесть канбан-доски в том, что под нее можно адаптировать любой рабочий процесс, если его отдельные задачи включают в себя однородные этапы.
Пример простой канбан-доски. Скриншот сделан в сервисе Kaiten
Как видите, канбан-доска напоминает конвейер, по которому движутся задачи. Анализируя ее, можно выявить «бутылочные горлышки» – места, где задачи задерживаются. Например, вы увидели, что много задач зависает на этапе проверки, отчего замедляется их выполнение. Данные позволяют вам решить проблему: например, назначить еще одного сотрудника на проверку задач.
Но канбан-доска – базовый элемент Kanban-метода. Для более точного анализа рабочих процессов используют специальные метрики и дашборды. С ними можно отследить эффективность сотрудников, время выполнения задач, длительность простоя задач на том или ином этапе и многое другое.

Метрики Kanban

Какие метрики есть в Kanban:
  • Пропускная способность (Throughput Chart). Измеряет, сколько задач выполнила команда за определенный временной период.
  • Время производства (Lead Time). Метрика, которая отслеживает, сколько времени ушло на выполнение задачи с ее создания до завершения (прохождения всех этапов).
  • Время цикла (Cycle Time). Метрика, которая отслеживает, сколько времени уходит на выполнение задачи на том или ином этапе.
  • Работа в процессе (Work in Progress). Это количество задач, которые находятся в работе в данный момент.
  • Заблокированные задачи (Blocked Tasks). Количество задач, которые не выполняются по тем или иным причинам.
Пример диаграммы, которая показывает пропускную способность команды в разрезе по дням. Скриншот взят с сайта сервиса Kaiten
Также в Kanban предусмотрены дополнительные инструменты для оптимизации рабочего процесса:
  • WIP-лимиты. Так называется ограничение количества задач в работе. Например, можно поставить лимит в 2 задачи в столбец «Проверка». WIP-лимиты спасают сотрудников от расфокусировки, за счет чего повышается эффективность их работы.
  • Приоритеты задач. Задаче можно присвоить особый статус, чтобы сотрудник выполнял ее в первую очередь.
  • Блокировка. Специальный статус для отметки задач, которые нельзя выполнить по той или иной причине. При блокировке карточки можно указать причину, по которой она заблокирована: например, не отвечает заказчик. Отслеживание причин блокировки также позволяет выявить закономерности и оптимизировать рабочий процесс.
Как и в Scrum, в Kanban-методе приветствуется обратная связь и есть специальные события, которые предназначены для встреч по тем или иным вопросам. Встречи в Kanban называются каденциями.
Какие каденции есть в Kanban и как часто их проводят:
  • Ежедневная встреча (Daily Meeting). Служит для тех же целей, что и Daily Scrum – «сверить часы».
  • Встреча по наполнению очереди (Replenishment Meeting). То же, что и уточнение беклога – определение задач на следующий временной период и их приоритизация. Обычно проводится раз в две недели.
  • Встреча по планированию поставки (Delivery Planning Meeting). Встреча, на которой анализируются оставшиеся задачи, которые необходимо выполнить, чтобы доставить клиенту обновленную версию продукта. Обычно проводится раз в две недели.
  • Обзор предоставления услуг (Service Delivery Review). Переговоры с заказчиком, на которых уточняется, доволен ли он работой. Обычно проводится раз в две недели.
  • Обзор рисков (Risk Review). На этой встрече анализируются причины блокировок задач и предлагаются идеи по их устранению. Проводится примерно раз в месяц.
  • Обзор операций (Operation Review). Это встреча представителей разных отделов, которая проводится, чтобы улучшить рабочие процессы между отделами. Проводится раз в месяц.
  • Обзор стратегии (Strategy Review). Встреча, на которой отслеживается прогресс выполнения долгосрочных целей и при необходимости корректируется стратегия. Проводится раз в квартал.
Далее рассмотрим, что нужно учитывать, чтобы работать по Kanban.

Как работать с Kanban

Kanban включает в себя шесть основных практик, которые наиболее наглядно отражают процесс работы с его использованием:
Визуализируйте. Главная задача Kanban – подсветить рабочий процесс, чтобы выявить места, которые требуют оптимизации. Для этой цели используют канбан-доску, а также вспомогательные инструменты, такие как дашборды метрик Kanban.
Ограничивайте незавершенную работу. Компания, которая внедрила метод, должна позаботиться о том, чтобы задачи выполнялись быстро и не «подвисали». Для этого используют WIP-лимиты.
Управляйте потоком работы. Смысл этой практики в том, что вы должны контролировать ход работ, отслеживая метрики и оптимизируя их.
Используйте инструкции. Рутинные процессы, которые можно оптимизировать с помощью базы знаний и регламентов, должны быть оптимизированы. Например, внедрение регламента поможет руководителю защититься от одинаковых вопросов подчиненных и сэкономить время для более важных дел.
Внедрите петли обратной связи. Без регулярных переговоров участников команды не получится проанализировать рабочий процесс глубоко. Поэтому лучше использовать каденции, предусмотренные в Kanban.
Улучшайте рабочие процессы. Главная цель Kanban – постоянное улучшение рабочих процессов. Данный принцип напоминает об этой цели.
Чтобы внедрить Kanban, используют STATIK – план по внедрению метода, который состоит из восьми отдельных этапов: начиная с целеполагания и заканчивая дизайном системы с ее последующим запуском.
А теперь о самом интересном: можно ли внедрить себе и Scrum, и Kanban.

Можно ли использовать Scrum вместе с Kanban

Сразу ответим: да, можно. Более того, фреймворк и метод отлично сочетаются друг с другом: многие онлайн-сервисы для управления проектами уже оптимизированы под такую систему.
Например, в специализированных сервисах можно создать скрам-доску, которая по сути является канбан-доской с четырьмя столбцами: «Бэклог», «Выбрано в спринт», «В работе», и «Готово». А примером Kanban-метода в Scrum можно считать планирование на основании статистики.
Между ними можно будет перемещать задачи, а для отслеживания продуктивности по их выполнению можно использовать метрики и дашборды, которые также предусмотрены в сервисе.
Примерно так выглядит доска для Scrum, которая включает в себя инструменты Kanban-метода. Скриншот взят с сервиса WEEEK

Резюмируем

Лучших подходов, методологий и фреймворков для управления процессом разработки нет – все они «заточены» под ту или иную задачу:
  • Agile-фреймворки и методы нужны для постоянной работы над продуктом с высокой степенью неопределенности.
  • Kanban-метод по мнению его авторов не входит в Agile-когорту. При этом используя определенные наборы инструментов и практик Kanban-метода можно прийти к реализации тех же принципов, что и в Agile. Kanban можно использовать как в продуктовом и проектном управлении, так и в классическом менеджменте.
  • Классические фреймворки нужны для управления разработкой конечных проектов с бюджетными и временными рамками. Для этого используют такие методологии, как PRINCE2 и PMI.
И помните, что если вам необходима консультация или помощь по внедрению современных управленческих практик – вы можете обратиться в Neogenda.
]]> Кто такой scrum-мастер: объясняем простым языком http://neogenda.ru/blog/zzhz8b3xs1-kto-takoi-scrum-master-obyasnyaem-prosti http://neogenda.ru/blog/zzhz8b3xs1-kto-takoi-scrum-master-obyasnyaem-prosti?amp=true Sun, 05 May 2024 14:22:00 +0300 Андрей Сидоренко Чтобы понять, кто такой scrum-мастер, представьте тренера футбольной команды, который учит игроков самоорганизовываться, подбадривает их...

Кто такой scrum-мастер: объясняем простым языком

Чтобы понять, кто такой scrum-мастер, представьте тренера футбольной команды, который учит игроков самоорганизовываться, подбадривает их и интересуется успехами. При этом тренер не выбирает тактику игры – это делают сами игроки. Еще тренер не говорит, с каким счетом команда должна выиграть матч – это делает владелец футбольного клуба. Так же и scrum-мастер – он следит за тем, как команда выполняет требования Scrum, не вмешиваясь в решение рабочих задач и не указывая требования к продукту.
Scrum-мастер – это одна из ролей в Scrum, легкого фреймворка для управления продуктами, наряду с разработчиками (Developers) и владельцем продукта (Product Owner). Иногда скрам-мастера называют «скрам-менеджер» (Scrum Manager). Можно сказать, что это «неканон», но суть та же.
Задачи и обязанности скрам-мастера определены в официальном руководстве по Scrum, переведенном на русский. Но руководство написано достаточно сухо и витиевато, а еще в нем используется много специальной терминологии. Из-за этого человек, который только начал погружаться в Scrum, может что-то понять неправильно. Поэтому мы подготовили статью, в которой доступно рассказали, какова роль Scrum-мастера в команде. А еще добавим, что если вам необходимо профессиональное внедрение Scrum в компанию – вы можете обратиться в Neogenda.
И да. В написании статьи нам помог Аноним – стартапер, который хочет внедрить Scrum в работу своей команды. Он считает, что руководство Scrum – что-то обобщенное, что подходит не для всех, и уж не для его команды точно. Он пару раз задал забавные, но дельные вопросы, которые возникают в головах других предпринимателей и руководителей, если те хотят внедрить Scrum. На его вопросы мы тоже ответили.
Далее в статье:
  • для тех, кто не знает: что такое Scrum, Agile и зачем они нужны;
  • какие обязанности у скрам-мастера;
  • какие задачи выполняет скрам-мастер, а какие – нет;
  • по каким признакам оценить эффективность работы скрам-мастера.
Рассказать о роли скрам-мастера не получится, если вам незнаком процесс, который он контролирует. Поэтому сначала коротко о том, что такое Scrum и гибкие методологии разработки. Если вам все это знакомо – пропустите следующий раздел.

Коротко: что такое гибкая разработка, Agile и Scrum

Фреймворк Scrum соответствует ценностям и принципам Agile.
Agile – это гибкий подход к разработке продукта. Если охарактеризовать его в двух словах, то он итеративный и инкрементальный. Итеративный значит, что продукт разрабатывается итерациями – определенными периодами времени. Инкрементальный означает «увеличивающийся постепенно» – с каждой итерацией продукт становится совершеннее. Благодаря этому Agile позволяет быстро реагировать на изменения и чаще выпускать обновленные версии продукта. Этим он отличается от классического «каскадного» подхода, при котором все задачи запланированы далеко наперед, отчего процессы сложно изменить в ходе работы.
Важно: для лучшего понимания рекомендуем прочесть официальный манифест Agile – он всего из двух страниц. Четыре ценности и двенадцать принципов Agile-манифеста лучшим образом представляют концепт гибкой разработки. Эффективно внедрить фреймворк Scrum не получится, если команда не будет разделять ценности и принципы Agile.
Реакция читателя, который слышал о Agile, но плохо представляет, чем занимается скрам-мастер
Scrum – это фреймворк, который соответствует философии Agile. Руководство по Scrum – это свод правил, которых должна придерживаться команда, чтобы работать в рамках фреймворка. Он появился в 1995 году – с тех пор он становился все популярнее и впитывал лучшие практики команд, которые отразились в последнем руководстве за 2020 год. Ключевой принцип Scrum – постоянное улучшение процесса разработки и самого продукта.
Scrum-команда работает в рамках коротких циклов, называемых спринтами, которые длятся до одного месяца:
  • В начале каждого спринта ставится цель, планируются задачи поменьше, а завершается спринт демонстрацией готового продукта или его части, которую выпускают в релиз для пользователей.
  • В конце цикла команда анализирует его ход и рассуждает о том, как можно отработать лучше в рамках следующего спринта.
Несмотря на то, что Agile и Scrum вышли из IT, их перенимают и другие отрасли, в которых ведется постоянная работа над продуктом.
И именно скрам-мастер отвечает за то, чтобы работа команды соответствовала правилам, описанным в руководстве Scrum.

Обязанности скрам-мастера

Ненадолго обратимся к руководству по Scrum. В нем указаны обязанности всех участников Scrum-команды, в том числе и Scrum-мастера. Руководство регламентирует правильное следование методологии Scrum, поэтому без него никуда.
Но мы объясним сложную терминологию своими словами.
В 2020 Scrum Guide сказано, что Scrum Master должен способствовать возникновению среды, в которой:

1. Владелец продукта упорядочивает работу по решению комплексной проблемы в беклоге продукта.

Владелец продукта (Product Owner) может быть заказчиком или его представителем. Беклог продукта (Product Backlog) – это постоянно обновляемый перечень приоритизированных задач, необходимых для создания и улучшения продукта. То есть, скрам-мастер следит за тем, чтобы заказчик приоритизировал цели команды, необходимые для создания лучшей версии продукта.
Аноним: А мой друг, Ян, внедрил себе скрам и стал в нем скрам-мастером, хотя он является владельцем продукта. Он говорит, что у него получается совмещать сразу две задачи – я тоже так хочу.
Neogenda: Предпринимателю подойдет роль владельца продукта – он будет думать, что команде нужно сделать в первую очередь, в рамках ближайшего спринта. Скрам-мастер должен быть беспристрастен к ходу работы – он следит только за качеством рабочего процесса и самого Scrum.
Если скрам-мастер – заинтересованное лицо, которому нужен результат, правила Scrum нарушатся и от этого пострадает общая эффективность команды. Например, владелец может добавить в спринт несколько срочных задач, отчего весь спринт «сломается». Люди не получат обновленную версию продукта, время на планирование спринта будет потрачено впустую, команда не вынесет опыт из ретроспективы. Это лишь один из примеров негативного влияния владельца бизнеса на Scrum в роли скрам-мастера – их можно вспомнить десятки.

2. Скрам-команда в ходе спринта превращает выбранную работу в инкремент, несущий ценность.

Что такое спринт вы уже знаете, а инкремент (Increment) – это обновление продукта или продукт, что сделали в ходе спринта. Нужно, чтобы цель спринта способствовала улучшению продукта, а сам спринт был успешно завершен.
Если говорить о разработке ПО, в качестве цели спринта в основном используют новую функцию, которую планируют добавить в продукт. Ее удобнее всего описать в виде пользовательской истории (user story). Она обычно написана в формате «Как [роль] я хочу [функциональность], чтобы [цель]». User story помогает команде понять, что именно должно быть реализовано, чтобы удовлетворить потребности пользователей продукта.
Пример пользовательской истории: «Как покупатель я хочу видеть рекомендации товаров на основе моих предыдущих покупок, чтобы упростить процесс выбора».

3. Скрам-команда и заинтересованные лица инспектируют результаты и вносят правки для следующего спринта.

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

Задачи скрам-мастера

Поддержка и мотивация команды

В Agile-манифесте говорится: «Люди и взаимодействие важнее процессов и инструментов». Это означает, что здоровый эмоциональный фон команды важнее Scrum, являющегося по сути инструментом. Можно вспомнить один из 12 принципов Agile: «Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им».
В гайде написано, что скрам-мастер «способствует устранению препятствий, мешающих прогрессу Scrum Team». Плохая мотивированность команды или ее участников – одно из таких препятствий. Поэтому за поддержку отвечает скрам-мастер.
У хорошего скрам-мастера участники команды всегда будут как на картинке слева

Обучение команды самоорганизации

Она очень важна по двум причинам:
1.«Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд».
Это еще один принцип Agile. Эффективность достигается за счет того, что участники команды получают свободу в принятии решений – сами выбирают инструменты, методы и план работы.
2. Люди лучше всего учатся на собственном опыте.
Самоорганизация участников команды является мощным фактором роста.
Эмпиризм – это фундамент, на котором базируется Scrum. Эмпиризм как философское течение учит, что личный опыт является лучшим источником знания. Мы склонны согласиться: ни один учебник не повлияет на мировоззрение так, как это сделает пережитый опыт. Сколько раз вы скептически относились к чему-нибудь, пока не наступили на чьи-то грабли? Мы думаем, что много.
Поэтому скрам-мастер должен не быть не столько «нянькой», сколько «оракулом» коллектива. Вместо того, чтобы давать советы для устранения конкретных проблем у участников команды, скрам-мастер должен задавать им правильные вопросы, чтобы они сами приходили к верному решению и впитывали собственный опыт.
Например, вместо того, чтобы конкретно указать на проблемы коммуникации внутри команды, скрам-мастер может задать вопрос: «Какие шаги мы можем предпринять, чтобы повысить эффективность наших совещаний?» Опытный скрам-мастер – настоящий волшебник, способный добиться гармонии в команде такими вот окольными путями.

Обучение команды Scrum

В гайде написано, что скрам-мастер «направляет, обучает и коучит организацию в применении Scrum», а еще он «планирует переход на Scrum и консультирует по вопросам применения Scrum в рамках организации». Это особенно важно для команд, которые внедрили фреймворк недавно. Приучить команду к новым организационным процессам – очень непростая задача..
При этом важно: команда должна не просто следовать Scrum, а осознавать пользу от его внедрения.
На глубокое понимание Scrum могут уйти годы

Организация и проведение событий Scrum

У Scrum есть пять событий, за организацию и проведение которых отвечает скрам-мастер:
Спринт (Sprint). Про него писали выше.
Планирование спринта (Sprint Planning). Это встреча команды, в ходе которой определяется цель спринта. Максимальная длительность планирования – восемь часов, в том случае, если спринт будет длиться месяц. Если спринт короче, на его планирование нужно еще меньше времени.
Ежедневный скрам (Daily Scrum). Так называют ежедневный созвон команды. На нем участники рассказывают, что сделали за последний день, что в планах на сегодня и что может помешать им выполнить свои задачи. Цель ежедневного скрама – обеспечить прозрачность в работе команды, обнаружить отклонения от плана на ранних стадиях и помочь каждому члену команды быть в курсе текущего состояния проекта. На такой созвон должно выделяться не более 15 минут в день.
Обзор спринта (Sprint Review). Это событие, которое проводится в конце спринта. В его время команда показывает результаты работы заинтересованным лицам со стороны заказчика, но этот процесс не сводится к одной лишь презентации продукта. Во время обзора команда и заинтересованные лица анализируют, чего достигли в рамках спринта, что изменилось в ходе его проведения и над чем работать дальше. На такой созвон выделяется не более четырех часов, если спринт длится месяц.
Ретроспектива спринта (Sprint Retrospective). Данное событие проходит после обзора спринта. В отличие от обзора, во время ретроспективы команда более детально анализирует прошедший спринт, включая поведение отдельных участников команды, их взаимодействие, а также внешние изменения и рабочие практики. Цель ретроспективы – понять, как добиться лучшей эффективности в рамках следующего спринта.
Еще есть уточнение бэклога продукта (Product Backlog Refinement). Этот процесс не относится к пяти мероприятиям Scrum, но тоже важен для успешной работы над проектом. Во время этого события команда с заказчиком оценивает задачи с точки зрения их важности и трудоемкости. Также команда уточняет у заказчика критерии приемки для каждой задачи из беклога, чтобы определить, когда она считается завершенной.
Сначала может показаться, что организовать переговоры просто. На деле, закулисная подготовка скрам-мастера может занять гораздо больше времени, чем сами переговоры. Иногда требуются часы на то, чтобы выявить неочевидные детали контекста будущих переговоров. Для этого скрам-мастеры общаются с участниками команды вне рабочего времени, сами вникают в рабочие процессы и механики, а порой и консультируются с экспертами.
Аноним: А зачем тратить столько сил, чтобы созваниваться каждый день? Например, в моей проектной группе есть контекстолог, который уже давно нашел рабочие связки. Иногда у него бывают A/B-тесты, но он их проводит минимум неделю, чтобы не исказить результаты тестирования сезонностью. Мне кажется, что часового созвона раз в неделю вполне достаточно.
Neogenda: Ежедневные скрамы нужны, чтобы быстро отреагировать на изменения окружающей среды. Речь идет о проектной группе, в которой постоянно что-то происходит: например, команде из разработчиков, тестировщика и дизайнера, которые работают над разными частями продукта. Там работа одного исполнителя часто зависит от результата работы другого исполнителя, поэтому им нужно синхронизироваться чаще, причем сразу всей группой.
Выборочное внедрение техник из Scrum не является Scrum. Лучше досконально придерживаться руководства, так как его правила являются результатом многолетнего опыта мирового комьюнити. Scrum внедрили тысячи компаний, обменивающихся между собой опытом – лучшие практики меняют правила, описанные в руководстве.

Фасилитация событий

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

Координация действий скрам-команды с другими скрам-командами

В больших компаниях над продуктом работает не одна, а несколько скрам-команд. В этом случае у каждой из команд будет свой скрам-мастер и им нужно будет координировать действия своих команд. Для этого скрам-мастеры организовывают совещания между собой, посвящают друг друга в в процессы своих команд и синхронизируют спринты. Также скрам-мастеры участвуют в процессе масштабирования скрама, создавая структуру для эффективного взаимодействия между несколькими командами.
В общем, если смотреть глобально, скрам-мастер учит команду, мотивирует ее и устраняет препятствия, которые мешают команде работать. Для этого хороший скрам-мастер должен обладать рядом качеств: от развитой эмпатии до высокой самодисциплины.
А теперь расскажем, что скрам-мастер делать не должен.
Задачи, которые не выполняет скрам-мастер
Обязанности скрам-мастеров менялись с годами. В 1998 году, когда впервые появился термин «Scrum Master», тогдашние специалисты мало отличались от руководителей проектных групп: они даже давали поручения ее участникам. По мере того, как Scrum набирал популярность и «обтачивался» командами разработчиков по всему миру, лишние обязанности были упразднены.
Допустимо, если роль скрам-мастера берет на себя один из участников команды. Но на переговорах он должен четко различать в себе две роли и давать понять команде, когда он говорит от лица участника команды, а когда – от лица скрам-мастера. Лучше всего, если скрам-мастер – отдельный участник команды, который не разбирается экспертно в работе участников проектной группы – тогда у него не будет соблазна повлиять на рабочие процессы команды.
Бывает, что на скрам-мастеров «навешивают» дополнительные обязанности. Так делать нельзя – это рушит Scrum. Вот что точно не должен делать скрам-мастер:
  • Администрировать сервис для управления проектом. Участники команды должны сами администрировать свои таски – скрам-мастер может только разово помочь или подсказать, как что-то сделать.
  • Выполнять мелкие поручения команды. Несмотря на то, что скрам-мастер должен обеспечивать хорошие условия для работы команды, это не значит, что он должен быть у нее на побегушках.
  • Брать на себя менеджерские обязанности. Скрам-мастер не вмешивается в рабочий процесс и не отвечает за результат работы команды.
А как тогда понять, насколько эффективен скрам-мастер, если он почти ничего не делает руками? Давайте разберемся.

По каким признакам оценить эффективность работы скрам-мастера

Команда разделяет ценности Agile, стремится к самоорганизации и развитию, а также старается следовать Scrum. Если команда только недавно внедрила Scrum, это яркий показатель эффективности скрам-мастера. Есть и проектные группы, которые давно работают по Scrum – такие нанимают скрам-мастера для поддержки процессов и его роль в успехе команды гораздо меньше.
Переговоры команды проходят во временных рамках Scrum и заканчиваются согласием всех участников. Например, ежедневный скрам должен длиться не более 15 минут. Если команда не успевает договориться за это время, или вообще ссорится – это препятствие, которое должен устранить скрам-мастер.
Команда выявляет и устраняет препятствия, которые мешают ее работе. Например, такими препятствиями могут быть недостаточная прозрачность рабочего процесса, проблемы в коммуникации команды или частые изменения в требованиях к продукту. Этот процесс можно отследить – препятствия фиксируются на специальной доске препятствий, которую делают в той же Jira.
Каждый спринт заканчивается поставкой инкремента. Если после каждого спринта продукт получает дополнительную ценность – команда работает отлично. Главное, чтобы цели и задачи спринта были действительно значимыми. Отметим, что достижение цели не означает выполнение всех задач, запланированных на спринт.
Например, для отслеживания прогресса по выполнению задач в срок используется диаграмма сгорания работ (Burndown chart). Это график, на котором видно, как меняется количество закрытых задач с течением дней. Сложность задач измеряется в сторипоинтах, которые помогают команде оценить объем работы. Сторипоинт – относительная единица измерения, величину которой определяет сама команда.
Рост Velocity или Capacity, если это не KPI команды. Это две метрики, которыми оценивают производительность Scrum-команды.
Среднее количество стори поинтов, которое команда проходит за 2-3 последних спринта, можно считать скоростью команды (velocity). Velocity помогает команде понять свою производительность и планировать объем работы на следующие спринты.
Есть и другая метрика – «емкость» команды (capacity). Это общее количество работы, которое команда может выполнить за определенный период времени, учитывая все ограничения: например, отпуска, болезни, внешние факторы и так далее. Capacity рассчитывается из количества часов, которые каждый участник команды может работать в течение недели.
Velocity измеряет фактическую производительность команды, а capacity – ее потенциальную производительность с учетом всех ограничений. Обычно метрики применяются вместе: velocity используется для планирования работы в спринте, а capacity помогает понять, сколько работы команда может взять на себя в следующем спринте.
Важно: эти метрики полезно отслеживать при оценке эффективности команды, но не стоит использовать их в качестве ее KPI. С большей вероятностью возникнет «эффект кобры» – команда будет намеренно оценивать задачи в большее количество стори поинтов.
Команда работает так же эффективно после ухода скрам-мастера. Может показаться, что в этом случае можно было вообще обойтись без скрам-мастера. Но это не так, потому что слаженная работа самоорганизующейся команды – его заслуга.
В общем, скрам-мастер помогает команде работать в соответствии со Scrum. Опытные скрам-команды могут организоваться и без специалиста со стороны, но молодые команды точно наделают кучу ошибок, отчего только ухудшат эффективность. Поэтому роль скрам-мастера будет актуальна всегда – без него внедрить фреймворк очень нелегко.
Если вам нужно внедрить фреймворк Scrum в компанию – обратитесь в Neogenda. Мы являемся экспертами по современным подходам и методам менеджмента. За нами более 100 успешных управленческих кейсов и 5 000 обученных сотрудников в таких компаниях, как Tinkoff, Яндекс, Авито, Сбер, Билайн, Skyeng и так далее. Оставьте заявку на бесплатную консультацию в Zoom – мы предложим лучшее решение для вашей задачи.
]]> Сustomer journey map: что это такое, пошаговая инструкция – как составить http://neogenda.ru/blog/cg7huy0h21-sustomer-journey-map-chto-eto-takoe-posh http://neogenda.ru/blog/cg7huy0h21-sustomer-journey-map-chto-eto-takoe-posh?amp=true Mon, 06 May 2024 14:26:00 +0300 Артур Нек Забота о клиентах, постоянное улучшение сервиса и качества продукта помогает компаниям оставаться конкурентоспособными, привлекать новых...

Сustomer journey map: что это такое, пошаговая инструкция – как составить

Забота о клиентах, постоянное улучшение сервиса и качества продукта помогает компаниям оставаться конкурентоспособными, привлекать новых клиентов и расширять базу постоянных. Изучить потребности клиента, боли и барьеры, мешающие покупке, помогает построение CJM. Результаты исследований дают маркетологам и менеджерам по работе с клиентами понимание как улучшить пользовательский опыт и заставить клиента возвращаться за покупками снова и снова.
CJM или сustomer journey map — это инструмент визуализации взаимодействия потребителя с продуктом или услугой. Точкой старта карты является момент первого соприкосновения или знакомства клиента с компанией. Завершается путь моментом покупки, разрывом связей с компанией или переходом клиента в статус постоянных покупателей и повторной покупкой.
Составляя карту, маркетолог встает на место клиента и действует согласно мудрости Далай-ламы — «возьми его обувь и пройди его путь, попробуй его слезы, почувствуй его боли, наткнись на каждый камень, о который он споткнулся». При таком подходе удается выявить и устранить все факторы, мешающие покупке и вызывающие вопросы у клиента.
Создание CJM — это одновременно процесс анализа и метод генерации идей по совершенствованию продукта или услуги.
Далее в статье:
  • для чего используют CJM;
  • этапы клиента на пути к покупке;
  • структура CJM;
  • инструменты для построения карт;
  • инструкция как составить карту путешествий клиента.
Если вам требуется выявить проблемы бизнеса, мешающие продажам — обратитесь в Neogenda. Мы более 40 лет помогаем бизнесу достигать результатов и имеем более 100 управленческих кейсов в крупнейших компаниях, таких как Сбер, Qiwi, Газпромбанк, Skyeng, X5 Group, Avito и других. Оставьте заявку и мы бесплатно подберем для вас решение на консультации в Zoom.

Для чего используют CJM

Представления владельца бизнеса и маркетологов о том, почему клиенты выбирают продукт и как происходит процесс покупки, бывают оторваны от реальности. Маркетолог может моделировать с помощью стратегии идеальный, на его взгляд, путь, а клиент в реальности пойдет совершенно по иному сценарию, споткнется о непродуманные участки пути и уйдет к конкурентам, так ничего и купив.
Основная цель CJM — выявить все возможные сценарии взаимодействия клиента и бизнеса и довести клиента по максимально короткому и простому пути до покупки.
Но есть и другие факторы, которые помогают закрыть построение карты пути клиента:
  • Проработать воронку продаж. Изучив путь клиента, можно лучше понять как «затянуть» его в воронку на любом этапе и убрать из воронки лишние точки контакта.
  • Увеличить процент повторных покупок. Удерживать постоянного клиента гораздо дешевле, чем привлекать новых.
  • Упростить процесс покупки. Чем быстрее клиент дойдет до цели, тем выше шанс, что он «не сорвется» и совершит целевое действие.
  • Повысить клиентоориентированность сотрудников. Команда, которая знает путь клиента, имеет готовые регламенты и скрипты для работы, четко знает как довести клиента до покупки, будет работать эффективнее.
  • Предупредить потери и риски до их возникновения. Построение карты помогает подсветить проблемные и «узкие» места в бизнес-процессах.
  • Выявить возможности для роста и развития. Анализируя поведение клиента, можно выявить чего клиенту не хватает и удовлетворить его потребности.
  • Определить точки соприкосновения клиента с продуктом или брендом. Карта показывает варианты откуда клиент может узнать о компании или ее продуктах.
  • Выявить целевую аудиторию и ее сегменты. Анализ, который проводится для создания CJM, может помочь собрать информацию об аудитории продукта и сформировать портреты пользователей.
  • Усилить вовлеченность клиентов. Изучение пути пользователя позволяет выявить места, где внимание клиентов ослабевает, они теряют интерес и уходят. Эти точки контакта компания должна усилить.
Если вы хотите узнать больше о способах анализа сильных и слабых сторон бизнеса, поиске возможностей и выявлении рисков, читайте нашу статью: «Что такое SWOT-анализ и как его провести». В ней мы рассказываем как бизнесу принимать важные стратегические решения и выстраивать стратегию продвижения.
Схема маркетинговой модели AIDA
AIDA — маркетинговая модель скрытого управления клиентом, следуя которой, можно с помощью определенных действий привлечь внимание клиента к продукту, сформировать потребность и плавно подвести к покупке.
Аббревиатура фреймворка расшифровывается как:
  • A (attention) — этап привлечения внимания. Первое знакомство клиента с компанией или продуктом. Например, привлечение внимания с помощью рекламы в соцсетях, рекомендации блогера, обзора на Youtube, прочтения экспертной статьи и т. д.
  • I (interest) — этап формирования устойчивого интереса к продукту. Клиент изучает ассортимент, проводит поиск альтернатив, изучает характеристики и особенности продукта.
  • D (desire) — этап появления желания купить продукт или воспользоваться услугой. Клиент принимает решение о необходимости покупки.
  • A (action) — этап перехода к активным действиям со стороны клиента. Клиент совершает покупку продукта или услуги.
На этих этапах строится воронка продаж, где прорабатываются все возможные точки контакта клиента с брендом и попадание в воронку.
Если бренд уже имеет построенные рабочие воронки, на них можно опираться при создании сustomer journey map и выстраивании user flow (пользовательских сценариев).
После того как продукт куплен и клиент начал его использовать, путь клиента не завершается. До момента покупки бренд мог влиять на потенциального клиента с помощью маркетинга и рекламы, а после покупки на первый план выходят потребительские качества продукта и клиентский сервис. Именно от этих факторов будет зависеть, станет ли клиент постоянным покупателем или разорвет связь с брендом и не будет больше совершать покупок.
Рассмотрим два постпродажных этапа:
→ Использование. Клиент получил желаемый продукт и начал его использовать. Он оценивает его качества, сравнивает со своими ожиданиями и потребностями. Если продукт удовлетворяет потребностям клиента, следующим этапом будет повторная покупка, если нет — разрыв связи с брендом и выход из воронки продаж.
  • Важный момент: продукты могут иметь брак, дефекты, быть несовершенными и не оправдывать ожидания клиента. Но компания может иметь хороший сервис, оказывать постпродажную поддержку пользователей и своевременно отрабатывать негатив. В этом случае, даже при возникновении проблем с продуктом, клиент может остаться удовлетворенным, вернуться за повторными покупками и дать бренду второй шанс.
→ Повторная покупка или освобождение. Удовлетворенный клиент переходит на этап повторной покупки и повторяет цикл снова. Мотивировать его вернуться могут бонусы, программа лояльности, выгодные условия, специальные предложения для постоянных клиентов. Счастливый клиент становится адвокатом бренда, рекомендует товар другим и сам остается с компанией. Компании выгодно поддерживать взаимосвязь с клиентом и вкладываться в повышение лояльности и маркетинговые действия по удержанию, так как привлечение нового клиента обходится, как правило, в разы дороже.
Не удовлетворенный клиент, которого не устроил продукт, клиентский сервис или возникли неразрешимые проблемы во время взаимодействия с компанией, уходит.
  • Важный момент: компаниям стоит помнить, что основной поток стабильной прибыли компания получает от покупок постоянных клиентов. Чем дольше жизненный цикл клиента (customer lifecycle), тем больше он окупает вложения в его привлечение и маркетинг.
Например.
  • Есть клиент А, его привлечение обошлось компании в 1000 рублей. Он совершил покупку на 800, был неудовлетворен, его взаимодействие с компанией завершилось и компания при этом не смогла окупить вложения в привлечение.
  • Есть клиент Б, его привлечение обошлось в те же 1000 рублей. Первая его покупка была на 500, вторая на 800, третья на 1200. Компания на стимуляцию повторных покупок и маркетинг тратит, например, 100. При такой схеме клиент окупает вложения во время своего жизненного цикла и компания остается в плюсе и получает прибыль даже при наличии операционных расходов на удержание.
Помимо того, что постоянные клиенты выгоднее бизнесу, существует тенденция, что постоянный клиент тратит на 60-70% больше, чем привлеченный новый клиент, а их средний чек может увеличиваться со временем.

Структура customer journey map

Универсального вида у карты путешествий пользователя нет, каждая компания подстраивает этот инструмент под свои нужды, иногда корректируя параметры или добавляя необходимое конкретно для своего проекта.
Классический шаблон customer journey map представляет собой матрицу из 10 параметров.
Первые 5 параметров – это этапы взаимодействия клиента с брендом:
  1. Возникновение потребности.
  2. Поиск информации.
  3. Оценка вариантов.
  4. Покупка.
  5. Использование.
Для каждого из этапов взаимодействия оцениваются 5 факторов:
  1. Задача или мотивация. Фактор описывает о чем думает клиент, какие задачи перед ним стоят, чем он мотивируется на каждом из этапов взаимодействия.
  2. Действия персонажа. Описывает действия клиента на каждом этапе.
  3. Точки контакта. Указание где происходит контакт с клиентом: путь пользователя на сайте, в соцсетях, в блоге компании и т. д.
  4. Эмоции. Описывает что клиент чувствует на каждом из этапов: что ему нравится, чего он боится, что вызывает у него вопросы и недоумение, доволен ли он.
  5. Проблемы и барьеры. Содержит проблемы и нюансы взаимодействия, на которые клиент натыкается на каждом из этапов.
Дополнительной строкой можно выделить возможности — варианты действий для улучшения пользовательского опыта на каждом из этапов.
Примерный вид матрицы параметров для создания customer journey map
Инструменты для построения CJM
Карту путешествий пользователя можно нарисовать на бумаге или построить с помощью листочков post-it — такой способ можно использовать на летучках и рабочих совещаниях для быстрой оценки ситуации и проведения мозговых штурмов. Но для крупных проектов и командной работы такой подход не подойдет. Карта должна быть оцифрована и доступна всем членам команды. При таком варианте ее можно будет предоставить коллегам для совместной работы, презентовать в презентабельном виде клиенту, вставить в презентацию или распечатать как раздаточный материал.
Среди современных вариантов ее создания можно выделить:
1. Google Таблицы. Самый простой и быстрый вариант после рисования на бумаге или набросков на маркерной доске. Создание необходимых строк и колонок не требует особых навыков и доступно любым пользователям с базовой компьютерной грамотностью.
В таблицу можно списком занести собранные данные и поделиться с коллегами для совместной работы.
2. Доски для командной работы, такие как Miro. Карту пути пользователя можно создать с нуля или воспользоваться готовыми шаблонами сервиса.
Шаблон карты пользовательского пути в сервисе Miro
3. Графические редакторы. Если требуется красивая визуализация, например, для защиты работы перед клиентом или вставки в презентацию, то отрисовать карту можно с помощью графических редакторов, таких как Adobe Photoshop, Illustrator или Figma.
Внешний вид и содержание таких карт ограничивается лишь фантазией и навыками дизайнера и маркетологов, которые будут их реализовать.

Пошаговая инструкция – как составить карту пути клиента

Рассмотрим пошаговую инструкцию для построения карты путешествий клиента.

Шаг 1. Создание шаблона CJM или подготовка таблицы

Самый простой вариант создания карты — подготовить шаблон в «Гугл Таблицах». Переносим 10 базовых параметров в таблицу, добавляем, при необходимости, строку с возможностями и начинаем заполнять.
Пример внешнего вида CJM в «Гугл Таблицах»
Такой вариант быстрой визуализации и совместного доступа удобен во время общих совещаний или созвонов, для быстрого сбора данных и командной работы.
По мере дальнейшего анализа необходимо заносить собранные данные в таблицу.

Шаг 2. Анализ ЦА и составление портретов

  • Определить, кто наш клиент и что он из себя представляет. Какого он возраста, финансового положения, какие имеет социально-демографические признаки, географию, интересы.
  • Сегментировать аудиторию. Собранных клиентов нужно разделить на группы или сегменты аудитории.
  • Разработать портреты ЦА. Для каждого из выделенных сегментов стоит построить по одному собирательному портрету клиента. Для построения карты путешествий в дальнейшем можно будет выбрать одного или несколько наиболее значимых.

Шаг 3. Сбор данных о действиях пользователей

Описать путь пользователя можно выяснив, какие шаги он проходит до выполнения целевого действия. Собрать данные о действиях пользователей можно:
  • с помощью сервисов аналитики, таких как «Яндекс Метрика» и Google Analytics;
  • проведя анкетирование или соцопрос аудитории;
  • используя данные маркетинговых исследований;
  • используя данные из отдела продаж и менеджеров по работе с клиентами;
  • опираясь на открытые данные и кейсы конкурентов, в надежде на их правдивость;
  • используя данные статистических агентств, таких как Statista;
  • просматривая отзывы на отзовиках, маркетплейсах, в поисковых системах;
  • используя собственный опыт.
Изучая данные о действиях пользователей, стоит обратить внимание на их частые вопросы, описанные в отзывах, эмоции и уровень удовлетворенности от продукта. По мере сбора данные стоит заносить в таблицу для соответствующего этапа.

Шаг 4. Поиск точек соприкосновения продукта с клиентом

Во время анализа ЦА, составления портретов и анализа действий обычно становится ясно откуда приходят клиенты и как узнают о компании.
Точками контакта могут быть:
  • рекомендации знакомых;
  • поиск сайта;
  • взаимодействие в соцсетях;
  • поиск товара на маркетплейсах;
  • посещение офлайн-магазина;
  • просмотр рекламы;
  • участие в ивентах компании;
  • просмотр обзора блогера;
  • и т. д.
Собирать можно все источники, откуда пользователь может узнать о существовании компании или ее товара.

Шаг 5. Поиск болей клиента, сбор барьеров, мешающих купить товар

Довольные клиенты не так часто транслируют окружающим уровень своей удовлетворенности покупкой, чего нельзя сказать о тех, чья покупка не оправдала ожиданий. Недовольные клиенты пишут отзывы, оставляют обращения в техподдержку, пишут жалобы, дают гневные антирекомендации. Эти «следы» бренда в сети и нужно собрать на этапе поиска болей.
Их можно найти:
  • на сайтах отзывов;
  • в обращениях техподдержки и службы заботы о клиентах;
  • среди жалоб в разных источниках;
  • в отзывах на товары конкурентов;
  • в отзывах на маркетплейсах и агрегаторах услуг;
  • руководствуясь собственным опытом.

Шаг 6. Устранение барьеров

На шестом шаге у нас должна собраться полная картина ситуации и быть заполнена таблица с картой пути пользователя.
В ходе анализа должны обозначиться:
  • понимание клиента: кто он и чего хочет от продукта;
  • какие цели продукт должен выполнить, а какие потребности закрыть;
  • положительные и отрицательные стороны продукта;
  • понимание как пользователи его воспринимают, что думают, удовлетворены ли;
  • список того, что мешает совершению покупки.
С последним и стоит поработать на данном этапе. Для всех выявленных проблем должны быть найдены решения и варианты исправления ситуации. Их можно внести в таблицу в строку «возможности» и внести в маркетинговую стратегию компании для дальнейшей реализации.

Шаг 6. Новое построение CJM

Работать над улучшением пользовательского опыта и клиентского сервиса стоит в постоянном режиме, необходимо периодически проводить подобный анализ. Это поможет бизнесу оставаться конкурентоспособным, компании понимать текущую ситуацию и уровень удовлетворенности клиентов, а клиентам получать максимум пользы от продукта.
При таком подходе клиенты не уйдут к конкурентам, будут лояльны к компании и станут вашими постоянными покупателями.
Если вам требуется создание CJM или консалтинг бизнеса — обратитесь в Neogenda. Мы уже помогли достигнуть результата и решить проблемы менеджмента в таких компаниях, как Tinkoff, Яндекс, Авито, Сбер, Билайн, Skyeng и так далее. Оставьте заявку на бесплатную консультацию в Zoom и мы расскажем вашему бизнесу как выйти на новый уровень.
]]> Что такое SWOT-анализ и как его провести http://neogenda.ru/blog/ed7i7jl5a1-chto-takoe-swot-analiz-i-kak-ego-provest http://neogenda.ru/blog/ed7i7jl5a1-chto-takoe-swot-analiz-i-kak-ego-provest?amp=true Tue, 07 May 2024 14:59:00 +0300 Артур Нек

Что такое SWOT-анализ и как его провести

Быстро оценить ситуацию и принять верное решение в бизнесе — сложная задача, особенно для начинающих руководителей. Опираться только на интуицию и деловое чутье рискованно. В таких случаях на помощь бизнесу приходят методики стратегического планирования, такие как SWOT-анализ. Аналитика помогает увидеть не только сильные и слабые стороны бизнеса, но и выявить взаимосвязь внешних и внутренних факторов, влияющих на ситуацию. С помощью этих данных можно выстроить эффективную стратегию продвижения, опираясь на реальное положение дел.
SWOT-анализ — это метод стратегического планирования для оценки текущей ситуации по четырем факторам: сильные стороны (strengths), слабые стороны (weaknesses), возможности (opportunities) и угрозы (threats). По результатам оценки происходит принятие решений по изменениям. Например, ввод нового продукта в линейку, развитие нового направления деятельности.
Методика похожа на коуч-сессию, где клиент формирует запрос и обозначает результат, которого требуется достичь, а коуч задает наводящие вопросы. Подбирая правильные вопросы во время анализа, можно получить наиболее полную картину происходящего, оценить риски и понять, в какую сторону бизнесу двигаться дальше.
Далее в статье:
  • какие факторы и характеристики изучают для SWOT-анализа;
  • кто и для чего использует методику;
  • в чем преимущества и недостатки SWOT-анализа;
  • пример, как делать SWOT-анализ и составить матрицу решений;
  • как оценить полученные результаты.
Если вам необходимо провести стратегическую оценку бизнеса — обратитесь в Neogenda. Мы имеем более 40 лет опыта в консалтинге, помогли решить проблемы менеджмента и достичь результата продуктовым командам Сбер, Магнит, Tinkoff, Яндекс, Avito и другим. Оставьте заявку, мы бесплатно разберем ваш кейс на консультации в Zoom и предложим решение.

Расшифровка характеристик для SWOT-анализа

Все характеристики и факторы, используемые при методе анализа SWOT, делятся на внешние и внутренние.
Параметры для SWOT-анализа, необходимые для оценки ситуации

Внутренние факторы

Особенности, на которые компания может напрямую повлиять своими действиями и изменить их при необходимости.
Например: организация менеджмента, маркетинг, наличие конкурентных преимуществ, работа персонала, ценовая политика, выбор целевой аудитории, продуктовый ассортимент и т. д.
К внутренним факторам относятся сильные и слабые стороны. Рассмотрим подробнее.
Strengths (сильные стороны) — список параметров, благодаря которым компания выгодно выделяется на фоне конкурентов, удовлетворяет потребности покупателей и привлекает новых клиентов.
Сюда можно отнести:
  • высокий уровень сервиса и быструю доставку;
  • уникальный товар не имеющий аналогов;
  • подарки при первой покупке;
  • наличие системы лояльности и кэшбэка и т. д.
Weaknesses (недостатки) — минусы компании или проекта, которые замедляют его рост и развитие, вызывают недовольство клиентов.
Например: из отзывов о компании или ее продукте можно выделить:
  • текучку кадров;
  • неукомплектованность компетентными специалистами и низкие зарплаты;
  • частый брак на производстве продукции;
  • отсутствие работы с негативом и возражениями клиентов.

Внешние факторы

Влияющие извне на деятельность компании особенности, на которые бизнес не может напрямую повлиять, но может воспользоваться возможностями и учесть выявленные риски при принятии стратегических решений.
Например: меняющиеся тенденции рынка, действия конкурентов, смена законодательства и политическая ситуация, экономическая ситуация в стране или регионе, экологическая ситуация, эпидемии, природные катаклизмы и другое.
К внешним факторам относятся возможности и угрозы.
Opportunities (возможности) — факторы, которые могут положительно повлиять на развитие бизнеса, если будут использованы. На возникновение возможностей повлиять нельзя, но можно их учесть и использовать на благо бизнеса.
Например: при изменившихся условиях рынка, текстильная фабрика, выпускающая ткани, может легко сменить курс и начать производство медицинских масок, а компания, реализующая продукцию только в офлайн-магазинах, может
выйти на маркетплейсы, набирающие все большую популярность.
Threats (угрозы) — факторы, которые могут отрицательно повлиять на развитие бизнеса и нанести ему ущерб. Часть угроз невозможно предугадать заранее и как-либо повлиять на их возникновение. Если есть риски, которые могут быть спрогнозированы — стоит их учесть в стратегии и постараться избежать либо минимизировать ущерб.
Пример 1: в столярной мастерской, изготавливающей мебель, есть высокий риск пожара из-за работы с быстро воспламеняющимися материалами. Для предотвращения этого стоит заранее принять все возможные меры противопожарной безопасности, провести обучение сотрудников и установить необходимое оборудование для своевременного обнаружения и ликвидации очагов возгорания.
Пример 2: сеть ресторанов находится на побережье моря и получает стабильный ежегодный заработок от потока туристов. Но в одно лето случается стихийное бедствие — проливные дожди приводят к наводнению. Бизнесу приходится восстанавливаться и терпеть убытки, но повлиять на это никак нельзя.

Задачи и цели SWOT-анализа

Руководителям бизнеса и управленцам постоянно приходится принимать быстрые решения, от которых зависит дальнейшая судьба проекта или даже всей компании. В рабочей текучке не всегда просто взглянуть на ситуацию объективно, привести нужные аргументы и обосновать правильность решения не только с точки зрения интуиции, но и опираясь на аналитические данные. В таких ситуациях поможет SWOT-анализ компании.
Компании могут опираться на данные анализа для следующих целей:
  • формирования уникального торгового предложения на основе выявленных сильных сторон;
  • улучшения клиентского сервиса, перестройки бизнес-процессов на основе выявленных недостатков;
  • повышения конкурентоспособности за счет устранения недостатков;
  • повышения качества продукции, процессов производства;
  • оценки рисков и принятия мер по предотвращению угроз;
  • проработки маркетинговой стратегии;
  • принятия решений о выводе новых продуктов на рынок или запуске других направлений;
  • проверки бизнес-идей;
  • оценки позиции компании на рынке;
  • выявления потенциальных точек роста и развития компании, определения прибыльных направлений.
Главная цель SWOT-анализа — получить объективную оценку ситуации и помочь в принятии управленческого решения, влияющего на рост и развитие компании.
Если вы хотите узнать больше о внедрении методов управления компанией, читайте нашу статью: «От целей – к результатам: что такое OKR и как он поможет твоему бизнесу». В ней мы делимся техниками эффективного управления и постановки целей сотрудникам.

Область применения SWOT анализа

SWOT-анализ является универсальным инструментом и может применяться в разных сферах и областях таких как образование, здравоохранение, экология, социальная сфера и другие. Инструмент направлен на оценку объектов и решений, что позволяет применить его для любого объекта:
1. Бизнеса. Рассматривается бизнес в глобальном понимании, его плюсы и минусы. Результатом оценки является стратегия дальнейшего развития бизнеса.
Пример. Бизнес остановился в росте, продажи не растут, доходность остается на одном уровне несмотря на прикладываемые усилия. Во время анализа SWOT детально разбирается возникшая ситуация, анализируются факторы, которые не дают развиваться, возможности, которые могут быть использованы для преодоления проблемы и составляется стратегия дальнейшего продвижения.
2. Проекта или инициативы. Рассматривается отдельный проект или направление бизнеса, его работа, доходность, сильные и слабые стороны. Проектные менеджеры могут использовать анализ при оценке внутренних и внешних факторов, влияющих на успешное завершение проекта, и разработке стратегии управления рисками.
Пример. Проектные менеджеры могут использовать анализ при оценке внутренних и внешних факторов, влияющих на успешное завершение проекта, и разработке стратегии управления рисками.
3. Продукта или услуги. Анализ помогает в оценке конкурентного положения продукта или услуги, и разработке маркетинговой стратегии.
Пример. Есть типография, которая занимается изготовлением наружной рекламы, баннеров и одно из направлений — печать табличек на дом. Их заказывают не часто, но направление потенциально выгодное. При анализе разбираются сильные стороны, которые могут привлечь больше клиентов. Например, уникальный дизайн табличек. Выявляется неиспользуемая возможность — реализация товара на маркетплейсах. Это решение помогает увеличить продажи и развить выгодное направление.
4. Личности или карьеры. При анализе оценивают конкретного человека с целью принятия решения или поиска вариантов профессионального и карьерного роста.
Пример. С помощью SWOT можно оценить каждого сотрудника, его сильные и слабые стороны, понять что тормозит его движение по карьерной лестнице и какие навыки стоит развить для роста скиллов или получения повышения.

Преимущества и недостатки метода

К плюсам метода можно отнести:
  • Простоту проведения анализа. С методикой справится любой руководитель или команда проекта, не требуется привлечение сторонних специалистов и бизнес-аналитиков.
  • Возможность стать лучше для компании. В ходе анализа выявляются недостатки, которые могут быть устранены, и преимущества, которые можно усилить.
  • Универсальное применение. Метод можно использовать для SWOT-анализа проекта, компании, филиала в конкретном регионе или бизнесу в целом.
  • Наглядность и структурированность информации. Информация разбита по категориям, ее можно проанализировать как в частности, так и отследить взаимосвязи.
  • Заблаговременное выявление угроз. Зная риски и потенциальные угрозы, к ним можно подготовиться, принять меры или минимизировать потери.
Минусы метода:
  • Невозможность учета изменений. С помощью метода происходит оценка ситуации «в моменте» и полученные данные не учитывают возможные изменения в будущем.
  • Нет конкретных цифр. SWOT матрица и данные анализа содержат факты о компании или анализируемой ситуации без указания конкретных метрик и данных.
  • Для анализа нужны полные и исчерпывающие данные. Для объективной оценки нужны достоверные и полные данные, которыми может не обладать специалист со стороны или неопытный руководитель.
  • Ошибки в выводах и слишком субъективная оценка. При оценке рассматривается множество характеристик и факторов, их взаимосвязи и зависимости. Неверная трактовка данных или выдвижение необоснованных гипотез может
  • привести к ошибкам.

Виды SWOT-анализа

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

Как сделать SWOT анализ: пошаговый план

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

Поиск сильных сторон

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

Поиск слабых сторон

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

Определение возможностей

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

Поиск угроз и рисков

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

Пример как делать SWOT-анализ

Разберем методику SWOT на примере анализа малого кафе. Аналитика внутренних и внешних факторов даст понять его текущее положение на рынке и определит стратегию дальнейшего развития.
Сильные стороны:
  • Качество продукции. Кафе предлагает высококачественные блюда и напитки, приготовленные из свежих ингредиентов.
  • Уникальный интерьер. Кафе имеет стильный и уютный интерьер, который создает приятную атмосферу для посетителей.
  • Удобное расположение. Кафе расположено в центре города, рядом с офисными зданиями и торговыми центрами, что обеспечивает большой поток клиентов.
  • Привлекательные цены. Цены на меню кафе доступны для широкой аудитории, что делает его привлекательным местом для посещения.
Слабые стороны:
  • Ограниченное меню. Меню кафе имеет небольшое количество позиций и не имеет некоторых привычных категорий блюд и напитков.
  • Недостаточное пространство. Кафе имеет небольшую площадь, что приводит к переполнению и длительному ожиданию заказов.
  • Мало рекламы. Кафе не проводит достаточно рекламных активностей, что снижает его видимость на рынке и привлекательность для новых клиентов.
Возможности:
  • Расширение меню. Кафе может расширить свое меню, добавив новые категории блюд и напитков, чтобы привлечь больше клиентов и удовлетворить разнообразные вкусы.
  • Внедрение программ лояльности. Программы лояльности и скидки для постоянных клиентов помогут удержать существующих клиентов и привлечь новых.
  • Улучшение маркетинга. Кафе может привлечь больше внимания к своему бренду и привлечь новых клиентов используя социальные сети, акции и события.
  • Развитие доставки. Доставка еды может расширить аудиторию кафе, позволяя клиентам заказывать еду прямо к себе домой или в офис.
Угрозы:
  • Конкуренция. Наличие других кафе и ресторанов в окрестностях создает конкурентную среду, что может снизить прибыльность кафе и уменьшить поток клиентов.
  • Экономические факторы. Инфляция или рост цен на продукты, могут повлиять на операционные затраты и способность кафе удерживать доступные цены для клиентов.
  • Изменения в потребительских предпочтениях. Изменения во вкусах и предпочтениях клиентов могут потребовать от кафе изменений в меню или обслуживании, чтобы оставаться конкурентоспособным.
  • Законодательство и регулирование. Изменения в законодательстве, такие как требования по безопасности пищевых продуктов или налоговые изменения, могут повлиять на операционные расходы и процессы кафе.
  • Проведение SWOT-анализа поможет кафе лучше понять текущее положение на рынке, выявить ключевые факторы, которые могут повлиять на его успех, и разработать стратегии для улучшения своей конкурентоспособности и удовлетворения потребностей клиентов.

Результат SWOT-анализа

Трактовать результаты анализа можно быстро просматривая собранные данные по внешним и внутренним факторам или провести более углубленное исследование и сформировать матрицу решений.
Матрица SWOT-анализа состоит из комбинации факторов и помогает выстроить четыре стратегии:
  1. Стратегия развития. S + O или сильные стороны + возможности. Сюда стоит указать все варианты – как бизнес может использовать свои преимущества для реализации потенциальных возможностей. Например, компания активно ведет свои соцсети и имеет большую аудиторию (преимущество) и хочет принимать заказы на доставку через чат-ботов в соцсетях, а конкуренты их не используют (возможность). Компания внедряет в работу этот инструмент и получает поток заказов через канал, которого нет у конкурентов.
  2. Стратегия улучшения. W + O или слабые стороны + возможности. Выделяем все варианты, при которых недостатки бизнеса могут помешать использовать возможности для развития. Например, у компании мало менеджеров, которые могут общаться с клиентами или они недостаточно опытные (недостаток), а при внедрении чат-ботов увеличится поток заказов и компания может с ними не справиться (упущение возможности).
  3. Стратегия защиты. S + T или сильные стороны + угрозы. Определяем, как преимущества бизнеса могут помочь избежать или защититься от потенциальных угроз. Например, компания производит обувь ручной работы под точные мерки заказчика из премиальных материалов, заказчик может выбрать материал и внешний вид изделия (преимущество). Есть новые конкуренты, которые недавно появились и делают похожую обувь, но быстрее и дешевле (угрозы). Но у конкурентов есть отличие — они делают обувь только под конкретный размер и из более дешевых материалов. Вывод — более дорогостоящий товар, сделанный под конкретного клиента, не будет конкурировать с товаром для массового потребителя, и на него все равно будет свой покупатель.
  4. Стратегия предупреждения. W + T или слабые стороны + угрозы. Недостатки компании могут сильно ухудшать положение бизнеса при возникновении внешних угроз. Например, клиенты жалуются на недостатки и брак продукта (слабые стороны), а на рынок выходит конкурент с более совершенным и современным продуктом, не имеющим подобных минусов (угроза). Если слабая сторона не превратится в сильную и компания не проявит гибкость для изменения, то клиенты могут полностью уйти к конкурентам.

Ошибки при проведении анализа

  • Мало данных. Недостаток данных может привести к упущению ключевой информации, необходимой для адекватной оценки ситуации.
  • Отсутствие объективности. Субъективность и предвзятость при оценке внутренних и внешних факторов может привести к искаженному представлению о реальной ситуации.
  • Недостаточная специализация у проводящего анализ. Отсутствие опыта или знаний в области, для которой проводится анализ, может привести к упущению важных аспектов или неверной интерпретации данных.
  • Игнорирование контекста. При игнорировании тенденций рынка, политической ситуации, социокультурных факторов могут быть существенные ошибки в выводах.
  • Нет оценки взаимосвязи факторов. При оценке факторов по одиночке могут возникнуть ошибки в выводах. Стоит оценивать взаимосвязь между факторами в контексте друг друга.
  • Недостаточное участие заинтересованных сторон. Участие в анализе сотрудников, клиентов, партнеров, увеличит широту анализа и поможет не упустить важные данные.
  • Отсутствие альтернативных сценариев. При анализе стоит рассматривать не только текущее положение дел, но и возможные варианты развития событий, чтобы разработать адаптивные стратегии.
  • Редкий повторный анализ и игнорирование изменений ситуации. Сделать SWOT-анализ один раз и надолго — не получится. Необходимо регулярно обновлять анализ, чтобы учитывать новые тенденции рынка и своевременно корректировать стратегию.
  • Игнорирование результатов анализа и бездействие. Проведение анализа без последующих действий по реализации разработанных стратегий — бесполезная трата времени.
Если вам нужно провести комплексную оценку бизнеса и выстроить грамотную стратегию продвижения — обратитесь в Neogenda. Мы реализовали более 100 успешных управленческих кейсов и обучали сотрудников в таких компаниях, как Tinkoff, Яндекс, Авито, Сбер, Билайн, Skyeng и так далее. Оставьте заявку на бесплатную консультацию в Zoom, и мы поможем вашему бизнесу найти новые точки роста.
]]> Управление портфелем проектов: как устранить неразбериху в проектах вашего бизнеса http://neogenda.ru/blog/payrdvvf11-upravlenie-portfelem-proektov-kak-ustran http://neogenda.ru/blog/payrdvvf11-upravlenie-portfelem-proektov-kak-ustran?amp=true Wed, 08 May 2024 08:39:00 +0300 Артур Нек Представим, что вы – владелец молодой, динамично развивающейся компании со всеми ее атрибутами, такими как...

Управление портфелем проектов: как устранить неразбериху в проектах вашего бизнеса

Представим, что вы – владелец молодой, динамично развивающейся компании со всеми ее атрибутами, такими как дружелюбный и энергичный коллектив. Все отлично работают, дела идут вверх. Но есть проблема: запущено столько разнородных процессов, что их становится невыносимо тяжело контролировать. Что ж, поздравляем! Настало время внедрить новую управленческую практику – портфель проектов.
Портфель проектов – это совокупность проектов, объединенных для более эффективного управления и достижения стратегической цели бизнеса. Реализуют в таблице или специализированной программе – там указывают все ключевые данные по различным проектам, отсортированные по их общим признакам. Портфель проектов дает возможность оценить, насколько успешно компания следует планам в среднесрочной перспективе.
Примерно так будет выглядеть портфель проектов. Этот сделан в сервисе GanttPRO – есть и другие
Далее расскажем:
  • какие задачи выполняются с помощью портфелей проектов;
  • какие сущности включают в себя портфели проектов;
  • как составить и внедрить портфельное управление проектами вашему бизнесу.
Если вашему бизнесу нужна помощь во внедрении современных управленческих практик – обратитесь за бесплатной консультацией в Neogenda. С нами работают крупнейшие корпорации: Сбер, Тинькофф, Яндекс, Авито, X5, Азбука
Вкуса и еще десятки других компаний, которые точно вам известны. Мы можем помочь в оптимизации рабочих процессов компании с любым штатом сотрудников. Свяжитесь с нами, чтобы провести реорганизацию бизнеса правильно и выйти на новые результаты.
Какие задачи выполняются с помощью портфелей проектов

Приоритизация проектов

Ресурсы любой компании ограничены. Чтобы компания выжила и развивалась быстрее, в первую очередь нужно запускать самые перспективные проекты.
Проблема проектов в том, что они разнородны, отчего их тяжело сравнить. Без бизнес-портфеля руководство гораздо чаще принимает неверные решения, выбирая проекты в работу по собственному наитию.
Пример. Федор, владелец интернет-магазина, запланировал ряд работ, направленных на повышение количества заказов с сайта. Среди прочих проектов, в планах была настройка контекстной рекламы и оптимизация страницы оплаты. Из-за того, что Федор не приоритизировал задачи, он вложил средства в контекстную рекламу, а работы по сайту отложил на потом. Рекламу настроили, но медленная и неудобная страница оплаты отталкивала значительную часть клиентов. Если бы Федор грамотно приоритизировал задачи, он бы получил больше прибыли.
Даже руководители с большим опытом принимают неверные решения, если руководствуются одной лишь интуицией

Оценка и распределение ресурсов компании

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

Контроль следования стратегическим целям

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

Корректировка плана работ

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

Какие сущности включают в себя портфели проектов

Вне зависимости от того, где вы соберете свой портфель: в Гугл-таблице или специализированном сервисе для управления проектами, в нем будут присутствовать эти данные:
  • Цель.
Портфель проектов включает в себя те работы, которые направлены на достижение одной или нескольких целей. Такая цель может быть SMART: например, увеличить количество покупателей на 20 % до конца года.
  • Проекты.
Это очевидно, так что идем далее.
  • Контрольные вехи.
Портфель проектов может иметь собственные временные рамки, которые будут шире, чем у отдельных проектов. Например, часть проектов из портфеля может относиться к оптимизации сайта. Все эти проекты могут иметь свой крайний срок, до которого их нужно выполнить – после команда будет выполнять другие задачи из портфеля.
  • Ответственные исполнители.
Портфель проектов будет содержать данные о лицах, ответственных за те или иные работы. Чаще всего в нем указывают проектных менеджеров, которые отвечают за тот или иной проект.
  • Ресурсы.
В портфеле проектов скорее всего будут присутствовать данные о количестве часов, необходимых для выполнения проектов или данные об их бюджетах.
  • Взаимосвязи между проектами.
Одни проекты не могут быть взяты в работу, пока не будут выполнены другие. Например, нельзя запустить рекламу на сайт, пока он не доделан. Такие зависимости тоже можно указать в портфеле проектов.
Идея подарка для вашего менеджера портфеля проектов – не благодарите
Теперь перейдем к практике: расскажем, как составить портфель проектов самому.
Этапы управления портфелем проектов: как его составить и внедрить
Читайте также: Дорожная карта проекта: как сделать + примеры

1 этап. Определяем ключевую цель

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

2 этап. Собираем проекты

Чтобы собрать проекты для составления будущего портфеля, их нужно привести в единый вид.
Какие данные о проектах вам понадобятся на этапе их сбора:
  • Описание работ и их результата. Чтобы сравнивать проекты между собой, в них нужно ориентироваться. Для этого нужно достаточно подробно описать, чего конкретно планируется достичь по выполнению проекта.
  • Крайние сроки проектов. Дедлайны проектов могут быть определены как до составления портфеля проектов, так и в его ходе. Например, если проекты поступают от клиентов, их крайние сроки будут предопределены. А если проекты касаются компании, руководство может выстраивать их крайние сроки, исходя из рамок портфеля.
  • Ресурсы, необходимые для выполнения проекта. Сюда относится количество человек, их специализация, а также планируемый бюджет или количество трудочасов на выполнение всех задач проекта. Например, для выполнения проекта может понадобиться 6 часов работы дизайнера и 9 часов работы верстальщика – все сразу понятно и прогнозируемо.
  • Особые условия для работы над проектом. Нужно выяснить, могут ли быть сложности при ведении того или иного проекта. К примеру, для запуска работ может понадобиться какой-нибудь высококлассный узкопрофильный специалист, которого будет тяжело найти. Все подобные риски нужно предусмотреть и устранить еще до возможного запуска проекта, если это будет оправданно.
Этих данных достаточно, чтобы предварительно собрать все имеющиеся проекты для их последующего отбора в портфель. Далее нужно выбрать критерии, по которым они будут сравниваться.

3 этап. Выявляем критерии для приоритизации проектов и приоритизируем их

Чтобы наиболее точно выявить самые перспективные проекты, лучше всего использовать систему взвешенных показателей. С ней у каждого из подобранных критериев будет своя степень влияния на итоговую оценку, потому что разные критерии обладают разной важностью.
В качестве примера приведу способ оценки проектов для интернет-маркетингового агентства, которое работает над клиентскими проектами. Агентство занимается настройкой контекстной рекламы: все клиенты у него на поддержке и платят каждый месяц. Представим, что агентство хочет создать портфель проектов, чтобы более точно распределять свои рабочие ресурсы между ними. И в случае нехватки ресурсов, сфокусироваться на более перспективных проектах.
Если пофантазировать, в этом случае можно представить следующие критерии оценки приоритетности проектов у агентства:
  • Доля ежемесячного платежа клиента от всей выручки за месяц. Если один клиент платит больше других, за него нужно сильнее держаться. Уход такого клиента будет более серьезным ударом для бизнеса, нежели уход клиентов, что платят меньше. В этом случае оценкой будет не число, а процентный показатель, на который можно умножать сумму баллов по другим критериям. Только процент мы укажем в виде десятичной дроби: например, если значение равно 5 %, то это будет 0,05. Пусть переменной этого критерия в формуле будет D.
  • Маржинальность проекта для агентства. Работа с одними клиентами может быть более выгодной, чем с другими. Можно оценить маржинальность проекта, если вычесть из бюджета проекта все издержки: например, оплату работы участников проектной группы. Далее можно перевести маржинальность проекта в коэффициент, с которым будет проще работать в формуле. Например, если чистая прибыль агентства равна 20 % от бюджета проекта, его можно указать в формуле в виде коэффициента 1,2. Переменная этого критерия: M.
  • Качество отношений с клиентом. Например, можно замерять NPS у своих клиентов и использовать его в качестве оценки. Если клиент чем-то недоволен, можно повысить его приоритетность, чтобы сосредоточить больше усилий на его проекте. Как и в случае с предыдущим показателем, процентный индекс лояльности клиента можно указать в виде коэффициента. Допустим, NPS в 20 % будет равен 1,2, а NPS в 80 % – 1,8. Переменная: Q.
  • Потенциал развития деловых отношений с клиентом. Зная проект, можно предположить, какова вероятность того, что объем работ увеличится и насколько сильно он увеличится. Чем больше вероятность развития отношений с клиентом и увеличения объема работ, тем он ценнее. Можно ставить проектам баллы по шкале от 0,1 до 1 с шагом в одну десятую. Такой показатель будет оцениваться интуитивно, исходя из контекста работы с клиентом и информации с его стороны. Переменная: P.
Исходя из критериев и переменных, которые мы им присвоили, можно составить примерно такую формулу:
Приоритетность проекта = ((Q + P) * M) * D
В этой формуле мы сначала складываем показатели «Качество отношений с клиентом», который в примере будет коэффициентом от NPS и «Потенциал развития деловых отношений с клиентом», который может быть оценкой от 0,1 до
1. Далее их сумму мы умножаем на показатель «Маржинальность проекта для агентства», который также будет выражен в коэффициенте: например, 1,2, если 20 %. И в самом конце мы умножаем все это на показатель «Доля ежемесячного платежа клиента от всей выручки за месяц».
Вот пример расчета:
Приоритетность проекта «Солнышко» = ((1,9 + 0,7) * 1,3) * 0,12 = 0,4056
Объясним, почему мы решили сделать именно так.
Качество отношений с клиентом и потенциал развития этих отношений нам кажутся самыми малозначительными критериями, если рассматривать их с точки зрения «здесь и сейчас». Представим, что мы хорошее агентство и все наши клиенты более-менее довольны услугами, такие мы сами не работаем с неадекватными клиентами, которые приносят больше бизнесу урона, чем пользы. Следовательно, сильной разницы в показателях разных проектов по этому критерию у не будет. Потенциал развития отношений тоже не так интересен, если нужно приоритизировать проекты в ближайшее время, чтобы быстро навести порядок в рабочих процессах.
Теперь попробуем выяснить приоритетность нескольких гипотетических проектов, используя Гугл-таблицу.
Можно увидеть, что численный показатель приоритетности обрел разные значения у разных проектов. Далее проекты можно отфильтровать по итоговому значению их приоритетности, и если результат расчетов вас устраивает, сделать такие показатели приоритетности финальными.
Примерно так может выглядеть расчет приоритизации проектов – таблицу сохранили
Можно увидеть, что численный показатель приоритетности обрел разные значения у разных проектов. Далее проекты можно отфильтровать по итоговому значению их приоритетности, и если результат расчетов вас устраивает, сделать такие показатели приоритетности финальными.
Так выглядит та же таблица, если отфильтровать проекты по итоговому показателю приоритетности
Если полученное значение показалось нам необъективным, мы можем чуть усложнить формулу, добавив к ее показателям веса.
Например, мы можем решить, что показатель «Качество отношений с клиентом» слишком сильно влияет на формулу – его значения колеблются от 1,5 до 1,8, в то время как численные значения показателя «Потенциал развития деловых отношений с клиентом» в среднем в два раза меньше.
Можно уравновесить показатели между собой, добавив вес в 50 % к показателю «Качество отношений с клиентом». Это значит, что каждое значение этого показателя мы будем делить на два – тогда значения показателя по проектам будут ближе к показателю «Потенциал развития деловых отношений с клиентом». Благодаря этому показатели столбца «Качество отношений с клиентом» будут оказывать примерно такое же влияние на итоговый расчет приоритетности, как и значения показателя «Потенциал развития деловых отношений с клиентом».
Тогда модернизированная формула будет выглядеть так:
Приоритетность проекта = ((0,5 * Q + P) * M) * D
Поясняем: в этой формуле мы сначала умножаем показатель Q («Качество отношений с клиентом») на 0,5, что по сути является делением на два. Дальше все считаем так же: прибавляем P, умножаем сумму на M, а в самом конце умножаем полученный результат на D.
За счет этого показатели приоритетности изменятся и, скорее всего, изменится порядок приоритизации проектов.
Так будет выглядеть расчет приоритетности с измененной формулой – обратите внимание на строку формулы. Кстати, этот лист тоже есть в таблице с примером расчета, которую мы расшарили
Если сравнить таблицы с двумя разными расчетами между собой, можно увидеть, что их результаты практически не отличаются – два проекта поменялись местами в чарте, только и всего. Но в вашем случае изменения могут быть более сильными.
На данном этапе нужно составить ту формулу, которая лучше всего будет соответствовать вашей задаче. После того, как вы внесете все данные в таблицу и составите предварительный расчет, вы можете «поиграть» с показателем приоритетности. Для этого нужно слегка видоизменять формулу и наблюдать за тем, как меняются итоговые результаты расчетов, чтобы прийти к наиболее оптимальному на ваш взгляд расчету.
В своем расчете вы можете использовать любые метрики и критерии, что подходят на ваш взгляд. От себя добавим, что при скоринге проектов популярны такие метрики, как NPV – чистый дисконтированный доход с проекта. Если вы можете спрогнозировать прибыль с проекта, этот критерий должен быть ключевым в ваших расчетах, ведь в конечном счете деятельность вашей организации направлена на получение прибыли (если вы не благотворительный фонд).
Далее разберем, как организовать работы с проектами внутри портфеля.

4 этап. Задаем рамки портфелю проектов

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

5 этап. Отслеживаем ход работы над портфелем проектов, вносим коррективы

Главная задача менеджера портфеля проектов – оперативно реагировать на изменения и вносить их в рабочее пространство портфеля проектов. Например, если выполнение какого-нибудь проекта переносится на определенный срок, менеджер портфеля проектов должен учесть эти изменения и перестроить работу над другими проектами, исходя из обновленных данных. Скажем, подвинуть крайние сроки у тех проектов, что можно подвинуть. А у тех, что нельзя, решить задачу более элегантно. Например, путем замены одного участника проектной команды на другого, у которого будет больше времени на работу над «горящим» проектом.
Что может послужить причиной внесения корректив в ход работ над портфелем проектов:
  • изменения в долгосрочной стратегии компании;
  • изменения в ходе работ проекта;
  • изменения требований к проекту или проектам;
  • форс-мажоры, связанные с участниками проектных групп;
  • …и многое другое, чего порой не предвидеть и лучше не знать.
Наша статья вам в этом поможет
Еще одна задача менеджера портфеля проектов – регулярная переприоритизация портфеля. Например, может произойти так, что по тем или иным причинам какие-то проекты стали приоритетнее других – эти изменения нужно учесть в рамках портфеля проектов. Проводить новый скоринг проектов нужно примерно раз в 3-6 месяцев, предварительно уточнив о важных деталях в ходе проектов у их менеджеров.
Надеемся, что эта статья поможет вам лучше организовать процессы вашей компании и выйти на новые высоты. А если вы собрались внедрять более серьезные организационные изменения и переживаете, что можете что-то сделать не так – обратитесь за бесплатной консультацией в Neogenda. И не переставайте читать наш блог, скоро здесь будет еще больше экспертных статей про современные практики управления 😎
]]> Что такое фасилитация и зачем её внедряют компании http://neogenda.ru/blog/u9sn87zxt1-chto-takoe-fasilitatsiya-i-zachem-eyo-vn http://neogenda.ru/blog/u9sn87zxt1-chto-takoe-fasilitatsiya-i-zachem-eyo-vn?amp=true Fri, 10 May 2024 08:44:00 +0300 Мария Савельева Как часто вы наблюдаете сотрудников на совещаниях, которые кивают головой, а сами скроллят соцсети под...

Что такое фасилитация и зачем её внедряют компании

Как часто вы наблюдаете сотрудников на совещаниях, которые кивают головой, а сами скроллят соцсети под столом? Вы отчаянно пытаетесь что-то донести, но выглядит всё как скучный урок истории в 10 классе. Или, наоборот, самые активные перебивают друг друга, спорят, ссорятся, так и не придя к общему решению, а молчуны только и делают, что закатывают глаза и перешептываются.
Чтобы мозгоштурмы и другие коллективные решения вопросов проходили эффективно, нужна фасилитация.
Ниже мы простыми словами расскажем, что такое фасилитация, зачем она нужна и как правильно ее организовать.
Но сначала давайте выясним…

В чем проблема обычных групповых обсуждений

Групповое обсуждение — это взаимодействие нескольких людей, что уже подразумевает различие мнений, идей. Все мы разные и по-разному думаем, ведем себя и реагируем. Наше взаимодействие в группах уже только по факту нашего различия может привести к неэффективности и проблемам:
  • Участники не хотят высказываться. «Лучше я промолчу», «послушаю, что скажут другие».
  • Привыкли, что кто-то найдет решение (здесь же команды с директивным и авторитарным управлением). «Зачем думать, сейчас кто-нибудь умный найдет решение».
  • Чувствуют себя как на экзамене, когда им задают вопросы — небезопасно, некомфортно.
  • Хотят очень быстро найти решение, пойти привычным путем — упускают много идей.
  • Обсуждение несет только поверхностный характер.
  • Вопросы для обсуждений сформулированы лидерами нечетко.
  • Обсуждаемая тема неактуальна для кого-то из группы (для какого-то отдела компании).
  • В процессе много догадок и ненужных додумок.
  • Много критики и эмоций.
  • Много времени уходит не на то.
  • Нет приверженности выбранному решению после (часто решение принимается только руководителями отделов, а остальные даже не участвовали в процессе, им принесли готовое решение).
Процесс группового обсуждения обычно представляется так: ставится проблема, все высказываются (тут рождаются идеи, вопросы, дополнительные идеи) и вуаля — общее решение найдено. Но на деле договориться не получается, идеи очень разные, возникают проблемы (см.выше). И всё приходит к тому, что действующий лидер как обычно выбирает решение сам. Кто-то останется безучастным, кто-то будет обсуждать за спиной неправильное решение, кто-то послушно пойдет выполнять, но не будет вкладываться.
Сэм Кейнер в Руководстве по фасилитации выделяет три этапа группового обсуждения.
Зона расхождения — когда мы составляем список идей и мнений.
«Зона стонов» — когда мы пытаемся понять позицию каждого, исследуются мнения и варианты. Здесь нужно прилагать усилия, чтобы совместить чужие мысли со своими, и это трудно. Появляются замешательство, разочарование, раздражение, нетерпение, защита. Именно на данном этапе группа может потерять ценные идеи и даже провалить весь процесс, хотя на самом деле «зона стонов» является естественным этапом процесса обсуждения.
Зона схождения — этап выбора, когда сортируют идеи, делают выводы, голосуют, все настраиваются на общую волну и пытаются выработать общее решение.
Пройти этот непростой процесс группового обсуждения так, чтобы все внесли свой вклад, нашли общее решение и горели им, можно с помощью фасилитации.

Что такое фасилитация

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

Для чего фасилитация в бизнесе

Фасилитация встреч нужна в тех обстоятельствах, когда люди собираются в группы для решения общих задач, будь то семинар, совещание, тренинг, стратегическая сессия или просто пятиминутная планерка. Фасилитатор повышает эффективность подобных встреч.
Цели применения фасилитации в компаниях могут быть разными:
  • Общая стратегия: в каком направлении движется компания;
  • Принятие качественных решений: фасилитация позволяет собрать разнообразные мнения и идеи от участников;
  • Улучшение коммуникации: более эффективное взаимодействие между работниками или отделами, повышение участия и вовлеченности;
  • Разрешение неблагоприятной или некомфортной обстановки;
  • Генерация идей (сюда же — сессии по анализу существующих продуктов и услуг или поиску новых);
  • Раскрытие потенциала команды, увеличение мотивации;
  • Моделирование процессов работы команд;
  • Анализ отдельных исследований (персонал, клиенты, продажи) и планирование действий по их улучшению.

Кто такой фасилитатор

Фасилитатор — это умелый организатор, своего рода коммуникативный тренер, который следит за ходом обсуждения, помогает установить правила вежливого общения, внедряет техники для того, чтобы группа «не распылялась» на ненужные обсуждения, а вела эффективную работу.
Фасилитировать — значит организовать процесс таким образом, чтобы каждый участник мог высказывать свои креативные идеи и был услышан остальными. Фасилитатор помогает сформулировать цели, поставить задачи и выработать оптимальные решения для каждой конкретной группы, основываясь на ресурсах и возможностях участников процесса.
«Фасилитатор — это не руководитель, который диктует свою волю, а скорее проводник, который помогает группе идти по пути совместного достижения целей», — Roger Schwarz, «Фасилитация принятия решений в группах»
Фасилитатором может быть любой человек, не обязательно занимающий должность руководителя или специалиста по управлению. Это может быть как сотрудник компании, например, обученный навыкам фасилитации эйчар или бизнес-тренер, так и внешний, приглашенный эксперт. Человек со стороны не имеет личной заинтересованности, каких-то посторонних мотивов, не знаком с сотрудниками и ему легче сохранять нейтральность.
Специалисты в Neogenda помогут вам провести фасилитацию, если решите привлекать стороннего специалиста. Это хороший вариант, когда у вас сложная бизнес-задача: разработка ценностей компании, улучшение взаимодействия между отделами, фасилитация больших групп.

Чем отличается от модератора

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

Роль фасилитатора

🔺 Подготовка. Уже на этапе подготовки фасилитатор должен определить существующие проблемы в группе, проведя интервью не только руководителя, но и ключевых участников. Определить проблему и цель фасилитации — одно, узнать, как эти проблемы решались прежде, какие вообще ценности у компании, кто с кем и как взаимодействует — другое. Часто случается, что после первичного исследования вскрываются другие пробелы и изначальный запрос на фасилитацию меняется.
🔺 Структура. Разрабатывает план встречи, доводит до участников цели и задачи и ведёт участников по запланированной структуре. Заранее продумывает сценарий, используемые техники и инструменты. Определяет дедлайны и тайминг.
🔺 Пространство. Создает общий психологический комфорт для всех, дружелюбное пространство, где царствуют доверие и уважение.
🔺 Помощь. Его задача способствовать, содействовать, а не выдавать себя за всезнайку (он может вовсе не разбираться в теме обсуждения). Фасилитатор помогает каждому участнику полноценно участвовать и не бояться высказываться. Он строит мосты между людьми, их идеями и мнениями.
🔺Единение. Задействует всех участников группы, стимулирует интровертов и тех, кто обычно отмалчивается или отвлекается, и, наоборот, не дает говорить все время только активным. То есть вытягивает мысли у робких, развивает их, удерживает, если необходимо, критикующих и притормаживает участников-лидеров. Кстати, ломает привычное представление о том, что лидер всегда прав и найдет решение (встречали такое на своих совещаниях?).
🔺Контроль. Возвращает участников в тему, если они от неё отошли. Также следит за временем, когда бесконечно обсуждают одно и то же или один участник говорит слишком долго. Избегает как излишнего напряжения, так и скуки. Если нарушаются нормы поведения, фасилитатор не позволяет переходить этические границы.
🔺Протокол. Фиксирует ключевые моменты и решения сессии.
🔺Консенсус. Обеспечивает достижения согласия группы или принятия решений.
🔺Развитие. Помогает группе развивать их собственные навыки взаимодействия. Хорошим эффектом здесь является раскрытие потенциала отдельных сотрудников.

Качества фасилитатора

Фасилитатору, кроме своей экспертности, для управления процессом необходимо иметь развитые soft skills:
  • Активное слушание — без него фасилитатор не сможет успешно работать; нужно поддерживать зрительный контакт, быть расслабленным, уметь задавать вопросы;
  • Эмпатия — позитивное отношение к людям, вера в способность участников и успех процесса;
  • Наблюдательность, чтобы считывать вербальные и невербальные сигналы, управлять настроениями в группе;
  • Умение хвалить и поддерживать, давать обратную связь высокого качества;
  • Уверенность и лидерские качества;
  • Ораторское мастерство и коммуникабельность — предстоит общаться с совершенно разными людьми, оценивать энергию группы и роли участников; тут важно — должен уметь донести простым языком и не заваливать терминами;
  • Гибкость и адаптивность — часто обсуждение идет не по плану, поэтому важно уметь ориентироваться по ситуации, заранее продумать сценарии, если в процессе не подходит один метод, пробуешь другой;
  • Объективность и критическое мышление — важно быть беспристрастным и не давать критических оценок, уметь анализировать быстро и по делу;
  • В какой-то мере ему нужно быть хорошим психологом и переговорщиком;
  • Стрессоустойчивость и умение управлять конфликтами — оставаться спокойным и не выходить из себя, а также уметь снижать «градус» группы;
  • Хороший тайм-менеджмент и пунктуальность;
  • Креативность.

Модели фасилитации

Первые систематизированные модели фасилитации начали появляться в середине 20-го века. Тогда подходы к управлению групповыми процессами из психологии и социологии перекочевали в сферы бизнеса, образования и другие области. Вот некоторые основные модели фасилитации.
  • Technology of Participation (Top): технология участия — это модель, в которой подчеркивается важность вовлечения всех членов группы в процесс принятия решений. Модель включает в себя несколько техник, таких как мозговой штурм, формирование консенсуса и др.
  • Future Search: призвана помочь группе визуализировать будущее, находить вдохновение и идеи образов в будущем.
  • Open Space: сначала выносятся вопросы, которые будут обсуждаться в каждой группе, участники записываются в группу с понравившейся темой, обсуждают, а затем, как на форуме или рынке, могут свободно перемещаться и присоединяться к другим группам.
  • Appreciative Inquiry (Исследование ценностей): это модель, которая фокусируется на выявлении и развитии сильных сторон и позитивных аспектов организации. Модель подчеркивает важность позитивного диалога и сотрудничества, а также предоставляет структурированную рамку для разработки общего видения и стратегии.

Методы и техники фасилитации

В арсенале фасилитатора существует огромное количество методов и техник. Более того, фасилитатор и сам может создавать собственные техники и упражнения, граничащие с психологией и коучингом, миксовать их в зависимости от задачи. Примеры самых популярных техник:
  • MeWeUs, что дословно переводится как «Мне, мы, нам». Каждый участник сначала пишет свое мнение/решение по вопросу (Me), затем обсуждение продолжается в мини-группах (We), в конце презентуют решения и обсуждают всей командой (Us).
  • World Cafe (Мировое кафе), когда участники в группах обсуждают вопрос, переходят затем в другую группу и додумывают то, что оставили предыдущие участники.
  • Мозговой штурм наоборот. Похож на классический мозговой штурм, но идеи накидываются от обратного. Если, например, целевой вопрос «Как нам надо продавать?», то в данной технике он будет звучать «Как нам НЕ надо продавать?»
  • Место для парковки. Когда возникает что-то, что не относится к текущему обсуждению, фасилитатор словно «паркует» это на месте для парковки (например, большой лист бумаги на стене). Другими словами, говорит, что разберется с этим позже. Это позволяет фасилитатору оставаться сосредоточенным, но дает участникам уверенность в том, что их услышат. (Предоставьте время в конце мероприятия или встречи в повестке дня для работы с местом для «парковки»).
  • SWOT-анализ — исследование сильных и слабых сторон, возможностей и угрозы (препятствия)
  • Icebreakers — задания, направленные на то, чтобы «растопить лёд» в команде.
В своей работе фасилитатор применяет различные инструменты фасилитации для демонстрации процесса или итогов: флипчарты, метафорические карты, голосование (точками, 0–10 и т. п.), схемы и диаграммы, электронные доски, сервисы для создания онлайн-опросов, сервисы и программы онлайн-конференций, матрицы, оценочные шкалы. Популярной шкалой является Urgent/Important Grid, когда вопрос оценивается с точки зрения Важно/Неважно и Срочно/Несрочно. Тут могут быть вариации, например, эффективно/неэффективно и дорого/дешево.
Сейчас, когда фасилитация уже плотно вошла в сферу менеджмента и не только, разрабатываются различные гайды о методах и моделях фасилитации или собираются целые библиотеки инструментов, разбитые по целям фасилитации.

Этапы фасилитации

Форматов проведения много, начиная с небольших совещаний и встреч до многочасовых сессий и даже командных выездов на несколько дней. Этапы могут меняться, но в целом классическая схема такая:
1. Запрос и подготовка. Важный этап, который включает определение целей фасилитации, интервью ключевых сотрудников, выбор подходящих методов и инструментов, разработку сценария сессии, подготовку материалов и прочее.
2. Проведение встречи:
  • Ввести в общий контекст, обговорить цели, правила и тайминг процесса, создать атмосферу доверия и понимания.
  • Сбор информации. Генерация идей.
  • Анализ и обсуждение. Структурируем, группируем, объединяем, дополняем.
  • Принятие решений. Группа принимает решения или разрабатывает конкретные планы действий.
  • Закрытие сессии. Фасилитатор помогает группе оценить результаты и процесс фасилитации, выделить уроки и заключения для будущих действий.
3. Оценка и заключение. Выдача отчета заказчику (часто в виде презентации). Обычно в результате сессии получается дорожная карта, в которой описаны:
  • последующие задачи команды;
  • ответственные по каждой задаче;
  • необходимые для достижения цели шаги;
  • ожидаемый результат.

Ошибки в проведении фасилитации

Неподготовленный фасилитатор

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

Неспособность управлять группой

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

Недостаточное внимание к динамике группы

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

Отсутствие гибкости

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

Недостаточный тайминг

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

Другие ошибки

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

Заключение

Фасилитация необходима каждому крупному бизнесу, вынужденному ежедневно принимать решения и искать новые идеи. Принципы фасилитации можно внедрить в любой проект или совещание. Попробуйте, и работа в вашей команде значительно улучшится, а совещания и планерки будут проходить продуктивно для всех участников процесса.
Что почитать:
  • Сэм Кейнер. «Руководство фасилитатора. Как привести группу к принятию совместного решения».
  • Майкл Вилкинсон. «Секреты фасилитации. SMART-руководство по работе с группами».
]]> Методологии управления проектами: топ 12 популярных систем http://neogenda.ru/blog/bbb8r9jz11-metodologii-upravleniya-proektami-top-12 http://neogenda.ru/blog/bbb8r9jz11-metodologii-upravleniya-proektami-top-12?amp=true Thu, 09 May 2024 08:49:00 +0300 Дмитрий Кустов

Методологии управления проектами: топ 12 популярных систем

Управлять людьми, процессами и ресурсами — задача, которую ежедневно выполняют проектные менеджеры. Их работа напоминает жонглирование: с одной стороны клиент с задачами, правками, обратной связью, а с другой — команда, которая должна выполнить работу в срок, качественно и достичь ожидаемого результата. Помочь выстроить бизнес-процессы, наладить работу команды, поставить ее на поток, поможет использование одной из методологий управления проектами или использование их комбинаций.
Управление проектами или project management — направление в менеджменте, отвечающее за выстраивание процессов внутри проекта. Согласно PMBOK (прим.: всемирно известная книга по проектному менеджменту «Стандарт управления проектами»), управление проектами — это применение навыков, умений, техник, необходимых для достижения целей проекта и поставленных результатов.
Основная задача проектного менеджера — сдать проект в срок и гарантировать достижение результатов, которые удовлетворят клиента.
Во время ведения проекта менеджер выступает связующим звеном между командой исполнителей и клиентом, выполняет следующие задачи:
  • согласование промежуточных результатов с заказчиком;
  • получение обратной связи и правок;
  • постановка задач команде и контроль выполнения;
  • решение проблем и форс-мажорных ситуаций;
  • управление сроками;
  • оценка рисков и их минимизация;
  • разработка плана проекта;
  • распределение ресурсов и бюджета на реализацию.
От действий и компетенций проектного менеджера, его управленческих навыков и компетенций зависит успех всей команды.
Далее в статье:
  • для чего нужно управление проектами;
  • какие есть этапы в ведении проекта;
  • 12 популярных методик управления;
  • как выбрать методику для своего проекта.
Если вам необходима помощь при выстраивании бизнес-процессов или обучение, внедрение и консалтинг бизнеса и руководителей — обратитесь в Neogenda. Мы более 40 лет помогаем бизнесу достигать результатов и имеем более 100 управленческих кейсов в крупнейших компаниях, таких как Сбер, Qiwi, Газпромбанк, Skyeng, X5 Group, Avito и других. Оставьте заявку и мы бесплатно подберем для вас решение на консультации в Zoom.

Для чего нужно управление проектами

Помочь разобраться в том, для чего нужно управление проектами, может знакомство с двумя важными понятиями — «проект» и «процесс».
Проект — это ограниченное по срокам, бюджетам и ресурсам мероприятие, требующее достижения результата. Для каждого проекта создается индивидуальный план реализации целей и задач, оговариваются требования к качеству и срокам выполнения, закладываются ресурсы и бюджет на выполнение. Такой подход для называется проектно-ориентированным.
Пример. Проектом может быть создание сайта, ведение соцсетей, разработка приложения, выход компании на маркетплейсы, внедрение новой программы, изготовление продукта.
Процесс — это комплекс последовательных действий для выполнения целей и задач. Процесс может быть повторяющимся, циклическим и регламентированным. Выполнение проекта состоит из нескольких процессов, которые могут выполняться линейно, по-простому — друг за другом, или параллельно друг другу. Такой подход называется процессно-ориентированным.
Пример. Во время проекта по разработке сайта команда выполняет процессы по созданию дизайна, верстки, написания контента на сайт. В частности эти процессы регламентированы, отлажены и повторяются на каждом проекте в необходимом объеме и в соответствии с поставленными задачами.
Комплексное управление проектами заключается в том, что практически любую задачу можно рассматривать как отдельный проект с набором процессов, приводящих к ее выполнению и достижению результата. Управлением этих процессов и занимается проектный менеджер.
Наглядно понять как происходит управление крупными проектами можно с помощью треугольника управления проектами.
Треугольник управления проектами
Треугольник демонстрирует тройственную ограниченность и сложность соблюдения баланса трех параметров при управлении проектами: времени, бюджетов и объема работ. Работа проектного менеджера состоит в том, чтобы не допустить перекоса в одну из сторон и сделать проект выгодным для компании и удовлетворяющим запросы клиента.

Из каких этапов состоит управление проектом

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

Этап 1. Инициация

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

Этап 2. Планирование

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

Этап 3. Исполнение

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

Этап 4. Мониторинг и контроль

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

Этап 5. Завершение

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

Методы и модели управления проектами

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

Waterfall (Водопад)

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

Agile

Agile — подход к управлению проектов, содержащий набор ценностей и принципов. Единым названием Agile называют семейство гибких подходов к управлению проектами, таких как: Scrum, Канбан, экстремальное программирование, Crystal или гибридное управление проектами.
Подход Agile основан на системе принципов и ценностей, по которым строится работа команды и выстраивание процессов.
Четыре основных ценности принципа согласно Agile Manifesto:
  1. Люди и взаимодействие важнее процессов и инструментов.
  2. Рабочее программное обеспечение важнее подробной документации.
  3. Сотрудничество с клиентами важнее согласований по договору.
  4. Готовность к изменениям важнее следования первоначальному плану.
Суть: Работа согласно Agile манифестам выражается в соблюдении 12 принципов и четырех ценностей.
Кому подойдет:
  • командам, имеющим минимум бюрократии в работе;
  • тем, кто постоянно улучшает и обновляет имеющийся продукт;
  • разработчикам новых, инновационных продуктов;
  • проектам, цель которых внедрить или разработать раньше конкурентов.

Scrum

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

Kanban

Kanban — метод управление проектами, использующий командные доски с очередями задач. Система отличается прозрачностью, каждый участник команды в реальном времени видит количество задач и может узнать, на каком они находятся этапе в текущий момент.
  • Размещение задач на досках решает проблемы:
  • контроля загрузки специалистов;
  • визуализации текущих процессов и задач;
  • отслеживания статуса выполнения задач;
  • демонстрации уровня важности задачи;
  • хранение информации по задачам внутри карточек.
Самые простые доски делят на три колонки: ждет выполнения, в работе и выполнено. Более сложные варианты содержат разбивки на все этапы, которые команда выполняет для реализации проекта.
Современные сервисы с онлайн-досками позволяют создавать отдельные доски для каждого проекта, а разделение работы команд или отделов компании может быть реализовано с помощью создания изолированных или связанных между собой пространств с набором досок.
Суть метода: команда визуализирует процессы внутри проектов, создает на досках карточки с задачами и выполняет поставленные задачи.
Кому подойдет: проектам и командам любого размера, особенно оценят подход удаленные сотрудники, которым нужно всегда оставаться на связи и быть в курсе происходящего.
Вариант организации канбан-досок в компании

Scrumban

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

Метод экстремального программирования (XP)

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

Lean

Lean — методология рационального управления, направленная на минимизацию всех видов излишеств, расходов и не обязательных ресурсов для достижения максимального результата, удовлетворяющего заказчика.
Основные принципы Lean включают в себя:
  • Ориентацию на потребности и ожидания клиентов.
  • Минимизацию всех видов потерь и издержек в процессе производства или предоставления услуг.
Стремление к непрерывному улучшению процессов и практик.
Согласно методологии есть три вида излишеств, представленные японскими словами, которые можно минимизировать:
  1. Muda (излишества). Ненужная деятельность, потери рабочего времени и ресурсов.
  2. Mura (неравномерность). Неравномерность загрузки, неравномерное использование ресурсов.
  3. Muri (избыток). Избыточная нагрузка на сотрудников, лишнее оборудование или процессы.
Суть метода: оптимизация всех процессов внутри команды, мешающих работать эффективнее.
Кому подойдет: командам, имеющим проблемы с эффективностью и необходимость оптимизации бизнес-процессов.

Шесть сигм

Шесть сигм, Lean Six Sigma и Agile Six Sigma — способ или философия управления качеством реализуемого проекта, не является полноценной методологией и используется в связке с принципами Agile и Lean.
Для достижения максимальной эффективности от внедрения методики шести сигм, рекомендуется использовать процесс Six Sigma DMAIC и его этапы:
  • Define (определение). Выявление проблемы или возможности улучшения, постановка целей.
  • Measure (измерение). Сбор данных о состоянии текущих процессов и выявления проблем.
  • Analyze (анализ). Проведение анализа собранных данных, выявление причин возникновения проблем.
  • Improve (улучшение). Улучшение процессов и достижение поставленных целей.
  • Control (контроль). Разработка системы мониторинга процессов и мер поддержания стабильной эффективности работы: обучение сотрудников, создание документов и регламентов.
Выстроить бизнес-процессы согласно философии Six Sigma помогает:
  • использование сервисов для создания интеллект-карт;
  • инструменты для построения блок-схем, диаграмм, графиков, визуализации бизнес-процессов;
  • внедрение канбан-досок;
  • использование онлайн-досок для командной работы;
  • внедрение CRM.
Суть метода: постоянное улучшение процессов и устранение недостатков в бизнес-процессах.
Кому подойдет: командам и проектам любого размера.
Схема методики шести сигм согласно Six Sigma DMAIC

PRINCE2

PRINCE2 или Projects IN Controlled Environments — стандарт управления проектами, разработанный в Великобритании для ведения масштабных ИТ-проектов. Методология разбивает процесс управления проектом на этапы, каждый из которых имеет цели и ожидаемые результаты.
Принципы метода включают:
  • фокус на бизнес-процессах проекта;
  • разделение проекта на этапы;
  • распределение ролей и обязанностей в проекте;
  • гибкость и адаптация методологии к конкретным условиям проекта.
Суть метода: обеспечить контроль, организацию и качество в проектах любого масштаба.
Кому подойдет: командам, которые ценят стандартизацию, документирование и строгий контроль.

Critical Path Method

Метод критического пути или Critical Path Method — методика, согласно которой проект разбивается на этапы, устанавливаются взаимосвязи между ними и выявляется наиболее длинный по времени путь для достижения цели.
Выявленный путь демонстрирует наиболее короткие сроки реализации проекта.
На старте проекта для всех этапов и выполняемых задач:
  • определяют точные сроки на реализацию;
  • выделяют взаимосвязанные этапы, старт которых зависит от завершения предыдущего;
  • определяют этапы, которые могут быть запущены в параллель;
  • выстраивают все возможные цепочки реализации со сроками;
  • выбирают самую короткую по времени цепочку.
Суть метода: определить минимальные сроки для реализации проекта, выявив цепочку этапов с наибольшей длительностью.
Кому подойдет: небольшим и средним проектам, где можно заранее спрогнозировать все варианты выполнения и просчитать наиболее быструю реализацию проекта.
Пример расчета критического пути для проекта

Critical Chain Project Management

Метод критической цепи или Critical Chain Project Management — методика управления, позволяющая определить приоритетность всех этапов реализации и начать выполнять самые рискованные и критические этапы раньше остальных, точно рассчитывая необходимые ресурсы.
Из самых рискованных этапов выстраивается критическая цепочка, требующая максимального внимания.
Суть метода: определить рискованные задачи, выполняемые ограниченными ресурсами или требующие быстрого выполнения, оставить основную часть ресурсов на выполнение оставшихся мелких задач и оставить запас буферных ресурсов на случай непредвиденных ситуаций.
Кому подойдет: проектам или командам, реализующим проекты с ограниченными ресурсами, при условии отсутствия или малого количества проектов, выполняемых в параллель.
Примерная схема определения критической цепочки проекта

Руководство PMBOK

Руководство PMBOK — это самый популярный свод правил и техник по профессиональному управлению проектами, предложенный Институтом управления проектами (Project Management Institute, сокращенно PMI). Он содержит набор практических рекомендаций и принципов, по которым проектные менеджеры могут выстроить работу команды и отладить бизнес-процессы.
Книга описывает пять классических этапов каждого проекта:
  1. Инициацию проекта.
  2. Планирование.
  3. Реализацию.
  4. Мониторинг и контроль.
  5. Завершение проекта.
Руководство PMBOK управление проектами не содержит четких инструкций по выполнению и используется в качестве рекомендаций и обучения проектного менеджера азам и тонкостям процесса управления проектами. На основе опыта, описанного в книге, можно выстроить собственную систему управления проектами, включающую использование комбинации других управленческих методик и принципов.
Кому подойдет: проектным менеджерам и руководителям проектов.
Обложка книги Руководство к своду знаний по управлению проектами (Руководство PMBOK®). Источник изображения: www.litres.ru

Как выбрать методологию управления

Универсального способа для выбора модели управления проектами не существует, каждая модель требует своего подхода, использования техник и инструментов для управления.
При выборе модели или их комбинаций стоит отталкиваться от потребностей конкретной команды и проекта, их размеров.
Факторы, которые стоит учитывать при построении стратегии управления проектами:
  • Сложность и масштабность проектов. Не все фреймворки управления проектами подходят для реализации крупных проектов.
  • Сфера деятельности. Анализируя специфику отрасли стоит понять, насколько сфера подвержена изменениям, подходят ей гибкие методологии или нужно использование более консервативных и жестких.
  • Ценности и приоритеты. Стоит понять что команда ставит на первое место — людей, эффективность, удовлетворенность клиентов и т. д.
  • Роли в команде. Перед выбором методологии стоит проанализировать есть ли у членов команды узкая специализация, являются ли они взаимозаменяемыми.
  • Размер команды. Количество участников, задействованных в реализации проекта, играет решающую роль при выборе метода управления бизнес проектами.
Если вам нужно выстроить бизнес-процессы и внедрить одну из методологий — обратитесь в Neogenda. Мы помогли решить проблемы менеджмента и управления в таких компаниях, как Tinkoff, Яндекс, Авито, Сбер, Билайн, Skyeng и так далее. Оставьте заявку на бесплатную консультацию в Zoom и мы предложим решение для вашего бизнеса.
]]> Роли в SCRUM: какие они и как их выполнять эффективно http://neogenda.ru/blog/vy0vulhge1-roli-v-scrum-kakie-oni-i-kak-ih-vipolnya http://neogenda.ru/blog/vy0vulhge1-roli-v-scrum-kakie-oni-i-kak-ih-vipolnya?amp=true Sat, 11 May 2024 09:00:00 +0300 Дмитрий Кустов Scrum – это фреймворк описывающий подход к разработке комплексных решений. Для его использования следует руководствоваться...

Роли в SCRUM: какие они и как их выполнять эффективно

Scrum – это фреймворк описывающий подход к разработке комплексных решений. Для его использования следует руководствоваться официальным руководством по Scrum. Там же описаны роли в Scrum – со своими обязанностями и зонами ответственности, которые делят между собой участники Scrum-команды.
Роли в Scrum – это ответственность и определенные функциональные обязанности, которые назначаются участникам команды для успешной реализации работ в рамках фреймворка Scrum. Всего фреймворк предусматривает три роли (зоны ответственности с 2020-го): владелец продукта (Product Owner), скрам-мастер (Scrum Master) и разработчиков (Developers). Чтобы получить пользу от использования Scrum, участники команды должны хорошо понимать и выполнять свои обязанности.
Роли мафии в Scrum
Далее по порядку:
  • что такое скрам-команда и какие условия нужны для ее создания;
  • эффективный владелец продукта – какой он;
  • кто такой скрам-мастер и что отличает хороших скрам-мастеров от плохих;
  • чего ожидают от команды разработки в Scrum.
Если вам необходима помощь во внедрении современных управленческих практик – обратитесь за бесплатной консультацией в Neogenda. На нашем счету более 100 управленческих кейсов и 5 000 обученных специалистов. Наши клиенты – это Сбер, МТС, Тинькофф, Билайн, Raiffeisen Bank, Магнит, Яндекс, Авито, Азбука Вкуса и другие, столь же известные компании. Обращайтесь к нам, чтобы увеличить прибыль вашей компании за счет оптимизации бизнес-процессов и выйти на новый уровень.

Что такое скрам-команда (Scrum Team)

Прежде всего, скрам-команда – это небольшая группа людей, которые сообща работают над одним продуктом. Размер скрам-команды – не больше 10 человек, иначе будет сильно страдать коммуникация. А прозрачная коммуникация – один из столпов Scrum, который позволяет команде анализировать ход работы и быстро адаптироваться к изменениям. Большие команды слишком разобщены и неповоротливы: если над продуктом работает более 10 человек, рекомендуется разделить коллектив на несколько скрам-команд.
При этом скрам-команда – самостоятельная «боевая единица», которая регулярно выпускает дополнительные функции и обновления продукта.
Следовательно, в команду должны входить работники разных специализаций: разработчик, аналитик, тестировщик, дизайнер и так далее. Но в то же время, у нескольких скрам-команд будет общая цель (Product Goal) и бэклог продукта (Product Backlog). Если что, Бэклог продукта – это упорядоченный и постоянно обновляемый список того, что необходимо для улучшения продукта.
Вся работа скрам-команды делится на спринты – мини-проекты в рамках непрерывной работы над продуктом. Происходит это так: команда определяет цель спринта и подбирает задачи из бэклога продукта, которые способствуют ее достижению. Так формируется бэклог спринта (Sprint Backlog), который команда должна выполнить за время, отведенное на спринт: чаще всего от пары недель до месяца. После того, как спринта завершается, команда сразу начинает следующий спринт.
Все участники скрам-команды делятся на три роли: владелец продукта (Product Owner), скрам-мастер (Scrum Master) и разработчики (Developers). Расскажем о них подробнее.

Роли и их обязанности в Agile-команде

Владелец продукта (Product Owner)

Это не то чтобы собирательный образ владельцев продуктов, скорее это продакт-овнер, которому есть куда расти
Владелец продукта – это представитель бизнеса, который вовлечен в работу скрам-команды над продуктом. Роль владельца продукта в скраме всегда выполняет один человек: если на действия команды влияет кто-то еще, они делают это через владельца продукта. У него есть ряд обязанностей, описанных в руководстве, и он может их делегировать, но ответственность за решения всегда лежит на владельце.
Какие обязанности лежат на владельце продукта:
  • Создание и проработка цели продукта (Product Goal), а также обеспечение ее понимания остальными участниками команды. Цель продукта – это описание его будущего состояния. Например, целью может быть создание сервиса с определенным набором возможностей, в который продукт постепенно превращается из MVP. Цель всегда одна – чтобы приступить к следующей, команда должна выполнить предыдущую цель или отменить ее. Задача цели продукта – сфокусировать скрам-команду, чтобы она двигалась в одном направлении – от спринта к спринту. А владелец продукта – это тот, кто следит за метриками качества в scrum команде
  • Создание, объяснение и упорядочивание элементов бэклога продукта (Product Backlog). Элементы бэклога продукта – это отдельные задачи, выполнение которых приближает команду к цели, ради которой создается продукт. Создание элемента бэклога продукта – это фиксация «сырой» идеи по улучшению и развитию продукта. Под объяснением подразумевается процесс, при котором владелец продукта совместно с командой приводит элементы бэклога к такому виду, чтобы над ними можно было работать и включить в спринт. Ведь как будет работать команда, если у нее нет четкого понимания, что именно от нее требуется. А упорядочивание – это приоритизация задач, чтобы в первую очередь работать над самыми важными из списка.
  • Обеспечение прозрачности, доступности и понимания бэклога продукта. Владелец продукта должен позаботиться о том, чтобы команда разделяла с ним важность задач, отраженных в бэклоге продукта. В противном случае у команды не будет достаточной мотивации работать на результат, да и в целом это противоречит ряду ценностей Scrum – открытости, уважения и сфокусированности. А без этих ценностей не получится достичь лучшего результата.
Поскольку Scrum существует уже не первый десяток лет, мировое комьюнити выделило ряд качеств, присущих результативным владельцам продукта.
Перечислим их.

Что отличает хорошего владельца продукта от плохого

  • Он вовлечен в работу над продуктом. Роль владельца продукта требует большой активности. Даже в рамках Scrum владелец продукта должен участвовать во всех встречах – спринтах, один из которых проводится раз в день. При необходимости он делится данными, помогает в поиске людей со своей стороны, выделяет бюджеты и согласует работы.
На всякий случай напомним, что роль владельца продукта может занимать человек, которому это делегировали, а делегировать может хоть генеральный директор. Большинство задач и обязанностей владельца продукта также можно поручать другим исполнителям. Гораздо больше других лайфхаков по внедрению Scrum вы узнаете, если обратитесь в Neogenda за бесплатной консультацией, – мы помогаем внедрить современные управленческие практики в ваш бизнес.
  • Он отлично разбирается в ситуации на рынке. Для этого владелец продукта проводит конкурентный анализ, следит за текущими тенденциями, пользовательским спросом и обратной связью от клиентов.
  • Его решения исходят из метрик. Хороший владелец продукта сможет из головы сказать, какую долю на рынке занимает его продукт, какой средний клиентский чек, какая конверсия в покупку и так далее. Он знает, сколько денег уйдет на выполнение спринта и как это повлияет на ключевые метрики. Если владелец бизнеса работает над ростом ключевых метрик, это означает, что он не просто «пилит фичи», а принимает стратегические решения.
  • Он быстро принимает решения. Владелец продукта не является «блокером», из-за которого тормозятся процессы.
  • Он говорит правду и доверяет команде. Если команде нужна какая-либо информация, владелец продукта делится ею. Прозрачность – один из трех столпов Scrum. Она нужна не только для того, чтобы команда понимала причинно-следственные связи и обладала полной картиной мира, но и для укрепления доверия среди участников Scrum-команды.
  • Он – новатор. Звучит пафосно, но это так – владелец продукта должен быть визионером с большим горизонтом планирования развития продукта. И вагоном маленьких идей по его улучшению. И большим желанием воплотить все это в жизнь. Так ведь и рождаются крутые продукты: берется потребительская проблема и придумывается самый элегантный способ ее решения.
  • Он не боится. Это очередное качество из списка, которое неплохо бы заиметь всем людям вообще, а владельцам продукта – в частности. Нужно опять таки для принятия рискованных решений.
Перейдем к лидеру-слуге. Что, не поняли? Мало кто с первого раза понимает, чем занимается этот специалист, так что это нормально. Расскажем о скрам-мастере.

Скрам-мастер (Scrum Master)

Если хотите узнать больше о профессии, читайте нашу статью: «Кто такой scrum-мастер: объясняем простым языком».
Тут есть те, кто видели скрам-мастера? Если видели, вопрос к вам: похож, да?
Скрам-мастер – это человек, который отвечает за понимание и применение командой Scrum. Им может быть как отдельный специалист извне (с хорошим опытом запуска Scrum), так и ваш сотрудник. Даже ваш специалист в составе скрам-команды, который выполняет еще и свои профессиональные задачи. Правда, тогда нужно, чтобы у него был опыт работы в хорошей скрам-команде, да и это сложно: нужно четко разграничивать две роли.
За что отвечает скрам-мастер:
  • Организация перехода на Scrum и его внедрение.
Прежде чем работать в составе команды, скрам-мастер должен спланировать переход организации на Scrum и руководить процессом.
  • Обучение Scrum.
Для этого скрам-мастер «направляет, обучает и коучит» как участников команды, так и организацию в целом.
  • Повышение эффективности применения Scrum.
Скрам-мастер устраняет препятствия применению Scrum, которые могут быть абсолютно разными: от «непричесанного» бэклога продукта до ссор в команде.
При этом скрам-мастер – «голова», а не «руки». То есть, он может показать, как формировать бэклог в Jira, но не будет это делать за вас.
  • Организация и проведение мероприятий Scrum.
Мероприятия – это встречи всей команды, каждая из которых необходима для определенной цели. Например, есть ежедневный скрам (Daily Scrum) – ежедневная встреча всей команды (не более 15 минут), на которой каждый участник делится своим ходом дел и планами. Есть и другие мероприятия: в руководстве указано четыре события.
Скрам-мастеры могут долго готовиться к встречам, чтобы проводить их наиболее эффективно – общаться с участниками, изучать проектную документацию и так далее. Благодаря этому скрам-мастер может поднять обсуждение важных тем.
  • Поддержка и мотивация команды.
Скрам-мастер – это тренер, коуч и наставник команды. Плохой эмоциональный фон команды – опасное препятствие, которое он обязан устранить.
Теперь разберем отличительные черты величайших скрам-мастеров.

Что отличает хорошего скрам-мастера от плохого

  • Выраженные лидерские черты.
Помните, чуть выше мы назвали скрам-мастера лидером-слугой? Это термин, который был упомянут в версии руководства по Scrum за 2011 год. Правда, потом его чуть подправили: много кто неправильно трактовал термин и считал, что скрам-мастер должен угождать команде как слуга, выполняя разную рутинную работу.
Идея в другом. Фокус скрам-мастера направлен на повышение эффективности команды, поэтому он ей «служит». Но что он делает как лидер?
Он «тащит» команду наверх, помогая ее участникам находить новые точки роста и развиваться в этих направлениях. Например, он берет на себя ответственность за то, чтобы добиться от двух крутых специалистов слаженной работы, поскольку те не доверяют друг другу. Например один считает другого менее квалифицированным и наоборот.
Чтобы устранить препятствие, скрам-мастер общается с этими коллегами, общается с их окружением в коллективе, устанавливает причинно-следственные связи такого поведения, находит подходы к каждому из сотрудников и убеждает их, что если они подружатся, так будет лучше для всех. Это лишь один пример: в жизни препятствием для слаженной работы команды может быть что угодно.
Чтобы брать на себя подобную «грязную» работу, нужна высокая проактивность, одно из качеств лидера. Чтобы люди действительно верили в подобные начинания и не считали их «дуростью», нужна смелость – второе лидерское качество. Поскольку в современном обществе, а также в Scrum, лидерство не должно базироваться на насилии, третье качество – высокий эмоциональный интеллект.
Напомним, что пять ценностей Scrum, выделеных в руководстве жирным – это приверженность, сфокусированность, открытость, уважение и смелость.
Настоящий лидер должен иметь эти качества, да и не сможет он без них стать лидером. А как слуга, он будет «ролевой моделью» для команды, делами доказывая следование этим ценностям.
  • Глубокое понимание Agile и Scrum.
Очевидно, что чем больше опыта у специалиста, тем он лучше работает. Но в случае со Scrum это стоит выделить отдельно – фреймворк кажется простым.
Подумаешь, руководство на 13 страницах – можно за час вдумчиво прочесть, а еще через пару часов внедрить в свой бизнес.
Но именно потому, что мы живем не в сферическом вакууме, нельзя так просто взять и изменить какой-нибудь управленческий инструмент – это невероятно сложная задача. Скрам-мастеру нужен большой практический опыт, чтобы устранять всевозможные препятствия и повышать эффективность команды. Начать свой путь Скрам-мастера можно в сложных Agile-структурах больших компаний, где их наставниками могут быть опытные Скрам-мастера и Agile-коучи.
Неопытному скрам-мастеру будет казаться, что внедрить Scrum легко, но он еще не представляет трудности, с которыми ему предстоит столкнуться.
А теперь расскажем о роли разработчиков.

Разработчики (Developers)

А кто-то даже женат
Разработчики (Developers) – это участники скрам-команды, специалисты которые, собственно и создают продукт. Выше мы уже говорили, что в команде могут находиться специалисты из любых сфер – все те, кто необходимы для регулярной поставки обновлений и улучшения продукта.
За что отвечают разработчики в рамках Scrum:
  • Составление плана работ на спринт (Sprint Backlog). При содействии владельца продукта, разработчики определяют, что конкретно будут делать в рамках спринта.
  • Качественное выполнение работ. В Scrum есть так называемые «критерии готовности» – условия при которых работа считается выполненной. Разработчики должны следить за тем, чтобы при работе над задачами эти критерии соблюдались.
  • Ежедневная адаптация плана для достижения цели спринта (Sprint Goal). Суть Agile-подходов к разработке – быстрое реагирование на изменения. Поэтому в Scrum предусмотрены разные встречи, такие как ежедневный скрам. Благодаря этому разработчики как минимум раз в день будут делиться своими планами и ходом работ по достижению цели спринта. На практике участники команды общаются по рабочим вопросам между собой гораздо чаще – и это только приветствуется.
  • Взаимная подотчетность специалистов между собой как между профессионалами. В руководстве говорится, что без прозрачности невозможна инспекция результатов и адаптация команды к изменениям на основе инспекции. Поэтому максимальная открытость отдельных участников скрам-команды – это ее фундамент, без которого все развалится.
Есть популярный вопрос касаемо разработчиков в Scrum: могут ли они участвовать сразу в нескольких скрам-командах? Отвечаем: формально это не запрещено, но нежелательно. У разработчиков не будет приверженности одной команде и сфокусированности на одном продукте. От этого возникает ряд проблем: рост сложности коммуникации из-за потери оперативности, ухудшение производительности из-за более частых переключений между задачами и сниженный моральный дух участников команды из-за переживания по поводу вышеперечисленных проблем.

Что отличает хорошую Scrum-команду от плохой

  • Подлинная сплоченность.
Если все участники команды мотивированы сделать лучший продукт на рынке, их обязанности будут выполняться сами собой. В рамках общей цели они будут активно и открыто коммуницировать друг с другом, ставить четкие планы, делиться лучшими практиками и контролировать качество выполнения работ.
Эффективная скрам-команда «играет» так же слаженно, как футбольная команда из высшей лиги. Не зря же «гол» переводится с английского как «цель».
  • Кросс-функциональные сотрудники.
«Мультискилловость» отдельных участников делают скрам-команду еще более эффективной. Собственно, когда в руководстве по Scrum упоминают кросс-функциональную команду, речь идет не только о команде в целом.
Главное преимущество такого качества – коллективный поиск решений экспертной команды, который приносит лучший результат, чем мнение отдельного эксперта. Более того, кросс-функциональность отдельных участников позволяет команде стать еще более гибкой. Такие участники команды могут более равномерно распределять между собой нагрузку и быстрее двигать продукт к цели.
Собственно, из-за отсутствия кросс-функциональности у отдельных участников команды Scrum часто «хейтят». Например, в скрам-команде может возникнуть ситуация, когда тестировщик ждет разработчика и наоборот: один отдыхает, пока другой работает. Если представить, что оба участника команды умеют делать и то, и другое, задержек в работе над продуктом будет гораздо меньше.
Отметим, что Scrum – лишь инструмент, который подойдет далеко не для всех работ. На этом часто «обжигаются» неопытные управленцы, которые могли вдохновиться философией Agile и попытаться внедрить его в свою компанию, хотя он ей не подходил с самого начала. Чтобы не допустить подобных ошибок – обратитесь за бесплатной консультацией в Neogenda. Мы изучим ваш бизнес и предложим лучшее решение для организации ваших бизнес-процессов.
Вообще, никто из нас не обладает каким-то одним навыком – у всех есть своя «ветка скиллов», которую мы прокачиваем с самого детства. На своем карьерном пути многие digital-специалисты тоже осваивают смежные профессии и обладают целым рядом квалификаций. Еще сильнее выражен такой рост в Scrum, если он устроен правильно – там участники каждый день обмениваются опытом и практиками. В долгосрочной перспективе участники скрам-команды перенимают друг у друга опыт, нужный в работе над продуктом, за счет чего работают еще эффективнее.

Резюмируем

В скрам-команде есть три основных роли (с 2020-го зоны ответственности): владелец продукта, скрам-мастер и разработчики.
  • Владелец продукта отвечает за ценность создаваемого Scrum-командой решения, определение цели, ключевых метрик и устанавливает приоритеты в бэклоге продукта.
  • Скрам-мастер учит команду и организацию эффективному применению Scrum и самоорганизованности. Еще он устраняет все помехи по внедрению Scrum и работе над продуктом. Также он следит за качеством взаимоотношений внутри Scrum-команды.
  • Разработчики составляют план работ на спринт и выполняют их. Еще они следят за тем, чтобы работа выполнялась эффективно и приводила целям.
]]> Эволюция Product Management http://neogenda.ru/blog/oyhpjrz0c1-evolyutsiya-product-management http://neogenda.ru/blog/oyhpjrz0c1-evolyutsiya-product-management?amp=true Sun, 12 May 2024 09:05:00 +0300 Дмитрий Кустов Как появился Product Manager В мире бизнеса инновации часто рождаются из неожиданных источников, привнося в...

Эволюция Product Management

Как появился Product Manager

В мире бизнеса инновации часто рождаются из неожиданных источников, привнося в привычные рамки свежие идеи и подходы. История Product Management насчитывает множество важных моментов, в которых компании открыли новые пути к успеху. Считается, что продакт-менеджмент берет свое начало в области FMCG.

Зарождение: “brand man”

В 1931 году Procter & Gamble создала специальную группу, чтобы опросить домохозяек о товарах для дома. Они поняли, что для полного понимания клиентов необходима глубокая аналитика, а именно знания о том, как клиенты пользуются товаром дома.
Первым продуктом, в разработке которого применили подобные исследования, стал продукт с низкими продажами — мыло Camay. В своем отчете Нил МакЭлрой описал схему продвижения товара, ввел новую должность “brand man”. Обязанности этой роли включали анализ создания бренда/продукта, опрос клиентов лично, отслеживание продаж, обучение дилеров. Так, первые бренд-менеджеры P&G начали координировать все процессы, включая не только маркетинг, но и разработку продуктов и продажи.

Оргструктура, ориентированная на продукт

Позднее по идеям Нила МакЭлрой два молодых стэнфордских инженера совершили следующий важный шаг в истории Product Management. Это были основатели компании Hewlett-Packard Билл Хьюлетт и Дэйв Паккард, которые стремились усовершенствовать процесс принятия решений, чтобы учитывать мнение клиентов. Для этого они внедрили уникальную организационную структуру: как только организация превышает 500 человек, она делится на более мелкие, и далее каждая группа продуктов уже обособленно несет ответственность за разработку, технологический процесс, продажи и маркетинг своего продукта.

Новая система управления продуктом на производстве

Японская автомобильная промышленность после Второй мировой войны столкнулась с кризисом существования. Компании Toyota пришлось прибегнуть к производству автомобилей “точно в срок” (just-in-time). Основной целью было создание производства, ориентированного на потребности рынка и одновременно минимизирующего издержки. Таким образом и появилась Toyota Production System (TPS), которую разработали Тайичи Оно и Эйдзи Тойода. В основе этой системы заложены принципы кайдзен и гэмба.
Кайдзен («улучшение») представляет собой культуру непрерывного совершенствования, в которой все сотрудники принимают активное участие в улучшении компании. В основе — цикл PDCA:
  • Plan (планируй): анализ текущего процесса и проблем, разработка нового плана;
  • Do (делай): следование плану или построенной гипотезе;
  • Check (проверяй): анализ нового процесса и результата;
  • Act (действуй): корректировка отклонений и ошибок / планирование нового цикла.
Гэмба (также генти генбуцу — «наличный товар на местах») подразумевает непосредственное обращение к месту выполнения рабочего процесса. «Ходить/прийти на гэмба» означает прийти на рабочее место (производственный цех, например) для сбора фактов, анализа недостатков и принятия решений на месте.
Внедрив цикл PDCA, Toyota внесла значительный вклад в историю управления продуктом и показала автомобильной индустрии как адаптировать производственный процесс под потребности рынка.

Переход в сферу разработки ПО

В 1983 году компания Intuit перенесла принципы бренд-менеджмента в разработку программного обеспечения и положила начало новой эры в разработке customer-centric продуктов.

Продукт, ориентированный на клиентов

Intuit была основана Скоттом Куком и Томом Проулксом. Их первым продуктом стал Quicken — финансовое ПО для домашних пользователей. Когда Quicken был впервые представлен, Кук заявил, что это не первое приложение для ведения чекового счета. На тот момент на рынке было около 50 таких продуктов.
Однако, все они были ориентированы на бухгалтеров и финансовых специалистов. Возможно, ввиду своего опыта работы на позиции “brand man” в Procter & Gamble, Кук решил, что Quicken должен быть прост в использовании для обычного человека. Для привлечения внимания пользователей разработчики сымитировали традиционную чековую книжку на монохромных экранах.
Одним из ключевых моментов стало внедрение программы Follow me home: представители Intuit лично посещали дома пользователей и наблюдали, как клиенты устанавливали и использовали программу дома на своих компьютерах.
Follow me home позволила компании Intuit глубже понимать потребности клиентов. Эти идеи сыграли важную роль в управлении продуктами, ориентированными на реальные запросы клиентов.

Менеджер программы

В это же время Microsoft осознала, что даже у лидеров – инженеров-разработчиков, были трудности именно с точки зрения изучения потребностей пользователей. Но посадить за один стол разработчика, с его техническими терминами, и пользователя, который ничего не понимает, было сложно.
Когда Microsoft приступила к созданию Excel для Macintosh, стало очевидно, что необходим человек, который будет выступать за интересы конечных пользователей. Так в компании появилась роль Менеджера программы (Program Manager), аналог брендмена в P&G — связующее звено между разработчиками и пользователями.

Дальнейшее развитие в сфере технологий

В статье Marketing Is Everything Реджис МакКенна описывает значительные изменения, которые технологии вносят в область маркетинга. Он подчеркивает, что в конце 20-го века наступает новая эпоха, в которой основным акцентом становится клиент. МакКенна утверждает, что 1990-е годы будут принадлежать заказчику/клиенту, что свидетельствует о существенном изменении в мировоззрении маркетологов. Это отображается в его словах: «Технология трансформирует выбор, а выбор изменяет рынок».
«Маркетинг не должен быть просто для того, чтобы увеличивать объем продаж, — говорил МакКена. Он должен быть о знаниях и опыте, о создании ценности для клиента, о навсегда меняющейся роли продавца». Таким образом, новая парадигма маркетинга отходит от традиционного подхода, ориентированного на продажи, и вступает в эру, где основное внимание уделяется удовлетворению потребностей клиента и предоставлению ему ценности.
В эти же годы выходит знаменательная книга Джеффри Мур «Преодоление пропасти: Как вывести технологический продукт на массовый рынок».
В 1998 году была основана первая Ассоциация международного маркетинга и менеджмента продуктов (AIPMM), миссия которой — развитие образования и повышение статуса сферы управления продуктом и брендом.
С течением времени, начиная с 1990-х годов, Product Management начал объединяться с инженерией и бренд-менеджментом, превращаясь в неотъемлемую часть деятельности технологических компаний.

Процесс становления Product Manager в 2000-х

В начале 2000-х годов продуктовый менеджмент стал доступен для широкого круга людей даже без технического образования, найдя своё место на пересечении дизайна, технологий и бизнеса. Этот период ознаменовался рядом важных событий, благодаря которым и сложилась профессия Product Manager.
В феврале 2001 года был разработан Agile манифест, который сменил Waterfall в создании программных продуктов, подчеркивая значимость продуктового менеджмента и клиентоориентированных подходов.
В 2002 году Марисса Майер внедрила в Google программу APM (Associate Product Manager), первую в своем роде, ставшую образцом для других мировых технологических компаний. Программа направлена на обучение будущих лидеров продуктов и знакомит их с культурой компании и современными тенденциями в разработке.
Книга легендарного генерального директора IBM Луиса Герстнера вышла в то же время, рассказывает о повороте IBM в продуктово-сервисную парадигму, а в книге «Четыре шага к озарению» Стив Бланк предложил методику развития клиента, особенно выделяя важность ориентации на клиента в процессе создания продуктов.
В 2004-м Ассоциация AIPMM, стандартизируя профессию, представила первый сертификационный экзамен для менеджеров по продуктам.
В 2009 году вышла книга Александра Остервальда «Построение бизнес-модели», в которой изложены инновационные методы, применяемые в крупных компаниях.
В этом же десятилетии такие компании, как Google, Amazon, Netflix, Apple и Adobe, сформировали современное управление продуктами, устанавливая новые стандарты. Требования к профессии Product Manager в компаниях разнятся, но все чаще данная роль определяется как связующее звено между дизайном, технологиями и бизнесом, отражая сложившийся облик этой профессии в современном мире.

Product Management на пике популярности

В начале 2010-х годов сообщество по управлению продуктами обрело глобальное признание. Управление продуктами превратилось из простой должности в настоящее ремесло. Это десятилетие стало эпохой, когда лидеры продуктового менеджмента начали активно выступать на конференциях, писать книги, вести подкасты, популяризируя клиентоориентированные подходы и делая акцент на наставничестве нового поколения продакт-менеджеров.
  • Эра Lean Startup и Customer Development: Появление книги «Бизнес с нуля» от Эрика Риса в 2011 году стало знаковым событием для индустрии. В книге совместились принципы Lean Startup, Customer Development и Agile, ставшие основой для быстрого тестирования идей и выбора эффективных бизнес-моделей.
  • Значимые публикации и обучение: Важными моментами в развитии Product Management стали публикации книг «Четыре шага к озарению» (2013) и
  • «Разработка ценностных предложений» (2014), которые привлекли внимание к методологиям развития клиентов и создания ценностных продуктов. Создание сертификационных программ и учебных пособий, таких как ProdBOK, в 2013 году, дало новое качественное развитие в области обучения и стандартизации профессии.
  • Инновации в UX и привычках потребителей: В 2014 году выходят книги «Hooked. На крючке» и «Спринт: Как разработать и протестировать новый продукт всего за пять дней», в которых представлены новаторские подходы к разработке продуктов с учетом привычек пользователей, а также эффективных методов проверки.
  • Рост и обучение лидеров: Публикации книг Марти Кагана и Алана Клемента в 2018 году, а также выход книги о системе OKR в 2018 году продемонстрировали продолжающийся интерес к теме и важность обучения в области Product Management. Книга Марти Кагана Empowered: Ordinary People, Extraordinary Products, выпущенная в 2020 году, продолжила тему лидерства в управлении продуктами и отметила значимость обучения нового поколения специалистов.

Заключение

Product Managers превращаются в связующее звено между потребностями клиентов и возможностями компании. Их роль заключается не только в удовлетворении требований рынка, но и в обеспечении оптимального баланса между этими потребностями и целями организации. Они играют ключевую роль в максимизации вложений в продукт и обеспечении его успешного выхода на рынок. Область продуктового менеджмента становится неотъемлемой частью стратегии развития компании, гарантируя ее конкурентоспособность и рост в долгосрочной перспективе.
]]> 7 видов канбан-каденций: что это такое, советы как проводить встречи http://neogenda.ru/blog/04jd4ib971-7-vidov-kanban-kadentsii-chto-eto-takoe http://neogenda.ru/blog/04jd4ib971-7-vidov-kanban-kadentsii-chto-eto-takoe?amp=true Mon, 13 May 2024 09:08:00 +0300 Мария Савельева Для всех подходов к управлению проектами критически важна обратная связь. Нужно держать в курсе ситуации...

7 видов канбан-каденций: что это такое, советы как проводить встречи

Для всех подходов к управлению проектами критически важна обратная связь. Нужно держать в курсе ситуации заказчика и стейкхолдеров, следить за ходом работ команды, решать возникающие в процессе разработки проблемы, оперативно реагировать на изменения внешних факторов. Канбан Метод предлагает широко использовать различные каденции для того, чтобы поддерживать и улучшать Сервисы поставки клиентской ценности. Рассмотрим более подробно различные типы канбан-каденций и их основное предназначение.
Канбан-каденции (Kanban Cadences) — регулярные рабочие встречи, цель которых — сбор обратной связи и коммуникация между участниками проекта.
Каденции представляют собой петли обратной связи. Петля обратной связи — это принятие управленческого решения на основе предыдущего решения. Точка в петле обратной связи, где происходит сопоставление результатов предыдущих решений и формирование новых, формируется в виде собрания или встречи.
Встреча или митинг существует для того, чтобы петля обратной связи существовала.
Встречи помогают эффективно управлять проектами, процессами и работой, выстраивать процессы по Канбан Методу, грамотно определять последовательность задач, решать возникающие проблемы и эволюционно улучшать рабочий процесс.
Далее в статье:
  • основные принципы канбан-каденций,
  • ежедневный Scrum и канбан-митинг: главные отличия,
  • 7 видов канбан-каденций,
  • полезные советы по организации канбан-митингов.
Если вам необходима помощь при выстраивании бизнес-процессов и использовании гибких подходов к управлению (менеджменту) — обратитесь в Neogenda. Мы являемся экспертами по современным методам менеджмента и реализовали более 100 управленческих кейсов в крупнейших компаниях, таких как Avito, Сбер, Яндекс.Здоровье, Азбука вкуса, Точка и других. Оставьте заявку, и мы бесплатно предложим решение для вашего бизнеса на консультации в Zoom.

Основные принципы канбан-каденций

Основные принципы канбан-каденций включают в себя следующие факторы:
  • Регулярность. Встречи проходят по определенному расписанию на регулярной основе, выбор частоты для каждой каденции происходит по своим принципам. Регулярность позволяет осуществить процесс непрерывных эволюционных улучшений.
  • Прозрачность. Все участники встречи должны быть информированы о состоянии, проблемах, задержках и изменениях в рабочем процессе.
  • Функционирование и развитие. Цели канбан-каденций — обеспечение функционирования и развития сервиса или сервисов
  • Обсуждение проблем и улучшений. В рамках каденций участники обсуждают возникшие проблемы, могут искать способы их решения и предлагают возможные улучшения в рабочем процессе.
  • Принятие решений. Регулярные встречи помогают принимать оперативные решения по внесению изменений в рабочие процессы.
  • Эмпирический подход. Встречи помогают анализировать текущее состояние процесса и оперативно реагировать на изменение внешних и внутренних факторов.
Соблюдение этих принципов помогает команде эффективно использовать Канбан Метод как инструмент улучшения вашего процесса, который будет решать именно ваши проблемы поставки ценности клиенту.

Ежедневный Scrum и канбан-митинг: главные отличия

Канбан-митинг и Ежедневный Скрам имеют сходные, но в то же время различные цели и форматы.
Ежедневный Scrum, или Daily Scrum — обязательный элемент фреймворка Scrum. Это короткое ежедневное совещание длительностью до 15 минут.
Цель ежедневного Скрама — инспекция процесса достижения цели спринта и адаптация плана по достижению цели спринта. Daily Scrum фокусируется на достижении Цели Спринта и создает план действий на рабочий день.
Daily Scrum фокусируется на достижении цели спринта и создает план действий на рабочий день. Формат проведения команда (Developers) может выбрать любой, лишь бы он помогал понять прогресс по достижению все той же цели спринта
Длительность: 15 минут.
Участники: Developers (в предыдущих версиях скрам гайда «Команда Разработки»)
Канбан-митинг — это каденция, главная цель которой — сфокусировать внимание участников команды на том, как движется работа: какие проблемы случаются и как их решить. На канбан-митинге анализируются изменения в движении работы по производственной системе, которые произошли с предыдущего собрания. С собрания люди должны уходить с информацией об актуальном положении дел в производственной системе, существующих проблемах и планах их решений.
Частота проведения собрания: зависит от того, насколько часто происходят изменения в производственной системе. Если команда собирается на собрание и изменений столько, что собрание становится слишком долгим, выходит за рамки получаса — встречи стоит проводить чаще. Если на собрании обсудить нечего, и не произошло никаких изменений в системе — встречи нужно организовывать реже.
Длительность: до 20 минут.
Участники: все люди, задействованные в работе Сервиса поставки клиентской ценности.

7 видов канбан-каденций

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

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

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

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

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

Канбан-митинг

Канбан-митинг — это регулярная короткая встреча для обсуждения хода работ в производственной системе. На ней обсуждаются возникшие проблемы и ход их решения.
Частота проведения: зависит от частоты изменений в производственной системе.
Продолжительность: в среднем составляет 15-20 минут.
Участвуют: все, кто задействован в поставке ценности клиенту.
Формат митинга часто называют «проходом по доске». Он заключается в том, что ведущий проходится справа-налево по всей канбан-доске и задает вопросы по каждому из рабочих элементов:
  1. Что это за рабочий элемент?
  2. Кто им занимается?
  3. Что требуется сделать, для того, чтобы он продвинулся дальше?
  4. Когда эти действия будут сделаны?
  5. Есть ли какие-то проблемы с этим рабочим элементом?
  6. Можем ли мы как-то помочь?
Список вопросов не является обязательным и часть ответов на вопросы уже могут присутствовать на доске. Например, ответ на вопрос – кто занимается задачей, может уже быть на доске, так как у каждой карточки обычно указан ответственный.
Проводит собрание наименьший общий начальник для всех участников проекта, либо менеджер поставки.
Основная цель ежедневной канбан-встречи — информация об актуальном положении дел с работой в производственной системе, существующих проблемах и планах их решений.

Обзор поставки

Обзор поставки (Service Delivery Review) — это собрание команды для обсуждения прошедшей поставки, ее соответствия или несоответствия ожиданиям заказчика.
Частота проведения: раз в неделю-две, в зависимости от частоты поставки и частоты, с которой заказчик готов принимать результат.
Продолжительность: от 30 минут до 1 часа.
Старайтесь уложиться по времени в 20-40 минут, не делайте очень глубокий анализ причин, это можно будет сделать на обзоре рисков. На данном собрании мы пытаемся найти решения в виде «низко висящих фруктов».
Участвуют: все участники команды, а при необходимости – заказчики и стейкхолдеры.
На данном собрании команда:
  1. Проводит краткий обзор того, что было поставлено, изучает соответствует ли поставка ожиданиям заказчика.
  2. Анализирует причины, по которым какие-то рабочие элементы не соответствуют ожиданиям заказчика.
  3. Генерирует идеи по исправлению ситуации с непопаданием в ожидания заказчика.
  4. Формирует план действий, направленный на улучшение процессов и повышение качества сервиса.
Проводит собрание менеджер поставки.
Основная цель встречи — разработка плана действий по улучшению производственного процесса, чтобы лучше попадать в ожидания заказчика.

Операционный обзор

Операционный обзор (Operation Review) — глобальная встреча по обзору всех текущих процессов и задач внутри всей компании, продуктового направления или, например, бизнес-юнита.
На собрании обсуждают:
  • поставленные заказчикам рабочие элементы, для которых потребовалось межсервисное взаимодействие;
  • проблемы, из-за которых поставка не оправдала ожиданий заказчиков;
  • варианты изменения правил взаимодействия между сервисами.
Часто в компаниях есть несколько взаимосвязанных продуктов или сервисы компании, которые разделяют между собой ресурсы. Например, продуктовое подразделение и маркетинговое совместно используют ресурсы подразделения дизайна. В таких случаях требуется собрание, похожее на обзор поставки, но не ограничивающееся одним продуктом или услугой, а затрагивающее большой бизнес юнит или направление. Таким собранием является операционный обзор.
Частота проведения: раз в неделю или месяц, в зависимости от количества проектов и их сложности.
Изначально рассмотрите проведение данного собрания раз в квартал, далее частоту встреч стоит подстроить под ваш контекст.
Если вы будете проводить собрание слишком часто, то у вас будет слишком мало вопросов, которые стоит обсуждать, транзакционные и координационные издержки на собрание будут превышать пользу, которую собрание может принести.
Если проводить данное собрание слишком редко — объем информации для обсуждения будет очень большой и собрание может затягиваться слишком надолго, также часть информации может быть забыта из-за длительного периода между собраниями.
Продолжительность: от 30 минут до 1 часа.
Участвуют: представители от каждого Сервиса поставки ценности, входящего в бизнес юнит. Дополнительно на собрание можно пригласить ключевых специалистов от каждого сервиса, заказчиков, представителей заказчиков и менеджеров запросов.
Вести собрание должен более высокий руководитель, чем собравшиеся представители подразделений, в идеале — представитель топ-менеджмента компании.
Еще один вариант — доверить проведение собрания фасилитатору.
По окончанию собрания должна быть получена информация:
  • как изменились правила межсервисного взаимодействия;
  • как перераспределились квоты на общие сервисы;
  • как изменились правила пополнения.

Собрание по пополнению

Собрание по пополнению (Replenishment Meeting) — регулярная встреча для определения рабочих элементов, которые должны быть приняты в производственную систему согласно освободившейся в ней емкости.
На входе должна быть информация:
  • от руководителя или лидера команд разработки: список свободных слотов в производственной системе;
  • от заказчиков и представителей заказчиков: список самых важных задач и запросов, которые должны попасть в систему.
Цель встречи – пополнение канбан-доски новыми задачами в освободившиеся слоты, обсуждение очередности работ.
Частота проведения: должна отражать скорость изменения информации у заказчика и транзакционные и координационные издержки на пополнение.
Нам важно опираться на то, насколько часто у заказчика меняется информация, меняется рынок и обстановка. Наша производственная система должна быть к этому готова.

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

Пополнение — это собрание, у которого есть транзакционные издержки (это затраты на то, чтобы организовать собрание), координационные издержки (это затраты на проведение собрания) ну и есть альтернативные издержки (это недополученная ценность, которая могла бы быть, если бы люди не ходили на собрание). Эти факторы должны сдерживать слишком высокую частоту собраний. Организация собраний стоит дорого и эти затраты должны быть оправданы.
Продолжительность: от 30 минут до 1 часа.
Участвуют: заказчики или их представители, руководитель или лидер команды разработки.
Важно: у собрания нет фокуса на столкновении заказчиков со специалистами по реализации, фокус — на столкновении заказчиков между собой за право пополнить производственную систему. После достижения договоренности происходит принятие обязательств по выбранным запросам.
Так как на собрании идет «баталия» заказчиков за право пополнения производственной системы — вести его должен человек, имеющий навыки фасилитации сложного общения, в идеале — наименьший общий начальник для заказчиков.

Для примера: если заказчиками являются Менеджеры Продуктов, то такое собрание возможно стоит вести Директору по Продуктам. Поэтому однозначно можно сказать, что это собрание должен вести человек в роли Менеджера Запросов.

Планирование поставки

Планирование поставки (Delivery Planning Meeting) — это собрание, на котором проектируется будущая поставка. Собрание организуется не в момент принятия обязательств по выполнению, а ближе к завершению рабочего элемента.
Если ваша поставка автоматизирована, то планировать ее не стоит, но в других случаях возможно вам потребуется собрание, которое называется Собрание планирования поставки.
Частота проведения: выбирается индивидуально, в зависимости от специфики проекта и потребностей команды.
Продолжительность: от 15 минут до 1 часа. Не должна превышать 1-1,5 часа.
Участвуют: ответственные за приемку, ключевые специалисты сервиса, ответственные за логистику поставки, руководители и ключевые специалисты смежных подразделений, ответственные за поддержки после поставки.
Проводить собрание должен Менеджер Поставки.
Главной целью участников на этой встрече является обсуждение состава поставки, планирование – кому, когда и каким образом будет передаваться продукт.
Во время собрания будет выявлена информация о сроках поставки для разных заказчиков: кому- то поставка нужна чуть быстрее, а кто-то просит отодвинуть сроки на более поздние. Эти данные будут полезны для обсуждения на следующем канбан-митинге для корректировки элементов и их сроков выполнения в производственной системе.
По окончании собрания у участников должен быть план, или так называемый манифест поставки. По нему будет ясно как будет осуществляться поставка и ответы на вопросы «кто? что? когда? кому? каким образом?» и главное — данные о том, как заказчик будет принимать готовый результат.

Обзор рисков

Обзор рисков (Risk Review) — это собрание, для глубокого анализа причин задержки рабочих элементов и разработки плана действий по системному решению проблем задержек.
Важно: на собрании обсуждаются уже случившиеся фактические задержки, а не потенциальные риски.
На собрании происходят два вида активностей:
  1. Кластеризация Блокировок. Активность по анализу и группировке устраненных блокеров в кластеры. В ходе работ некоторые рабочие элементы вызывают проблемы и не могут быть завершены.Таким элементам вешается специальный стикер — блокер. На нем указывается суть проблемы, дата и время возникновения, ответственный за устранение.Далее блокеры устраняются: на стикер добавляются данные о дате и времени устранения и стикер с блокером убирается с доски.Когда стикеров с устраненными блокерами накапливается достаточное количество — организуется встреча по их кластеризации.
  2. Отрезание Хвостов. Активность, во время которой происходит анализ диаграммы времени выполнения и выявление рабочих элементов, попавших в хвост.Для рабочих элементов, попавших в хвост, анализируются причины задержек и разрабатывается план действий по недопущению попадания элементов в хвост. Действиями могут быть изменения WIP-лимитов для этапов работ или буферов, или разработка правил по изменению класса обслуживания для элементов.
Частота проведения: один раз в месяц и далее по необходимости.Для проведения обзора рисков нам необходимо большое количество качественных данных, поэтому проводить его часто не получится. Мы рекомендуем стартовать с частоты раз в месяц или два, а дальше корректировать частоту по обстоятельствам.

Данное собрание можно проводить как на один сервис, так и на несколько (состав сервисов должен быть аналогичен тому, которое разбирается на операционном обзоре).
Продолжительность: зависит от количественных данных.
Участвуют: один или несколько Менеджеров Поставки (в зависимости от того, сколько сервисов будут разбираться на собрании), люди, обслуживающие сервис, либо ключевые сотрудники (по представителю от каждой функции).
Если собрание идет на один сервис — вести его должен Менеджер Поставки сервиса. Если собрание идет на несколько сервисов — ведущий аналогичен ведущему операционного обзора.
Следует рассмотреть возможность пригласить вести собрание канбан-коуча — внутреннего или внешнего консультанта, глубоко разбирающегося в Канбан Методе. Данный специалист имеет незамыленный взгляд на проблемы ваших сервисов, а также хорошую насмотренность, для того, чтобы помочь вам выработать неочевидные решения.
На встречу участники приходят с информацией о блокировках, диаграммой распределения времени выполнения и историческими данными о реализации запросов попавших в хвост.
По итогу встречи создается план действий по устранению проблем.

Обзор стратегии

Обзор стратегии (Strategy Review) — ежеквартальное совещание на уровне компании, бизнес-юнита или группы компаний для рассмотрения и оценки:
  • текущих рынков;
  • стратегического положения компании на рынке;
  • стратегий выхода на рынок;
  • ключевых показателей эффективности;
  • потенциальных возможностей;
  • согласования стратегии развития и использования возможностей.
Частота проведения: раз в месяц или даже несколько месяцев, по необходимости.
Продолжительность: от 1 до 2 часов.
Участвуют: руководители высшего звена и представители отделов стратегического планирования, отдела продаж, маркетинга, управления портфелем ценных бумаг, управления рисками, предоставления услуг и обслуживания клиентов.
На встрече рассматриваются следующие вопросы:
  • С какими рынками мы работаем? Какие продукты или услуги мы предлагаем на этих рынках?
  • Как мы сегментируем каждый из рынков?
  • Есть ли у нас правильные критерии соответствия для каждого сегмента?
  • Мы являемся лидерами рынка, новаторами или последователями в каждом из сегментов?
  • Мы выделяемся на фоне конкурентов, являемся лидером по затратам, нишевым игроком или «застряли посередине» в каждом из сегментов? Каким образом мы выделяемся на фоне конкурентов?
  • Соответствуем ли мы поставленной цели?
  • Насколько хорошо мы справляемся с заданными показателями физической подготовки?
  • Появились ли новые сегменты? Нужно ли скорректировать наши критерии пригодности?
  • Каковы наши текущие возможности по: периодичности планирования и принятию обязательств, времени выполнения заказов, предсказуемости, частоте доставки, качеству, соответствию нормативным требованиям.
  • Насколько хорошо наша стратегия согласована с нашими возможностями?
  • Какие возможности мы хотим использовать, что улучшить и почему?
  • Производим ли мы то, что могли бы купить, арендовать, передать на аутсорсинг или передать в офшоры?
  • Покупаем ли мы, арендуем, передаем на аутсорсинг или передаем в офшоры то, что мы должны делать собственными силами?
  • Нужно ли нам менять нашу стратегическую позицию или стратегию выхода на рынок, чтобы лучше соответствовать нашим возможностям?

Полезные советы по организации канбан-митингов

При рассмотрении всех видов каденций может возникнуть чувство, что при таком количестве коммуникаций и встреч у команды не остается времени на работу, а весь их день — одни сплошные переговоры. Но это не так.
Важно помнить, что каденции нужны:
  • не всем;
  • не всегда;
  • не все виды.
Ваша задача — понять потребности вашей команды и проектов и выбрать для себя наиболее значимые из перечисленных видов. От чего зависит выбор каденций, для чего и кого нужна каждая из встреч — мы подробно описали выше.
Грамотное проектирование каденций под контекст конкретной компании помогает использовать метод по максимуму и не делать потому, что так сейчас модно.
Для этого стоит следовать ряду правил по организации встреч:
  • Определите четкую цель встречи. Перед началом митинга обозначьте цель и ожидаемые результаты. Это поможет участникам встречи быть на одной волне и сосредоточиться на действительно важных вопросах.
  • Пригласите все заинтересованные стороны. Оповестите заранее всех заинтересованных участников проекта, убедитесь, что они свободны в указанное время и смогут присутствовать на каденции.
  • Подготовьте план. Составьте список тем и вопросов, которые будут обсуждаться на встрече, чтобы эффективно использовать время и не отходить от темы.
  • Ограничьте время. Каждая встреча должна иметь строгое время начала и окончания. Отдельно могут быть установлены тайминги и ограничения для обсуждения отдельных тем. Это поможет избежать длительных разговоров, отхождения от целей встречи и сосредоточиться на ключевых вопросах.
  • Поддерживайте инициативу. Любое мнение имеет право быть высказанным, а участники встречи могут участвовать в обсуждении без страха критики, не боясь быть перебитыми.
  • Резюмируйте встречи. Важно вести записи ключевых моментов обсуждения, фиксировать принятые решения и действия, которые должны быть выполнены после встречи.
  • Оцените эффективность. После встречи подведите итоги: обсудите что было хорошо и что можно улучшить в следующий раз.
Эти советы помогут вам организовывать любые рабочие встречи более эффективно и результативно.
А для проектирования канбан-каденций под контекст вашей организации мы дадим вам удобный шаблон. Хотите узнать больше – об этом мы рассказываем на наших тренингах по Канбан-Методу, кроме того, Алексей Пименов подробно описал все в своей книге.
Шаблон проектирования канбан-каденций
Если вам требуется консультация или консалтинг бизнеса по внедрению одной из методологий управления — обратитесь в Neogenda. Оставьте заявку на бесплатную консультацию в Zoom, и мы поможем вашему бизнесу найти новые точки роста и оптимизировать процессы.
]]> Product Owner: история и эволюция http://neogenda.ru/blog/snokrx3d01-product-owner-istoriya-i-evolyutsiya http://neogenda.ru/blog/snokrx3d01-product-owner-istoriya-i-evolyutsiya?amp=true Mon, 08 Jul 2024 07:46:00 +0300 Дмитрий Кустов Поднимаем занавес и отправляемся в 1995 год. В целях гармоничной и продуктивной разработки продуктов Кен...

Product Owner: история и эволюция

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

Прародители Product Owner

В первом руководстве Кен Швабер определил две команды:
  • команда разработки во главе со скрам-мастером;
  • команда управления, или менеджмента, во главе которой стоит Менеджер по продукту (Product Manager). Он устанавливает содержание и сроки релиза, управляет проектом и рисками на протяжении его развития.
Сделано это было с целью улучшить коммуникацию между командами, а главное — для понимания и учета потребностей заказчика.
Через три года становится понятно, что в формировании бэклога для продукта участвует много разных отделов, и требуется человек, решающий, что следует включить в бэклог, а что – нет. Так в руководстве 1998 года выходит в свет первая отдельно стоящая личность, ответственная за приоритизацию бэклога и достижение целей продукта. Такую обязанность в то время возлагали на менеджера по продукту или менеджера по маркетингу продукта. Но черты product owner здесь уже обрисовались по следующей причине: упоминается, что он не является частью команды Scrum и работает самостоятельно.

Первое упоминание Владельца Продукта

Только спустя 6 лет в своей первой книге Agile Software development with Scrum Кен Швабер дал определение Владельца продукта (Product Owner), и с тех пор его имя прочно укоренилось в нашем понимании Scrum. Наличие такого лица уменьшает количество споров и проблем в команде разработчиков.
The Product Owner is responsible for turning issues into work that the Scrum Team selects for a Sprint. This issue is not ready to be defined as something to develop.
Бэклог продукта представляет собой «айсберг»:
  • на поверхности — конкретный функционал и технические аспекты продукта — детализированные, оцененные и понятные элементы для команды разработки;
  • внизу «айсберга бэклога» — неопределенные вопросы или проблемы (issues), которые как раз в зоне ответственности Владельца продукта, и он решает, давать этим вопросам приоритет или нет.
Этот подход подчеркивал наличие неопределенности в процессе разработки продукта. А роль Владельца в коммерческой разработке программного обеспечения все еще мог играть и менеджер по продукту или менеджер проекта, но отдельно от команды Scrum.
Причем при внесении изменений в бэклог последнее слово всегда за Владельцем Продукта — его должны сначала убедить в правильности таких изменений.

Роль Владельца Продукта в Скраме

В 2003 году структура команды, работающей над продуктом, меняется: теперь вся команда — Scrum-мастер, команда разработки и Владелец продукта, вместе отвечают за ценность и бэклог. Так Project owner стал частью команды Scrum.
Scrum implements this iterative, incremental skeleton through three roles: the Product Owner, the Team, and the ScrumMaster.
Ответственность Project owner продолжает расти:
  • он несет ответственность за успех всего продукта,
  • представляет интересы всех заинтересованных сторон и за полученные результаты,
  • обеспечивает финансирование проекта и разрабатывает планы релиза,
  • отвечает перед финансирующей стороной за максимизацию возврата инвестиций.
Тот же Кен Швабер в 2007 году определяет существенные изменения в сфере разработки продуктов.
Истинными владельцами продуктов являются клиенты; то есть клиент решает, что нужно продукту, и нужно ориентироваться на потребности рынка, а не только на мнение менеджмента.
Владелец продукта в компании — высшее руководство.
The most senior executive in the enterprise is the Product Owner.
Джефф Сазерленд в своей книге Scrum Handbook (2010) добавляет для Владельца продукта несколько новых аспектов ответственности:
  • Владелец Продукта несет ответственность за прибыль и убытки только в случае коммерческого продукта, а в случае внутренних разработок отвечает за максимизацию бизнес-ценности и управление затратами команды. Это подчеркивает важность приоритизации элементов бэклога и способа их реализации. Тесно связаны роли во фреймворке, и каждая роль вносит свой вклад в максимизацию ценности продукта.
  • Владелец продукта активно взаимодействует с командой, анализируя результаты.
  • Владелец продукта может делегировать свои обязанности в случае нескольких команд, но решения принимает верховный Владелец продукта единолично. То есть и Scrum-команда тоже вносит свой вклад в максимизацию ценности продукта, хоть и Владелец продукта остается ответственным за это. Эта же мысль прослеживается в более поздних руководствах по Scrum (2011–2020 гг.)
Все эти работы показывают, что роль владельца продукта в Скраме становится все более важной и ответственной, и что не только он вносит свой вклад в максимизацию ценности продукта.

О развитии роли Product Owner в Scrum Guide

Изменения в 2013 году

В обновлении Scrum Guide 2013 года роль Product Owner претерпела небольшие изменения. Если раньше говорилось, что Product Owner обеспечивает ценность (ensure), то теперь он должен ее оптимизировать (optimize). Это изменение может восприниматься как снижение уровня ответственности владельца продукта, так как «гарантировать» («обеспечивать») предполагает наличие определенных гарантий, в то время как понятие «оптимизировать» дает более широкую интерпретацию.

Изменения в 2017 году

Следующее обновление Scrum Guide в 2017 году внесло коррективы в формулировку ответственности Product Owner. Теперь он отвечает за максимизацию ценности продукта, являющегося результатом работы команды разработки, тогда как ранее речь шла о максимизации отдельно ценности продукта и отдельно работы команды. Это изменение подчеркивает более тесную связь между результатами работы команды и ценностью продукта.

Изменения в 2020 году

Обновление 2020 года вносит более существенные изменения. Теперь ответственность за все продуктовые активности распределяется на всю Scrum Team, включая взаимодействие с заинтересованными сторонами, верификацию, обслуживание и исследование. Кроме того, вся Scrum Team ответственна за создание ценного инкремента в каждом спринте, что ранее возлагалось в основном только на Product Owner.

Отказ от термина «роли»

В 2020 году произошел отказ от термина «роли». Теперь Product Owner, Scrum Master и разработчики рассматриваются как зоны ответственности (accountabilities), а не роли (roles). Это изменение направлено на сплочение команды, так как термин «роль» может подразумевать наличие отдельных целей и задач.

Увеличение ответственности Product Owner

Изменились и обязанности Product Owner. Теперь он не просто отвечает за максимизацию ценности продукта, но и несет полную подотчетность за результаты и последствия работы других. Это подчеркивает его единоличную ответственность перед заинтересованными сторонами.

Управление бэклогом продукта

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

Заключение

Все изменения, что претерпевал Product Owner в Scrum Guide, лишь подчеркивают растущую важность его роли в процессе разработки продукта. Его ответственность расширяется, включая более тесное взаимодействие с командой разработки и акцент на долгосрочные цели, что способствует более эффективному управлению продуктом и достижению его ценности.
]]> Системный подход к использованию Канбан: разбираемся как нам поможет STATIK http://neogenda.ru/blog/uyrr7hpsd1-sistemnii-podhod-k-ispolzovaniyu-kanban http://neogenda.ru/blog/uyrr7hpsd1-sistemnii-podhod-k-ispolzovaniyu-kanban?amp=true Wed, 10 Jul 2024 07:51:00 +0300 Мария Савельева Построение системы, где людям будет комфортно работать, сотрудники не будут перегружены, качество выполняемой работы будет...

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

Построение системы, где людям будет комфортно работать, сотрудники не будут перегружены, качество выполняемой работы будет на высоте, а заказчики удовлетворены результатами — иногда кажется невыполнимой задачей. Но существуют инструменты и методы, позволяющие оценить текущее состояние рабочих процессов в компании, спроектировать и реализовать систему в соответствии с тем, как люди работают на самом деле, и в дальнейшем ее совершенствовать, например, при помощи Канбан Метода. Чтобы начать использовать Канбан Метод надо изучить ваш производственный процесс и описать его в виде Канбан Системы. Идеальный вариант — подойти системно и использовать STATIK.
STATIK (Systems Thinking Approach to Introducing Kanban) — это подход, который является результатом многолетней практики большого количества менеджеров и консультантов. Был описан в виде алгоритма Майком Барроузом (Mike Burrows). Он помогает компаниям применять принципы системного мышления для успешной реализации Канбана.
STATIK помогает понять текущее состояние системы, определить необходимые изменения и шаги для использования Канбан Метода.
Если вам требуется внедрение Канбан — оставьте заявку на бесплатную консультацию от Neogenda и мы поможем не внедрять, а использовать метод именно под ваш контекст.
Далее в статье:
  • что такое сервисная парадигма в Канбан;
  • STATIK и понятие сервисной археологии;
  • 8 шагов STATIK к использованию Канбана.

Что такое сервисная парадигма в Канбан

При объяснении что такое STATIK, часто встречается понятие сервиса, сервисного подхода и сервисной парадигмы. Многие могут подумать, что раз они производят продукт и не оказывают услуг клиентам, то эти методы организации процессов не для них. На самом деле понятие сервиса применимо к любому продукту. Разберемся подробнее, в чем же суть этих терминов.
Канбан не является исключительно сервисным методом. В его основе лежит принцип визуализации рабочего процесса и управления потоком задач. Однако, сервисная парадигма может быть интегрирована в Канбан.
Сервисная парадигма — это подход к предоставлению услуг, основанный на понимании потребностей клиентов и высоком качестве обслуживания. Согласно сервисной парадигме, окружающий нас мир состоит из услуг и сервисов.
Представим, что где-то есть клиент у которого есть потребность. А у нас с вами есть группа людей, обладающая определенными навыками, технологиями, производственным процессом и рабочим окружением. Совокупность всего вышеперечисленного может решить клиентскую потребность и это будет называться
Сервисом Поставки Клиентской Ценности или просто Сервисом. Понимание, что вся наша организация — это сеть таких взаимозависимых сервисов и есть сервисная парадигма.
Основной идеей сервисной парадигмы является сервисно-ориентированный образ мышления — переход к восприятию разработки продукта, или предоставления услуги, как к сервису, сфокусированному на удовлетворении потребностей и ожиданий заказчиков.
Пример. Можно купить солнцезащитные очки на рынке — это будет простое приобретение продукта. Клиент получит товар низкого качества, из дешевых материалов, не имеющий особых свойств и не обладающий ценными характеристиками.
А можно приобрести товар известного бренда с качественными линзами, поляризационным эффектом, с фирменным футляром для хранения и т. д.
То есть, покупая продукт клиент закроет сразу несколько своих потребностей:
  • ему помогут подобрать нужную модель консультанты, которые понимают в этом;
  • модель будет подобрана под нужную задачу, например, выбраны очки для вождения со специальными линзами;
  • в брендовом товаре будет продумана и проработана каждая деталь, что закроет потребность выглядеть стильно, получать одобрение общества и т. д.;
  • помимо очков клиент получит футляр для хранения и ему не придется докупать это самому;
  • он сможет получить гарантию качества, купив сертифицированный товар, в котором уверен.
То есть клиент платит больше не просто за продукт, а за то, что прилагается вместе с ним — помощь в выборе, дополнительные аксессуары, гарантия на товар, уверенность в том, что это не подделка и т.д.
Хочешь разобраться, что тебе даст Канбан?
Выбери, что ближе твоему запросу — и получи 🎁 подарок
Хочу понять, как работает Канбан Хочу понять, подходит ли мне Канбан Хочу разобраться, как это работает на практике
Но есть и другой вариант: для кого-то очки с рынка — это то, что нужно. Для некоторой целевой аудитории это будет тот самый продукт, который закроет все потребности, в том числе — потребность в сервисе.
Важно помнить: не всегда и не всем нужно быстро-дорого-качественно. На каждый продукт найдется своя аудитория.
Сервисная парадигма (образ мышления) предполагает, что компании стремятся делать сервис, соответствующий своему предназначению. Не просто поставлять на рынок какой-то продукт, а изучать потребности своих заказчиков, ориентироваться на клиентские метрики. Грубо говоря, мы смотрим на организацию, как на сервис для клиентов, и организационная структура нам не так важна, как набор стадий, через которые проходит запрос клиента.
Главная цель сервисной парадигмы — обеспечить заказчику удовлетворение его потребности наиболее целесообразным образом, выяснив, что клиент хочет, как и когда он хочет это получить. Компания должна понять насколько она сейчас может удовлетворить эту потребность и взять фокус на повышение текущего уровня удовлетворенности.
Сервисная парадигма становится все более значимой в современном бизнесе, поскольку компании осознают, что удовлетворенные клиенты — основа успешного бизнеса. Сервисно-ориентированный образ мышления позволяет компаниям повысить конкурентоспособность, улучшить взаимоотношения с клиентами и занять прочную позицию на рынке.

STATIK и понятие сервисной археологии

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

8 шагов системного подхода к использованию Канбана (STATIK)

Для успешного использования Канбан Метода в организации можно провести STATIK, его часто проводят в виде сессии или воркшопа.
Как стоит проводить STATIK в вашей компании? Ответ на данный вопрос будет зависеть от культуры вашей компании и готовности к использованию новых инструментов. Можно выделить несколько способов проведения:
  • воркшоп, который задействует всех участников и заинтересованных лиц вашего Сервиса поставки клиентской ценности;
  • персональный сбор информации через интервью, и проектирование на основе этой информации Канбан Системы;
  • персональное построение Канбан Системы руководителем.
У каждого из этих способов есть свои особенности, подробнее можно прочитать в книге Алексея Пименова.
Воркшоп STATIK – это встреча, направленная на изучение текущего рабочего процесса, моделирование его составляющих и проектирование Канбан Системы, которая будет в точности отражать существующий процесс.
Основная цель проведения STATIK заключается в изучении производственного процесса и описания его в виде канбан-системы. Спроектированная через STATIK Канбан Система будет отражать процесс поставки клиентской ценности в соответствии с:
  • реальной нагрузкой и возможностями сервиса;
  • существующими источниками неудовлетворенности;
  • особенностями реализации работ.
Выходной артефакт STATIK-а — глубокое понимание того, как идет работа, визуализация этой работы и возможность снимать с производственной системы данные, которые мы можем использовать для улучшения процесса ради попадания в ожидания заказчиков.
Спойлер на будущее: Зачастую, просто используя визуализацию, вы уже сможете находить точки улучшений и совершенствовать свой производственный процесс. Но такие явные точки улучшений достаточно быстро заканчиваются и приходится оперировать уже более долгосрочными наблюдениями или анализировать собранные данные
STATIK предлагает последовательность из 8 шагов. Прежде чем мы рассмотрим подробнее каждый из них, необходимо вспомнить, что любой продукт или услугу мы расцениваем как что-то, что удовлетворяет потребность заказчика — клиентскую ценность. Которую мы «производим» через Сервис поставки клиентской ценности.

Шаг 1. Анализ цели вашего сервиса

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

Шаг 2. Выявление источников неудовлетворенности

Второй этап направлен на выявление мотивации к изменениям через текущие проблемы сотрудников или заинтересованных лиц сервиса, основных проблем существующей системы или сервиса.
Источники неудовлетворенности можно разделить на две категории:
  • Внешние. Сюда относится недовольство внешних участников процесса, которые не участвуют в создании сервиса. Это могут быть, например, заказчики, пользователи, смежные сервисы.Пример. Вы разрабатываете банковское приложение и раз в неделю обновляете пользовательский интерфейс. Пользователи недовольны тем, что они не успевают привыкнуть к одному, а утром оно уже опять другое. Или заказчики недовольны тем, что вы постоянно не попадаете в обещанные сроки.
  • Внутренние. К внутренним относится недовольство участников процесса, задействованных в создании продукта или услуги, то есть участников сервиса. Команда может быть недовольна организацией процессов, иметь трудности с выполнением своих обязательств и удовлетворении потребностей клиентов.Например, сотрудников может не устраивать отсутствие обратной связи от заказчиков. Или количество бесполезных встреч. Или им постоянно приходится ждать какого-нибудь уникального эксперта, чтобы продолжить работу.
Если внутренних источников неудовлетворенности много и они достаточно сильные, то у команд сервиса не возникает эмпатии к заказчику и они не могут взять его источники неудовлетворенности в фокус. Важно понимать внутренние источники неудовлетворенности и устранять их для возможности появления эмпатии команд к источникам неудовлетворенности заказчика.
Источники неудовлетворенности — это драйверы к изменениями. Если всех все устраивает, то нет причин для изменений и ничего меняться не будет.
Вот несколько вопросов, которые можно задать на этом этапе:
  • Какие основные проблемы и недочеты наблюдаются в текущей системе или сервисе?
  • Что вызывает наибольшее недовольство со стороны пользователей или сотрудников?
  • Что является наиболее уязвимыми и часто приводят к ошибкам или задержкам?
  • Что мешает эффективному выполнению работы и достижению поставленных целей?
  • Какие жалобы поступают от пользователей или клиентов? На какие проблемы они указывают?
  • Что не дает выполнить работу нужным образом, с нужным качеством и так как надо?
  • Чем недовольны заказчики, какие есть точки конфликта с ними?
Ответы на вопросы помогут выявить основные причины недовольства и определить, какие процессы требуют изменений и улучшений.
В компаниях с гипер позитивной культурой вместо «источников неудовлетворенности» ищите «точки роста».

Шаг 3. Анализ нагрузки

На этапе анализа потребностей важно понять, что именно требуется от сервиса с точки зрения заказчиков сервиса, изучить источники и природу нагрузки. Под нагрузкой на Сервис поставки клиентской ценности мы понимаем запросы, которые приходят от заказчиков.
Вопросы, на которые стоит ответить во время анализа:
  • Какие потребности и задачи пользователей должен решить сервис?
  • Какие типы работы есть в сервисе?
  • Откуда приходит работа? Какой источник возникновения для каждого типа работ?
  • Куда работа идет после вас? Кто принимает каждый тип работ или куда они передаются далее?
  • Как часто приходит каждый тип работ? Какое количество такой работы приходит за определенную единицу времени?
  • Какие есть особенности появления каждого типа работ? Есть ли паттерн появления, цикличность, такая, как например, сезонность?
  • Какие у заказчиков есть ожидания по выполнению каждого типа работ?
  • Какие ожидания у пользователей относительно сервиса?
  • Какие проблемы или требования пользователей стоит учесть при улучшении сервиса?
  • Что клиенты просят добавить в сервис в отзывах и жалобах?
Помимо этой информации нужно получить фактические данные о количестве запросов. Это нам необходимо для двух целей:
  1. Определения того, как мы справляемся с работой.
  2. Грамотного планирования загрузки нашего сервиса поставки ценности.
Анализ нагрузки помогает понять, сколько, как часто и какой работы приходит в наш сервис. И изучить природу и источники нагрузки.

Шаг 4. Анализ возможностей системы

Этап направлен на изучение текущих возможностей и ограничений системы, которые могут влиять на ее способность удовлетворить потребности пользователей. На этом этапе важно изучить то, как ваш сервис справляется с нагрузкой.
Вопросы, которые следует задать на этапе:
  • Какие возможности уже имеет система и соответствуют ли они потребностям пользователей?
  • Какие есть типы работ?
  • Какие есть особенности у каждого типа работ?
  • Какая пропускная способность системы по каждому типу работ?
  • Каков процент выполнения каждого типа работ?
  • Как выглядит диаграмма распределения времени выполнения каждого типа работ (Lead Time Distribution)?
  • Какие ограничения существуют у системы сейчас и как они влияют на работу?
Проведение анализа возможностей помогает оценить текущее состояние сервиса, выявить сильные и слабые стороны, а также определить направления и причины для дальнейших усовершенствований.
Определить возможности системы можно изучив распределение времени выполнения по каждому типу работ и Накопительную диаграмму потока (Cumulative flow diagram).
Накопительная диаграмма потока показывает, сколько рабочих элементов находится на каждом из этапов рабочего процесса в конкретную дату, какое среднее время выполнения при каком количестве одновременно выполняемых рабочих элементов и какова динамика пропускной способности системы
Распределение времени выполнения рабочих элементов. Показывает статистические данные по времени выполнения завершенных задач. Сколько рабочих элементов данного типа за какое время было сделано. Строится отдельно для каждого типа рабочих элементов, только для элементов, работа над которыми закончена (они сделаны).
Здесь мы видим на одной диаграмме несколько типов рабочих элементов. Нагляднее строить отдельную диаграмму для каждого. Источник изображения: https://www.youtube.com/watch?v=cw1U5XXXuiI

Шаг 5. Построение жизненных циклов

Полученный на этом этапе результат ляжет в основу визуализации процесса. На этом этапе важно определить, какой жизненный путь проходит запрос.
Проще всего это делать как большое упражнение, в котором задействованы все специалисты, обслуживающие ваш сервис поставки ценности:
  1. Для каждого типа рабочих элементов определите те активности, которые специалисты сервиса выполняли для того, чтобы его завершить. Здесь важна целостная картина реализации тех или иных рабочих элементов.
  2. Распределите данные активности по условной шкале времени.
  3. Сгруппируйте активности в некоторые стадии и выделите доминантную активность в этой стадии. После этого необходимо придумать названия доминантных активностей и разделить временную шкалу на этапы, в которых эти доминантные активности происходят.
На этом можно данный этап исследования считать законченным.

Шаг 6. Определение классов обслуживания

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

Шаг 7. Проектирование канбан-системы

Этап направлен на проектирование канбан-системы под контекст сервиса, на основании всех собранных нами данных. Доска не должна быть шаблонной или скопированной.
Суть STATIK-а в том, чтобы разработать систему, которая будет подходить под контекст конкретного сервиса. Один сервис — один STATIK.
Элементы Канбан-системы:
  • точка принятия обязательств;
  • типы работ;
  • классы обслуживания;
  • жизненные циклы запросов, с учетом того, что они построены как процесс накопления знаний;
  • дизайн тикета;
  • дизайн доски;
  • петли обратной связи;
  • первичные договоренности.
Система должна учитывать всю информацию, собранную на предыдущих этапах:
  • данные об особенностях продукта или услуги: какой он и для кого создан;
  • слабые места продукта и сервиса, требующие улучшения;
  • список потребностей пользователей и их ожиданий от готового продукта;
  • возможности системы: производительность команды, ресурсы и т. д.;
  • информацию о всех этапах работ.
При проектировании Канбан-доски стоит следовать рекомендациям:
  1. Помните, что доска и стикеры — это отражение того, как у вас сейчас устроен рабочий процесс. Они не должны диктовать правила работы, они являются их отражением.
  2. Проектировать канбан-систему важно с теми, кто участвует в производственном процессе, а не приносить людям уже готовую.
  3. При проектировании есть два очень сильных визуальных элемента, видимых издалека и легко распознаваемых, — это цвета стикеров и дорожки. Используйте их для обозначения самой важной информации.
  4. Каждая Канбан Система уникальна и создается для контекста конкретного процесса. Их нельзя эффективно копировать из других подразделений или компаний.
  5. Помните, грамотный дизайн тикета упрощает дизайн доски. На карточке должна быть информация, которая помогает нам сделать доску проще. Например, использование чек-листов в карточках часто сокращает количество необходимых столбцов. Это может быть как в цифровом инструменте типа Кайтена, так и на бумажной карточке, если доска аналоговая (висит на стене в кабинете).
Если вы будете следовать этим советам, то сохраните себе много времени на этапе внедрения созданной Канбан Системы и обучения пользователей.
Пример Канбан-доски и дорожек с этапами работ

Шаг 8. Запуск и социализация

После того как дизайн системы готов, можно переходить к запуску. Чтобы начать использовать систему, нужно наполнить данными визуализацию проекта — внести туда все, чем сейчас занимается Сервис поставки клиентской ценности.
Этот процесс не является единоразовым. Сначала вы выносите на визуализацию все данные, которые помните, затем начинается активное использование доски и, скорее всего, будут появляться работы, которые вы или ваши команды делали ранее, но они не отражены на доске. Вы будете их фиксировать и размещать на доске пока новые находки не прекратятся.
Во время использования визуализации вы можете столкнуться с появлением новых стикеров, для которых не подходит не одна из существующих колонок. Это сигнал о том, что во время проектирования было что-то упущено и визуализация требует корректировок. В этом нет ничего плохого, дизайн доски и стикера — это живой инструмент и он может меняться по необходимости. Сразу после построения системы изменений будет много, вы будете находить какие-то вещи, которые не учли, не вспомнили, не подумали о них. Такая активность со временем сойдет на нет.
В ходе корректировок вы будете находить точки для улучшения в производственном процессе, проводить организационные изменения и это будет отражаться на визуализации вашего процесса.
Важно всегда помнить: визуализация — это выходной артефакт. Она отражает то, как у вас идет работа в текущий момент. В начале вы должны поменять рабочий процесс и только потом отразить изменения на визуализации.
Нельзя сначала поменять WIP-лимит или добавить пару новых колонок на доску, а затем сказать команде, что теперь следует работать согласно доске. Доска не диктует правила работы — она их отражает. Поэтому вначале вы меняете процессы, договариваетесь с командой, убеждаете их в необходимости внесения изменений, подводите людей к самостоятельному принятию решения о корректировках производственных процессов, и только после принятия «новых правил игры» отражаете это на визуализации.

Итеративное повторение шагов

Итеративное повторение STATIK — важный фактор успешного развития канбан-инициатив.
Важно понимать, что невозможно спроектировать идеальную Канбан-систему один раз и оставить ее без изменений навсегда. Реальность такова, что производственные процессы, потребности клиентов и команды изменчивы, и система требует постоянной корректировки и адаптации.
Повторное проведение STATIK желательно делать регулярно, но не чаще чем раз в месяц.
Также могут возникать события при которых необходимо провести STATIK повторно, такие как:
  • изменение состава сотрудников вашего сервиса;
  • появление новых заказчиков или прекращение сотрудничества со старыми;
  • технологические изменения производственного процесса.
Хороший формат проведения повторного STATIK-а — проведение его в обратном порядке. Такой формат получил название Реверсивный STATIK (Reverse STATIK).
На регулярных STATIK-сессиях команда может пересматривать текущую Канбан-систему, обсуждать возможные улучшения, адаптировать систему к новым требованиям и вносить изменения по мере необходимости. Этот подход позволяет сохранить систему актуальной, эффективной и соответствующей текущим потребностям бизнеса.
Если вам требуется помощь с внедрением Канбан или других методологий управления проектами — обратитесь в Neogenda. Наш тренинг ответит на все вопросы про запуск канбан инициатив и проведение STATIK. Прямо во время курса вы сможете разработать свою Канбан-систему для вашего процесса или команды.
]]> Роль Product Owner в LeSS, Nexus, SAFe® http://neogenda.ru/blog/vgg8fszdh1-rol-product-owner-v-less-nexus-safe http://neogenda.ru/blog/vgg8fszdh1-rol-product-owner-v-less-nexus-safe?amp=true Fri, 12 Jul 2024 08:14:00 +0300 Дмитрий Кустов Владелец Продукта в Scrum играет ключевую роль в управлении продуктом. Но меняются ли его функции,...

Роль Product Owner в LeSS, Nexus, SAFe®

Владелец Продукта в Scrum играет ключевую роль в управлении продуктом. Но меняются ли его функции, когда речь заходит о масштабировании Agile-практик на уровень организации или проекта в таких фреймворках как Nexus, LeSS и SAFe? Отличается ли от классического подхода, принятого в методологии Scrum?
В данной статье мы рассмотрим не фреймворки как таковые, а именно как меняется содержание и задачи Владельца Продукта в рамках каждого из них.

LeSS (Large-Scale Scrum)

Фреймворк LeSS родился в 2005 году, когда потребовалось масштабировать методологию Scrum для крупных клиентов. LeSS представляет собой применение скрама к нескольким командам, работающим вместе над одним продуктом. Это не новый или усовершенствованный скрам, а это о том, как ввести принципы скрам в большом контексте как можно проще.
Роль владельца продукта в LeSS аналогична его роли в скраме для одной команды и немного отличается следующим:
  • В LeSS один владелец продукта может координировать работу не одной, а до 8-ми скрам-команд, которые ведут работу над общим бэклогом.
  • Владелец продукта уже не посредник, а связующее звено — помогает командам непосредственно взаимодействовать с реальными пользователями и клиентами для обновления элементов бэклога.
  • Владелец продукта сосредоточен больше на понимании продукта и обеспечивает максимальную отдачу инвестиций (ROI — возврат/рентабельность инвестиций).
В LeSS уделяется особое внимание непосредственному общению между командами разработки и конечными пользователями по ряду факторов:
  1. Минимизируются искажения и потери информации.
  2. При разработке решений улучшается сотрудничество между разработчиками и клиентами, что позволяет лучше удовлетворять потребности пользователей.
  3. Повышается мотивация разработчиков и их отзывчивость по отношению к пользователям.
Если количество команд в продукте превышает 8, то активируется LeSS-Huge и у владельца продукта появляются помощники — Area Product Owners (APO).
Каждый APO работает с минимум тремя командами и развивает какую-то одну грань продукта с учетом потребностей клиента. Своего бэклога APO не имеет, все работают в рамках одного единственного бэклога.
В целом, Product Owner в LeSS практически идентичен владельцу продукта в скраме.

Nexus

Фреймворк Nexus появился в 2015 году, был представлен Кеном Швабером, в основе — Scrum, но с некоторыми улучшениями.
Цель Nexus — увеличить ценность, которую способны доставить несколько скрам-команд (до 9 команд), имеющих общий бэклог продукта. Для этого в Nexus вводится дополнительная Команда Интеграции.
Кен Швабер дал следующее определение Владельца продукта, почти в точности повторяя его из гайда Scrum:
Владелец продукта несет ответственность за максимизацию ценности продукта и работы, выполняемой и интегрируемой командами Scrum в Nexus.
То есть в Nexus роль Product Owner остается той же, что и в Scrum.

Scaled Agile Framework® (SAFe)

В 2011 году Дин Лёфингвэлл представил фреймворк SAFe 1.0.
SAFe® для Lean Enterprises является базой знаний проверенных, интегрированных принципов, практик и компетенций для достижения деловой гибкости с использованием Lean, Agile и DevOps.
SAFe не позиционирует себя как фреймворк Scrum. Тем не менее, SAFe вводит понятие Product Owner, и его роль там довольна интересна.
Существенные отличия самого популярного фреймворка для масштабирования Agile-практик:
Вместо Scrum, на уровне команд используется SAFe Scrum (процесс, созданный сообществом SAFe, похожий на Scrum).
Присутствуют еще две роли, участвующие в управлении ценностью продукта — Менеджмент Продукта (Product Management) и Владельцы Бизнеса (Business Owners).
Итак, SAFe Scrum — это Agile-метод, используемый командами для предоставления ценности клиентам в короткие сроки.
Ниже даны определения главных ролей в SAFe — Product Owner, Product Manager и Business Owner.
РольProduct OwnerProduct ManagementBusiness Owners
Описание роли Участник Agile-команды, ключевая ответственность которого в максимизации ценности, поставляемой командой, за счет соответствия Бэклога Команды потребностям клиентов и заинтересованных лиц. Отвечает за определение желательных, жизнеспособных, выполнимых и устойчивых решений, которые удовлетворяют потребности клиентов и поддерживают разработку на протяжении всего жизненного цикла продукта. Являются ключевыми заинтересованными сторонами, которые несут основную деловую и техническую ответственность за возврат инвестиций (ROI), управление и соблюдение требований.
Участник Agile-команды, ключевая ответственность которого в максимизации ценности, поставляемой командой, за счет соответствия Бэклога Команды потребностям клиентов и заинтересованных лиц.
Отвечает за определение желательных, жизнеспособных, выполнимых и устойчивых решений, которые удовлетворяют потребности клиентов и поддерживают разработку на протяжении всего жизненного цикла продукта.
Являются ключевыми заинтересованными сторонами, которые несут основную деловую и техническую ответственность за возврат инвестиций (ROI), управление и соблюдение требований.
Таким образом, в SAFe роль Владельца Продукта из Scrum разделяется между несколькими ролями: Product Owner, Менеджер Продукта и Владелец Бизнеса.
Кстати, в многих англоязычных источниках ошибочно берут определение Product Owner из SAFe и, видимо, поэтому рассматривают Владельца Продукта как специалиста, тесно взаимодействующего с командой разработки, чтобы отвечать на запросы менеджмента по продукту и высшего руководства.
Каждая из этих ролей в SAFe выполняет определенные функции, связанные с управлением продуктом, его ценностью и соответствием бизнес-целям. Однако, все они направлены на максимизацию ценности продукта, что является ключевой задачей Владельца Продукта в рамках фреймворка Scrum.
Вне зависимости от выбранного подхода, Владелец Продукта выполняет определенные функции, связанные с управлением продуктом, его ценностью и соответствием бизнес-целям, и играет ключевую роль в достижении успеха продукта. Однако в каждом подходе у этой роли есть свои особенности и акценты.
SAFe and Scaled Agile Framework являются зарегистрированными товарными знаками Scaled Agile, Inc.
]]> В чем разница между Владельцем и Менеджером продукта http://neogenda.ru/blog/1d5atkxid1-v-chem-raznitsa-mezhdu-vladeltsem-i-mene http://neogenda.ru/blog/1d5atkxid1-v-chem-raznitsa-mezhdu-vladeltsem-i-mene?amp=true Mon, 15 Jul 2024 10:36:00 +0300 Дмитрий Кустов Product Owner (владелец продукта) и Product Manager (менеджер продукта) популярные профессии в наше время. Кто-то...

В чем разница между Владельцем и Менеджером продукта

Product Owner (владелец продукта) и Product Manager (менеджер продукта) популярные профессии в наше время. Кто-то считает, что это иерархически связанные позиции, и тут требуется определиться, какая роли в организации находится выше. Кто-то считает, что это одно и тоже по сути, просто разные названия. В этой статье расставляем ориентиры, которые помогут вам разобраться в данной теме.
Когда меня спрашивают, чем отличается Владелец продукта от Менеджера продукта, то задаю встречный вопрос:

— Какого владельца и менеджера продукта вы имеете ввиду, потому что существует как минимум две версии Product Owner и два типа Product Manager?

Два Владельца продукта

Первый Product Owner пришел из фреймворка Scrum в 2011.
Владелец продукта несет ответственность за максимизацию ценности продукта, получаемого в результате работы Scrum Team. Также несет ответственность за эффективное управление Product Backlog. Product Owner может выполнять это работу сам или делегировать ее выполнение другим лицам. Тем не менее, Product Owner остается ответственным за нее.

(с) Руководство по Scrum 2020
Простыми словами, Владелец продукта в Scrum — это человек, который несет единоличную и нераздельную ответственность за максимизацию ценности продукта, как результата работы Scrum команды.
!НО, есть одна фраза в руководстве по Скрам, которая уменьшает вес роли.
Способы достижения максимальной ценности могут быть очень разными и зависят от организаций, Scrum Teams и конкретных людей.

(с) Руководство по Scrum 2020
Другими словами, если в организации решили, что достижение максимальной ценности как результата работы Scrum Team является увеличение количества выполненных задач за промежуток времени, то Владелец продукта в данном контексте превращается в Delivery менеджера. А учитывая, что определение термину «Продукт» в руководстве по Скрам нет, то наполнение его зависит от фантазии людей.
Мне не нравится данная фраза, потому что она открывает организациям пространство для манёвра и применение роли Product Owner на сущности, которые не являются продуктами. Есть даже факт того, что изначально под максимизацией ценности продукта, в 2004 году Кен Швабер, один из создателей Scrum, пишет в своей книге Agile Project Management with Scrum, что Владелец продукта несет ответственность перед теми, кто финансирует проект, за реализацию видения таким образом, чтобы максимизировать рентабельность инвестиций (ROI). И всё же, с момента выпуска первой версии Scrum Guide 2011 до настоящего времени, понимание максимизация ценности продукта, остаётся на откуп людям в компаниях, которые решили применять фреймворк Scrum.
Во фреймворках масштабирования Scrum, таких как Scrum of Scrums, Nexus и LeSS, Владелец продукта понимается аналогично версии из Scrum Guide.
Второй Product Owner пришел из Scaled Agile Framework®.
В 2011 году Дин Лёфингвэлл представил первую версию SAFe 1.0
Владелец продукта (Product Owner) является участником Agile команды, отвечает за определение историй и расстановку приоритетов в бэклоге команды(!), чтобы оптимизировать выполнение приоритетов программы при сохранении концептуальной и технической целостности функций или компонентов. Роль предполагает плотное взаимодействие с менеджментом продукта, пользователями, владельцами бизнеса и другими заинтересованными сторонами.

(с) Scaled Agile Framework®
Простыми словами, Владелец продукта в SAFe — это человек, который отвечает за составление и приоритезацию и реализацию элементов бэклога команды, которые направлены на достижение целей и задач менеджмента продукта.
С владельцами продукта познакомились, переходим к Менеджеру продукта, где как уже было сказано есть два типа.

Краткая история развития Менеджера продукта

История появления роли менеджера продукта начинается в прошлом столетии в компании Procter & Gamble’s.
В 1931 году Нил Макэлрой изложил обязанности и ответственность новой в компании должности «brand man». Бренд-менеджеры отвечали за бренд, изучение клиентов и территории продаж, маркетинг, разработку, управление продуктами и управление цепочками поставок.
Спустя несколько лет, Нил консультирует молодых предпринимателей Билла Хьюлетта и Дэвида Паккарда, основателей Hewlett-Packard. Они интерпретировали концепцию brand men как “максимально приближение процесса принятия решений к клиенту”. Благодаря этой реализации HP стала одной из первых компаний, внедрили понятие управление продуктами (product management).
В 90-х годы произошло значительное развитие в дисциплине продуктового менеджмента направляется на ускорение получения обратной связи от пользователей, для эффективной адаптации продуктов компаний под потребности. Например в Microsoft, это привело к формированию новой роли в индустрии — Менеджера программы (Program Manager), который служил связующим звеном между инженерами и пользователями, переводя и адаптируя технические требования в контексте потребностей пользователей.
В новом тысячелетии одним из ключевых изменений стало широкое внедрение Agile-подходов в разработке, что позволило компаниям быстрее адаптироваться к быстро меняющимся технологиям и требованиям рынка. Происходит стремительное развитие интернет-технологий и мобильной связи, что привело к возникновению новых категорий продуктов, включая мобильные приложения и облачные сервисы. Менеджеры по продукту стали играть ключевую роль в создании маркетинговой и продуктовых стратегий, опираясь на глубокое понимание потребностей потребителей.

Два типа Менеджера продукта

В отличие от Владельца продукта в мире продуктовых менеджеров существует факт грейдирования Менеджеров продукта на junior, middle, senior и director. Также существует разделение продуктовых менеджеров по специализациям: product marketing manager, product design manager, product development manager и т.д.
В книге The Guide to the Product Management and Marketing Body of Knowledge в управлении продуктами выделяют два уровня продуктового менеджмента:
Upstream Product Management (Management position) отвечает за стратегию, финансы, развитие бизнес-моделей продуктов и направлений, управление портфелем продуктов, запуск новых продуктов, выход на новые рынки, принятие решений об инвестициям в перспективные технологии, развитии сотрудников компании и т.д.
Upstream Product Management (Management position): Chief Executive Officer (CEO), Product Lead, Head of Product, VP of Product, VP of Marketing, Chief Marketing Officer (CMO), Chief Information Officer (CIO), Chief Product Officer (CPO), Chief Technical Officer (CTO), Chief Financial Officer (CFO), Human Resources Director (HRD) и другие C-level позиции. В данном эшелоне находятся менеджмент на уровне отдельных продуктов и функций организаций.
Downstream product management (Contribution position) отвечает за реализацию намеченной стратегии, достижение целей и задач, включает в себя: разработка и развитие продуктов, улучшение и разработка внутренних систем, улучшение показателей эффективности и т.д.
Downstream product management (Contribution position): Junior Product Manager, Middle Product Manager, Senior Product Manager, Product Manager, Product Marketing Manager, Data Product Manager, Product Designer, UI/UX Product Manager и другие исполнительные позиции на уровне продукта и на уровне функции. В данном эшелоне находятся менеджеры руководящего, среднего и начальных позиций как на уровне продукта, так и на уровне функций организаций.
В небольших компаниях, менеджеры продуктов часто объединяют обе позиции, особенно это ярко выражено в стартапах.
Для меня ключевым разделением между Management и Contribution менеджерами заключается в наличии полномочий принимать управленческие решения касательно целей и вектора развития продукта. Например, Contribution position менеджер может принимать решения о том, как улучшить первую сессию клиента, как улучшить процесс онбординга или определять форму и наполнение той или иной функциональности. НО, Contribution position менеджер не имеет полномочий решать, на чем в данный момент стоит сфокусировать команду: повышении retention, поднятия конверсии воронки, повышение среднего чека или поднять вовлеченность пользователей. На чем сфокусироваться и на что сделать ставку, определяется Management position менеджерами.

Сравниваем Владельцев и Менеджеров продукта

Думаю, кто-то смог заметить, что Product Owner in SAFe хорошо укладывается в Contribution position. С Product Owner in Scrum, чуть сложнее, так как эта позиция предполагает активности на обоих уровнях и Management и Contribution position.
Теперь у вас есть карта, которая позволит самостоятельно сравнивать между собой разные версии Владельцев и Менеджеров продукта. Главное, чтобы в организации было единое понимание полномочий и зону ответственности роли, и не важно будет это Менеджер или Владелец продукта.
В завершении статьи, оставлю для вас один вопрос, который вызывает заторы в синапсах руководителей компаний.
— Кто является лицом отвечающим успех продукта?
Множество людей и команд оказывают влияние на продукт компании: бизнес-функции, IT, дизайнеры, маркетологи, продажи, служба поддержки клиентов, логистика, финансы, юристы и т.д. В какой-то мере, каждая группа специалистов уверена, что с их точки зрения будет лучшим в развитии продукта для клиентов и компании. Однако это разнообразие мнений, порой приводит к затяжным спорам, затягиванию принятия решений, а желание всем угодить размывает фокус и снижает эффективность работы. По этой же причине, Кен Швабер подчеркивает необходимость в определении конкретного лица, отвечающего за продукт, чтобы обеспечить согласованность и эффективное управление продуктом.
Всем отличных управленческих решений 🤘
]]> 5 самых важных Agile-метрик и 11 второстепенных http://neogenda.ru/blog/hfepvb1if1-5-samih-vazhnih-agile-metrik-i-11-vtoros http://neogenda.ru/blog/hfepvb1if1-5-samih-vazhnih-agile-metrik-i-11-vtoros?amp=true Wed, 17 Jul 2024 12:39:00 +0300 Дмитрий Кустов В современном мире гибкие подходы к управлению проектами занимают ведущие места в разработке ПО и...

5 самых важных Agile-метрик и 11 второстепенных

В современном мире гибкие подходы к управлению проектами занимают ведущие места в разработке ПО и многих других областях, обеспечивая гибкость, прозрачность и эффективность процессов. Но для достижения успеха в Agile-командах необходимо иметь четкое представление о том, как оценивать ключевые показатели и улучшать процессы внутри команды. Тут на помощь руководителям проектов и Scrum-мастерам приходят Agile-метрики.
Agile-метрики — это количественные показатели для оценки качества и эффективности работы Agile-команд. Метрики помогают командам лучше понимать свою работу, оптимизировать процессы, анализировать прогресс проекта, улучшать качество продукта и достигать успешных результатов.
Использование Agile-метрик помогает удовлетворить ожидания клиентов, повысить конкурентоспособность продукта, а также обеспечить эффективное управление проектами. Если вам необходимо внедрение гибких подходов – вы можете обратиться в Neogenda.
Далее в статье:
  • цели сбора метрик;
  • 5 основных agile-метрик;
  • обзор второстепенных метрик для отслеживания;
  • как правильно оценивать.

Цели сбора Agile-метрик

Сбор метрик в Agile-командах необходим не только для отслеживания процессов и оценки результата, но и для анализа эффективности работы, выявления проблем на ранней стадии и принятия обоснованных управленческих решений. Без использования метрик Agile-команды могут столкнуться с неопределенностью, неэффективностью и неспособностью достичь стоящих перед ними целей.
Целями сбора метрик могут быть:
  • Организация прозрачности процессов. Для самосовершенствования продукта с каждой последующей итерацией разработки, команде важно отслеживать показатели проекта. Такой подход формирует доверительные отношения между членами команды и повышает продуктивность.
  • Поиск способов для мотивации команды, выявление причин снижения продуктивности. Руководителю проектов важно мониторить показатели проекта, чтобы отслеживать подъемы и спады продуктивности команды, их первопричины. Это важно для поддержания здоровой атмосферы в коллективе и снижения выгорания сотрудников.
  • Предоставление данных для руководства и стейкхолдеров. От их обратной связи и заинтересованности в проекте напрямую зависит конечный результат, но для их эффективного участия в разработке, они тоже должны получать ответы на свои вопросы и быть в курсе ситуации на проекте.
  • Принятие управленческих решений. Опираясь на метрики можно оценить реальную картину происходящего и принять обоснованное решение.
Главная цель отслеживания метрик — постоянное улучшение результативности и эффективности работы команды.

Основные Agile-метрики

Agile-метрики играют ключевую роль в оценке результативности и эффективности работы команды.
Среди самых важных стоит выделить:
  • диаграмму сгорания работы или задач (Burn Down Chart);
  • скорость команды (Velocity);
  • контрольную диаграмму (Control Chart);
  • накопительную диаграмму потока (Cumulative Flow Diagram);
  • пропускную способность команды (Throughput).
Далее мы рассмотрим каждую из этих метрик подробнее и разберем их применение в контексте управления проектами.

Диаграмма сгорания задач в спринте (Burn Down Chart)

Диаграмма сгорания задач в спринте (Burn Down Chart) — это график, отображающий количество незавершенной работы в спринте. Горизонтальная ось обычно представляет время, а вертикальная — объем задач.
Цель диаграммы сгорания — помочь команде отслеживать прогресс выполнения задач, оптимизировать работу и оценить, укладывается ли команда выполнить запланированную на спринт работу.
Пример построения диаграммы сгорания задач спринта

Скорость команды (Velocity)

Скорость команды (Velocity) — эта метрика отображает количество работы, которое команда может завершить за один спринт, измеряет Burndown chart. Обычно рассчитывается в количестве Story points за спринт. Рассчитывается на основе завершенных задач из предыдущих спринтов.
Скорость команды помогает предсказать, сколько задач команда сможет выполнить в будущих спринтах и запланировать реалистичный объем работы.
Пример графика скорости команды для четырех спринтов. Саммари: за 4 спринта скорость команды увеличилась с 10 sp до 14 sp, команда способна решать больше сложных задач за спринт и реализует запланированный объем задач (выполняет и перевыполняет план на протяжении 2 последних спринтов)

Контрольная диаграмма (Control Chart)

Контрольная диаграмма (Control Chart), также известная как график контроля — инструмент статистического управления качеством, который используется для мониторинга и анализа процессов в Agile разработке. Основной целью контрольной диаграммы является отслеживание дисперсии времени выполнения задач (Lead Time) в рамках проекта.
Контрольная диаграмма позволяет команде визуально представить изменения и колебания времени выполнения задач (Lead Time), а также выявить необычные или негативные тренды в процессе работы. На основе статистики выполнения задач, формируются договоренности о целевом показатели времени выполнения задач, или уровне сервиса SLA (Service Level Agreement).
Контрольная диаграмма помогает команде отслеживать уровень SLA, другими словами, какой процент выполненных задач соответствует договоренностям. Задачи, которые находятся ниже уровня SLA — были выполнены согласно договоренностям, те, что выше — были выполнены с нарушением SLA.
Пример визуализации контрольной диаграммы. Саммари: на диаграмме видно, что 4 из 19 задач, не укладываются в SLA. Как минимум следует разобраться в причинах, возможно следует провести изменения в процессе работы, а может пора передоговориться об уровне SLA.
Контрольные диаграммы используются для мониторинга стабильности процесса, предсказания возможных проблем и принятия решений на основе данных.

Накопительная диаграмма потока (Cumulative Flow Diagram)

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

Пропускная способность (Throughput)

Пропускная способность (Throughput) — это метрика, измеряющая количество задач или единиц работы, которые команда смогла завершить за определенный период времени, например, спринт или неделю. Она показывает результативность работы команды и позволяет оценить, как быстро команда достигает результатов.
Пример:
  • Нам нужно понять какая пропускная способность команды за 10 дней в период с 6 мая по 16 мая.
  • Смотрим на Накопительной диаграмме потока количество выполненных задач 6 мая — выполнена 1 задача.
  • Смотрим количество выполненных задач на момент 16 мая — 3 задачи.
Итого: пропускная способность команды за 10 дней составляет 2 задачи.
Пример расчета пропускной способности команды за выбранный период
Используя метрику руководители проекта могут более точно планировать объем работы на будущие итерации, улучшать распределение задач, оптимизировать процессы и повышать общую эффективность работы.

Дополнительные Agile-метрики для мониторинга ситуации на проекте

Помимо основных пяти показателей, для agile-проектов можно использовать и второстепенные, но не менее полезные метрики. Они помогут лучше разобраться в контексте конкретной ситуации, дадут более полную и исчерпывающую картину происходящего на проекте и помогут принять оптимальное решение.
Среди таких качественных и количественных метрик можно выделить:
  • Время цикла (Cycle time). Время, требуемое для завершения работы на конкретном этапе. Cycle time показывает реальное время, необходимое для завершения определенной работы, что позволяет улучшать процессы, уменьшать задержки и повышать производительность.
  • Динамика изменений цикла (Cycle time trends). Метрика используется для отслеживания и оценки тенденций эффективности этапов работы. Cycle time trends позволяют выявить изменения во времени, анализировать причины сдвигов и прогнозировать будущие показатели производительности.
  • Метрика качества (Quality). Количественный показатель, который используется для измерения уровня качества продукта, услуги или процесса. Метрика отражает количество найденных за проект или релиз багов и соответствие продукта стандартам качества.
  • Точность выполнения обязательств (Accuracy of Commitment, Forecast). Метрика, отражающая способность команды выполнять задачи в оговоренные сроки. Accuracy of Commitment отражает разницу между запланированными сроками выполнения и фактическими.
  • Работа в сверхурочное время (Overtime). Дополнительные часы работы сотрудника, за которые ему обычно полагается дополнительная оплата. Показатель, который отражает увеличение рабочего времени сотрудника сверх нормы и может служить индикатором повышенной загруженности или дополнительной мотивации сотрудника или команды. Предельное использование Overtime может указывать на неэффективность в распределении задач и организации рабочего процесса.
  • Эффективность усилий (Effort Effectiveness). Показатель, отражающий количество усилий, времени, ресурсов для достижения результата. Чем выше эффективность усилий, тем меньше ресурсов требуется для получения результата.
  • Эффективность потока (Flow Efficiency. Показатель измеряет отношение чистого рабочего времени к общему времени выполнения задачи. Помогает понять, сколько времени задачи находятся в состоянии ожидания и как можно улучшить процесс для уменьшения простоев.
  • Количество дефектов. Показатель, который отражает количество обнаруженных дефектов или ошибок в продукте, процессе или проекте. Чем меньше количество дефектов, тем выше качество продукции или услуги.
  • Уровень клиентского удовлетворения (CSI). Метрика, которая измеряет удовлетворенность клиентов продуктом, услугой или опытом взаимодействия с компанией.
  • Частота релизов. Показатель, отражающий частоту выпуска новых версий ПО или продуктов на рынок. Демонстрирует, как часто компания вносит изменения, улучшения и нововведения в свои продукты, обновляет их функционал и исправляет ошибки. Чем выше частота релизов, тем более активно компания работает над улучшением своих продуктов, следит за требованиями рынка и удовлетворяет потребности пользователей.
  • Скорость отклика на изменения. Показатель, который отражает общее время, за которое компания, команда или отдельный процесс реагирует на изменения внешних требований или условий. Показатель включает в себя время на принятия решения и реализации изменений. Чем быстрее компания может адаптироваться к изменениям, тем конкурентоспособнее она на рынке и успешнее использует новые возможности для развития бизнеса.

Как правильно оценивать показатели

Для грамотной оценки метрик недостаточно просто изучить конкретный показатель и сделать на его основе выводы о ситуации — такая оценка будет субъективна и не даст информацию о реальном положении дел на проекте.
Вот несколько советов, которые помогут принять важное решение, опираясь на факты и аналитику проекта:
1. Учитывайте контекст ситуации. Оценка показателей должна учитывать особенности и цели конкретного проекта или продукта. Каждая команда и организация уникальны, поэтому важно адаптировать показатели к своей среде, бизнес-модели, целям и специфике задач. Набор ключевых показателей и метрик также стоит подбирать индивидуально.
2. Проводить комплексный анализ нескольких показателей. Оценку Agile-процессов целесообразно проводить не только на основе одного показателя, а на основе комплекса различных метрик. Это позволяет получить более полное представление о состоянии проекта или продукта, его эффективности и качестве.
3. Изучайте взаимосвязи между показателями. Ключевым также является анализ взаимосвязей между различными метриками. Например, увеличение скорости разработки может повлиять на качество продукта, а повышение частоты релизов может сказаться на удовлетворенности клиентов. Понимание этих связей позволяет более точно оценить эффективность Agile-процессов и принимать обоснованные решения для улучшения работы команды.
Если вам нужно оценить эффективность работы команды или внедрить гибкие подходы к управлению проектами — обратитесь в Neogenda. Мы обучили более 5000 участников продуктовых команд и помогли достичь результатов таким компаниям как Tinkoff, Яндекс, Авито, Сбер, Билайн, Skyeng и так далее. Оставьте заявку на бесплатную консультацию в Zoom и мы предложим решение для вашего бизнеса.
]]> Как управлять временем производства с помощью WIP-лимитов http://neogenda.ru/blog/smvtcy07s1-kak-upravlyat-vremenem-proizvodstva-s-po http://neogenda.ru/blog/smvtcy07s1-kak-upravlyat-vremenem-proizvodstva-s-po?amp=true Fri, 19 Jul 2024 13:07:00 +0300 Алексей Пименов Постоянная перегрузка людей, сверхурочная работа, огромное количество одновременно выполняемых задач, низкое качество оказания услуг и...

Как управлять временем производства с помощью WIP-лимитов

Постоянная перегрузка людей, сверхурочная работа, огромное количество одновременно выполняемых задач, низкое качество оказания услуг и разработки продуктов — все это может серьезно замедлить развитие бизнеса и потянуть компанию вниз. Одним из инструментов, которые помогают справиться с этими проблемами, является WIP-лимит.
WIP-лимит (Work in Progress limit) — это ограничение количества незавершенной работы, т.е. в производственном процессе у вас не может быть больше чем определенное количество рабочих элементов одновременно..
WIP (Work in Progress) — это количество незавершенной работы.
Отличие между WIP и WIP-лимитом заключается в том, что WIP представляет собой количество работы, которое было начато, но до сих пор не закончено, а
WIP-лимит — это ограничение на количество этой работы, т.е. вы не можете стартовать ничего нового, пока не закончите старое.
Какие преимущества дает установка WIP-лимитов:
  • Фокус — WIP-лимит не дает вам начать очень много работы и распыляться на нее, WIP-лимит фокусирует вас на достаточно небольшом количестве работы;
  • Емкость — WIP-лимит дает вам понимание емкости своей производственной системы, что помогает отвечать на вопрос: “А можете взять еще в работу?”;
  • Сокращение времени производства — такая метрика, как время производства, крайне чувствительна к размеру WIP и установка WIP-лимита может помочь в сокращении времени производства.
Установленный лимит, а в частности небольшое его значение (ну например меньшее, чем количество людей в вашей команде) способствует повышению уровня совместной работы, увеличению прозрачности в работе команды и улучшению коммуникаций.
Для внедрения WIP-лимитов и консультации по выстраиванию процессов внутри команды вы можете обратиться в Neogenda.
Далее в статье:
  • преимущества использования WIP-лимитов;
  • как определить начальный WIP-лимит;
  • как понять что стоит уменьшить лимит;
  • когда использование лимитов нецелесообразно;
  • советы по использованию WIP-лимитов.

Преимущества использования WIP-лимитов

От использования ограничения количества незавершенной работы выигрывает и бизнес, и команда. Бизнес получает предсказуемую производственную систему, а производственная команда или команды — стабильную нагрузку.
Среди преимуществ использования WIP-лимитов можно выделить:
  1. Предсказуемость системы. Если количество работы в производственной системе ограничено, то мы не будем иметь разброса по времени производства у похожих рабочих элементов за счет того, что кто-то набирает в систему дополнительной работы, тормозя тем самым завершение уже начатой работы.
  2. Защита команды от выгорания. При установлении лимитов исключается возможность перегрузить сотрудников излишним объемом работ до состояния «тлеющего пепла». Сотрудники испытывают меньше стресса и могут сделать работу «так как надо» и быть горды за результат.
  3. Повышение коллабораци. С установленными WIP-лимитами может случиться ситуация в которой одни люди освобождаются, в то время как другие люди сильно заняты и это может являться стимулом к появлению прецедентов взаимопомощи и совместной работы.
  4. Более серьезное отношение к бизнес-ценности и приоритетам. При вводе WIP-лимитов на количество задач, команда не сможет брать неограниченное количество задач в работу, это заставляет заказчиков тщательнее подходить к отбору потенциальной работы и расстановке приоритетов.

Как определить начальный WIP-лимит

Не существует универсальной формулы для определения WIP-лимита, так как каждый контекст производственной системы уникален. Определение WIP-лимита — это эмпирический процесс, в котором будут и эксперименты и корректировки.
Вот несколько советов по определению WIP-лимита для команды:
1. WIP-лимит у вас уже есть, вы просто об этом еще не знаете. Попробуйте проанализировать статистику по количеству незавершенной работы в вашем производственном процессе за последние полгода. Наверняка вы найдете некое значение, выше которого WIP не поднимался — это будет ваш натуральный WIP-лимит. За счет чего он возник?
  • Возможно, в какой-то момент времени, ваши сотрудники сказали “Та-а-а-а-к, по моему нам достаточно!” и стали активно сопротивляться поступлению новой работы.
  • Возможно вы сами решили «Та-а-а-а-к, по моему моим достаточно!» и стали сопротивляться поступающей в производственную систему работе.
  • Возможно ваш заказчик сказал «Та-а-а-а-к, по моему этим достаточно» и перестал запихивать новую работу.
  • И наконец, у заказчика, могут просто закончиться идеи того, что за работу ему для вас принести.
2. Начните с того, что есть сейчас. Проще всего начать использовать WIP-лимит просто фиксируя, сколько сейчас в производственной системе находится работы и договориться не брать больше. Помните, что это всего лишь первая установка WIP-лимита и к ней придется еще адаптироваться, мы не пытаемся установить лимит раз и навсегда.
3. Вам не всегда нужен маленький WIP-лимит. Да, небольшое значение WIP-лимита позволяет и стимулировать команду к взаимодействию и хорошо сокращает время производства, но это вам нужно не всегда. Порой у вас есть специализированные люди, которые могут взять и сделать не всякую задачу и для того, чтобы их загрузить работой, надо иметь в системе несколько рабочих элементов, среди которых исполнитель может выбрать, с какой задачей он справится лучше всего. Также, вы можете захотеть развить своих сотрудников и сделать так, чтобы старшие специалисты обучали и растили младших специалистов. Для этого старшим специалистам порой надо в паре с младшими сделать какую-то работу, показать “мастер-класс” и поддержать младшего специалиста в его инициативах. В такой ситуации бывает полезно держать в производственной системе несколько рабочих элементов, среди которых старший специалист может выбрать, на каком рабочем элементе он обучит младшего.
4. Обсуждайте значения WIP-лимита с командой. Вы не можете просто нарисовать цифру над колонкой на доске, чтобы WIP-лимиты начали работать правильно и ими начали пользоваться, необходимо вначале с командой договориться о наличии такой практики и только потом зафиксировать договоренность в виде отображения лимита на доске.

Какие способы ограничения незавершенной работы существуют

Ограничения могут устанавливаться на разные сущности и это будет приносить различный эффект:
  • Персональный WIP-лимит. Это самый простой вариант ограничения количества незавершенной работы. Мы просто договариваемся с исполнителями о том, сколько рабочих элементов каждый из них может взять себе в работу. Такая практика защитит специалистов от выгорания, но не сделаем работу предсказуемой, не сделает производственную систему вытягивающей и слабо повлияет на метрики.
  • WIP-лимит на производственную систему целиком. Такой вид ограничения называют ConWIP. Такой лимит защитит производственную систем от «произвола заказчика», но не защитит от «произвола исполнителей». Количество работы в системе будет ограничено и это безусловно благотворно скажется на предсказуемости и метриках, но внутри производственной системы может царить бардак с неравномерным прохождением через нее работы, что не даст реализовать потенциал WIP- лимитов должным образом.
  • WIP-лимит на активности. Другими словами — это WIP-лимит на этапы работ. При этом, польза достигается именно тогда, когда WIP-лимит установлен на все этапы работ, а не на какой-то один или два, чтобы это не провоцировало накопление работы в системе в определенных этапах, что негативно скажется на показателях производственной системы. Такой способ установки WIP-лимитов считается наиболее правильным и именно он делает производственную систему вытягивающей.
  • WIP-лимит на тип работ и/или класс обслуживания. Это скорее вариант распределения производственной мощности между типами работ и классами обслуживания. Например: в системе находится 10 рабочих элементов. Из них 5 — это запросы на расширение функциональности продукта, 3 — это дефекты и 2 — это задачи технического долга. Такая практика позволит вам распределять усилия специалистов в по разным типам работ. С классами обслуживания можно сделать все ровно то же самое.
  • Ограничивающие на входной буфер. Ограничение может быть установлено на входной буфер, что будет защитой от непомерного аппетита заказчика. Такое ограничение не сделает наш процесс вытягивающим и может никак не повлиять на предсказуемость системы, но вся непредсказуемость системы будет теперь зависеть только от действий команды, а не от поведения заказчика.

Как понять, что WIP-лимит следует поменять

На необходимость изменения значений WIP-лимита может указывать ряд признаков:
  • На статусном собрании вы идете по рабочим элементам в производственной системы и планируете действия сотрудников, которые следует завершить до следующего собрания и вполне может сложиться ситуация, когда задач еще много, а вот люди закончились (у них уже есть работа до следующего собрания). Такая ситуация является прямым намеком на то, что количество работы в производственной системе надо снизить.
  • На статусном собрании вы идете по рабочим элементам в производственной системы и планируете действия сотрудников, которые следует завершить до следующего собрания и вполне может сложиться ситуация, когда задачи кончились, а незанятые люди остались. Это является сигналом к тому, что нам нужно либо стимулировать совместную работу, либо увеличивать значение WIP-лимита.
  • Если требуется сократить время производства, то самым верным способом будет снизить WIP-лимит, но при таком действии вы снизите ресурсную эффективность (что может не понравиться топ-менеджменту) и можете хорошенько снизить пропускную способность. Помните об этом.
Дополнительным напутствием будет еще то, что WIP-лимит нельзя менять часто, вы должны ощутить эффект от изменения и только потом корректировать свое решение.

Когда WIP-лимиты не нужны

Нужна ли практика WIP-лимитов всегда и является ли она обязательной для каждого? Конечно нет! Если текущий производственный процесс и его результаты устраивают заказчика — не стоит ничего менять. Возможно мне возразят: “Но можно же сделать лучше!”. И ответ мой не будет в духе “Лучшее — враг хорошего!”.
Просто при внедрении какой-либо практики без потребности вы точно получите сопротивление людей изменению их привычного уклада жизни и никакими логическими объяснениями преимуществ WIP-лимитов вы не заставите сотрудников ими пользоваться. Они всегда будут их нарушать.
Если вам необходима оптимизация рабочих процессов, использование WIP-лимитов или других управленческих инструментов — обратитесь в Neogenda. Мы реализовали более 100 управленческих кейсов в крупнейших компаниях, таких как Tinkoff, Яндекс, Авито, Сбер, Билайн, Skyeng и так далее. Оставьте заявку на бесплатную консультацию в Zoom, и мы предложим решение для вашего бизнеса.
]]> Управление бэклогом продукта: методы, инструменты и советы http://neogenda.ru/blog/5b25eeac41-upravlenie-beklogom-produkta-metodi-inst http://neogenda.ru/blog/5b25eeac41-upravlenie-beklogom-produkta-metodi-inst?amp=true Mon, 22 Jul 2024 13:10:00 +0300 Дмитрий Кустов Узнайте, что такое product backlog и почему его ведение важно для успешной разработки продуктов. Изучите...

Управление бэклогом продукта: методы, инструменты и советы

Узнайте, что такое product backlog и почему его ведение важно для успешной разработки продуктов. Изучите ключевые концепции, методы и инструменты для эффективного управления бэклогом продукта. Получите советы по оптимизации процесса планирования и приоритизации задач.

Что такое бэклог продукта

Бэклог продукта — это приоритезированный список задач, требований и функций, которые необходимы для улучшения продукта. Этот список является основным артефактом для планирования и управления развитием продукта.
Концепция бэклога появилась вместе с развитием гибких методологий управления проектами, особенно с распространением Agile и Scrum в 1990-х годах. Сам термин «бэклог» происходит от английского слова backlog, что означает «незавершенные дела» или «запасы». Scrum, самый популярный Agile фреймворк, впервые ввел понятие бэклога продукта, чтобы помочь командам лучше управлять приоритетами и объемом работы.
Может показаться, что бэклог продукта — это просто список дел, так называемый “to-do list”. Но на деле не совсем так. Представьте, что бэклог — это вишлист (wishlist). Так, рассматривая бэклог как список желаний, мы создаем пространство для гибкости и изменений в разработке продукта.
Это артефакт для принятия решений, который помогает оценивать, уточнять и расставлять приоритеты для всех задач, которые могут потребоваться в будущем.

Бэклог в проектном управлении

Хорошие практики имеют тенденцию переходить из одной сферы в другую. Так артефакт из Scrum нашел своё место в управлении проектами. Вот несколько ключевых причин, почему это важно:
1. Приоритизация задач.
Бэклог помогает команде сфокусироваться на самых важных и ценных задачах, обеспечивая выполнение первоочередных требований и исправление критических ошибок.
2. Гибкость и адаптация.
Рынок постоянно меняется, пожелания и мнение клиентов тоже. Постоянное обновление и уточнение бэклога позволяет быстро реагировать на эти изменения. Это позволяет сохранять гибкость и адаптироваться к новым обстоятельствам.
3. Прозрачность и общение.
Бэклог обеспечивает прозрачность процесса разработки для всех участников проекта. Он служит инструментом коммуникации между заказчиками, командой разработчиков и другими заинтересованными сторонами.
4. Эффективное планирование.
Бэклог облегчает планирование спринтов и релизов, предоставляя четкую картину объема работ и необходимых ресурсов. Это позволяет более точно оценивать сроки и распределять задачи.
5. Улучшение качества продукта.
Постоянное внимание к бэклогу и регулярное его обновление способствует улучшению качества продукта. Команда может быстро выявлять и устранять проблемы, что приводит к созданию более надежного и функционального продукта.

Основные концепции

Бэклог продукта vs. бэклог спринта
В сфере управления продуктом часто путают эти два понятия. Схематично можно объяснить так: бэклог спринта вытекает из бэклога продукта, то есть из множества основных задач отбираются задачи в спринт.
Бэклог продукта (product backlog) — это всеобъемлющий и постоянно обновляемый список всех задач и требований, необходимых для улучшения продукта.
Бэклогом продукта управляет Владелец продукта (Product Owner) и определяет приоритеты задач на основе их ценности для бизнеса, клиентов и запросов заинтересованных сторон.
Фундаментом для бэклога продукта как правило выступают видение продукта, стратегия бизнеса, дорожная карта. В проектном управлении фундаментом для бэклога выступает дорожная карта и цели проекта. Элементами бэклога продукта являются пользовательские истории, исправления ошибок, улучшения функционала и другие. Они описаны в основном простым языком, обобщенно и без технических подробностей.
Есть два важных критерия ведения бэклога продукта:
🔺Первый критерий хорошего бэклога — наиболее приоритетные элементы являются прозрачными и понятными для команды разработки, то есть команда четко понимает, какой результат ожидается получить в результате работы.
🔺Второй критерий хорошего бэклога — наиболее приоритетные элементы бэклога достаточно компактны, чтобы быть выполненными за спринт.
Если оба эти критерия не выполняются для самых приоритетных элементов бэклога, то проводится встреча по уточнению бэклога, где элементы бэклога дополняются информацией, разбиваются на более мелкие элементы.
Бэклог спринта (sprint backlog) — это элементы бэклога продукта, которые были выбраны для выполнения командой разработки в спринте. Наполнение бэклога спринта происходит на Планировании спринта, если вы используете Scrum. В отличие от бэклога продукта, элементы бэклога спринта дополняются техническими подробностями выполнения работы. Если команда работает по фреймворку Scrum, то бэклог спринта наполняется целью на спринт.

Создание и ведение бэклогов

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

Элементы бэклога

Элемент бэклога — расставленная по приоритету работа, действия или результат который необходимо получить. Как правило, бэклог продукта содержит четыре категории элементов:
  • Пользовательские истории (user stories): описывают функции или требования с точки зрения пользователя.
  • Технические требования: особенности продукта с технической точки зрения и его функциональности.
  • Улучшения: задачи, направленные на улучшение существующего функционала.
  • Дефекты или баги: ошибки и проблемы, которые необходимо исправить.
Пример User Story
Пользовательские истории занимают особое место в бэклоге продукта, ведь продукт в первую очередь создается для использования, поэтому ценность для клиента имеет высокий приоритет.
Рассмотрим простой пример user story. В мобильном приложении для онлайн-покупок нужно добавить функцию «добавление товара в избранное».
Пользователь: «Как пользователь, я хочу отложить этот товар, чтобы вернуться к нему позже».
Пользователь: «Могу ли я просмотреть все мои избранные продукты в одном месте позже?»
Критерии приемки (условия, по которым пользовательская история будет считаться выполненной):
  1. Пользователь может видеть кнопку «Добавить в избранное» на странице каждого продукта.
  2. Нажатие на кнопку добавляет продукт в список избранного пользователя.
  3. Пользователь может просмотреть все избранные продукты в отдельной секции «Избранное».
  4. Пользователь может удалить продукт из списка избранного.
Далее эта пользовательская история добавляется в бэклог продукта и разбивается на технические составляющие в бэклоге спринта.
Единственно верных способов оформления бэклога продукта не существует. Есть хорошие практики, такие как Пользовательские истории, но это не запрещает использовать любые другие способы описания элементов бэклога.

Как составить бэклог продукта

  1. Для начала определите цели и видение продукта.
  2. Далее определите ключевые вехи (дорожная карта) реализации целей и видения продукта.
  3. На основе Product Roadmap соберите все возможные требования, функции, идеи и ожидания от клиентов, заказчиков и заинтересованных сторон.
  4. Оцените важность, срочность, реализуемость и приоритет выполнения требований в рамках целей и видения продукта.
  5. Декомпозируйте и оценивайте наиболее приоритетные элементы бэклога.
  6. Планируйте спринты.
  7. Регулярно анализируйте, контролируйте и обновляйте бэклог.

Методы управления бэклогом

Владелец продукта управляет бэклогом, использует различные методы для приоритизации задач, чтобы держать фокус команды на самом важном . Есть важные, срочные задачи, а какие-то задачи можно отложить до следующего релиза. Можно использовать различные методы для того, чтобы классифицировать задачи:
  • MoSCoW: разделение на категории Must have (обязательно), Should have (желательно), Could have (возможно), Won’t have (не нужно) для расстановки приоритетов.
  • Kano Model: классификация требований по их влиянию на удовлетворенность пользователя.
  • Weighted Shortest Job First (WSJF): выбор задач по их относительной ценности и затратам.
  • Value vs. Effort: Оценка задач по их ценности и усилиям на реализацию.
  • ICE Scoring: Оценка задач по Impact, Confidence, Effort.

Инструменты для ведения бэклога продукта

Бэклог продукта необходимо где-то вести, чтоб его видели все участники процесса. Это, конечно, может быть и табличка в Excel, но лучше воспользоваться более удобными инструментами и сервисами, представленными сейчас на рынке.
Jira: Мощный инструмент для управления проектами и задачами, позволяющий вести бэклог, планировать спринты и отслеживать прогресс.
Trello: Визуальный подход к управлению задачами с помощью досок, списков и карточек. Простой и интуитивный инструмент для команд любого размера.
Asana: Организация и управление задачами с использованием различных видов представления данных, таких как списки, доски и календари.

Советы по оптимизации

Необходимо поддерживать бэклог в актуальном, организованном и эффективном состоянии.
  1. Регулярно проводите Уточнение бэклога — пересмотр, детализация и удаление устаревших задач, а также обновление приоритетов.
  2. Постоянно собирайте обратную связь от пользователей для корректировки элементов бэклога.
  3. Используйте визуальные инструменты, такие как Kanban-доски, для отслеживания прогресса выполнения задач.
  4. Концентрируйтесь на задачах, которые приносят наибольшую ценность для пользователей и бизнеса.

Заключение

Управление бэклогом продукта играет ключевую роль в успешной разработке продуктов, особенно в контексте гибких подходов. Этот артефакт позволяет командам сфокусироваться на приоритетах, поддерживать гибкость и адаптироваться к изменяющимся условиям рынка.
]]> Фреймворк SCRUM: что это и как его использовать для управления проектами http://neogenda.ru/blog/uoftfyoft1-freimvork-scrum-chto-eto-i-kak-ego-ispol http://neogenda.ru/blog/uoftfyoft1-freimvork-scrum-chto-eto-i-kak-ego-ispol?amp=true Thu, 25 Jul 2024 06:24:00 +0300 Андрей Сидоренко Необходимость быстро создавать продукты готовые к релизу, работа в условиях постоянно изменяющихся требований заказчика и...

Фреймворк SCRUM: что это и как его использовать для управления проектами

Необходимость быстро создавать продукты готовые к релизу, работа в условиях постоянно изменяющихся требований заказчика и внешних факторов — это повод задуматься о внедрении фреймворка SCRUM. Подход помогает команде слаженно работать над решением общих задач, обеспечивает гибкость и предсказуемость процессов в условиях хаоса и неопределенности.
Фреймворк SCRUM — это подход к разработке, который позволяет создавать комплексные продукты и решения при высокой неопределенности рынка и клиентов. Он соответствует ценностям Аджайл, описанным в Agile Manifesto, и опирается на свои принципы:
  • прозрачность (transparency), суть которой во взаимном доверии и открытой коммуникации,
  • инспекция (inspection), которая говорит команде о том, что необходимо постоянно анализировать и оценивать текущее состояние,
  • адаптация (adaptation), смысл которой в корректировках, которые необходимо делать, получая новую информацию на основе данных.
Одни из отличительными особенностей работы по SCRUM:
  • итеративность и постоянный инкремент (наращивание ценности) в разработке;
  • самоорганизация команды;
  • постоянное улучшение процессов;
  • активное вовлечение заинтересованных сторон.
Разработка проекта, согласно подходу, ведется небольшими итерациями, которые называются спринтами. Каждый спринт длится от 1 до 4 недель и завершается релизом работающего инкремента продукта.
Использование фреймворка позволяет управлять проектами более гибко, быстро реагировать на изменения и достигать высоких результатов. Если вам требуется внедрение фреймворка SCRUM для команды — обратитесь в Neogenda. Мы предложим решение для вашего бизнеса на бесплатной консультации в Zoom.
Далее в статье:
  • что такое фреймворк и чем он отличается от методологии;
  • история появления SCRUM;
  • для каких задач подходит SCRUM;
  • преимущества и недостатки;
  • ценности и основные принципы;
  • как внедрить SCRUM;
  • основные сложности внедрения.

Что такое фреймворк и чем он отличается от методологии

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

История появления фреймворка SCRUM

Впервые фреймворк SCRUM был упомянут в 1986 году в статье Harvard Business Review, японскими учеными Хиротако Такеути и Икудзиро Нонаки.
Один из разделов статьи назывался «Moving the Scrum Downfield» и приводил необычную аналогию термина с игрой в регби. В регби термин « SCRUM» обозначает ситуацию, когда игроки обеих команд собираются вместе после приостановки игры, сцепляются между собой, ожидают продолжение игры и очередного вброса мяча. Эта фаза игры, где команды борются за мяч, является отправной точкой развития событий в игре и определяет дальнейший ход событий.
В статье Хиротаки Такеути и Икудзиро Нонаки обсуждались принципы и концепции гибкого управления проектами, основанные на итерационном и коллаборативном подходе. Авторы подчеркивали важность быстрого реагирования на изменения и постоянные улучшения в процессе разработки продуктов.
Именно эти идеи и принципы послужили основой для дальнейшего развития и распространения фреймворка SCRUM в современном мире.
Easel Corporation стала первой компанией, где был внедрен SCRUM. В 1993 году команде из Джеффа Сазерленда, Джона Скамниоталеса и Джеффа МакКенны пришлось разработать программный продукт за рекордные 6 месяцев. Статья Такэути и Нонаки вдохновила Сазерленда применить предложенный подход на срочном проекте. С использованием нового подхода проект был успешно завершен в срок, в рамках бюджета и с минимальным количеством ошибок.
Позднее, в 1995 году, Кен Швабер и Джефф Сазерленд объединились для доработки и описания фреймворка SCRUM в его привычном виде. Они презентовали свой доклад «Процесс разработки Scrum» на конференции OOPSLA и приняли участие в написании Agile-manifesto.
Постепенно SCRUM стал популярным в различных областях, включая разработку ПО, маркетинг, образование и даже здравоохранение. Сегодня SCRUM является одним из наиболее распространенных и успешных фреймворков для управления проектами и продуктами, и применяется многими компаниями во всем мире.

Для каких задач подходит использование SCRUM

Фреймворк SCRUM хорошо подходит для широкого спектра задач не только из сферы IT и разработки, но применять его имеет смысл не в каждой ситуации и команде.
Ниже некоторые особенности, которые стоит учитывать, если вы хотите внедрить Scrum для реализации проекта:
  • Неопределенность. Scrum работает в неопределенной среде. Когда решения неочевидны или вообще являются гипотезами.
  • Комплексность. SCRUM применяется для разработки сложных продуктов, требующих поэтапного подхода. Такие проекты содержат инновационные технологии, большие объемы работы или требуют поиска нестандартных решений.
  • Кросс-функциональость. Для того, чтобы Scrum работал, требуется профессиональная кросс-функциональная команда, способная самостоятельно решать задачи и принимать решения.
  • Инкрементальность в короткие сроки. Это означает, что придется искать решения. при которых проект будет делиться на короткие поставки ценности, которые можно будет уложить в спринты от 1 до 4 недель. Под ценностью подразумевается работоспособность.
  • Петли обратной связи и и адаптация под изменяющиеся условия. Подход предполагает регулярные обзоры и ретроспективы, а также гибкость в изменении приоритетов и бэклога. Нужно быть готовыми к частым итерациям и корректировкам.
  • Постоянное взаимодействие с заказчиком. Проект должен предусматривать постоянное взаимодействие с заказчиком и стейкхолдерами, готовность к оперативным изменениям и корректировке стратегии разработки.
Иными словами, если вы понимаете, что у вас комплексный проект, неопределенная среда и вы готовы, опираясь на принципы Scrum и ценности Agile работать итерациями, искать новые решения и постоянно поставлять ценность, внедрять события, которые позволяют постоянно улучшать свой процесс и постепенно становиться кросс-функциональной командой, то вас ждет успех во внедрении этого фреймворка.

Преимущества и недостатки фреймворка в управлении проектами

К достоинствам использования фреймворка SCRUM для разработки продуктов можно отнести:
  • Гибкость и адаптивность. Фреймворк позволяет командам быстро адаптироваться к изменениям, реагировать на обратную связь и корректировать бэклог в ходе проекта.
  • Прозрачность. В SCRUM четко определены роли, обязанности и процессы, что создает прозрачность в работе команды и повышает ее продуктивность.
  • Возможность быстрого выхода на рынок. Работа спринтами позволяет команде часто выпускать готовые инкременты продукта, что способствует быстрому выходу на рынок и улучшениям продукта в ходе дальнейших итераций.
  • Динамика. Фреймворк задает высокую динамику работы команды за счет коротких циклов разработки и регулярных релизов.
  • Повышение качества продукта. Команда имеет возможность улучшать продукт на протяжении всего процесса разработки за счет постоянного контроля качества и обратной связи.
Среди недостатков можно выделить:
  • Необходимость командной самоорганизации. Фреймворк требует, чтобы команда была самоорганизованной и принимала самостоятельные решения. В случае отсутствия такой способности у команды, подход может не дать желаемых результатов.
  • Сложность внедрения. Для успешного внедрения SCRUM необходимо четкое понимание всех процессов и готовность всех участников к изменениям в работе.
  • Необходимость постоянного взаимодействия с заказчиком. Фреймворк предполагает активное взаимодействие с заказчиком и стейкхолдерами, что иногда оказывается сложным из-за разницы во взглядах и приоритетах.
  • Возможность перегруза команды. Постоянное выполнение итераций без перерывов и ошибки в планировании, могут привести к выгоранию членов команды и снижению уровня мотивации.
  • Отсутствие строгих регламентирующих документов. Фреймворк не предусматривает создания регламентирующих документов на запуске проекта, что может затруднять понимание общей стратегии развития продукта и реализацию проекта.

Ключевые элементы SCRUM

Фреймворк SCRUM — это набор ценностей, ролей, событий и артефактов, которые должны обязательно использоваться для получения максимального эффекта от фреймворка:
  • 5 главных ценностей: приверженность, сфокусированность, открытость, уважение и смелость
  • 3 ключевых роли: владелец продукта, SCRUM-мастер и команда разработчиков;
  • 5 основных событий: спринт, планирование спринта, ежедневный SCRUM, обзор спринта и ретроспектива спринта;
  • 3 важных артефакта: бэклог продукта, инкремент и бэклог спринта.
Далее, мы уделим внимание ролям, событиям и артефактам.

Scrum-команда

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

Владелец продукта (Product Owner)

Владелец продукта (Product Owner) — это член SCRUM-команды, который несет ответственность за максимизацию ценности продукта и его соответствие потребностям заказчика.
Он несет ответственность за:
  • Определение цели продукта. Описание того, каким будет продукт в будущем. Это помогает Scrum-команде планировать свою работу.
  • Составление и управление бэклогом продукта. Список всего, что необходимо сделать для того, чтобы улучшать продукт и достигать цели продукта. Это единственный источник работы для команды.
  • Упорядочивание элементов бэклога продукта. Исходя из цели продукта, наверху бэклога должны быть элементы, которые приносят максимальную ценность. Они должны быть описаны и иметь критерии завершенности.
  • Прозрачность, доступность и понимание бэклога участниками Scrum команды. Все элементы продуктового бэклога должны быть синхронно понятными участникам команды для максимального вовлечения в их реализацию.

Скрам мастер (Scrum Master)

SCRUM-мастер (Scrum Master) — это человек, ответственный за понимание теории и практики Scrum и за его применение в соответствии с руководством.
В его обязанности входит:
  • Коучинг участников команды. Scrum мастер помогает команде становится кросс-функциональной и нацеленной на самоуправление
  • Фокусировка на ценности. Scrum мастер фокусирует команду на том, чтобы выпускаемый инкремент соответствовал критериям готовности и нес ценность.
  • Устранение препятствий. Одной из основных задач SCRUM-мастера является помощь команде в устранении препятствий, которые могут затруднять выполнение работ и достижение целей проекта.
  • Фасилитация событий. SCRUM-мастер организует и ведет SCRUM-события. Он помогает команде эффективно использовать время этих событий.
Если вы хотите узнать больше о том, кто такой SCRUM-мастер, читайте нашу статью: «Кто такой scrum-мастер: объясняем простым языком». В ней мы подробно рассказываем кто это и какие у него функции в команде.

Разработчики (Developers)

Разработчики — это люди, которые нацелены на создание инкремента в каждом спринте, готового к использованию.
Они несут ответственность за:
  • Sprint Backlog. разработчики создают план на Sprint и определяют, какие части Backlog попадут в ближайший спринт.
  • Качество. Разработчики руководствуются критериями готовности и стремятся сделать максимально качественный готовый инкремент.
  • Адаптация. Разработчики ежедневно принимают решения на основании своего плана, как им необходимо меняться для достижения Цели Спринта.
  • Взаимодействие. Разработчик несут друг перед другом ответственность и проявляются профессионализм друг перед другом.

SCRUM события

Во фреймворке SCRUM существует 5 видов регулярных событий.
Схема событий при работе над проектом по фреймворку SCRUM
Рассмотрим подробнее каждое из них.
  1. Спринт (Sprint). Событие с фиксированной продолжительностью от 1 до 4 недель, в течение которого команда работает над созданием рабочего инкремента продукта. Спринт создает условия для предсказуемость, а короткие отрезки создают динамику, которая способствует проявлению инспекции процесса и адаптации новых решений.
  2. Планирование спринта (Sprint Planning). Событие, на котором Scrum-команда планирует, что будет взято в работу в будущем спринте. На этом событии обсуждаются наиболее важные элементы Продуктового бэклога, поэтому команда может звать на помощь людей, которые не находятся в Scrum-команде.
  3. Ежедневный Scrum (Daily Scrum). Ежедневная инспекция прогресс по достижению цели спринта. Обычно около 15 минут, в течение которых разработчики обсуждают и корректируют работу над элементами цели спринта.
  4. Обзор спринта (Sprint Review). Рабочее событие, в течение которого Scrum команда демонстрирует результаты по спринту заинтересованным лицам и выявляются необходимые корректировки в дальнейше работе над продуктом, и непосредственно в бэклог продукта.
  5. Ретроспектива спринта (Sprint Retrospective). Событие, на котором команда инспектирует прошедший спринт и находит наиболее полезные для улучшения и повышения эффективности и конкретные решения, которые могут этому способствовать, после чего такие решения добавляются в следующий спринт.

Артефакты

Артефакты в SCRUM — это помогают поддерживать прозрачность и сфокусированность в обмене ключевой информацией, а так же подкреплять ценности Scrum
В SCRUM есть три артефакта:
  1. Бэклог продукта (Product Backlog) — это упорядоченный и обновляемый список всего, что необходимо для улучшения продукта. Создается и поддерживается владельцем продукта, дорабатывается в ходе работы над проектом.
  2. Бэклог спринта (Sprint Backlog) — это план работ, который создают разработчики для работы над будущим спринтом. Такой план составляется исходя из Цели спринта и может меняться по ходу спринта в зависимости от получения новых знаний.
  3. Инкремент (Increment) — это конкретное улучшение в продукт, которое появляется в течение спринта и является частью продуктовой цели. Инкремент должен соответствовать критериям готовности и является дополняющем продукт ко всем предыдущим инкрементам. За спринт может быть выпущено несколько инкрементов.

Как внедрить SCRUM в управление проектами

Чтобы успешнее внедрить Scrum, мы рекомендуем учесть следующие шаги:.
1. Определите. что Scrum действительно вам подходит. Поймите, к какой области определенности относится ваш проект. Действительно ли будет разумно использовать итеративно-инкрементальную разработку.
2. Поймите, что есть спонсор. Как правило, это лидер, который поддерживает такие важные изменения в процесс разработки. Если такового лидера не найдется, внедрение может провалиться.
3. Проведите обучение будущей команды. Организуйте обучающий тренинг по SCRUM для всех участников команды, сформируйте общее понимание работы по фреймворку для всех членов команды.
4. Определитесь с ролями. Кто будет Product Owner и отвечать за максимизацию ценности продукта и выбор целей продукта. Кто будет Scrum мастером.
5. Соберите разработчиков. Определите компетенции ,которые будут вам нужны для следования цели продукта. Соберите людей, которые готовы разделять ценности и принципы Scrum.
6. Соберите бэклог продукта. Вместе с владельцем продукта составьте список требований, задач и целей проекта, который будет отражен в бэклоге.
7. Проведите планирование первого спринта. На планировочном митинге выберите задачи из бэклога продукта для реализации первого спринта и определите объем работы.
8. Проводите ежедневные Daily Scrum. Установите время для ежедневных коротких встреч для обсуждения прогресса, проблем и планов на день.
9. Отслеживайте работу в рамках спринта. Следите как команда выполняет задачи в соответствии с планом спринта, мониторьте прогресс.
10. Проведите демонстрацию результатов на ретроспективе. По окончании спринта проведите демонстрацию инкремента заинтересованным лицам. Обсудите изменения, которые необходимо внести в продукт и бэклог.
11. Проведите ретроспективу по итогам спринта. Определите ключевые вопросы, требующие инспекции. Процессы, взаимодействия, культура, технические аспекты и т.д.. Договоритесь о внедрении улучшений в будущий спринт.
12. Поощряйте команду за самоорганизацию и автономность. Стремитесь к тому, чтобы члены команды самостоятельно принимали решения, организовывали свою работу и решали возникающие проблемы совместными усилиями.
13. Поддерживайте высокий уровень коммуникаций и собирайте обратную связь. Обеспечивайте команду всей необходимой информацией, проводите обучающие мероприятия, предоставляйте обратную связь для постоянного развития.

Основные сложности внедрения SCRUM

Внедрение SCRUM требует значительных изменений в рабочем процессе, культуре команды и взаимодействии с заказчиком. Участники команды не всегда готовы к таким изменениям и при внедрении может возникнуть ряд сложностей:
  • Непонимание ценностей и принципов SCRUM. Одной из основных проблем при внедрении может быть недостаточное понимание ценностей и принципов фреймворка. Если команда не осознает важность слаженной командной работы, итеративного процесса разработки, самоорганизации и постоянного совершенствования, то внедрение SCRUM может не принести желаемого результата.
  • Слишком длинные или короткие спринты. Слишком длинные спринты могут привести к задержкам в доставке продукта, а слишком короткие – к перегрузке команды и снижению продуктивности. Поиск баланса в определении длительности спринтов требует опыта и понимания специфики проекта.
  • Постоянная адаптация к изменяющимся требованиям. SCRUM предполагает гибкость и адаптивность к изменениям, однако постоянное изменение требований и влияние внешних условий может вызвать проблемы. Команда должна быть готова реагировать на изменения, оперативно пересматривать приоритеты и вносить коррективы в работу – это требует организационной гибкости и четкости в коммуникациях.
  • Проблемы планирования. Планирование в SCRUM играет важную роль, но может стать сложным из-за неопределенности требований, сложности в оценке задач, неопытности команды или недостаточного понимания объема работ. Недостаточно обдуманное планирование может привести к задержкам или недооценке сроков выполнения задач.
Если вам требуется внедрение фреймворка SCRUM — обратитесь в Neogenda. Мы помогли решить проблемы бизнеса и управления крупнейшим компаниям, среди которых Тинькоff, Сбер, Авито, Азбука Вкуса, Газпромбанк и другие. Оставьте заявку и мы предложим решение на консультации в Zoom.
]]> Диаграмма сгорания (Burndown Chart): как управлять ходом разработки http://neogenda.ru/blog/pllsd9edh1-diagramma-sgoraniya-burndown-chart-kak-u http://neogenda.ru/blog/pllsd9edh1-diagramma-sgoraniya-burndown-chart-kak-u?amp=true Fri, 26 Jul 2024 06:27:00 +0300 Андрей Сидоренко У плохой команды горят сроки и сотрудники, а у хорошей – сгорают задачи. Чтобы увидеть...

Диаграмма сгорания (Burndown Chart): как управлять ходом разработки

У плохой команды горят сроки и сотрудники, а у хорошей – сгорают задачи. Чтобы увидеть такое своими глазами, достаточно хоть один раз взглянуть на диаграмму сгорания задач (burndown chart).
Диаграмма сгорания задач – это график, на котором отображена динамика выполнения задач по мере движения к концу спринта в Scrum. Для Scrum не подойдет какая-нибудь диаграмма Ганта или любой другой инструмент для визуализации проектных работ, ход которых можно точно спрогнозировать. Но в целом диаграмму сгорания можно использовать где угодно – не только в Scrum.
Ведение и анализ диаграммы сгорания дает понять, не опаздывает ли команда к завершению спринта. А скрам-мастер может заметить еще кое-что интересное, взглянув на график, но обо всем по порядку.
Примерно так выглядит диаграмма сгорания задач
Далее в статье:
  • что такое диаграмма сгорания задач и как она устроена;
  • какие у нее преимущества и недостатки;
  • как верно интерпретировать данные диаграммы сгорания задач – покажем на типичных примерах;
  • как правильно составить и вести диаграмму сгорания задач;
  • бонус: чем диаграмма сгорания отличается от диаграммы burnup (а это что?).
Если вашему бизнесу необходимо внедрение современных управленческих практик – обратитесь за бесплатной консультацией в Neogenda. На нашем счету работа с такими компаниями как Тинькофф, Сбер, Яндекс, Точка, X5 Group и так далее. Мы оказываем более 100 различных услуг – от обучения вашего персонала до реорганизации вашего бизнеса.

Что такое диаграмма сгорания задач и как она устроена

Диаграмма сгорания – это простой график с двумя осями, где ось X – это дни, выделенные на спринт или проект, а ось Y – это количество задач, выраженное в численной метрике. На оси Y чаще всего отражают стори-поинты – очки, которыми оценивают трудоемкость задач в Scrum.
Та же самая диаграмма, только с пояснениями
Кроме осей графика на диаграмме отображаются две линии:
  • Планируемый ход работ. Это ровная диагональная линия, которая тянется от верхнего левого угла к правому нижнему. Она отражает идеальный ход работ над проектом: как если бы команда изо дня в день выполняла задачи с равномерной скоростью, пропорционально их общему количеству. Например, команде нужно выполнить 20 задач за 10 дней: если она будет выполнять по 2 задачи в день, ее ход работ отразится на графике такой же ровной диагональной линией.
  • Фактический ход работ. Это линия, которая отражает как в действительности меняется количество оставшейся работы. Например, в начале рабочего дня, 2 мая 2024 года, у команды было задач на 20 стори-поинтов: на оси X это будет значение «02.05.2024», а на оси Y – 20 (стори-поинтов). За день команда выполнила задач на три стори-поинта – значит, 3 мая 2024 года значение на оси X будет «03.05.2024», а на оси Y – 17. Так, с каждым днем, на диаграмме постепенно вырисовывается линия фактического хода работ.
Так будет выглядеть диаграмма сгорания в самом разгаре работ – линия фактических работ еще не завершена
Выходит, что если линия фактического хода работ выше, чем запланированного хода работ – команда отстает от графика. И наоборот, если линия «факта» ниже – команда опережает график.
Далее расскажем, почему Scrum-команды активно используют диаграмму сгорания задач, но не забудем и о ее недостатках.
Читайте также: Роли в SCRUM: какие они и как их выполнять эффективно

Преимущества и недостатки использования диаграммы сгорания задач

Начнем с хорошего:
  • Диаграмма обеспечивает наглядное представление хода спринта.
С ней можно за секунду оценить обстановку: сразу видно, сколько работ сделано, сколько осталось и успевает ли команда к дедлайну. Диаграмма понятнее, нежели беклог спринта со списком задач, по которым сходу и не скажешь, насколько они трудоемкие.
Благодаря этому, команда может быстро отреагировать на ситуацию: например, подумать, что можно предпринять, чтобы успеть в срок.
А теперь о плохом:
  • Диаграмма не учитывает неправильную оценку трудоемкости работ.
Неопытная команда может неверно рассчитать силы, взяв в спринт больше работы, чем она может выполнить. Из-за этого будет складываться впечатление, что она опаздывает, хотя фактически ее участники просто плохо рассчитали свои силы.
  • Диаграмма не учитывает качество выполненной работы.
Если команда завершила задачу, но сделала это плохо, график все равно покажет прогресс.
Разберем, как правильно использовать диаграмму.

Как работать с диаграммой сгорания задач

1. Сформируйте бэклог спринта.
Беклог спринта – это список задач, которые команда планирует выполнить в его рамках. В первую очередь нужно собрать эти задачи.
2. Оцените трудоемкость задач.
В зависимости от методологии или фреймворка, с которым будет работать ваша команда, задачи могут оцениваться разными метриками: например, трудочасами. В Scrum чаще всего используют стори-поинты, которыми команда оценивает задачи в рамках «покера планирования» (Planning Poker).
Такой «покер» – это мероприятие, при котором все участники команды коллегиально присваивают каждой задаче ту или иную оценку сложности. Обычно для оценки сложности задач используют числа Фибоначчи: 1, 2, 3, 5, 8, 13 и так далее. Если команда опытная и сработанная, оценки ее участников будут совпадать и будут объективно оценивать сложность задачи.
3. Анализируйте диаграмму.
Нет смысла фиксировать ход работ, если его не анализировать. За диаграммой сгорания нужно следить каждый день, чтобы суметь своевременно внести коррективы в ход работ.
4. Адаптируйтесь в ходе спринта.
Исходя из анализа, команда должна предпринимать меры, если работы идут не по плану. Например, добавить еще больше задач в спринт, если «факт» опережает «план». Или придумать, как оптимизировать рабочий процесс, если команда опаздывает.
5. Проведите ретроспективу спринта.
Ретроспектива спринта – одно из обязательных событий в Scrum. На нем команда должна проанализировать завершенные работы, чтобы понять, как лучше выполнить следующий спринт. Например, в ходе ретроспективы команда может понять, что посчитала какие-то задачи более легкими, отчего не успела в срок.
А теперь рассмотрим наглядные примеры диаграмм сгорания, которые могут натолкнуть вас на инсайты.

Как верно интерпретировать данные диаграммы: продвинутый уровень

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

Пример № 1: «Факап дедлайна»

Чуточку не дожали
Банальная ситуация: команда не успела выполнить все задачи в срок. В этом случае, задача проектного менеджера или скрам-мастера разобраться, почему так. И придумать, что сделать, чтобы это не повторялось.

Пример № 2: «Подозрительно быстро»

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

Пример № 3: «На чилле, на расслабоне»

На такой диаграмме линия «факта» похожа на гамак, что как бы намекает
Такой график символизирует, что команда «спалилась» – сначала выполняла задачи слишком быстро, потом одумалась и сбавила темп. В этом случае с ее участниками нужно пообщаться, чтобы договориться о честной работе.
Но не спешите звать команду «на ковер»: вероятно, она быстро закрыла легкие задачи, а потом застряла на сложных.
Еще кажущееся снижение темпа работы может быть вызвано неверной оценкой трудозатрат по некоторым из задач. Например, задачу оценили в 5 стори-поинтов, хотя фактически она тянула на все 8. Пара таких задач может заметно исказить график.

Пример № 4: «Смена стиля»

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

Пример № 5: «Команда “А”»

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

Пример № 6 (наш любимый): «Какая диаграмма?»

Что?
Если какие-то работы выполнялись, но их ход не был отражен в диаграмме – поздравляю, ее никто не вел. Вообще, в действительности такая ситуация уже почти невозможна – современные таск-менеджеры автоматически фиксируют изменения в диаграмме сгорания. А вот раньше такое могло встретиться.
Что ж, с примерами закончили. Напоследок расскажем о диаграмме burnup – что это и чем она отличается от диаграммы сгорания.

Чем диаграмма сгорания отличается от диаграммы burnup

Если просто, диаграмма burnup – это как диаграмма сгорания, только наоборот. Она показывает, как объем выполненной работы увеличивается с течением времени. Ось Y представляет объем работы (выполненной и оставшейся), а ось X – время. Диаграмма burnup также имеет две линии: одну для «плана» и другую для «факта».
Так выглядит диаграмма burnup, на которой виден не только ход работы над спринтом, но и изменения в беклоге спринта
А зачем нужна диаграмма burnup, если есть диаграмма сгорания? В диаграмме сгорания изменения в объеме работы не отражаются напрямую. Там, если в спринт добавляются новые задачи, линия «факта» может перестать падать или даже начать расти – можно подумать, что команда работает плохо. А в burnup сразу видно изменение в количестве задач.
Поэтому обе диаграммы могут эффективно дополнять друг друга. Диаграмма сгорания дает четкое представление о текущем состоянии и оставшейся работе, а диаграмма burnup – о прогрессе и изменениях в общем объеме работы. Лучше всего использовать обе диаграммы, чтобы оценивать динамику работ и принимать более информированные решения.

Резюмируем

  1. Диаграмма сгорания помогает следить за прогрессом спринта. Она показывает, сколько работы осталось и как успешно идет выполнение задач.
  2. Она позволяет анализировать отклонения, чтобы оперативно вносить коррективы в ход работ. Если что-то идет не так, всегда можно выяснить причины и исправить ситуацию.
  3. Диаграмма сгорания не показывает полную картину происходящего. Важно правильно оценивать трудоемкость работ и следить за качеством их выполнения – эти данные вы не увидите в диаграмме.
  4. Для более точной оценки происходящего дополнительно стоит использовать диаграмму burnup. На ней видно изменения в количестве работ, а на диаграмме сгорания – нет.
Учитывайте предыдущий опыт и обсуждайте трудозатраты с командой – так вы сможете эффективнее оценивать их с каждым новым спринтом. И обращайтесь в Neogenda за бесплатной консультацией, если вам необходима экспертная помощь во внедрении современных управленческих практик.
]]> Матрица Пью или матрица принятия решений: как выбирать лучшее из неочевидного http://neogenda.ru/blog/drivtgxd41-matritsa-pyu-ili-matritsa-prinyatiya-res http://neogenda.ru/blog/drivtgxd41-matritsa-pyu-ili-matritsa-prinyatiya-res?amp=true Tue, 30 Jul 2024 07:39:00 +0300 Андрей Сидоренко Успех компании выстраивается постепенно из череды принятия правильных решений. Порой ставки так высоки, что ваш...

Матрица Пью или матрица принятия решений: как выбирать лучшее из неочевидного

Успех компании выстраивается постепенно из череды принятия правильных решений. Порой ставки так высоки, что ваш выбор может стать как причиной кратного роста, так и краха всего дела. К примеру, мой знакомый нашел недобросовестного партнера и из-за его действий лишился строительной фирмы и небольшой сети аптек. Порой сложно принимать взвешенные решения из головы – тут на помощь приходят специальные инструменты, такие как матрица вариантов.
Матрица Пью, она же матрица вариантов или матрица принятия решений. Это таблица, которая позволяет сравнить несколько вариантов по ряду критериев, чтобы выбрать лучший из них. Она названа в честь своего создателя – британского инженера Стюарта Пью.
Простой пример матрицы Пью – разные варианты оцениваются по однородным критериям, благодаря чему можно выбрать лучший из них по итоговой оценке
Далее в статье:
  • когда подойдет использование матрицы Пью;
  • как пользоваться матрицей критериев;
  • когда и как использовать другие матрицы для принятия решений: матрицу Эйзенхауэра и матрицу RACI.
Если вам необходимо внедрение современных управленческих практик, обратитесь в Neogenda. За нами более 100 успешных управленческих кейсов и 5 000 обученных сотрудников в таких компаниях как Tinkoff, Яндекс, Авито, Сбер, Билайн, Skyeng и так далее. Оставьте заявку на бесплатную консультацию в Zoom, и мы предложим индивидуальное решение, с которым ваша команда достигнет лучших результатов.

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

Матрица Пью – инструмент с широкой областью применения. С ее помощью можно выбрать самые важные проекты, найти подходящего подрядчика или партнера. Да хоть вторую половинку, если вы пользуетесь популярностью среди противоположного пола и все не можете определиться, кто же станет вашим спутником по жизни. Но использование матрицы не всегда подойдет под вашу ситуацию.
Нужно убедиться, что вы можете подравнять все варианты под одну гребенку, чтобы сравнить их между собой. Например, сравнить нескольких подрядчиков просто – критерии оценки напросятся сами. Это будет стоимость работы, наличие подходящих успешных кейсов, качество общения с подрядчиком и так далее.
Порой вам может показаться, что ваши варианты выбора неоднородны – убедитесь в этом. Например, как определиться, во что лучше вложить средства: в вывод на рынок нового продукта или продвижение текущего? В этом случае нужно попробовать привести варианты к единому виду, исходя из ключевой цели или метрики, на которую они рассчитаны.
Например, и вывод нового продукта, и продвижение старого нацелены на рост продаж, верно? А можете ли вы смоделировать оба варианта развития событий, чтобы выяснить, какой из них будет более выгодным? Скажем, оба варианта можно сравнить по ожидаемому уровню доходности, требуемым вложениям и времени, необходимому для достижения финансовой SMART-цели. После того, как оба варианта будут приведены к единому виду для сравнения, можно использовать матрицу Пью.
А вот контрпример: вы пытаетесь определиться, начать ли свое дело или продолжить работать в текущей компании.
В этом случае решение будет зависеть от множества факторов: скажем, личных целей, желаемого стиля жизни, вашего финансового положения, устойчивости к риску и так далее. Такие критерии не всегда получится объективно оценить с помощью матрицы Пью хотя бы потому, что у вас нет достаточного личного опыта. Такое решение потребует глубокого самоанализа, консультации с экспертами, а также учета личных предпочтений и обстоятельств. Без этого вы не сможете дать объективную оценку критериям, на основе которых будете делать выбор. Или сможете?
Сложнее выбора мир еще не видывал
В общем, матрицу Пью стоит использовать тогда, когда вы можете выявить все важные критерии для сравнения нескольких вариантов между собой и дать этим критериям объективную оценку. Тогда она вам поможет, а не навредит.
А теперь расскажу, как правильно пользоваться матрицей принятия решений.
Читайте также: Дорожная карта проекта: как сделать + примеры

Как пользоваться матрицей критериев

1 этап. Определите варианты выбора

Итак, вы пришли к выводу, что вам нужно достичь какую-то цель за счет принятия того или иного решения – вы уже на полпути от нахождения лучшего варианта. Осталось убедиться, что все варианты выбора однородные: то есть направлены на эффективное достижение поставленной цели.
Например, если вашей целью является увеличение узнаваемости бренда, ведение соцсетей и реклама на ТВ – открытие новых точек магазина вам не подходит.. Менее подходящие варианты исключаются просто: интуитивно отсекаются бритвой Оккама. Также можно использовать SWOT-анализ.
Читатель, когда в статье про матрицу Пью предложили использовать SWOT-анализ
Или еще пример: вы решили взять в команду разработчика, но риски велики – сильно жмут сроки. Наймете не того – потеряете кучу ресурсов и времени, а работа будет простаивать. Логичнее всего будет поискать специалиста среди «своих» – поспрашивать у знакомых, тех, кто состоит в комьюнити.
Едем далее.

2 этап. Выявите критерии для оценки вариантов

Чтобы было понятнее, давайте этот и последующие этапы разберем на примере.
Представим, что наша цель – сравнить нескольких кандидатов на должность разработчика в продуктовую команду. Какие критерии мы можем выделить для их сравнения?
Нам на ум пришло несколько:
  • данные о квалификации кандидата из рекомендаций, тестовой и обратной связи коллег;
  • стоимость трудочаса;
  • пунктуальность;
  • «экологичность» общения;
  • навыки коммуникации – умение излагать мысли в деловой переписке.
Вот таких кандидатов подобрало рекрутинговое агентство
В зависимости от ситуации список критериев может быть шире или вообще другим. Например, если разработчик устраивается в веб-студию, ему могут понадобиться знания разных языков программирования и фреймворков – это нужно учесть. В скрам-команде могут быть необходимы смежные навыки: например, тестировщика или дизайнера. В общем, поиск и нахождение всех важных критериев – ваша задача и ответственность, от которой будет зависеть эффективность анализа.

3 этап. Задайте веса для уравновешивания отдельных критериев

Не все критерии матрицы выбора решений будут однозначными, поэтому к каждому из критериев нужно добавить свой вес. Если вы не учились на экономиста, вес – это коэффициент, присущий тому или иному критерию. Например, если критерий A в полтора раза важнее, нежели критерий B, то оценку критерия A нужно умножать на 1,5, чтобы итоговые оценки были более объективными.
Давайте порассуждаем, какие веса могут быть у критериев в нашей матрице принятия решений:
  • Квалификация. Работа над продуктом непростая: у него много легаси-кода, часть которого тяжело прочесть. Документации по коду тоже не хватает: чтобы понять какие-то фрагменты, нужно лезть и разбираться. Поэтому от разработчика требуется высокая квалификация: чтобы работать над проектом, он должен в совершенстве разбираться в архитектуре сложных приложений, а еще знать язык программирования и фреймворк продукта. Поэтому вес критерия «квалификация» будет 2.
  • Стоимость трудочаса. Несмотря на важность опыта разработчика, нужно, чтобы он влез в месячный бюджет продуктовой команды – его окупаемость итак висит на волоске, а инвесторы морщатся, когда им предлагают провести A/B-тестирование какой-нибудь перспективной фичи. Поэтому вес у данного критерия будет 1,5.
  • Пунктуальность. Да будь наш разработчик хоть Тэнком из первой «Матрицы», который умел видеть Матрицу глядя на код – какой в этом смысл, если он будет вечно опаздывать? От опозданий одного сотрудника может зависеть вся команда, а от нее – бизнес. Так что вес критерия «Пунктуальность» – 1,7.
  • «Экологичность» общения. Продуктовая команда работает давно: все друг с другом на одной волне, каждый понимает другого с полуслова. Скрам-мастера знают, что замена одного участника – это уже другая скрам-команда. В команде никто не оскорбляет друг друга, а если кто-то на кем-то и подшучивает, то максимально беззлобно. Появление «токсика» в команде, даже если он крутой спец, может испортить эмоциональный фон и снизить продуктивность других участников команды. Из-за этого вес критерия «экологичность» будет 1,5.
  • Деловая переписка. Умение излагать мысли тоже важно: если новый разработчик не сможет доходчиво ими делиться, команда будет тратить лишнее время на то, чтобы понять что он хочет. Но важность этого критерия не такая большая, если сравнивать ее с другими. Поэтому у данного критерия веса не будет.
Выходит, что формула расчета оценки варианта будет выглядеть примерно так:
Итоговая оценка = (Квалификация * 2) + (Стоимость трудочаса * 1,5) + (Пунктуальность * 1,7) + (Экологичность * 2) + (Переписка * 1)
Если непонятно, давайте попробую заполнить таблицу.

4 этап. Заполните матрицу и вычислите итоговую оценку

После того, как мы выявили критерии и взвесили их, нужно проставить оценки вариантам по всем критериям. Так получится сравнить итоговые оценки разных вариантов и выбрать наиболее выгодный.
Считать будем так: ставить оценку от 1 до 5, после чего умножать оценку того или иного критерия на ее коэффициент. Далее взвешенные оценки по тем или иным критериям суммируются в итоговую оценку.
Этим разработчиком был Альберт Эйнштейн. Обратите внимание на формулу одной из итоговых ячеек – там учтен вес каждого из критериев

5 этап. Проанализируйте результат

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

Какие еще существуют матрицы для принятия решений

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

Матрица Эйзенхауэра

Матрица Эйзенхауэра, названная в честь 34-го президента США Дуайта Д. Эйзенхауэра – популярный олдскульный инструмент для управления временем и задачами. Она помогает расставить приоритеты и определить, какие задачи требуют немедленного внимания, а какие можно отложить, делегировать или даже забыть.
Матрица состоит из четырех квадрантов с задачами:
  1. Срочные и важные: выполнить немедленно, лучше своими силами.
  2. Не срочные, но важные: важны для долгосрочных целей, но не требуют немедленных действий.
  3. Срочные, но не важные: требуют немедленного внимания, но не критичны для долгосрочных целей. Как правило, их можно делегировать.
  4. Не срочные и не важные: можно отложить или вовсе исключить из списка дел.
Чтобы использовать матрицу Эйзенхауэра, нужно анализировать каждую задачу по очереди, распределяя их между квадрантами.
Если что, про спортзал мы пошутили
Когда лучше применять матрицу Эйзенхауэра?
Она идеально подходит для управления повседневными задачами, когда надо быстро расставить приоритеты и определить, на чем сосредоточить усилия в первую очередь. Это помогает избежать прокрастинации и сосредоточиться на действительно важных делах. Но и для работы она тоже подойдет, если у вас нет четкого плана с приоритизацией задач – матрицу Эйзенхауэра можно сделать за пять-десять минут.

Матрица RACI

Матрица RACI (или диаграмма ответственности) используется для определения ролей и ответственности в проекте. Она помогает распределить задачи между членами команды и четко определить кто за что отвечает.
Название RACI расшифровывается так:
  • R (Responsible). Тот, кто выполняет задачу.
  • A (Accountable). Тот, кто несет ответственность за выполнение задачи.
  • C (Consulted). Тот, с кем нужно проконсультироваться при выполнении задачи.
  • I (Informed). Тот, кого нужно информировать о выполнении задачи.
Заполненная матрица RACI будет выглядеть примерно так
Чтобы использовать матрицу RACI, нужно:
  1. Создать таблицу с задачами по вертикали и ролями по горизонтали. Или наоборот.
  2. Заполнить таблицу, указав, кто за какую задачу отвечает (Responsible), кто несет ответственность (Accountable), с кем нужно консультироваться (Consulted) и кого нужно информировать (Informed).
  3. Распечатать таблицу и повесить на стену, чтобы ее видели все заинтересованные лица и не задавали лишних вопросов.
Где и когда применять матрицу RACI?
В проектах и командах, когда важно четко распределить роли и обязанности. Она помогает избежать путаницы, улучшить коммуникацию и повысить эффективность совместной работы.
Надеемся, что эта статья поможет вам в ваших делах – как личных, так и бизнесовых. Но если вдруг вы понимаете, что одних только матриц недостаточно – обратитесь за бесплатной консультацией в Neogenda. Мы можем не только обучить ваших сотрудников лучшим управленческим практикам, но и полностью реорганизовать ваши бизнес-процессы, чтобы сделать их более эффективными.
]]> Что такое Scrum-спринты в управлении проектами: гайд http://neogenda.ru/blog/8uox3ih2e1-chto-takoe-scrum-sprinti-v-upravlenii-pr http://neogenda.ru/blog/8uox3ih2e1-chto-takoe-scrum-sprinti-v-upravlenii-pr?amp=true Wed, 31 Jul 2024 07:43:00 +0300 Андрей Сидоренко Одним из ключевых преимуществ внедрения Scrum является улучшение совместной работы команды и оптимизация бизнес-процессов. Фокусирование...

Что такое Scrum-спринты в управлении проектами: гайд

Одним из ключевых преимуществ внедрения Scrum является улучшение совместной работы команды и оптимизация бизнес-процессов. Фокусирование на коротких итерациях (спринтах) помогает команде быстрее достигать результатов, улучшает коммуникацию между участниками проекта, увеличивает прозрачность процессов и позволяет быстрее реагировать на изменения.
Спринт — основное Scrum-событие, ограниченный по времени цикл разработки, за который команда выполняет поставленные цели и задачи. Результатом выполнения Scrum-спринта является готовый к тестированию работоспособный инкремент проекта.
Старт каждого спринта начинается с встречи по планированию спринта, где команда обсуждает задачи разработки, планирует объем работ и создает бэклог проекта.
Во время выполнения команда собирается на ежедневный скрам, где обсуждает фактическую ситуацию:
  • что уже удалось реализовать;
  • что находится в работе;
  • что планируют начать/закончить;
  • блокировки;
  • какие есть вопросы и проблемы.
По завершению спринта команда собирается на обзор спринта для представления результатов работы и ретроспективу для подведения результатов. На ретроспективе обсуждаются возникшие проблемы и способы их устранения для следующих спринтов.
Использование спринтов делает работу над проектом более гибкой, прозрачной и удобной для команды разработки и заказчика.
Далее в статье:
  • для чего нужен спринт;
  • какая продолжительность у спринтов;
  • какие есть преимущества;
  • как строится работа с использованием Scrum-спринтов;
  • распространенные ошибки.
Если вам требуется помощь в выстраивании бизнес-процессов и консалтинг — обратитесь в Neogenda. Мы помогли решить проблемы менеджмента и достигнуть результатов крупнейшим компаниям, таким как Сбер, Qiwi, Газпромбанк, Skyeng, X5 Group, Avito и других. Оставьте заявку и мы предложим решения для вашего бизнеса на бесплатной консультации в Zoom.

Для чего нужен спринт

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

Длительность спринта

Оптимальная длина спринта выбирается командой разработки в начале работ над проектом. Все спринты проекта желательно планировать одинаковой продолжительности.
Продолжительность одного спринта фиксирована и обычно составляет от одной до четырех недель. Спринты более месяца рискованны и могут оказаться слишком сложными в реализации для команды.
Короткие недельные спринты хорошо подойдут опытным Scrum-командам или небольшим проектам, спринты по 3-4 недели стоит выбирать для масштабных проектов с большим объемом работ.
Важно помнить: фреймворк Scrum уделяет особое внимание ценности получения частой обратной связи от всех участников проекта: владельца продукта, Scrum-мастера, команды разработки. При высокой продолжительности спринтов этому уделяется меньше внимания, возникает больше ошибок, вопросов, требуется больший контроль над задачами.

Преимущества спринтов

Использование Scrum-спринтов дает ощутимую пользу бизнесу и дает ряд преимуществ:
  • Гибкость разработки. Корректировать ход работ можно после завершения каждого спринта, на основании обратной связи от заказчика или команды.
  • Прозрачность процессов. Все участники команды видят не только свои задачи и часть работ, но и ситуацию на всем проекте.
  • Четкие цели отдельных спринтов. Помимо основной цели проекта, цели ставятся для каждого из спринтов. Это позволяет получать готовый для релиза инкремент проекта.
  • Улучшение качества. Проведение ретроспективы по окончанию спринта помогает выявить возникшие проблемы и устранить ошибки во время следующей итерации разработки.
  • Высокий уровень мотивации в команде. Достижение быстрых и видимых результатов, отслеживание прогресса и получение обратной связи мотивирует команду, не дает ей расслабляться и повышает вовлеченность в проект.
  • Регулярная выдача ценности бизнесу. Каждый спринт это самостоятельная рабочая часть проекта, с поставленными целями и задачами. Работа по спринтам дает возможность не ждать долгого завершения проекта, а выдавать пользу для пользователей и заказчика в каждой итерации разработки.

Как строится работа по спринтам

В отличие от детерминированных методологий, где все детали процесса известны заранее или предсказуемы, Scrum предлагает команде работать в коротких спринтах — такой подход помогает команде быстро адаптироваться к изменениям, возникающим в процессе работы. Вместо того, чтобы пытаться предсказать все детали заранее, Scrum позволяет команде гибко реагировать на новые требования или изменения приоритетов. Это особенно полезно в сфере разработки программного обеспечения, где требования могут меняться в процессе работы над проектом.
Эмпирический подход Scrum помогает справляться с неопределенностью и сложностью проектов. Команда может быстро прототипировать и тестировать идеи, получая обратную связь и внося изменения на ранних этапах разработки. Это позволяет достичь лучших результатов и удовлетворить потребности заказчика.
Пример. Разработка мобильного приложения для ресторана может обрастать новыми задачами от релиза к релизу. Для первой версии MVP будет достаточно приложения с минимальным функционалом, в котором пользователь может ознакомиться с актуальным меню без возможности заказать. Дальнейшие версии обрастут функциями и получат пожелания заказчика реализовать: функцию заказа на доставку и самовывоз, расширение функционала для работы с сетью ресторанов, личные кабинеты пользователей, системы лояльности, накопления кэшбэка, оплату заказов баллами и многое другое. Все это — функционал который может быть добавлен к MVP, вышедшему в релиз за пару недель, в ходе дальнейших итераций разработки.
Каждый спринт строится из четырех неизменных обязательных этапов:
  1. Планирования.
  2. Ежедневного скрама.
  3. Обзора спринта.
  4. Ретроспективы спринта.
Схема организации спринтов по фреймворку Scrum
После окончания спринта работа над проектом не прекращается и не делается пауза. Сразу за завершенным спринтом идет следующая итерация, которая также начинается с планирования и определения целей спринта.
Рассмотрим более подробно работу на каждом из этапов.

Планирование спринта

Новая итерация разработки всегда начинается с этапа планирования. На этом этапе владелец продукта, Scrum-мастер и разработчики обсуждают план и объем работ.
Важный момент: владелец продукта в данной схеме организации работы не заказчик и клиент, а полноценный участник процесса разработки, такой же важный как Scrum-мастер и разработчики. От его обратной связи зависит насколько хорошо будут спланированы спринты, какое количество ошибок на пути к цели встретит команда и какой результат выйдет в конце.
На этапе планирования команда оценивает сложность и трудоемкость разработки, используя для этого story points.
Story points — это условные единицы, помогающие оценить сложность и трудоемкость элементов бэклога. Они позволяют отойти от стандартной оценки сложности в человеко-часах и помогают объективно оценить «вес» элементов бэклога, относительно всего проекта. Обычно для выставления стори поинтов используют числа Фибоначчи (0, 1, 2, 3, 5, 8, 13, 21, 34). Это упрощает планирование, помогает точнее и реалистичнее предсказать дату релиза.
Во время планирования спринта команде требуется:
  • Определить приоритеты. Расставление приоритетов помогает грамотно планировать ресурсы и время разработчиков во время каждого спринта.
  • Определить цель спринта. Цели устанавливаются не только для всего проекта (или продукта) в целом, но и для каждого инкремента в отдельности.
  • Декомпозиция задач, заполнение бэклога спринта. Выполнять большие задачи целиком, управляя соответствующими процессами и промежуточными результатами, гораздо сложнее, чем выполнять много мелких задач. Выполненные задачи мотивируют команду, дают ощутимый видимый результат и повышают эффективность работы.
  • Формирование резерва. Резервное время должно быть заложено для каждой из итераций на случай возникновения форс-мажоров. Так же отдельно можно заложить временные резервы для самых сложных задач, получившим самые высокие story points (но лучше такие задачи, конечно, разбивать на более мелкие и понятные).
  • Визуализация на Скрам-доске. Scrum-доска используется для визуализации работы команды во время спринта. На нее заносятся задачи из бэклога продукта и перемещаются по этапам во время их выполнения. Так вся команда в режиме реального времени может отслеживать какие задачи были запланированы, какие в очереди на выполнение, какие выполняются в текущий момент, а какие уже завершены.
Итогом этого этапа является заполненный бэклог спринта, он же — план работы на весь спринт.
Пример планирования спринта на Scrum-доске
Если команда не справится со спринтом и не достигнет поставленных целей, это может привести к серьезным последствиям. Возможные негативные последствия включают в себя:
Задержку в общем графике реализации проекта и увеличение стоимости.
Ухудшение мотивации членов команды, напряженность в коллективе.
Потеря репутации компании, ослабление доверия заказчика к компании.
Неудовлетворенность заказчика и возможное прекращение сотрудничества.
Поэтому так важно грамотно планировать спринты, контролировать выполнение задач и регулярно анализировать причины возможных провалов, чтобы своевременно корректировать работу команды и достигать успеха в проектах, основанных на фреймворке Scrum.
Если вы хотите узнать больше о том, кто такой Scrum-мастер, читайте нашу статью «Кто такой Scrum-мастер простым языком». В ней мы разбираем его задачи и обязанности в команде.

Ежедневный скрам

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

Обзор спринта

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

Ретроспектива

Ретроспектива спринта — заключающий этап итерации разработки. На ней команда проводит работу над ошибками, обсуждает все возникшие блокеры, составляет список доработок для новых спринтов.
Ретроспектива по времени длится до 3 часов.
За ретроспективой начинается следующая итерация разработки и цикл повторяется снова, начиная с этапа планирования.

Распространенные ошибки

Несмотря на всю гибкость и адаптивность к изменениям работы фреймворка Scrum, есть ошибки, способные навредить работе команды и существенно отодвинуть сроки реализации функционала.
Вот некоторые ошибки и заблуждения, которые совершают управленцы при организации работы команды:
1. Слишком долгие ежедневные скрамы и куча лишних совещаний. Рабочие планерки обязательно должны иметь четкие ограничения по времени, определенную цели, а их количество должно регулироваться необходимостью и здравым смыслом. Если этим пренебрегать, то команда будет целыми днями совещаться, а у разработчиков возникнет вопрос «когда работать, если мы только разговариваем?»
2. Сотрудники, отсиживающие рабочие часы. При переводе компании на работу по Scrum нужно оценивать и ее сотрудников. Часть из них может быть настроена на работу «по времени», а не на командную работу и достижение совместных результатов. С такими людьми лучше прощаться и не ждать, пока они начнут тянуть проекты вниз.
3. Ожидание, что работа команды будет слаженной и эффективной с первых спринтов. Работа спринтами похожа на постоянное обучение, работу над ошибками и рост компетенций команды через решение возникающих проблем. Не стоит ждать, что все будет хорошо с самой первой итерации.
4. Scrum — не волшебная пилюля для решения управленческих проблем. Часто от внедрения Scrum ждут моментального видимого результата, но сам метод управления и его принципы может не подойти компаниям из-за специфики бизнеса или быть адаптированным не сразу. Например, длина или структура задач может не соответствовать итеративному подходу Scrum. В таких случаях, компаниям следует рассмотреть другие гибкие методологии управления, которые лучше соответствуют их потребностям. Например, Kanban или Lean может быть более подходящими вариантами для компаний с особыми требованиями или процессами.
Если вы хотите узнать больше о том, какие есть методологии управления проектами, читайте нашу статью «Методологии управления проектами: топ-12 популярных систем». В ней мы разбираем его задачи и обязанности в команде.
5. Внесение глобальных изменений во время спринтов. Цели и задачи спринта определяются на этапе планирования и не должны изменяться во время его реализации. Корректировать общий курс проекта и вносить изменения можно на этапе планирования следующего спринта. Попытки сломать систему и внести изменения во время запущенной итерации недопустимы.
Если вам нужно обучить команду и внедрить фреймворк Scrum — обратитесь в Neogenda. Мы помогли решить проблемы менеджмента и управления в таких компаниях, как Tinkoff, Яндекс, Авито, Сбер, Билайн, Skyeng и так далее. Оставьте заявку на бесплатную консультацию в Zoom и мы предложим решение для вашего бизнеса.
]]> Матрица RACI: руководство по распределению ролей и ответственности в проекте http://neogenda.ru/blog/chatlkpe21-matritsa-raci-rukovodstvo-po-raspredelen http://neogenda.ru/blog/chatlkpe21-matritsa-raci-rukovodstvo-po-raspredelen?amp=true Fri, 02 Aug 2024 09:53:00 +0300 Андрей Сидоренко Когда над одной и той же задачей, проектом или сервисом работают несколько независимых исполнителей, понятие...

Матрица RACI: руководство по распределению ролей и ответственности в проекте

Когда над одной и той же задачей, проектом или сервисом работают несколько независимых исполнителей, понятие «зона ответственности» становится весьма расплывчатым и нечетким.
Подрядчики, подразделения организации, разные команды и исполнители могут перекидывать ответственность друг на друга, не иметь четко оговоренных границ зон ответственности, да и попросту не хотят брать ответственность за задачи, которые выполняются сразу большим кругом лиц. Чтобы регламентировать подобные процессы используют матрицу RACI.
Матрица RACI, диаграмма RACI, также известная как матрица назначения ответственности (RAM) или диаграмма линейной ответственности (LRC) — это управленческий инструмент, используемый для определения ролей и зон ответственности в проекте или организации.
Использование матрицы RACI позволяет четко определить роли всех участников проекта, избежать дублирования обязанностей или неопределенности в распределении ответственности.
Если вам требуется внедрение OKR или других подходов к управлению проектами — обращайтесь в Neogenda. Мы разберем ваш кейс на бесплатной консультации и подберем индивидуальное решение для вашего бизнеса.
Далее в статье:
  • что такое матрица RACI – расшифровка;
  • зачем составлять матрицу;
  • виды матриц и смежные подходы;
  • пошаговая инструкция по созданию диаграммы RACI;
  • основные ошибки при составлении.

Что такое матрица RACI: расшифровка аббревиатуры

Матрица RACI в управлении проектами представляет собой таблицу или диаграмму, которая используется для визуализации ролей и ответственности участников проекта или процесса. Внутри матрицы каждая задача или процесс разбивается на строки, а в столбцах указываются роли участников.
Шаблон матрицы RACI
RACI — это акроним, который обозначает четыре основных роли:
  1. Responsible (Ответственный);
  2. Accountable (Подотчетный);
  3. Consulted (Консультант);
  4. Informed (Информированный).
Рассмотрим подробнее каждую из ролей.

Responsible (Исполнитель)

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

Accountable (Ответственный или утверждающий)

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

Consulted (Консультант)

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

Informed (Информированный или наблюдатель)

В роли информированного может выступать любое заинтересованное лицо, такое как руководитель подразделения, руководитель команды, владелец компании, заказчик, клиент. Этим участникам процесса должна своевременно доноситься информация о ходе выполнения работ, прогрессе или возникающих проблемах.
Зачем составлять матрицу ответственности
Задач, которые может решить диаграмма RACI, несколько:
Контроль над выполнением задач. Матрица ответственности помогает определить, кто отвечает за выполнение конкретной задачи.
Распределение ответственности. Каждый участник команды видит, какая роль ему назначена и какой вклад необходим для успешного выполнения проекта.
Повышение прозрачности. Матрица ответственности является инструментом, который делает видимым вклад каждого участника в проект.
Улучшение коммуникации. За счет четкого определения ответственности и ролей участников проекта улучшается коммуникация внутри команды. Каждый знает, к кому обратиться по конкретному вопросу или проблеме.
Улучшение управления рисками. Матрица помогает выявить потенциально узкие места в проекте и обеспечивает оперативное реагирование при возникновении проблем.

Разновидности RACI-матриц и смежные подходы

Подход RACI гибок и может подстроиться под нужды любого проекта, но существуют и другие разновидности матрицы, в которых добавлены дополнительные роли:
RACIQ — матрица, в которой к привычным четырем ролям добавляется пятая — Quality. Это сотрудник, в обязанности которого входит оценка результатов работы и контроль качества.
RASCI — матрица, в которой дополнительно добавляется роль Supportive. Сотрудник выполняет роль поддержки для ответственного за выполнение, но сам не несет ответственности за результат.
RACI-VS — в стандартную матрицу добавляются две дополнительные роли: Verifier и Signatory. В обязанности этих сотрудников входит приемка работ в соответствии с принятыми стандартами качества и согласование передачи продукта в эксплуатацию.
RACIO или CAIRO — к модели RACI добавляется необычная роль — Out of the loop. Что переводится как участник команды, которого не должно быть в рабочем процессе.
DACI — похожая по смыслу матрица, но с отличными ролями:
  • Driver (Ведущий). Участник выступает в качестве инициатора процесса, он формирует цели и определяет необходимые шаги для их достижения.
  • Approver (Утверждающий). Участник принимает окончательные решения и утверждает результаты работ.
  • Contributor (Участник). Участник активно участвует в работе над проектом, вносит свой вклад и выполняет задачи в соответствии с назначенной ролью. Он отвечает за выполнение задач и достижение поставленных целей.
  • Informed (Информируемый). Участник не принимает активного участия в процессе принятия решений и выполнения задач, но оповещается о ходе работы, принимаемых решениях и изменениях по мере необходимости.
RAPID — матрица имеющая роли:
  • Recommend (Рекомендовать). Участник предлагает решения и дает рекомендации по принятию решений. Он обладает экспертными знаниями и опытом в определенной области.
  • Agree (Соглашаться). Участник принимает окончательное решение по предложенным вариантам и обеспечивает согласованность с общими целями и стратегией организации.
  • Perform (Выполнять). Участник ответственен за выполнение решений и задач, которые были приняты.
  • Input (Подавать информацию). Участник предоставляет необходимую информацию и данные для принятия решений.
  • Decide (Принимать решение). Участник принимает ключевые решения, опираясь на рекомендации, согласование, входные данные и свою экспертизу.

Как создается матрица RACI: пошаговая инструкция

Шаг 1: Определите область применения

Первым шагом стоит определить, для какого проекта или задачи создается матрица RACI.
Например, для проекта по разработке сайтов.

Шаг 2: Напишите список задач или процессов

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

Шаг 3: Определите участников

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

Шаг 4: Назначьте роли

Для каждой задачи из ранее собранного списка определите участников и назначьте каждому из них одну из четырех ролей:
  • Responsible (Ответственный);
  • Accountable (Подотчетный);
  • Consulted (Консультант),
  • Informed (Информируемый).
Для удобства в матрице можно использовать только первые буквы ролей.
Пример распределения ролей в матрице RACI

Шаг 5: Проверьте, согласуйте и утвердите

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

Шаг 6: Мониторьте и корректируйте изменения

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

Ошибки при составлении матрицы RACI

При составлении матрицы RACI могут возникнуть следующие ошибки:
1. Неправильное распределение ролей. Может привести к недопониманию обязанностей каждого участника команды и, как следствие, к неэффективной реализации проекта.
2. Отсутствие ясности в распределении ответственности. Если зоны ответственности не распределены четко и ясно, возможно возникновение путаницы при выполнении задач, дублирование работы или, наоборот, упущение важных деталей проекта.
Например, если назначить ответственными сразу несколько разноплановых специалистов на одном и том же этапе работ, то может возникнуть конфликт и непонимание зон ответственности. В таких случаях лучше назначить одного специалиста ответственным, а смежных — консультантами или наблюдателями.
3. Недостаточное вовлечение в процесс. Если не все участники команды активно вовлечены в процесс составления матрицы RACI, это может привести к недостаточной мотивации для выполнения задач.
4. Избыточность ролей. Назначение большого количества ответственных лиц в матрице RACI может затруднить управление проектом, увеличить количество согласований, вызвать сложности при приемке конечного результата и привести к конфликтам в команде.
Например, есть задача отрисовать баннер для сайта. Если назначить слишком много ответственных, консультантов и наблюдателей, то это может превратиться в бесконечные круги согласований и переделок, так как у каждого участника свой вкус и каждый будет вносить свои корректировки, не влияющие существенно на внешний вид готовой работы.
5. Игнорирование изменений. Матрица RACI должна быть динамическим инструментом, способным адаптироваться к изменяющимся обстоятельствам. Игнорирование изменений и недостаточная реакция на них может привести к провалу проекта.
Например, изначально проект имел 6 этапов разработки, для каждого из них были назначены роли для участников команды. Но в ходе работ заказчик внес корректировки и этапов стало 8.
В этом случае не стоит надеяться, что специалисты сами распределят новые обязанности и выполнят работу в нужном объеме. Такой подход может привести к перегрузке специалистов, недостатку ресурсов или размытию зон ответственности — сотрудники будут переводить стрелки друг на друга.
При подобном изменении проекта стоит пересмотреть матрицу ответственности, скорректировать или перераспределить роли и при необходимости привлечь дополнительных специалистов.
6. Использование имен вместо ролей. В матрице желательно не привязываться к конкретным сотрудникам и не вписывать имена, так как с сотрудником могут происходить разные форс-мажоры – от выхода на больничный до увольнения, и проект не должен от этого страдать. Лучше указывать именно роли, например «дизайнер».
Если вам требуется помощь с распределением ролей в проекте или продуктовой команде — обращайтесь в Neogenda. Мы детально изучим потребности вашего бизнеса и предложим решение на бесплатной консультации в Zoom.
]]> User Story Mapping: зачем нужны пользовательские истории и как их правильно писать http://neogenda.ru/blog/4p8uj10371-user-story-mapping-zachem-nuzhni-polzova http://neogenda.ru/blog/4p8uj10371-user-story-mapping-zachem-nuzhni-polzova?amp=true Thu, 08 Aug 2024 09:57:00 +0300 Андрей Сидоренко В процессе разработки команда может слишком увлечься производственными процессами: вносить логичные, на их взгляд, улучшения...

User Story Mapping: зачем нужны пользовательские истории и как их правильно писать

В процессе разработки команда может слишком увлечься производственными процессами: вносить логичные, на их взгляд, улучшения в продукт, обновлять функционал, держать курс на потребности бизнеса и монетизацию продукта, но забыть о самом важном — потребностях пользователя. Чтобы создавать востребованные продукты с ориентиром на конечного потребителя, собирают пользовательские карты, одна из таких — user story map.
Карта пользовательских историй или user story map — это маркетинговый инструмент с описанием функциональных возможностей продукта в простой и понятной форме, написанный от имени конечного пользователя. Истории не содержат сложных технических деталей и подробностей реализации продукта. Их основная цель — фокус на удовлетворении потребностей пользователя.
В манифесте Agile люди и удовлетворение их потребностей ставятся выше процессов и инструментов. Это значит, что продукт всегда должен создаваться с ориентиром на конечного пользователя.
Истории помогают команде разработки лучше понять, для кого они создают продукт и сделать его максимально ценным для конечного потребителя.
Если вам требуется определение позиционирования продукта или анализ ценностного предложения — обратитесь в Neogenda. Мы детально проанализируем ваш случай и предложим решение на бесплатной консультации в Zoom.
Далее в статье:
  • структура пользовательских историй;
  • зачем нужно их составлять;
  • преимущества и недостатки инструмента;
  • как user story используются в Скрам и Канбан;
  • пошаговая инструкция по написанию user story;
  • критерии оценки историй.

Структура user story

Любая пользовательская история имеет три важных составляющих:
  1. Роль. Описывает роль или тип пользователя, потребность которого требуется реализовать в рамках разработки или создания продукта.Например, «как покупатель», «как администратор», «как гость».
  2. Действие. Описывает конкретное действие или функциональность, которую пользователь хочет выполнить или получить от системы.Например, «хочет просмотреть список товаров», «хочет добавить товар в закладки или отложенное».
  3. Ценность для пользователя. Указывает на ценность или пользу, которую пользователь получит от выполнения задачи, описанной в user story. Отвечает на вопрос «Зачем это нужно пользователю?» и помогает понять, какой результат ожидается от реализации функции.
Общий шаблон составления юзер стори строится по формуле:
Как кто? (ответ на вопрос «кто пользователь») , я хочу (описание функционала), чтобы (потребность пользователя, которую требуется закрыть)
Пример составления user story с учетом трех составляющих

Зачем нужно составлять пользовательские истории

Создание пользовательских историй решает сразу несколько проблем разработки:
  • Формирование единого понимания целей и задач проекта. Пользовательские истории пишутся простым и доступным языком, что помогает всем участникам производственного процесса одинаково понимать требования пользователей к готовому продукту.
  • Помощь в подготовке сценариев для тестирования готового продукта или его инкрементов. На основании пользовательских историй могут быть разработаны сценарии для юзабилити-тестирований и тест-кейсы для QA-инженеров.
  • Фокус на создании ценности для клиента. Каждая история содержит не только описание самой функции, но и имеет ответ на вопрос «Для чего это нужно пользователю?»
  • Подготовка критериев приемки. Пользовательские истории помогают оценить готовность продукта и его соответствие ожиданиям пользователей.
  • Проектирование внешнего вида продукта и его отдельных функций. На основании user story можно более точно проектировать интерфейс и создавать дизайн продукта.
  • Расстановка приоритетов разработки. При составлении историй можно выделить набор самых важных и нужных функций для пользователей и начать реализацию именно с них.
  • Сокращение временных затрат на разработку ненужного функционала. С помощью историй можно сосредоточиться только на ключевых функциях и не тратить время на реализацию маловажного или вовсе ненужного пользователям.

Преимущества и недостатки story mapping

Среди плюсов составления историй можно отметить:
  • Истории помогают команде разработки взглянуть на продукт под другим углом, рассматривать его не как набор технических функций и элементов, а как способ удовлетворения потребностей пользователя.
  • Изучение историй помогает поддерживать тесную коммуникацию внутри команды, искать и обсуждать свежие идеи по реализации описанных функций.
  • Одна история = одна функция. Этот принцип хорошо подходит для scrum- и agile-команд, которые могут использовать истории в качестве цели спринта.
  • Простой язык и минимум технических подробностей.
К минусам можно отнести:
  • Не всегда точное описание требований. Иногда истории могут быть поверхностными и не содержать достаточной информации для понимания требований.
  • Ограничение в детализации. Некоторые важные детали или технические аспекты могут быть упущены в историях из-за ориентации на точку зрения пользователя. Это может затруднить работу команды разработчиков.
  • Трудность в оценке и планировании. Пользовательские истории не всегда легко оценить, правильно определить приоритет и сроки выполнения, что может создать трудности в планировании разработки.

Как пользовательские истории используются в Канбан и Скрам

Пользовательские истории как инструмент хорошо вписываются в современные подходы к менеджменту, например, Скрам и Канбан.
В Канбан-методе пользовательские истории могут быть представлены в виде отдельных карточек на доске и пропущены через весь производственный процесс. Каждая история представляет собой конкретный сценарий использования продукта или функциональное требование со стороны пользователя. Карточки помогают отслеживать прогресс реализации каждой user story и осуществлять приемку работы в соответствии с ожиданиями и требованиями пользователей.
Для отслеживания реализации user story в Канбан используют электронные доски, такие как Trello, Jira, Asana, Kaiten, Weeek и другие. Эти инструменты позволяют устанавливать приоритеты для каждой карточки с историей, добавлять подробности и отслеживать прогресс выполнения работ.
Во фреймворке Скрам пользовательские истории формулируются в бэклог продукта и детализируются в рамках каждого спринта. При планировании нового спринта команда выбирает определенное количество пользовательских историй для реализации в течение итерации. Каждая выбранная история должна быть выполнена и протестирована к концу спринта.
Для отслеживания пользовательских историй в фреймворке Скрам используются инструменты для управления проектами, такие как Jira, Azure DevOps и другие. С помощью этих инструментов можно создавать и отслеживать реализацию пользовательских историй в рамках проекта.

Чем пользовательские истории отличаются от задач

Пользовательская история — это описание того, как пользователь будет использовать продукт и какой ему требуется функционал. Она помогает понять, какие задачи должен выполнять пользователь и для чего ему нужен продукт. Например, пользовательская история может быть описанием возможности покупки товара онлайн.
Задача — это конкретное действие, которое разработчики выполняют, чтобы реализовать функциональность, описанную в пользовательской истории. Это шаги или операции, которые необходимо выполнить для создания продукта. Например, задачей может быть добавление кнопки «Купить» на странице товара.
Таким образом, пользовательская история описывает, что нужно сделать с точки зрения пользователя, а задача определяет, как это будет реализовано с технической точки зрения.
Например, у нас есть user stories «Как клиент интернет-магазина одежды, я хочу видеть рядом со списком размеров одежды размерную сетку или инструкцию по выбору размера».
Если эту историю без каких-либо корректировок сразу добавить к выполнению на канбан-доску, то разработчики обязательно придут с вопросами:
  1. Как именно это нужно сделать?
  2. Как это должно работать?
  3. Какие элементы нужно добавлять?
  4. Как это будет редактировать администратор сайта?
То есть история не может сразу стать задачей. Нужно провести декомпозицию и разбить это на несколько подзадач. Например:
  1. Добавить рядом с выбором размеров кнопку «Таблица размеров».
  2. Добавить всплывающее окно с размерной сеткой по нажатию на кнопку «Таблица размеров».
  3. Добавить в админпанель поля для редактирования таблицы размеров и т. д.
Такие подзадачи, в отличие от самой истории, сформулированы техническим языком, содержат детали реализации и не вызовут вопросов у команды разработчиков.

Как написать пользовательскую историю: пошаговая инструкция

Для написания продуманной и качественной истории нужно выполнить несколько шагов.

Шаг 1. Подготовительный анализ

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

Шаг 2. Анализ целевой аудитории

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

Шаг 3. Прописать эпики и истории

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

Шаг 4. Написать критерии приемки

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

Шаг 5. Расставить приоритеты историй

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

Шаг 6. Прописываем задачи для каждой истории

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

Шаг 7. Реализация

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

Критерии оценки User Story

Для написания качественных пользовательских историй, способных действительно помочь разработке, применяют критерии оценки историй INVEST.
Аббревиатура INVEST расшифровывается следующим образом:
  • Independent (Независимая). Каждая user story должна быть независимой от других историй, чтобы ее можно было реализовать отдельно от других задач и историй.
  • Negotiable (Обсуждаемая). История не должна содержать конкретных шагов реализации, она должна быть гибкой и обсуждаемой.
  • Valuable (Ценная). История должна быть значимой и приносить реальную ценность бизнесу, пользователям и стейкхолдерам.
  • Estimatable (Оцениваемая). История должна быть достаточно четко сформулирована, чтобы можно было оценить затраты по времени и ресурсам на ее реализацию.
  • Small (Маленькая). История должна быть достаточно маленькой, чтобы ее можно было реализовать за один спринт или короткое время, сохраняя тем самым непрерывность работы.
  • Testable (Тестируемая). История должна быть сформулирована таким образом, чтобы ее можно было протестировать и проверить, достигнута ли описанная цель.
Истории, которые не соответствуют критериям INVEST, не должны браться в работу. Их стоит еще раз оценить и, при необходимости, скорректировать.
Если вам требуется помощь в организации бизнес-процессов продуктовой команды или консалтинг бизнеса — обратитесь в Neogenda. Мы являемся признанными экспертами по современным инструментам менеджмента и точно знаем, как помочь вашему бизнесу достичь результата.
]]> Что такое управление рисками и почему это важно http://neogenda.ru/blog/noof89up01-chto-takoe-upravlenie-riskami-i-pochemu http://neogenda.ru/blog/noof89up01-chto-takoe-upravlenie-riskami-i-pochemu?amp=true Wed, 21 Aug 2024 10:00:00 +0300 Артур Нек Узнайте, что такое риск-менеджмент, из каких этапов он состоит и какие методы стоит применять, чтобы...

Что такое управление рисками и почему это важно

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

Система управления рисками

Концепция управления рисками существует уже несколько десятилетий, но с каждым годом она становится все более важной и комплексной. В 1970-х годах управление рисками начало развиваться в финансовом секторе, а сегодня оно стало неотъемлемой частью управления проектами в различных отраслях. Современные методы управления рисками включают как традиционные подходы, такие как SWOT-анализ, так и инновационные инструменты, например, анализ Монте-Карло.
Управление рисками — это процесс выявления, оценки и контроля потенциальных угроз, которые могут негативно повлиять на выполнение проекта.
Игнорирование рисков может привести к серьезным последствиям, включая задержки в выполнении проекта, ущерб, превышение бюджета и снижение качества конечного продукта.
Система управления рисками — это не просто выявление и контроль рисков, это целый комплекс, состоящий из нескольких взаимосвязанных компонентов:
  • Документированные правила, процедуры и стандарты, которые определяют общие подходы и методы управления рисками в организации.
  • Структурированные процессы и специализированные инструменты, используемые для выявления, оценки, мониторинга и контроля рисков.
  • Четкое распределение ролей и обязанностей среди членов команды проекта и заинтересованных сторон.
  • Эффективные механизмы коммуникации и отчетности, обеспечивающие прозрачность и своевременное информирование о рисках.

Виды рисков

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

4 причины, почему риск-менеджмент важен

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

Процесс управления рисками

Процесс управления рисками включает несколько основных шагов.
1. Идентификация рисков.
Идентификация риска — это первый и один из самых важных шагов в риск-менеджменте. Целью данного этапа является систематическое выявление всех возможных, потенциальных угроз и возможностей, которые могут повлиять на успешное выполнение проекта. Здесь применимы методы мозгового штурма и, например, «мирового кафе», когда обсуждаются всевозможные форс-мажоры. Используются экспертные оценки, данные аудитов и маркетинговых исследований.
2. Анализ рисков и оценка.
Недостаточно просто определить риски, необходимо ранжировать их и оценить по вероятности возникновения, степени информированности, степени последствий и значимости.
Выделяют качественный и количественный анализ рисков. При качественном анализе определяют, что и когда может произойти, какие будут последствия и какова их вероятность. Количественный анализ обычно проводят после качественного, и он определяет, сколько денег и времени потеряет компания при наступлении того или иного риска.
Расставляются приоритеты, рискам присваивается соответствующий ранг. Так, риску, который причинит небольшие неудобства, но не сильно нарушит бизнес-операции, присваивается низкий ранг, а риску, который может нанести ущерб или привести к остановке всего бизнеса, присваивается наивысший ранг. Этот шаг позволяет определить, на что следует направить больше времени и ресурсов команды.
3. Планирование реагирования.
Целью данного этапа является разработка стратегий по предотвращению рисков или их смягчению и выбор эффективного и доступного решения. Это так называемая обработка риска — определение плана предупреждения. В зависимости от характера риска существует четыре возможных стратегии реагирования — ответа на риск, — которые мы рассмотрим ниже.
4. Мониторинг и контроль рисков.
Необходимо периодически пересматривать результаты анализа рисков, чтобы адаптироваться к изменениям. Работают ли средства контроля так, как задумано? Можно ли их улучшить? Какие стратегии оказались наиболее эффективны? Цель мониторинга — выявлять ключевые показатели риска, которые могут послужить толчком к изменению стратегии.

Инструменты для идентификации рисков

Существует множество инструментов для идентификации рисков. Некоторые из наиболее распространенных включают:
SWOT-анализ (Strengths, Weaknesses, Opportunities, Threats)
Это простой и эффективный метод для начальной оценки рисков. Анализ сильных и слабых сторон проекта, а также возможностей и угроз.
Мозговой штурм
Может проводиться на любом этапе проекта. Это групповая сессия, в ходе которой участники генерируют идеи и обсуждают возможные риски. Стимулирует креативное мышление и позволяет выявить различные точки зрения.
Консультации с экспертами отрасли
Например, метод Дельфи — метод экспертного опроса, в котором группа экспертов анонимно отвечает на вопросы и пересматривает свои ответы на основе общего мнения группы.
Также используются всевозможные опросы и анкетирование, анализ предыдущих проектов для выявления повторяющихся рисков (метод аналогий), опыт членов вашей команды, аудит с использованием интеллектуального программного обеспечения.

Методы оценки рисков

Тепловая карта рисков
Известна также как матрица оценки рисков, она дает наглядное представление о характере и критичности рисков компании.
Уровни рисков визуализируются по двум основным параметрам: вероятности их наступления и степени воздействия на проект или организацию. Тепловая матрица помогает быстро идентифицировать наиболее критичные риски, требующие приоритетного внимания.
Матрица представляет собой сетку, где:
Ось X отображает вероятность наступления риска (от низкой до высокой).
Ось Y отображает степень воздействия риска (от низкой до высокой).
Каждая ячейка матрицы окрашивается в определенный цвет, соответствующий уровню риска:
  • Зеленый: Низкий риск (незначительное воздействие и/или низкая вероятность).
  • Желтый: Умеренный риск (умеренное воздействие и/или вероятность).
  • Красный: Высокий риск (значительное воздействие и/или высокая вероятность).
Квадрат Декарта
Квадрат Декарта, также известный как декартовы вопросы, — это метод, разработанный для улучшения процесса принятия решений. Этот инструмент универсален и помогает анализировать возможные варианты и их последствия. Квадрат Декарта состоит из четырех вопросов, расположенных в форме квадрата, каждый из которых помогает рассмотреть решение с разных сторон:
Что произойдет, если это случится?
  • Этот вопрос помогает представить положительные и отрицательные последствия принятия решения. Он фокусируется на том, что можно получить или потерять.
Что произойдет, если это не случится?
  • Этот вопрос рассматривает текущую ситуацию и потенциальные потери или выгоды, если решение не будет принято. Он помогает оценить статус-кво.
Что не произойдет, если это случится?
  • Этот вопрос обращает внимание на то, какие возможности будут упущены или что не изменится, если решение будет принято. Это позволяет увидеть скрытые аспекты принятия решения.
Что не произойдет, если это не случится?
  • Этот вопрос помогает выявить, что останется неизменным, если решение не будет принято. Он оценивает стабильность и потенциальные риски бездействия.
Имитационное моделирование
Имитационное моделирование — это метод, который позволяет предсказывать результаты и оценивать риски в сложных системах и проектах. Обработка риска производится путем создания модели системы и проведении множества экспериментов с этой моделью для изучения различных возможных сценариев.
Одним из распространенных является метод Монте-Карло. Он получил свое название в честь известного казино, так как использует случайные числа для моделирования вероятностей. Сначала задается вероятностное распределение (например, для проекта стоимость материалов может варьироваться от $100 до $200). Затем с помощью генератора случайных чисел создается множество возможных значений для каждой переменной, проводятся тысячи или даже миллионы симуляций с различными комбинациями случайных значений.
В итоге полученные результаты анализируются, чтобы получить возможные исходы и оценить риски.

Методы управления рисками

В системе управления рисками различают несколько стратегий реагирования.

Превентивные методы

Эти методы направлены на предупреждение возникновения рисков до их реализации.
1. Обучение персонала:
Регулярное повышение квалификации сотрудников, проведение тренингов, что помогает предотвратить ошибки и снизить вероятность возникновения рисков.
2. Стандартизация процессов:
Введение стандартных процедур, правил и инструкций для выполнения задач, что помогает уменьшить неопределенность и риск ошибок.

Корректирующие методы

Применяются для смягчения последствий рисков, которые уже реализовались. За рубежом используется термин «митигация» рисков. К ним относятся:
1. Разработка планов реагирования:
Создание детальных планов действий на случай возникновения различных рисков.
2. Резервирование ресурсов:
Выделение дополнительных ресурсов (временных, финансовых, человеческих) для покрытия непредвиденных затрат.
3. Диверсификация:
Распределение рисков путем диверсификации активностей или ресурсов.
Например, использование нескольких поставщиков для обеспечения бесперебойных поставок.

Перенос рисков

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

Избегание риска

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

Принятие

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

Основные стандарты в области управления рисками

В области управления рисками разработаны несколько ключевых стандартов:
  • ISO 31000 Управление рисками — Руководство (ГОСТ Р ИСО 31000-2019) предоставляет универсальные руководящие принципы по управлению рисками, подходящие для любых организаций.
  • COSO ERM включает модель из пяти компонентов и помогает интегрировать управление рисками в стратегическое планирование и операционную деятельность организации.
  • PMBOK Guide (Project Management Body of Knowledge) от Института управления проектами (PMI) описывает стандарты и лучшие практики в управлении проектами, включая управление рисками. Руководство охватывает идентификацию, анализ, планирование реагирования и мониторинг рисков.
  • NIST SP 800-30 от Национального института стандартов и технологий США фокусируется на управлении рисками информационных систем.
  • Автоматизация управления рисками

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

Программы, такие как RiskWatch, RiskWatch International или RiskyProject, позволяют автоматизировать процессы оценки и мониторинга рисков.
Использование дашбордов и графиков в инструментах, таких как Power BI или Tableau, для наглядного представления информации о рисках.
Внедрение систем, которые автоматически отслеживают показатели и сигнализируют о возможных рисках.

Пример успешного управления рисками

Рассмотрим на примере, как правильно выбранные и реализованные методы управления рисками могут привести к успешным результатам, снижению негативных последствий и максимальному использованию возможностей.
Строительный проект
Крупный строительный проект по возведению офисного комплекса в центральной части города.
Выявленные риски:
  • Вероятность задержек из-за погодных условий.
  • Риск превышения бюджета из-за непредвиденных расходов на материалы.
  • Вероятность получения жалоб от местных жителей на шум и пыль.
Методы управления рисками.
Превентивные методы:
  • Внедрение стандартов управления качеством и регулярное обучение персонала.
  • Создание резервного бюджета для покрытия непредвиденных расходов.
  • Установка шумозащитных барьеров и регулярное орошение стройплощадки для уменьшения пыли.
Корректирующие методы:
  • Разработка плана реагирования на задержки, включая возможность переноса части работ на ночное время.
Мониторинг:
  • Еженедельные проверки и аудиты для отслеживания состояния проекта и корректировки действий при необходимости.
Результаты:
  • Проект был завершен вовремя и в рамках бюджета, благодаря чему были минимизированы негативные последствия рисков и улучшено взаимодействие с местными жителями.

Заключение

Различные методы и инструменты управления рисками могут быть эффективно применены в различных отраслях. Ключом к успеху является интеграция системы в общую стратегию проекта, постоянный мониторинг и адаптация к изменяющимся условиям.
Пандемия COVID-19 нанесла большой ущерб во многих сферах и привела к тому, что управление рисками стало ключевой задачей для многих компаний. Это заставило их пересмотреть существующие методы и внедрить новые технологии и процессы. Обзор текущих тенденций в управлении рисками показывает, что эта область активно развивается и полна инновационных идей на всех этапах реализации проекта.
]]> Матрица Эйзенхауэра: простой способ упорядочить свои дела http://neogenda.ru/blog/el61gccmo1-matritsa-eizenhauera-prostoi-sposob-upor http://neogenda.ru/blog/el61gccmo1-matritsa-eizenhauera-prostoi-sposob-upor?amp=true Tue, 27 Aug 2024 10:11:00 +0300 Андрей Сидоренко В жизни каждого сотрудника случаются дни, когда дела наваливаются, как снежный ком, и кажется, что...

Матрица Эйзенхауэра: простой способ упорядочить свои дела

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

Что такое матрица Эйзенхауэра

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

История матрицы Эйзенхауэра — почему она так называется

Матрица Эйзенхауэра названа в честь 34-го президента США Дуайта Эйзенхауэра, который известен не только своей политической карьерой, но и выдающимися способностями к управлению временем и приоритетами.
Одна из знаменитых цитат Эйзенхауэра хорошо иллюстрирует работу матрицы:
У меня есть два вида проблем: срочные и важные. Срочные не важны, а важные никогда не бывают срочными.
И хоть Эйзенхауэр подчеркивал, что важно различать срочные и важные задачи, чтобы не тратить время на второстепенные дела, официального подтверждения, что именно он создал матрицу, не было.
В 1984 году Лотар Зайверт (один из ведущих экспертов по тайм-менеджменту) впервые представил матрицу в своей книге «Ваше время — в ваших руках».
Но настоящую популярность этот метод начал набирать ближе к концу 1980-х, когда Стивен Кови (консультант по организационному управлению) включил его в свою известную книгу «Семь навыков высокоэффективных людей».

Как работает матрица

Матрица Эйзенхауэра помогает быстро распределить задачи по важности и срочности. Количество задач, которые можно оценивать, — неограниченно.
Чтобы расставить приоритеты, нужно сделать список из задач и ответить на два вопроса:
  1. Это важно?
  2. Это срочно?
И далее рассортировать их по таблице. Чтобы разобраться, давайте рассмотрим каждый квадрант подробнее.

Квадрант A

Квадрант А предназначен важных и срочных дел. Это те задачи, которые нельзя отложить на потом, потому что их задержка может привести к серьезным последствиям, например, задержки работы других команд, срыва дедлайнов, договоренностей с клиентом и др.
Сюда относят ЧП, авралы, критические проблемы в работе, горящие дедлайны, кризисные ситуации, проблемы со здоровьем и т.д.
Примеры таких задач:
  • Завершение проекта. Проект должен быть сдан в ближайшие сроки, чтобы избежать штрафов и недовольства клиента.
  • Встреча с клиентом. Например, встреча для разрешения конфликта, чтобы сохранить важного клиента.
  • Исправление серьезной ошибки в работе. Обнаружение ошибки в отчете или бага в работе приложения, который нужно срочно исправить.
Обычно в этом квадрате находятся 2-3 задачи. Это позволяет не терять фокус и доводить всю работу до конца.

Квадрант B

Блок включает важные, но несрочные задачи. Именно на эти дела следует тратить большую часть времени, потому что они способствуют долгосрочному успеху и развитию.
К таким задачам можно отнести планирование, обучение новых сотрудников, развитие навыков и т.д.
Вот несколько примеров задач из квадранта В:
  • Долгосрочное планирование. Разработка стратегии развития компании на следующий год.
  • Профессиональное обучение. Посещение курсов повышения квалификации или изучение нового иностранного языка.
  • Забота о здоровье. Регулярные физические упражнения и планирование здорового питания.

Квадрант C

Квадрант C включает в себя срочные, но не важные дела. Задачи в этом квадранте требуют быстрого реагирования, но не оказывают значительного влияния на достижение целей. Их можно делегировать или минимизировать.
Примеры таких задач: перерывы на телефонные звонки, срочные, но не важные встречи, мелкие организационные вопросы и т.д.
Какие задачи можно вписать в этот квадрат:
  • Ответ на не срочные запросы коллег. Помощь коллеге в подготовке к презентации, которая не является приоритетной для вашей работы.
  • Устранение мелких поломок в офисе. Замена лампочки или починка принтера.
  • Административные задачи. Заполнение форм, оформление документов, которые требуют быстрого выполнения, но не критичны.
Как правило, с такими задачами можно быстро справиться, например, делегировать или автоматизировать их. Или вовсе отказаться от таких дел, если это возможно. Например, ремонт техники в офисе можно поручить другому специалисту, настроить автоматические ответы на письма или отказаться от участия во встрече, на которой не нужно ваше присутствие.
Задачи из квадранта C не должны занимать большую часть вашего времени. Если они доминируют, это может привести к чувству недовольства и ощущению, что вы тратите время впустую. Лучше сосредоточиться на задачах из первых двух квадрантов.

Квадрант D

Эти задачи не способствуют достижению значимых целей и не требуют немедленного выполнения. Они могут отвлекать от более важных дел и часто являются пустой тратой времени.
К этим задачам относятся развлечения, рутинные, неважные задачи, просмотр социальных сетей и т.д. Например:
  • Любой развлекательный контент, как просмотр нового сериала или мемов про работу.
  • Наведение порядка в рабочих файлах или на рабочем столе — можно работать и без этого.
  • Прокрастинация, например, перекладывание бумаг, организация файлов, не приносящие реальной пользы.
Задачи из квадранта D не должны занимать большую часть вашего времени. Отдыхать и развлекаться — нужно, но в умеренных количествах. Хороший подход — оставить такие задачи на конец рабочего дня или на выходные. Это поможет расслабиться после продуктивной работы.

Как применять матрицу в тайм-менеджменте

Как найти баланс между всеми четырьмя квадрантами? Ответ прост — нужно научиться правильно распределять задачи по квадрантам.
Вот несколько советов, которые помогут правильно расставить приоритеты.
1. Записывайте абсолютно все задачи. Каждый день или неделю составляйте список задач. И не забывайте про дела, которые кажутся незначительными — так они не потеряются. Или вы просто откажитесь от них.
2. Планируйте порядок и сохраняйте гибкость. Если представить идеальный день работы по матрице, то у задач должен быть такой порядок:
  • сначала решаем задачи из квадранта B,
  • после переходим к срочным и важным задачам из квадранта A,
  • оставшееся время тратим на задачи из квадранта C,
  • и завершаем день приятными и расслабляющими делами из квадранта D.
Но в реальной жизни всё не может быть идти гладко. Поэтому обычно первым делом мы хватаемся за то, что горит — задачи из квадранта A. И дальше следуем рандомному порядку.
Отсюда делаем вывод: жизнь непредсказуема, и иногда планы могут меняться. Будьте готовы корректировать матрицу в зависимости от изменяющихся обстоятельств. Если что-то идет не по плану — не страшно. Но всё же старайтесь планировать свой следующий день согласно идеальному порядку.
3. Регулярно пересматривайте задачи. Тайм-менеджмент — это динамичный процесс. Регулярно пересматривай задачи в своей матрице, чтобы актуализировать приоритеты и убеждаться, что вы работаете над тем, что действительно важно.
4. Разбивайте крупные задачи на подзадачи. Большие проекты могут казаться непосильными. Разбивайте их на более мелкие подзадачи и распределяйте их по квадрантам. Так получится лучше контролировать процесс и продвигаться к цели шаг за шагом.
5. Не забывайте про делегирование. Некоторые задачи можно и нужно делегировать — особенно из квадранта C. Делегируйте их коллегам или подчиненным, чтобы сосредоточиться на более значимых задачах.
6. Соблюдайте баланс между работой и отдыхом. Важно не только эффективно работать, но и вовремя отдыхать. И хоть задачи из квадранта D могут показаться пустой тратой времени, но они также необходимы для поддержания баланса и восстановления сил. Нет ничего плохого в том, чтобы посмотреть сериал, прогуляться или полистать ленту в соцсетях в обеденный перерыв.
7. Используйте инструменты и сервисы для визуализации задачи. Последний совет в нашем списке, но не по важности. Существует множество приложений и программ для планирования — на любой вкус и цвет. Выберите понравившийся таск-трекер и визуализируйте задачи в нем. Внутри можно создавать карточки и расставлять приоритеты для каждой задачи. Это поможет организовывать дела, видеть объем предстоящей работы и получать напоминания о приближающихся дедлайнах.

Где построить матрицу Эйзенхауэра

Есть несколько вариантов.
На бумаге — в блокноте, тетради или на листе А4. Это самый простой способ построить матрицу. Сделайте список из ваших задач, а потом начертите таблицу с четкими границами.
В текстовом редакторе. Матрицу Эйзенхауэра можно легко построить в любом офисном редакторе, где можно создавать таблицы. Выбирайте тот, что есть у вас. В качестве примера мы сделали матрицу в Гугл Таблицах.
В графическом редакторе. Например, можете собрать квадраты с задачами в Figma или поискать готовый бесплатный шаблон матрицы на платформах как Canva, Supa, Desygner и других редакторах. Например, этот шаблон мы сами собрали в Фигме:
А этот — выбрали из готовых и отредактировали на сайте Canva:
Таск-трекеры. Если вы работаете в команде и вам нужно визуализировать задачи и их приоритеты, можно делать это в специальных сервисах. Но построить матрицу в них не получится. Как вариант, можете сортировать задачи в выбранном шаблоне матрицы, а потом переносить их на командную доску.
Таск-трекеров — очень много. Самыми популярными являются Trello, Jira и Asana, но они ушли с российского рынка. Есть множество российских аналогов: Kaiten, Yandex Tracker, YouGile, WEEEK, Битрикс24 и другие. Выбирайте тот, который покажется вам самым удобным.
Пример расстановки приоритетов в сервисе Kaiten

Заключение

Матрица Эйзенхауэра — один из инструментов тайм-менеджмента. С его помощью можно четко разделять задачи по важности и срочности, что позволяет фокусироваться на значимых делах.
Задачи разделяются на четыре квадрата:
  1. важные и срочные,
  2. важные и не срочные,
  3. не важные и срочные,
  4. не важные и не срочные.
Построить матрицу можно как на листе бумаги, так и в специальном редакторе. А расставлять приоритеты для задач удобнее в таск-трекерах.
Если вам требуется помощь с распределением приоритетов или организации командной работы по гибким методологиям — обращайтесь в Neogenda. Мы детально изучим потребности вашего бизнеса и предложим решение на бесплатной консультации в Zoom.
]]> Управление командой проекта: стратегии и методы для успешного выполнения проектов http://neogenda.ru/blog/ngk7aa71l1-upravlenie-komandoi-proekta-strategii-i http://neogenda.ru/blog/ngk7aa71l1-upravlenie-komandoi-proekta-strategii-i?amp=true Thu, 29 Aug 2024 10:18:00 +0300 Андрей Сидоренко Без надзора проектная команда скорее всего не выполнит работу как нужно. Проект выйдет за рамки...

Управление командой проекта: стратегии и методы для успешного выполнения проектов

Без надзора проектная команда скорее всего не выполнит работу как нужно. Проект выйдет за рамки либо требований, либо ресурсов, а чаще – всего сразу. Даже если над проектом трудится команда мечты, они будут сфокусированы на своих задачах, а не ходе проектных работ. Чтобы победил порядок, нужен проектный менеджер, который возьмет на себя ответственность за управление командой проекта.
Сначала проектные менеджеры говорят, что у них нет выгорания, а потом пишут такое
Расскажем обо всем последовательно:
  • какие роли есть среди команды проекта и его участников;
  • какие методы и инструменты управления командой используют прожженные проджекты;
  • какие существуют стили управления подчиненными и что из этого не будет считаться насилием;
  • как организовать управление командой и временем проекта;
  • как оценить эффективность управления командой проекта.
Если вашему бизнесу необходимо внедрение современных управленческих практик – обратитесь за бесплатной консультацией в Neogenda. На нашем счету работа с такими компаниями как Тинькофф, Сбер, Яндекс, Точка и X5 Group. Мы оказываем более 100 различных услуг: от обучения вашего персонала до реорганизации вашего бизнеса.

Роли команды и участников проекта

Прежде чем делиться тонкостями управления проектной командой, нужно знать, чем, собственно, она является и кто в нее входит.
Менеджер проекта – управленец, который занимается организацией проектных работ и несет ответственность за их успешное выполнение. «Успешно», значит в соответствии с требованиями и в рамках выделенных ресурсов.
Время вспомнить классику: кто, по вашему мнению, среди них проектный менеджер?
Команда проекта – это специалисты или группы специалистов, которые привлечены к выполнению работ по проекту и подчиняются менеджеру проекта. И все.
Это важно отметить: иногда к команде проекта относят владельцев бизнеса или его управляющих. Такая классификация неверна, поскольку проектный менеджер может лишь согласовать работы с ними, но не может давать им поручения.
Верно будет так: и проектного менеджера, и команду, и стейкхолдеров можно охарактеризовать как участников проекта. Владельцев бизнеса и управляющих извне можно отнести к стейкхолдерам – всем лицам, оказывающим влияние на проект извне. К стейкхолдерам можно отнести даже конкурентов, СМИ и клиентов, поскольку они тоже могут оказывать влияние на ход проекта – он может измениться от их требований.
Также можно выделить команду управления проектом. Это менеджеры проектов и их руководители: например, менеджеры портфелей проектов, которые ответственны за успешное проведение проекта. Такие команды часто встречаются в больших компаниях, где штат специалистов делится на отдельные подразделения, которые работают над большим количеством проектов. Там за проект могут отвечать несколько управленцев разного уровня ответственности.
Читайте также: Управление портфелем проектов: как устранить неразбериху в проектах вашего бизнеса
Теперь разберем методы и инструменты, которые применяет проектный менеджер при управлении командой.

Методы и инструменты управления командой проекта

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

Методы

  • Декомпозиция проекта и делегирование задач.
Главная организаторская задача проектного менеджера – разбить проект на отдельные задачи и поделить их между участниками команды. Благодаря этому становится понятнее, сколько ресурсов нужно на выполнение проекта и кто виноват, если в проекте что-то идет не так.
  • Приоритизация задач.
У участников проектной команды может быть несколько задач по проекту с разной степенью важности или срочности. Еще специалисты могут работать сразу на нескольких проектах организации.
Задача проектного менеджера – учесть всю нагрузку специалистов, оценить важность их отдельных задач и делегировать их таким образом, чтобы команда выполняла их последовательно в бюджетных и временных рамках.
  • Коммуникация.
Менеджер проекта много общается со всеми участниками команды. По большей части, через общение менеджер контролирует понимание и выполнение поставленных задач. Но иногда руководителю группы приходится выступать медиатором в конфликтах участников проектной группы. Поэтому хороший проектный менеджер должен уметь находить со всеми общий язык.
Типичный проектный менеджер и его типичные проблемы, которые решаются посредством качественной коммуникации
Сюда же можно отнести мотивацию и поддержку участников проектной группы. Хороший проектный менеджер должен быть лидером и коучем.

Инструменты

  • Таск-менеджеры для команды и программы для управления проектами.
Есть много сервисов, без которых уже не представить организацию проектных работ. В них можно указывать задачи, назначать им крайние сроки и ответственных, определять контрольные вехи проекта, следить за расходом ресурсов и многое другое. Многие из них поддерживают визуализацию работ над проектом в разных режимах одновременно, будь то календарь, канбан-доска или диаграмма Ганта.
В качестве примеров командных таск-менеджеров, доступных в России, можно привести WEEEK и Kaiten, Shtab и Yandex Tracker.
К примеру, так выглядит диаграмма Ганта в сервисе Yandex Tracker
  • Инструменты для составления майнд-карт и мудбордов.
Бывает, что проектному менеджеру нужно упорядочить разрозненную информацию для работы над проектом. В этих случаях хорошо использовать мудборды – белые доски, на которые можно лепить стикеры с текстом и изображениями, а также майнд-карты – схемы из блоков с текстом, соединенных между собой линиями. Наиболее популярными сервисами для этих задач являются MIro и Figma ~ у них есть бесплатные версии с ограничениями, но платные тарифы недоступны в России.
Так выглядит сервис Miro
  • Сервисы для коммуникации.
Сюда относятся как мессенджеры, такие как Telegram, так и сервисы для видеоконференций, такие как Google Meet. Иногда в командах используют корпоративные мессенджеры, такие как зарубежный Slack или отечественный Compass, чтобы не отвлекаться на посторонние чаты.
  • Облачные хранилища.
При работе над проектом зачастую собирается большое количество разнородной информации, которую лучше хранить в одном месте. Для текстовой информации зачастую используют Notion – он недоступен для оплаты в России, но есть бесплатная версия. Для разнородных файлов используют Google Drive или Яндекс Диск.
Рабочее пространство в Notion
С методами и инструментами разобрались – теперь коротко пройдемся по основным стилям управления подчиненными и подскажем, какой выбрать в той или иной ситуации.

Стили управления подчиненными: какой выбрать

Есть разные классификации стилей управления: поделимся, на наш взгляд, наиболее емкой и полновесной.
Глобально можно выделить три стиля управления подчиненными:
  • Авторитарный.
В этом случае проектный менеджер дает подробные инструкции для выполнения задач и пристально следит за ходом их выполнения. Задачи могут делиться на отдельные контрольные точки – достигнув их, исполнитель отчитывается менеджеру, чтобы тот принял работу.
Такой стиль хорош, если работать нужно с неопытными сотрудниками. Зачастую его используют тим-лиды, которые разбираются в своей специальности и могут глубоко декомпозировать задачи.
Например, тим-лид разработки может объяснить джуну, что и как конкретно нужно сделать. Проектный менеджер может не обладать навыками программирования, поэтому он может поставить задачу, только описав ее в общих чертах..
Главная проблема авторитарного стиля в том, что управлению нужно уделять много времени. Иногда таким стилем «грешат» – слишком контролируют опытных сотрудников, которые могут организоваться самостоятельно. Для такого излишнего контроля есть оскорбительное нарицательное – «микроменеджмент».
Думаем, что в школе все проходили через микроменеджмент
  • Демократический.
В этом случае участники проектной группы наделены большей свободой – они могут сами выбирать способы и инструменты решения задач, но ограничены крайними сроками и требованиями к задаче. Такой подход оптимален для специалистов среднего уровня, которых в простонародье кличут «мидлами». По сути верхнеуровневое описание задачи проектным менеджером относится к демократическому стилю управления.
  • Либеральный.
При использовании этого стиля проектный менеджер доносит в общих чертах, чего требуется достичь: будь то результат или KPI. Сроки, способы и ресурсы на выполнение задачи будет определять ее исполнитель. Такой метод делегирования можно использовать только при передаче задачи опытному специалисту. Например, проектный менеджер может делегировать фронт работ тимлиду, чтобы тот сам определил сроки, ресурсные рамки и способы решения задачи.
В иных случаях либеральный руководитель может делегировать весь проект: например, поручить настройку контекстной рекламы опытному контекстологу, который лучше разбирается в своей профессиональной деятельности. Он сможет рассчитать рекламный бюджет, время, необходимое на выполнение проекта, понять, с помощью каких видов кампаний продвигаться. Это куда лучше, чем постараться разобраться в рекламе самому и навязать исполнителю пагубные рамки, от которых пострадает эффективность выполнения проекта.
А теперь к самому интересному – расскажем, как в рамках пяти этапов ведения проекта организовать управление его командой.

Организация управления командой и временем проекта: 5 этапов

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

1 этап. Предварительная оценка проекта и сбор проектной команды.

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

2 этап. Декомпозиция проектных работ, точное определение бюджетных и временных рамок проекта.

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

3 этап. Организация работ и делегирование задач.

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

4 этап. Контроль хода работ по проекту.

Обязанность проектного менеджера – добиться от исполнителей своевременного и качественного выполнения задач. Для этого он должен заранее предусмотреть риски и устранить их, а еще устранять препятствия по ходу ведения работ над проектом.
Препятствия могут быть какими угодно: например, ссора между верстальщиком и дизайнером. Путей решения проблем много, поэтому их сложно описать в статье. Например, менеджер может выступать связующим звеном, передавая информацию от одного исполнителя к другому. Но будет лучше, если он сможет уладить конфликт, чтобы не тратить время на лишние коммуникации. А еще лучше, если менеджер сумеет предвидеть давний конфликт между исполнителями и не будет их ставить в один проект.
Совет: не забывайте давать позитивную обратную связь исполнителям. Например, по данным Achievers, 90 % исполнителей говорят, что если их хвалить, они будут работать лучше. По нашим наблюдениям, так и есть, – так что не стесняйтесь почаще хвалить исполнителей за успешное выполнение задачи. А если критикуете, то делайте это конструктивно и не переходите на личности.
Итак, работы выполнены и приняты заказчиком, остается последний этап – разбор полетов.

5 этап. Анализ выполнения проекта и архивация данных о его ходе.

Анализ нужен, чтобы избежать повторных ошибок в работе над новыми проектами. Поэтому важно хранить архивные данные о выполненных проектах: благо, такая возможность есть во всех популярных планировщиках задач для команды.
Также менеджеру стоит провести ретроспективу с проектной группой. На ней команда может обсудить ход проекта и понять, что было под контролем, а что – нет. Ретроспективы являются частью современных управленческих методов и фреймворков. Например, они есть в Scrum и в Канбан-методе.

Заключение

Управление командой проекта – не точная наука. Понимание и навыки проектного управления приходят с личным опытом. То есть, чтобы стать хорошим проектным менеджером, скорее всего вам придется вылететь за рамки пары-тройки проектов 🙂
Но если вы не можете позволить себе такую роскошь – обратитесь за бесплатной консультацией в Neogenda. Мы предоставляем разные услуги: от обучения ваших сотрудников лучшим управленческим практикам до полной реорганизации процессов вашего бизнеса.
]]> Пропускная способность: метрика производительности производственной системы, которая активно используется в Канбан Методе http://neogenda.ru/blog/1yxevpm9x1-propusknaya-sposobnost-metrika-proizvodi http://neogenda.ru/blog/1yxevpm9x1-propusknaya-sposobnost-metrika-proizvodi?amp=true Thu, 19 Sep 2024 10:22:00 +0300 Алексей Пименов Пропускная способность (Throughput) – это метрика, которая используется для оценки производительности производственной системы или команды....

Пропускная способность: метрика производительности производственной системы, которая активно используется в Канбан Методе

Пропускная способность (Throughput) – это метрика, которая используется для оценки производительности производственной системы или команды. Пропускной способностью называют количество рабочих элементов (задач, эпиков, историй), которые покидают вашу произвоственную систему за определенный промежуток времени: например, неделю. Скажем, если команда выполнила 5 задач за рабочую неделю, ее пропускная способность – пять.
Эту метрику используют в современном Канбан Методе, который используется для эволюционного улучшения процессов за счет анализа, визуализации, работы с рисками и других инструментов. Измерение пропускной способности дает представление о производительности вашей производственной системы.
Пропускная способность производственной команды по дням: по вертикали измеряется количество выполненных задач. На диаграмме можно заметить промежутки по два дня, во время которых задачи не закрываются – это выходные
Далее в статье:
  • зачем измеряют пропускную способность;
  • как измерить пропускную способность;
  • как улучшить пропускную способность;
  • как подделывают данные пропускной способности.
Если вам необходимо внедрение современных управленческих практик – обратитесь в Neogenda. За нами более 100 успешных управленческих кейсов и более 5 000 обученных сотрудников в таких компаниях, как Tinkoff, Яндекс, Авито, Сбер, Билайн, Skyeng и так далее. Оставьте заявку на бесплатную консультацию – мы предложим индивидуальное решение, с которым ваша команда достигнет лучших результатов.

Зачем измеряют пропускную способность

Показатель пропускной способности в динамике наглядно демонстрирует производительность производственной системы. Он не изменится от роста количества запущенных проектов проектов, потому что ваши команды не начнут от этого завершать больше задач. Это темп работы, зная который, можно принимать ряд решений:
  • Управлять нагрузкой. Например, маленькое веб-агентство, которое делает сайты для клиентов, может отслеживать пропускную способность, чтобы понимать, сможет ли оно взять еще один проект в работу или нет.
  • Строить прогнозы объема завершения. Зная пропускную способность и объем задач в текущих проектах, можно более-менее точно построить прогноз касаемо завершения запросов. Чтобы построить прогноз с вероятностью в 100 % по каждому запросу, нужно знать еще и распределение времени производства, времени от попадания запроса в производственную до ее выполнения. Это еще одна ключевая метрика в Канбане, которую часто путают с пропускной способности.
  • Начать работать над увеличением пропускной способности. Усредненный показатель пропускной способности можно и нужно улучшать. Чтобы ставить реалистичный KPI по его оптимизации, нужно знать текущий уровень и тестировать гипотезы, направленные на его улучшение.
Теперь разберемся, как измерить показатель пропускной способности и какие можно сделать выводы из этих измерений.

Как измерить пропускную способность

Средняя пропускная способность – один из наиболее точных подходов к отслеживанию производительности рабочего процесса. Для того, чтобы анализировать метрику, используют гистограмму пропускной способности.
Чтобы наглядно продемонстрировать гистограмму, возьму данные из предыдущей таблицы и составлю на их основе то, что нам нужно.
Такой получилась гистограмма пропускной способности
Эта гистограмма содержит следующие данные:
  • По горизонтали: количество задач, которые закрывает команда за день или другой промежуток времени. Названия столбиков (0, 3, 4, 5 и т.д.) – это количество задач, которые команда закрыла за временной период. Например, в один день команда закрыла 5 задач – этот и другие дни будет включать в себя столбец «5».
  • По вертикали: количество раз (например, дней), когда команда закрывала определенное количество задач. Видно, что у столбца «5» показатель 7 – дни, когда команда выполняет такое количество задач, случаются часто. Чаще только дни, когда команда выполняет 0 задач – такое было 8 раз. Это выходные, в которые команда не выполняла задачи – на прошлой диаграмме эти дни были без столбцов.
Как вы понимаете, гистограмму можно строить по разным срезам: по дням, неделям и т. д. Полезно знать среднюю пропускную способность, рассчитанную как с учетом выходных, так и без них. Включение выходных даст вам точное значение пропускной способности для расчета за более длительные периоды времени. Их исключение даст более точное среднее значение пропускной способности для типичного рабочего дня.
Продолжая разбирать пример, будем считать, что если не учитывать выходные, команда чаще всего выполняет 5 задач в день, поскольку это самый большой столбец на гистограмме. В целом да, но вам могут встретиться и диаграммы с более неоднозначными диапазонами набора данных. Тогда вам понадобится рассчитывать среднее значение гистограммы.
Существует 3 вида средних значений, знакомых нам из школьной алгебры:
  • Мода – это число, которое повторяется чаще всего на гистограмме (имеет самый высокий столбец). Помним, что мы не учитываем выходные: тогда в нашем случае это «5».
  • Медиана – это среднее число набора данных. Например, в наборе значений (2, 4, 8, 10, 12) это будет 8. В нашем случае это снова «5», так как 5 – среднее значение в своем наборе (3, 4, 5 , 6, 7).
  • Среднее арифметическое – это сложение общего количества задач и деление его на количество дней. В нашем случае это 128 / 25 = 5,12 задач на рабочий день.
То или иное среднее нужно использовать, исходя из данных на гистограмме. Если на гистограмме нет явно лидирующего столбца, считайте среднее арифметическое. Если разброс данных примерно одинаковый в обе стороны, используйте медиану. Если один показатель сильно выше других, выбирайте средним показатель моды.
Пропускную способность можно и нужно смотреть не только у организации в целом, но и у отдельных сотрудников, департаментов и так далее. Средней пропускной способности «по больнице» может не хватить для детального анализа и принятия взвешенных решений.
А теперь о самом интересном: как улучшить пропускную способность, чтобы ваша производственная система стала более производительной.

Как улучшить пропускную способность

Если исходить из теории ограничений Голдратта, пропускная способность производственной системы равна или меньше теоретической пропускной способности ее слабого звена. Следовательно, чтобы улучшить общую пропускную способность, нужно искать слабое звено производственного процесса. Слабое звено называют ресурсом ограниченной мощности.
Пример ресурса ограниченной мощности: этап процесса, на котором специалисты не успевают обработать все рабочие элементы, которые до них доходят. Из-за этого процесс всей системы будет тормозиться до скорости обработки рабочих элементов специалистами на это этапе.
Ресурс ограниченной мощности не получится найти в статике: нужно смотреть в динамике, изучая историю изменений количества рабочих элементов скопившихся на том или ином этапе. Для выявления слабого звена используют накопительную диаграмму потока. На ней видно, как изменяется количество общих рабочих элементов в системе – карточек на разных этапах канбан-доски.
Видно, что в розовая и красная область диаграммы со временем становится толще – на этих этапах скапливаются задачи. Но узкое звено — это этап который идет сразу следом за последним этапом где скапливаются задачи. В данном примере — это синяя область, пусть это будет этап тестирования. А красная область — это очередь задач на тестирование, которая постоянно растет
После того, как узкое звено выявлено, нужно работать над ростом его пропускной способности до его теоретически возможной. Для этого необходимо избавить узкое звено от неспецифичной работы. Например, если узкое звено — это этап тестирования, то надо рассмотреть, какую деятельность, которую делают тестировщики мы могли бы передать на специалистов с другого этапа нашего производственного процесса. Таким образом мы выведем на максимум пропускную способность в рамках тех ресурсов, которыми мы располагаем.
Следующим шагом можно расшить узкое звено — например, можно нанять еще одного специалиста, или купить дополнительное оборудование, но стоит помнить, что расшив узкое звено в одном месте — оно переместится в другое и дальше вам надо осознать — избавиться от узкого звена нельзя, но можно его перемещать по производственной системе и мы могли бы найти такую конфигурацию, при которой пропускная способность системы станет удовлетворять нашу потребность или управляемость системы с такой конфигурацией узкого звена станет для нас удобной.
Помните, пропускная способность чувствительна к количеству ресурсов в вашей производственной системе. Наняв людей на определенный этап или добавив дополнительное оборудование вы будете завершать больше рабочих элементов в единицу времени, но это никак не повлияет на длительность реализации каждого рабочего элемента в отдельности.

Манипуляции с пропускной способностью

Пропускная способность — это метрика, которую достаточно легко взломать. Например, к вам приходит большой проект и вы его разбиваете на задачи и измерение пропускной способности у вас идет по задачам. Если вы поменяете механизм декомпозиции и порежете проект на большее количество мелких задач — ваша пропускная способность увеличится. Однако это никак не скажется на пропускной способности вашей производственной системы в проектах.
Если вы хотите, чтобы ваши подчиненные менеджеры и специалисты не манипулировали пропускной способностью, то замеряйте ее для сущностей, которые имеют реальную ценность для клиентов. Мы называем такие сущности — рабочий элемент распознаваемый заказчиком. Заказчик посмотрев на вашу доску и увидев там задачи может ничего не понять о том, что это, какое это имеет отношение к нему и что он получит, как только задача будет решена — это значит, что задача не является рабочим элементом распознаваемым заказчиком. Но вот проект, скорее всего его принес заказчик и именно если реализовать проект, то заказчик будет счастлив и будет снята какая-то его боль, поэтому проект — это рабочий элемент распознаваемый заказчиком.
Всегда измеряйте пропускную способность по рабочим элементам распознаваемым заказчиком.
В заключение хотим поделиться ссылками на видео на YouTube нашего эксперта – Алексея Пименова, автора книги «Канбан Метод. Базовая практика». Чтобы еще лучше разобраться в работе с пропускной способностью, а также Канбан-методом в целом, рекомендуем к просмотру видео «Производственный процесс глазами Канбан-практика» и «Работа с узкими звеньями процесса».
А если вам необходимо профессиональное внедрение современных управленческих практик – обратитесь за бесплатной консультацией в Neogenda.
]]> Этапы разработки проекта: как превратить ожидания в реальность http://neogenda.ru/blog/evb5rn0gp1-etapi-razrabotki-proekta-kak-prevratit-o http://neogenda.ru/blog/evb5rn0gp1-etapi-razrabotki-proekta-kak-prevratit-o?amp=true Thu, 19 Sep 2024 10:31:00 +0300 Андрей Сидоренко Представьте, что проект — это видеоигра. Перед вами лежит захватывающий, но непредсказуемый путь, полный загадок,...

Этапы разработки проекта: как превратить ожидания в реальность

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

Что такое жизненный цикл проекта

Все проекты имеют начало и конец — это и называют жизненным циклом.
Жизненный цикл — это последовательность этапов, через которые проходит каждый проект. После окончания цикла команда получает конкретный результат: работающий продукт, его функцию, услугу и т.д.
С пониманием жизненного цикла команда сможет:
  • структурировать задачи и грамотно распределить ресурсы;
  • отслеживать ход работы на каждом этапе;
  • вовремя обнаруживать и устранять проблемные места;
  • быстрее работать в сжатые сроки;
  • минимизировать риски.
Количество этапов может варьироваться в зависимости от специфики проекта и его масштаба. Но существует общая классификация этапов разработки, через которые проходят все проекты.
Институт управления проектами (PMI) выделил такие фазы жизненного цикла проекта как:
  1. Инициация.
  2. Планирование.
  3. Исполнение.
  4. Оценка эффективности.
  5. Завершение.
Основные этапы проекта
Давайте рассмотрим стадии проекта подробнее.

Инициация

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

Ключевые задачи

⭐ Определить бизнес-цели и критерии успеха. Они являются фундаментом проекта. Важно понять, какие проблемы клиента или бизнеса решает проект. Критерии успеха помогут оценить достигнуты ли цели на последнем этапе — завершении.
⭐ Сформировать команду и назначить владельца продукта (Product Owner). Определите, кто будет руководить проектом, кто будет принимать решения и кто будет отвечать за доставку ценности.
⭐ Собрать первоначальное видение продукта (Product Vision). Это краткое описание конечного результата проекта: каким будет продукт, как он будет использоваться и какую ценность принесет.
Вопросы для этого этапа
  • Что нужно достичь? Почему этот проект важен?
  • Какой конечный результат мы ожидаем?
  • Что входит в проект, а что нет? Какие задачи решаются в рамках этого проекта, а какие оставляются на потом?
  • Кто участвует в проекте? Кто будет влиять на него, и кого он затронет?
  • Какие ресурсы нам понадобятся? Каков наш бюджет? Откуда мы будем брать необходимые ресурсы?
  • Какие проблемы могут возникнуть? Как их решать?

Советы для успешного завершения этапа инициации

  • Соберите команду и организуйте встречу, где каждый сможет высказать свои идеи и предложения. Для этого отлично подойдет вариант мозгового штурма.
  • Разделите обязанности и назначьте ответственных за различные аспекты проекта. Так каждый будет знать, за что он отвечает.
  • Определите, как и когда вы будете общаться. Регулярные встречи и отчеты помогут держать всех в курсе дел.
  • Создайте документацию по проекту, чтобы все участники имели доступ к важной информации и могли легко ее найти.
  • Будьте готовы к изменениям. Проекты редко идут по плану, поэтому будьте гибкими и готовыми адаптироваться к новым обстоятельствам.

Планирование

Планирование (Planning) — это этап, на котором создается подробный план действий: устанавливаются задачи, распределяются ресурсы и определяется график выполнения.
Если провести аналогию с видеоигрой, это подготовка к миссии: прокачка персонажа и сбор снаряжения. Нельзя же отправляться в путешествие неподготовленным, правда?
Цель этапа: команда должна детально продумать, как будет реализован проект. Важно не просто составить список задач, но и определить приоритеты.

Ключевые задачи

⭐ Оформить устав проекта. Команда должна создать устав проекта — краткий документ, который официально утверждает начало проекта. Это его визуальное представление.
Устав фиксирует цели, задачи, сроки реализации проекта и ресурсы, а также определяет ответственных. Это поможет всем участникам понять, что нужно сделать и в каких рамках работать.
Оформить его можно в любом удобном виде — собрать в документе, таблице или заполнить готовый шаблон.
Устав проекта — шаблон
⭐ Создать бэклог продукта. Бэклог — это список всех задач, идей и функций, которые нужно выполнить в рамках проекта. Его можно сравнить с написанием списка покупок перед походом в магазин, чтобы ничего не забыть.
⭐ Определить приоритеты задач. Не все задачи одинаково важны. Нужно понять, что следует выполнить в первую очередь, а что — отложить. Например, лучше начать с задач, которые принесут бизнесу пользу на ранних этапах.
⭐ Запланировать первый спринт. Спринт — это короткий временной промежуток (1-2 недели), в течение которого Скрам-команда выполняет запланированные задачи. Если команда только начинает работать по Scrum, лучше подробно распланировать первый спринт — задачи должны быть четко определены, выполнимы и важны.

Как провести планирование

Чтобы планирование прошло гладко, учтите следующие моменты.
1. Связанные задач
Все задачи взаимосвязаны. Команда должна определить, какие задачи следует выполнять сначала, а какие могут идти параллельно .Например, перед тем как начинать дизайн сайта, нужно утвердить концепцию и написать текст. Для этого можно создать цепочку выполнения задач, используя диаграмму Ганта.
Пример связанных задач на диаграмме Ганта на примере сервиса Kaiten
2. Простановка дедлайнов
Оцените временные затраты: сколько займет выполнение каждой задачи, учитывая ресурсы, сложность и возможные риски. Затем установите дедлайны — крайние сроки выполнения задач. Это поможет управлять временем и следить за прогрессом проекта.
Пример указанных дедлайнов в карточках на примере сервиса WEEEK
3. Назначение ответственных сотрудников
Всем задачам нужно назначить ответственного. Важно, чтобы каждый сотрудник знал свою зону ответственности и к кому можно обратиться за помощью. Задачи распределяйте с учетом навыков и опыта сотрудников для максимальной эффективности.
4. Установка вех
После того как все задачи визуализированы и распределены по срокам и ответственным, можно расставить вехи — контрольные точки.
На примере с играми это чек-поинты. Т.е. игрок проходит уровень и добегает до точки сохранения, где может перевести дух.
Вехи проекта (milestones) — это важные этапы развития проекта, которые отмечают значимые достижения в работе. Например, «Готовность прототипа» или «Запуск бета-версии». Они помогают отслеживать, насколько успешно продвигается проект.
Каждая веха должна быть напрямую связана с важными целями проекта. Вехи помогают команде понять, что именно нужно достичь на каждом этапе, и дают возможность вовремя скорректировать курс, если что-то пошло не так.

Вопросы для планирования

  1. Какие задачи нужно выполнить для достижения целей проекта?
  2. Как разбить проект на конкретные шаги и этапы?
  3. Какие ресурсы понадобятся на каждом этапе?
  4. Как расставить приоритеты задач?
  5. Что нужно сделать в первую очередь, а что может подождать?
  6. Какие вехи определить для проекта? Какие этапы или события будут считаться важными достижениями?
  7. Как распределить задачи между членами команды?
  8. Каков график выполнения задач и когда, например, должны быть завершены этапы проекта?

Советы для планирования проекта

  • Разбейте проект на этапы и задачи. Представьте проект как большой пазл: разделите его на небольшие части, чтобы легче было собрать.
  • Создайте подробный план-график. Используйте диаграммы Ганта или другие инструменты, чтобы визуализировать стадии проекта, кто и когда выполняет задачи и т.д.
  • Определите ключевые показатели эффективности (KPI). Задайте метрики для отслеживания прогресса и успеха проекта.
  • Обеспечьте участие всех заинтересованных сторон. Привлекайте ключевых участников к планированию, чтобы учесть их мнения и ожидания.
  • Будьте готовы к корректировкам. Планы — это не высеченные законы на камне. Внесение изменений по мере развития проекта — нормальная практика.
Исполнение (Execution) — реализация проекта. Это этап, на котором команда выполняет запланированные задачи, создавая и поставляя продукт или услугу в соответствии с требованиями. Можно сказать, что это сердце любого Agile-проекта.
На примере игры этот этап, как прохождение уровней и выполнение квестов. Каждый уровень — это новый спринт, где решаются конкретные задачи. И для каждой задачи нужен свой подход и специальные навыки.
Цель этапа: превращать идеи в реальность. Команда выполняет задачи, запланированные на предыдущем этапе, и на каждом шаге приносит реальную пользу бизнесу.

Ключевые задачи

⭐ Реализация задач спринта. Команда берет задачи из бэклога, запланированные на текущий спринт, и выполняет их. Важно, чтобы задачи были разбиты на небольшие части, которые можно завершить за спринт. Например, задача «создать новый экран в приложении» может быть разделена на дизайн, верстку, тестирование и другие этапы.
⭐ Проведение ежедневных встреч. Это короткие планерки (10-15 минут), где команда обсуждает, что сделано вчера, что предстоит сегодня и есть ли препятствия. Встречи помогают держать руку на пульсе и быстро реагировать на изменения. Если обсуждать нечего — встречу лучше пропустить, чтобы не тратить время впустую.
⭐ Непрерывное взаимодействие с командой и владельцем продукта. Agile — это про гибкость, поэтому нужно постоянно общаться с продакт-оунером, чтобы убедиться, что команда движется в правильном направлении. Например, если выясняется, что нужно срочно добавить или изменить функционал, команда может оперативно это обсудить и внести правки.

Вопросы, на которые нужно ответить на этапе исполнения

  • Кто отвечает за конкретные действия и этапы проекта?
  • Какие инструменты и методы нужно использовать для мониторинга выполнения задач?
  • Как реагировать на изменения или непредвиденные обстоятельства?
  • Как проверять и контролировать качество выполняемых задач и конечного продукта?
  • Как решать возникающие проблемы? Есть ли план действий на случай задержек или неполадок?

Советы для успешного исполнения

1. Проводите встречи
В Agile существует несколько видов встреч, которые помогают своевременно собирать обратную связь. Одна из ключевых — ежедневная встреча (Daily Scrum).
Удерживайте встречу в рамках структуры: каждый участник отвечает на три вопроса — что сделал вчера, что собирается делать сегодня и есть ли какие-то проблемы. Это помогает всем быть в курсе и быстро решать возникающие вопросы.
2. Используйте визуальные инструменты
Канбан-доска — отличный способ визуализировать, на каком этапе находится каждая задача. Она помогает команде видеть прогресс и понимать, что еще предстоит сделать.
Пример работы с задачами проекта на Канбан-доске на примере сервиса Trello
Также для отслеживания эффективности используйте Agile-метрики и графики. Например, один из таких — Burndown Chart — это график, который показывает, сколько задач осталось выполнить до конца спринта. Это помогает команде оценивать, укладываются ли они в сроки.
Пример Диаграммы сгорания задач
3. Адаптируйтесь к изменениям
В Agile важно уметь быстро реагировать на новые требования или изменения в приоритетах. Если команда сталкивается с неожиданными проблемами или новыми идеями, не бойтесь менять планы.
Например, если в середине спринта становится ясно, что текущий дизайн не работает, лучше внести изменения сразу, чем ждать конца спринта.
4. Общайтесь открыто и прозрачно
Держите всех участников проекта в курсе дел, делитесь успехами и проблемами, чтобы совместно находить решения.

Оценка эффективности

Следующий этап развития проекта — оценка эффективности, или мониторинг и контроль (Monitoring and Controlling).
Если провести аналогию с игрой, то это момент, когда нужно поставить игру на паузу и проверить прогресс: сколько квестов выполнено, какие еще остались, не пора ли улучшить снаряжение или прокачать новые навыки. Если что-то идет не так — например, игрок не справляется с боссом, — можно вернуться к прошлому сохранению или изменить тактику.
Цель этапа: убедиться, что проект идет по плану. Если возникают отклонения, важно вовремя их обнаружить и исправить. В Agile мониторинг и контроль — это не строгий надзор, а гибкость и готовность адаптироваться к изменениям, сохраняя фокус на конечной цели.

Ключевые задачи

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

Вопросы для этапа оценки эффективности

  1. Достигли ли целей проекта? Насколько успешно выполнены задачи и достигнуты запланированные результаты?
  2. Были ли соблюдены временные рамки и бюджет? Уложились ли в сроки и бюджет?
  3. Каково качество конечного продукта? Удовлетворены ли требования и ожидания заинтересованных сторон?
  4. Какие проблемы возникли и как команда их решала? Какие трудности встретились на пути и как удалось с ними справиться?
  5. Что можно улучшить в будущем? Какие уроки извлекла команда и как их можно применить в следующих проектах?

Советы для этого этапа

1. Используйте Agile-метрики
Метрики — это не просто цифры, а инструмент для понимания прогресса. Например, отчет Velocity (скорость команды) показывает, сколько задач команда может завершить за один спринт. Это помогает точнее планировать будущие спринты.
2. Анализируйте данные
Помимо графиков, анализируйте KPI и другие показатели эффективности, которые были установлены в начале проекта. Это поможет объективно оценить результаты.
3. Будьте готовы к изменениям
Если в ходе выполнения задач становится ясно, что какие-то из них требуют больше времени или ресурсов, не бойтесь адаптироваться. Это может включать изменение приоритетов или перераспределение задач между членами команды. Важно обсуждать любые изменения с командой и Product Owner, чтобы все были в курсе и могли оперативно реагировать.
4. Регулярно собирайте обратную связь
Промежуточные ретроспективы или короткие встречи в середине спринта помогают вовремя выявить проблемы и внести корректировки. Например, если кто-то из команды сталкивается с трудностями, это можно обсудить и перераспределить нагрузку.
5. Проводите итоговые встречи
Соберите команду, чтобы обсудить результаты проекта, поделиться успехами и определить области для улучшения.

Завершение

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

Ключевые задачи

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

Вопросы для этапа закрытия проекта

  1. Закрыты ли все запланированные задачи и цели?
  2. Собраны ли финальные отчеты, включая все ключевые данные и результаты?
  3. Переданы ли результаты и документы заказчику или заинтересованным сторонам?
  4. Проанализированы ли успехи и неудачи? Сделаны ли выводы для будущих проектов?

Шаги для успешного завершения проекта

  1. Составление финального отчета. Включите в отчет все важные аспекты: достижения, проблемы, решения и выводы.
  2. Организация финальной ретроспективы. Проведите встречу совместно с командой и заинтересованными сторонами, чтобы обсудить результаты и получить обратную связь. Важно, чтобы каждый участник мог высказаться, а все предложения по улучшению были зафиксированы.
  3. Сравнение результатов с целями проекта. Проанализируйте, насколько конечный продукт соответствует изначальным требованиям и ожиданиям. Если какие-то цели не были достигнуты, обсудите причины и возможные решения. Например, если сроки были нарушены из-за недостаточной оценки сложности задач, в будущем можно уделить больше внимания этапу планирования.
  4. Передача документов и результатов. Убедитесь, что все необходимые документы и результаты переданы заказчику или заинтересованным сторонам.
  5. Оценка работы команды. Оцените вклад каждого участника, поблагодарите за работу и обсудите возможности для дальнейшего сотрудничества.
  6. Подготовка плана для будущих проектов. На основе полученных данных и опыта составьте рекомендации и планы для улучшения работы в будущих проектах.

Коротко о главном

Жизненный цикл проекта — это последовательность этапов, которые проходит проект от начала до завершения.
Согласно PMBOOK основные этапы проекта это:
  1. Инициация — это старт проекта, где важно четко определить цели, вовлеченных лиц и границы проекта. Успешная инициация закладывает фундамент для всей дальнейшей работы.
  2. Планирование — на этом этапе команда детально прорабатывает задачи, расставляет приоритеты и планирует спринты. Здесь важно понять, что и когда будет делаться, чтобы избежать хаоса и задержек.
  3. Исполнение — этап, на котором происходит основная работа. Команда реализует задачи, проводит ежедневные встречи и оперативно реагирует на изменения. Главное — поддерживать темп и гибкость.
  4. Оценка эффективности — команда следит за прогрессом и своевременно корректирует план, если что-то идет не так. Также на этом этапе используются метрики и собирается обратная связь.
  5. Завершение — финальный этап, на котором команда подводит итоги, оформляет документацию и передает готовый продукт. Это время для ретроспективы и обсуждения хороших и плохих ситуаций в работе над проектом, чтобы улучшить рабочие процессы.
Небольшая шпаргалка: этапы работы над проектом и их краткое описание
Если вам нужна помощь в визуализации этапов проекта и организации работы по Scrum — обратитесь в Neogenda. Оставьте заявку на бесплатную консультацию, и мы предложим эффективное решение на бесплатной консультации в в Zoom.
]]> Система грейдов в IT: в чем разница между джуном, мидлом и сеньором и есть ли другие уровни у программистов http://neogenda.ru/blog/l9cjvmjiy1-sistema-greidov-v-it-v-chem-raznitsa-mez http://neogenda.ru/blog/l9cjvmjiy1-sistema-greidov-v-it-v-chem-raznitsa-mez?amp=true Tue, 24 Sep 2024 14:04:00 +0300 Андрей Сидоренко Системы грейдов есть в разных отраслях: взять хоть тех же сварщиков с их разрядами или...

Система грейдов в IT: в чем разница между джуном, мидлом и сеньором и есть ли другие уровни у программистов

Системы грейдов есть в разных отраслях: взять хоть тех же сварщиков с их разрядами или даже каратистов с поясами. Кто-то однажды придумал, что есть разработчики уровней junior, middle и senior.
Но градация субъективна: известны случаи, когда человек сидел над одним проектом и был его почтенным сеньором, а потом мог устроиться в более технологичную компанию и стать там джуном.
Так давайте же разберемся:
  • зачем тогда разработчикам в компаниях присваивают грейды;
  • какие грейды есть;
  • как выстроить систему грейдов для разработчиков у себя: подскажем ряд советов.
Но для начала расскажем о себе. Neogenda – это консалтинговая компания. Мы помогаем компаниям освоить современные подходы и методы менеджмента. Наши клиенты – это Сбер, МТС, Тинькофф, Билайн, Raiffeisen Bank, Магнит, Яндекс, Авито, Азбука Вкуса и другие компании, которые вам скорее всего тоже известны. На нашем счету более 100 управленческих кейсов, 5 000 учеников и 40 лет практики. Если вы считаете, что ваш бизнес может стать прибыльнее за счет грамотного внедрения современных управленческих практик – обратитесь за бесплатной консультацией в Neogenda.
Пика-Пика!

Зачем разработчикам в компаниях присваивают грейды

  • Чтобы оценить стоимость работы сотрудника. От грейда может зависеть месячный оклад или стоимость часа работы программиста. Зная грейд, вы сможете платить сотруднику достойно, не тратя слишком много средств или не демотивируя сотрудника маленькой оплатой.
  • Чтобы удерживать сотрудников. Как правило, системы грейдов внедряют в крупные компании, где будут десятки, а то и сотни разработчиков. Если компания растет, штат нужно расширять: через годы позиции старших сотрудников часто занимают бывшие джуны. Система грейдов дает четкое понимание сотрудникам, что они могут в компании идти дальше по карьерной лестнице. Это помогает удержать сотрудников, потому что найти хороших разработчиков не так-то просто. А оперативно найти замену разработчику, который покидает рабочее место и оставляет горящий проект, еще сложнее.
  • Чтобы формировать эффективные проектные группы. Если к системе грейдов привязан тест, который позволяет оценить навыки разработчика, управленцы в компании могут объективнее оценить свой кадровый состав. С этим они могут эффективнее собирать группы под конкретные проекты. Такие команды обаладают всеми нужными навыками и укладываются в проектные рамки, потому что там нет чересчур опытных специалистов с избыточными знаниями, которые стоят дорого.

Какие грейды есть

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

Junior

Чем-то похожи, да?
Джуны (Junior-разработчики) – это специалисты с небольшим практическим опытом, которые могут выполнять только несложные задачи. Например, написать какой-то небольшой участок кода.
Джуны всегда получают задачи от более опытных сотрудников и чаще всего за джунами эти задачи проверяют, потому что они с большой вероятностью могут ошибиться.
Если говорить о кодинге, то у джунов часто получается тяжелый синтаксис кода, потому что они еще не умеют элегантно решать поставленные задачи. Если джун совсем неопытный, его лучше «помикроменеджерить»: ставить больше контрольных точек для проверки задач и направлять в нужное русло. Джун не умеет мыслить в рамках системы, поэтому нужно помочь ему сделать так, чтобы его работа встала нужным элементом в общую мозаику.
По большей части, джуны – это инвестиции в компанию. На них приходится тратить время старшим сотрудникам, а еще джуны будут медленнее справляться с задачами, нежели более опытные разработчики. С другой стороны, мидлы могут быть сами по уши в задачах и декомпозиция задач на джунов – меньшее зло. Чтобы джуны отрабатывали эффективнее, к каждому из них лучше приставить ментора – так они будут быстрее обучаться и брать все на себя более сложные задачи.
Есть и большое преимущество джунов: они становятся очень лояльными к организации, если их обучают, а еще если им обеспечивают достойные условия и сулят карьерный рост. Порой компании проще вырастить джуна «под себя», нежели искать специалиста со стороны, который всегда может «свинтить» из-за оффера послаще.
Главные качества, которые должны быть у джуна – большой интерес к работе и высокая обучаемость. Ну, и разумеется, развитые софт-скиллы – без чужой помощи он вряд-ли задержится на рабочем месте. Если это все есть, после пары лет упорной работы он сможет стать уверенным мидлом в своей компании. Для этого ему нужно пару раз пройти полный цикл разработки, чтобы наступить на всевозможные «грабли», которые учтет мидл с более богатым практическим опытом.
👉 Читайте также: «Управление командой проекта»

Middle

Именно мидлы зачастую проверяют и менторят неопытных джунов
Мидлы (Middle-разработчики) – это специалисты среднего уровня, которые могут брать на себя достаточно сложные задачи. Если за джунами нужно приглядывать, мидлы способны сами себя организовывать и доводить задачу до нужного результата. Они хорошо разбираются в технологиях своего стека и пишут более качественный код. Также специалисту такого уровня под силу изучить какие-то новые технологии, если это нужно для выполнения проекта.
Разработчик уровня Middle способен находить разные способы решения задач. Поэтому подробные ТЗ могут даже навредить эффективности выполнения задачи. Другое дело, что мидл скорее всего не сможет предложить лучшее архитектурное решение для выполнения проекта.
Зачастую хорошие разработчики так и остаются мидлами, потому что они не хотят брать на себя ответственность за стратегические решения. А те, кто не боятся – становятся сеньорами.

Senior

Хм, а может быть граф?
Сеньор (Senior-разработчик) – это специалисты высокого уровня, которые могут решить любую задачу, если та касается их профессиональных навыков. Но кодинг – это то, чем старшие специалисты занимаются меньше всего.
Сеньоры руководят процессом: помогают разрабатывать требования, проектируют архитектуру ПО, участвуют в переговорах с заказчиком, помогают рассчитать бюджетные и временные рамки и так далее. И при необходимости такой спец мог бы в одиночку разработать проект с нуля, но у него есть дела поважнее.
Если сеньор вдруг добирается до среды разработки, начинается магия: из под клавиш вылетает простой и легко читаемый код. Легкий синтаксис сеньора – полная противоположность коду джуна-зазнайки, который чему-то научился и думает, что теперь знает все, выдавая высокоуровневые абстракции. Опытный разработчик знает, что код нужно писать для других людей, чтобы его удобно было обслуживать и масштабировать.
Новички думают, что сеньоры – это такие крутые хакеры, которые используют самые современные инструменты, работая исключительно над интересными проектами. Но реальность чаще противоположна – сеньоры поддерживают легаси-код больших и сложных сервисов, существующих не один год. Делая это просто потому, что никто на это больше не способен. При этом синьоры все равно держат руку на пульсе – технологии и практики находятся в постоянном развитии, и если не быть в теме, можно через пару лет обнаружить себя в мидлах.
Но софт-скиллы куда важнее для сеньора, нежели хард-скиллы. Ведь большая часть работы старших специалистов состоит не из кодинга, а из составления требований к работе над ПО, переговоров и менторинга. Самое главное качество сеньора – способность чувствовать себя комфортно в среде с высокой неопределенностью. В отличие от мидла, сеньор не боится рисковать и способен брать на себя большую ответственность.
С сеньорами прояснили, теперь поговорим о фантастических грейдах, которые где-то, да обитают: Junior+, Middle- и так далее.
👉 Читайте также: «Управление бэклогом продукта: методы, инструменты и советы»

Промежуточные грейды

В больших компаниях могут встречаться промежуточные грейды, которые помогают еще детальнее структурировать кадровый состав. Бывает даже, что в компаниях могут быть джуны, мидлы и сеньоры разных рангов: наверное, так делают дотошные кадровики, которые любили играть в RPG. Например, можно встретить какого-нибудь Junior+++, но это уже дебри.
Безумие
Вот наиболее популярные из промежуточных грейдов:
  • Junior+ – обычно это джуны, которые не нуждаются в микроменеджменте и способны самостоятельно закрывать небольше задачи.
  • Middle- – этот грейд обычно используют для того, чтобы мотивировать джунов развиваться и стать наконец мидлом, хоть и авансом. Такие спецы уже лучше разбираются в технологиях, нежели джуны с плюсом и могут решать еще более сложные задачи.
А теперь разберем должности разработчиков, которые часто путают с грейдами, хотя это просто отдельные рабочие направления. Отметим, что такие должности чаще всего занимают синьоры – у менее квалифицированных исполнителей для этого недостаточно опыта.

Какие должности часто путают с грейдами

Тимлид – это руководитель команды разработчиков. Обычный синьор тоже может менторить и делегировать задачи, но тимлид куда больше вовлечен в управление разработчиками, а также их поддержку и наставничество.
Техлид – это разработчик, который задает требования к ПО. Он не управляет командой, но занимается составлением технической документации, по которой потом будут работать специалисты меньшего ранга.
И напоследок перейдем к прикладной части: поделимся советами, которые помогут выстроить эффективную систему грейдов в вашей компании.
👉 Читайте также: «User story mapping: зачем нужны пользовательские истории и как их правильно писать»

Как выстроить систему грейдов у себя: советы

Разработчики не могут сами себе назначить грейд мидла или синьора – это будет необъективно. Поэтому о создании системы грейдов заботятся кадровики компании, руководители или наиболее опытные специалисты.
Подготовили короткие советы, которые помогут вам не наступить на грабли других компаний:
  • Чтобы оценить грейд ваших специалистов, нужно разработать большой тест с перечнем открытых вопросов. В тест должны входить вопросы как о софт-, так и о хард-скиллах, потому что «мягкие» навыки не менее важны для работы, нежели уровень владения технологиями. Вопросы должны быть открытыми, потому что тесты с вариантами ответов не позволят вам «докопаться» до разработчика, чтобы оценить его реальный уровень понимания того или иного рабочего аспекта. Вопросы должны соотноситься с практическими задачами разработчика: скажем, если он программирует на C#, то и вопросы должны быть по этому языку.
  • Нужно интервьюировать сотрудников. Если оставить им решать тест на дому, то они с большей вероятностью спишут правильные ответы. Опрашивать специалистов должна экспертная группа, которая сможет точно определить уровень разработчиков.
  • Систему оценивания нужно тестировать. С большей вероятностью, в первый раз вы создадите тест, который нужно будет переделывать. Например, вы забудете добавить в тест вопросы о познании какого-нибудь ООП или сделаете оценочную шкалу, по которой будет трудно выставлять объективные оценки сотрудникам.
  • Результаты тестов лучше обнародовать. Если сотрудник знает, в чем он разбирается хорошо, а в чем плавает, он будет знать, какие навыки ему нужно подтянуть. Поскольку прохождение теста будет влиять на грейд сотрудника, оно будет влиять и на зарплату – у разработчиков будет мотивация развивать свои навыки.
  • Нужно делать регулярную переоценку. Поскольку специалисты со временем будут обрастать опытом, оценивать их навыки нужно в динамике, чтобы давать более высокий грейд спецам, которые этого заслуживают. Оптимально – проводить тест раз в полгода. Более того, данные в динамике позволят вам выделить сотрудников, которые растут быстрее остальных – таких лучше держать поближе.
  • К результатам тестов нужны отдельные дополнения. Есть рабочие аспекты, которые тяжело учесть в тесте: например, один разработчик может спасать горящие проекты, а другой умеет хорошо менторить. Эти данные лучше занести в «досье» сотрудника и иметь их в виду.
Надеемся, что статья поможет вам определить, кто есть кто в вашей организации. Если вашему бизнесу необходимы организационные перемены, обращайтесь в Neogenda за бесплатной консультацией. Мы являемся экспертами во внедрении современных управленческих практик: руководим процессом, учим и консультируем.
]]> Кросс-функциональные команды http://neogenda.ru/blog/9vajhgss61-kross-funktsionalnie-komandi http://neogenda.ru/blog/9vajhgss61-kross-funktsionalnie-komandi?amp=true Thu, 26 Sep 2024 16:08:00 +0300 Андрей Сидоренко Чем сложнее продукт, тем больше разных специалистов требуется для его создания. И сейчас в IT...

Кросс-функциональные команды

Чем сложнее продукт, тем больше разных специалистов требуется для его создания. И сейчас в IT распространено кросс-функциональное взаимодействие, когда в продуктовую команду набирают работников разных специальностей.
Кросс-функциональная команда – это команда, которая состоит из специалистов разных направлений: например, программиста, тестировщика, дизайнера, продуктового менеджера, бизнес-аналитика и так далее. Благодаря «миксу» из разных спецов, такая команда способна самостоятельно улучшать небольшой MVP, стартап или микросервис большого продукта.
Радиоактивные люди
Далее в статье:
  • почему такой подход стал популярным и когда он оправдан;
  • что представляет из себя кросс-функциональная команда;
  • преимущества кросс-функциональной команды;
  • недостатки кросс-функциональной команды;
  • матричная структура управления: микс кросс-функциональной и линейно-функциональной структуры;
  • как создать эффективную кросс-функциональную команду.
Если вашему бизнесу необходимо внедрение современных управленческих практик – обратитесь за бесплатной консультацией в Neogenda. На нашем счету работа с такими компаниями как Тинькофф, Сбер, Яндекс, Точка и X5 Group. Мы оказываем более 100 различных услуг: от обучения вашего персонала до реорганизации вашего бизнеса.
Читайте также: «Управление командой проекта: стратегии и методы для успешного выполнения проектов»

Почему в IT решили прийти к созданию кросс-функциональных команд и когда они нужны

Исторически сложилось, что большие компании состоят из разных отделов: отдела продаж, отдела маркетинга, юридического отдела и так далее. Так же и с IT-отделом, в который входят все специалисты, что работают над цифровым продуктом компании. Вроде бы все логично: сотрудники находятся на своем месте, обмениваясь друг с другом экспертизой и получая задания от своего руководства.
Поскольку у большой компании много работы, ей нужно много сотрудников: например, над цифровыми продуктами какого-нибудь банка могут работать сотни или тысячи айтишников. Соответственно, IT-отдел компании будет делиться на подразделения: разработчиков, тестировщиков и так далее.
И из-за этого между отделами условной компании появляется некая «пропасть». Скажем, разработчики пишут код, занимаясь «хаяньем» дизайнеров: те по их мнению добавляют в дизайн какие-то бесполезные функции, которые не стоят погружения в дебри легаси-кода. Или менее айтишный пример: вечные недопонимания и войны в организациях между отделом продаж и отделом маркетинга. А вот пример, который вы точно ощутите на себе: вспомните, как в школе ваш класс не любил параллельный класс, было же такое?
Мем, взятый из интернета
И вот: из-за недопонимания между отделами ухудшается качество работы. Негативно настроенные департаменты плохо кооперируются: не делятся полной информацией и нехотя выполняют взаимные просьбы.
А от плохой кооперации сильно замедляется время выполнения задач, требующих вовлечения специалистов из разных отделов. Даже если отношения между отделами нормальные, на согласование работ уходит слишком много времени. При этом оперативное реагирование на изменения во внешней среде – одно из ключевых конкурентных преимуществ. Особенно в мире цифровых продуктов.
Вспомните те же соцсети, которые постоянно обрастают новыми функциями. Лучшие идеи они заимствуют друг у друга. А если дело касается технической поддержки платформы, на которой работает сервис, оперативное реагирование вообще становится жизненно необходимым.
Но полбеды – что-то обсудить. Ситуация еще хуже, если один отдел передает другому задачу в работу. Скорее всего, у другого отдела итак будет много своих забот. Из-за этого задача может подвиснуть: нужно оценить загрузку специалистов, выбрать самого свободного, оценить трудозатраты и перестроить планы. Это не говоря о времени, которое уйдет на выполнение самой задачи.
Поэтому айтишники через какое-то время поняли: работа над проектами или микросервисами продукта шла бы куда быстрее, если бы участники рабочей группы лучше скооперировались между собой. Так и возникли кросс-функциональные команды.
Лирическое отступление: кросс-функциональные команды имеет смысл создавать только тогда, когда для выполнения работ нужны специалисты из разных областей. Если задача касается одного вида деятельности, то собирать такую команду не нужно. Например, если нужно написать какой-нибудь код, для этого будет достаточно только разработчиков.
И еще: кросс-функциональные команды не нужны для выполнения отдельных задач или небольших проектов. Тратить время на подбор специалистов и их организацию выгодно, только когда работы длительные.
А для такой задачи понадобится кросс-функциональная команда «Навуходоносора»
Итак, мы узнали, как возникли кросс-функциональные команды и когда в их создании есть реальная необходимость. Но как выглядит такая команда? Сейчас расскажем.
Читайте также: «Матрица RACI: руководство по распределению ролей и ответственности в проекте»

Что представляет из себя кросс-функциональная команда

В интернете можно встретить статьи, в которых пишут, что в кросс-функциональную команду входят участники абсолютно всех процессов, связанных с продуктом. Например, туда входят не только спецы, которые поставляют обновления продукта, но и маркетологи, которые его продвигают.
Это ошибочное суждение: кросс-функциональные команды редко состоят более, чем из 10 человек. Иначе сильно пострадают коммуникации. Об этом написано в том же скрам-гайде, который отчасти популяризировал термин «кросс-функциональная команда».
Пример: приложение большого банка. Над его микросервисами могут работать десятки, если не сотни продуктовых команд. Они доставляют пользователям дополнительную ценность приложения, устраняя его старые недоработки и добавляя новые функции.
У каждой из таких команд будет своя зона ответственности. Например, одна из продуктовых команд банка может может отвечать за оптимизацию чата поддержки. Она может улучшать ИИ-автоответчик, выявлять устранять баги чата, править легаси-код, тестировать новые функции чата и так далее.
А продвижение приложения и его субпродуктов – отдельный процесс, за который чаще всего отвечают совершенно другие команды. По этой логике, если упоминать всех специалистов, которые работают над продуктом, состав кросс-функциональной команды можно растянуть до кадрового состава всей компании. Там будут и юристы, и топ-менеджеры, и сейлзы, и так далее.
С другой стороны, в больших продуктах кросс-функциональные команды часто объединяют в большие департаменты. Они могут относиться к тому или иному направлению продукта. Например, команда чата поддержки может входить в департамент работы с клиентским сервисом. Но такие объединения все равно не назовешь кросс-функциональной командой.
Несмотря на то, что мы рассказали о потребности в возникновении кросс-функциональных команд, те обладают не только преимуществами, но и недостатками. Расскажем и о хорошем, и о плохом.
Читайте также: «Фреймворк SCRUM: что это и как его использовать для управления проектами»

Преимущества кросс-функциональной команды

  • Самостоятельность.
Кросс-функциональная команда включает в себя всех участников, которые будут сами развивать и оптимизировать продукт. Например, такая команда может сама поставить задачи на обновление микросервиса, за который отвечает, выполнить эти задачи и выкатить обновленную версию.
  • Погруженность в контекст.
Главная фишка кросс-функциональной команды в том, что она работает над одним и тем же на протяжении долгого времени. Соответственно, ее участникам не нужна документация или созвоны, чтобы быть посвященными в условия какой-нибудь задачи. Это сильно упрощает и ускоряет процесс работы.
  • Быстрые коммуникации между специалистами разных областей.
Ранее мы уже рассказали, какой волокитой может обернуться обсуждение какого-нибудь процесса даже между двумя отделами. А если в обсуждении задействовано сразу несколько разных сторон, то коммуникации растянутся на еще более долгий период времени.
Создание кросс-функциональной команды способствует более быстрому продвижению проекта. Очевидно, что у участников команды будет общий чат, где все смогут перекинуться мыслями по тем или иным деталям работы. Более того, формирование отдельной команды чаще всего подразумевает, что ее участники могут ни с кем не согласовывать свои действия и не тратить время на лишние бюрократические процессы.
  • Коллективные решения.
Если процессы в команде выстроены хорошо, ее участники совещаются между собой, чтобы найти лучшее решение для той или иной задачи. Разные навыки и знания у участников помогают найти более элегантные выходы из разных ситуаций.
Например, бизнес-аналитик выявил узкое горлышко в воронке продаж, которое было связано с интерфейсом приложения. Он предложил запустить A/B-тест, чтобы путем теста оптимизировать интерфейс. Но еще в команде был UX/UI-дизайнер, коллеги которого работали над схожим продуктом. Он знал, что та продуктовая команда проводила UX-исследование по схожей задаче и запросил у ее участников результаты исследования, чтобы сразу предложить более удачное решение по оптимизации интерфейса.
Читайте также: «Управление портфелем проектов: как устранить неразбериху в проектах вашего бизнеса»

Недостатки кросс-функциональной команды

  • Накопление опыта только внутри команды.
Когда рабочая группа долго работает над чем-то одним, она все лучше погружается в контекст и оптимизирует рабочий подход. Но смежные команды могут решать схожие задачи и не знать о более удачных практиках, которые уже есть у другой команды. Если над задачами работают специалисты из разных отделов, они с большей вероятностью будут делиться между собой опытом.
  • Ограниченность взгляда на контекст.
Из-за того, что в кросс-функциональной команде есть эксперты разных областей, ее участники могут ни к кому не обращаться за помощью – это хорошо. Но если над задачей работают внутри того или иного отдела, специалист с большей вероятностью может обсудить задачу с кем-нибудь еще и услышать разные мнения внутри коллектива. А еще специалиста в отделе будет контролировать более опытный руководитель, который может предложить более удачное решение задачи. Также на некоторые ситуации иногда нужен «незамыленный» взгляд со стороны, которого не будет внутри кросс-функциональной команды.
Но есть способ взять только лучшее от деления штата сотрудников на кросс-функциональные команды. Этого можно достичь за счет внедрения матричной структуры управления.
Читайте также: «Agile, Scrum, Kanban и Waterfall – что выбрать вашему бизнесу»

Матричная структура управления: микс кросс-функциональной и линейно-функциональной структуры

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

Как собрать эффективную кросс-функциональную команду

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

Хард-скиллы

В первую очередь, в команде должны быть все специалисты, нужные для того, чтобы команда могла самостоятельно работать над продуктом: поддерживать его работоспособность и выпускать обновления.
Конкретный состав команды будет сильно зависеть от продукта. Например, для поддержки какой-то платформы в серверной части приложения команда может состоять исключительно из технарей: скажем, разработчика, тестировщика, сисадмина, техлида и продуктового менеджера. А если команда занимается разработкой молодого веб-сервиса, в ней скорее всего будет веб-дизайнер, а может даже и маркетолог.
Понятие «кросс-функциональность» касается не только команды, но и отдельных специалистов. Есть термины, которыми можно охарактеризовать набор навыков того или иного участника команды:
  • I-shaped специалист. Так называют участников команды, которые обладают экспертизой в одной сфере деятельности. Например, таким спецом может быть бэкенд-разработчик, который работает только в этом направлении. Знать что-то одно – вовсе не плохо. Хорошо, если ваш разработчик или тестировщик – I-shaped специалист, который поднимает квалификацию именно в своей сфере деятельности.
  • T-shaped специалист. Это мультискиллоыве спецы, которые хорошо разбираются в чем-то одном, но поверхностно разбираются еще в ряде дисциплин. T-shaped специалистами должны быть руководители – если они немного разбираются в деятельности других участников команды, им проще ей управлять. Также T-shaped специалист может подхватить зону ответственности другого участника команды в нужную минуту: если коллега, скажем, заболел.
  • «Расческа»-shaped специалист. Сюда относятся спецы, которые являются экспертами в двух или более сферах деятельности. Таких мало, потому что нужно потратить годы, а то и десятилетия кропотливой работы, чтобы в совершенстве постичь несколько дисциплин. Скажем, это может быть какой-нибудь фулстек-разработчик. Зачастую навыки таких спецов избыточны, потому что чаще всего спецы в команде занимаются каким-то одним видом деятельности.
Он потратил десятки лет на работу
Скорость выполнения задач участников команды должна соответствовать нагрузке. Скажем, если в команде слишком много нагрузки на разработчика и из-за него стопорится процесс, в команду нужно привлечь еще одного разработчика. В одной кросс-функциональной команде такое выявить легко, но проблема часто встречается в сложных организационных структурах. Выявить ее помогает измерение пропускной способности – метрики, используемой в Канбан Методе. Про то, как ее измерить и улучшить у нас есть отдельная статья в блоге: «Пропускная способность (Throughput): что это, как и зачем улучшать».

Софт-скиллы

Чтобы команда достигала лучших результатов, ее участники должны уравновешивать друг друга не только по хард-, но и по софт-скиллам.
Для того, чтобы классифицировать характеры всех участников команды, можно использовать модель командных ролей Рэймонда Белбина – ученого, имеющего докторскую степень по психологии.
Модель гласит, что участники команды должны обладать разными особенностями поведения, с которыми они будут дополнять друг друга. Каждому участнику присуща та или иная роль, которая выражается в его мышлении и поведении наиболее ярко. У каждой роли есть свои преимущества и недостатки.
Всего в модели выделяется 8 разных ролей:
  1. Душа команды. Это идейный вдохновитель команды, который способен устранять конфликты и мотивировать ее участников работать. Такой человек не сдастся перед препятствием. Минус таких людей в том ,что они легко поддаются чужому мнению и «душнят», фокусируясь на достижении поставленных целей.
  2. Координатор. Так называют искусных управленцев, которые следят за рабочим процессом и делегируют задачи. Минус: излишнее делегирование, из-за которого такие люди все же теряют контроль над некоторыми процессами.
  3. Генератор идей. Это креативные люди с хорошо развитой фантазией, которые фонтанируют гипотезами. Минус: могут витать в облаках и не видеть насущные проблемы.
  4. Собиратель идей. Это экстраверсивные аналитики, которые хорошо себя показывают в поиске новых возможностей. Минус: отсутствие интереса к каким-то устоявшимся процессам.
  5. Стратег-аналитик. Так зовут людей, которые могут разобрать любую идею на косточки и раскритиковать ее, если она недостаточно хороша. Минус: неумение заставить других людей действовать.
  6. Шейпер. Сюда относятся добросовестные сотрудники, которые следят за качеством выполнения работы. Минус: им тяжело делегировать работу, потому что они могут потерять контроль над ситуацией, а еще они могут быть излишне требовательными из-за своего перфекционизма.
  7. Педант. Так зовут экспертов в той или иной сфере. Их минус: фокус только на своей деятельности, но не на общей картине.
  8. Реализатор. Представителям этой роли свойственно воплощать в жизнь любые идеи, они берут и делают. Минус: они не смотрят по сторонам, из-за чего им тяжело адаптироваться к изменениям.
По мнению Рэймонда, всем людям присущи черты всех ролей, правда некоторые выражены более ярко. Каждый человек будет обладать 1-2 сильно выраженными ролями, 4-6 ролей будут выражены средне, а оставшиеся 1-2 роли – слабо.
Чтобы уравновесить команду, нужно выявить роли ее возможных участников, после чего постараться собрать у себя в команде равнозначное количество представителей всех ролей. Для визуализации состава команды удобно использовать матрицу – таблицу, в которой будут перечислены участники и их возможные роли.
Пример более-менее удачно укомплектованной команды
За счет использования модели, вы можете собрать более эффективные команды, если будете распределять сотрудников не только по требуемым навыкам, но и по их характеру.
Если вам нужна помощь в сборе продуктовых кросс-функциональных команд – обратитесь за бесплатной консультацией в Neogenda. Мы предоставляем разные услуги: от обучения ваших сотрудников лучшим управленческим практикам до полной реорганизации процессов вашего бизнеса.
]]> Стили управления командой: все о кнутах и пряниках http://neogenda.ru/blog/rzry5h5gb1-stili-upravleniya-komandoi-vse-o-knutah http://neogenda.ru/blog/rzry5h5gb1-stili-upravleniya-komandoi-vse-o-knutah?amp=true Thu, 03 Oct 2024 21:39:00 +0300 Артур Нек Людей можно по-разному мотивировать выполнять поручения: хоть премией, хоть, кхм, раскаленным паяльником. Существуют разные классификации...

Стили управления командой: все о кнутах и пряниках

Людей можно по-разному мотивировать выполнять поручения: хоть премией, хоть, кхм, раскаленным паяльником. Существуют разные классификации стилей управления командой, но лучше других прижилась модель, которую в 1939 году создал американский психолог Курт Левин.
Его модель стала популярной потому, что он выявил и четко обозначил три фундаментальных типа лидерства. Благодаря этому типологию легко запомнить и применять на практике. Она хорошо перекладывается на менеджмент, отчего из нее можно сделать вывод о том, какие бывают стили руководства.
По мнению психолога, тип лидерства может быть авторитарным, демократическим или попустительским. У всех типов есть свои отличительные черты, а также плюсы и минусы, о которых мы расскажем далее. А еще, в самом конце статьи мы кратко пройдемся по альтернативным классификациям стилей управления.
А кто тогда Шурик?
Но перед этим немного о себе. Neogenda – это консалтинговая фирма, которая занимается внедрением современных управленческих практик. На нашем счету работа с такими компаниями как Тинькофф, Сбер, Яндекс, Точка, X5 Group и так далее. Мы оказываем более 100 различных услуг – от обучения персонала до реорганизации бизнеса. Если вы хотите, чтобы мы взялись за ваши процессы – обратитесь к нам за бесплатной консультацией.
👉 Читайте также: «Управление командой проекта: стратегии и методы для успешного выполнения проектов»

Небольшой экскурс: как появились типы лидерства Курта Левина

В 1939 году Курт Левин составил дизайн эксперимента, в котором ему помогало еще два коллеги – Рональд Липпит и Ральф Уайт. На тот момент ученый уже выделил три типа лидерства и подробно описал их. Задачей эксперимента было отследить влияние типов лидерства на поведение контрольных групп, тем самым, подтвердив их существование.
Какими чертами отличались выделенные типы лидерства:
  • авторитарный – лидер дает четкие инструкции подчиненным, которые они должны строго выполнять;
  • демократический – лидер обсуждает задачи с подчиненными, слушает альтернативные решения, берет ответственность за принятие окончательного решения и контролирует выполнение результата;
  • попустительский – лидер обеспечивает подчиненных полной свободой действий.
Для проведения эксперимента в качестве испытуемых собрали три равночисленные группы мальчиков 10-11 лет. От мальчиков требовалось делать театральные маски из папье-маше. Сам эксперимент проводился в детском клубе, где каждая из групп находилась в одинаковом помещении.
Разница была лишь в руководителях групп: к каждой из групп был привязан взрослый управляющий, который руководил, соответствуя особенностям того или иного типа лидерства. Каждые 7 недель руководители менялись между группами, а всего эксперимент длился 21 неделю.
Кадр из видеоотчета о проведении эксперимента, в который попали некоторые эпизоды самого эксперимента. Взят из YouTube
Проведение эксперимента подтвердило влияние типов лидерства на поведение подчиненных: следовательно, модель типов лидерства имела право на жизнь. А еще по результатам эксперимента обнаружились интересные инсайты:
  • Если у контрольной группы авторитарный руководитель, то в коллективе низкий уровень агрессивного поведения.
  • Если группа переходит от авторитарного лидерства к демократической или попустительской модели, в ней на первых порах поднимается уровень агрессии, после чего ее эмоциональный фон стабилизируется.
  • У группы с авторитарным руководителем самая большая производительность, но средние показатели качества.
  • У группы с демократическим управлением не самая большая производительность, но лучшее качество работы.
  • В группе с попустительским управлением производительность и качество хуже всего. В целом, дети в группе с полной анархией мучили руководителя вопросами и работали крайне неохотно.
В общем, эксперимент выявил ряд интересных закономерностей. Но этот опыт не получится в полной мере соотнести с управлением рабочим коллективом по двум причинам:
  • в эксперименте участвовали дети, которые еще даже не стали подростками;
  • руководитель всегда находился рядом с детьми.
А теперь давайте подробно разберем каждый из стилей в рамках взрослых рабочих коллективов.
👉Читайте также: «Управление портфелем проектов: как устранить неразбериху в проектах вашего бизнеса»

Авторитарный стиль управления

Авторитарный руководитель императивно командует. 10 год до битвы при Явине
На самом деле, авторитарный руководитель – не канцлер Палпатин из Звездных Войн и даже не Дарт Вейдер.
Что характеризует авторитарного руководителя:
  • личное принятие решений;
  • микроконтроль хода работ сотрудников (читай, микроменеджмент);
  • четкие ТЗ и инструкции, которые он дает сотрудникам для выполнения задачи;
  • личная проверка и приемка работ.
Заметьте, тут ничего не сказано про насилие! Хотя некоторая связь между токсичностью руководителей и строгим контролем все же имеется. Но далеко не все авторитарные руководители – деспоты.
Ключевая проблема авторитарного стиля в том, что руководитель становится «бутылочным горлышком» процесса, контролируя промежуточные шаги и итоговые результаты работ сотрудников. Его одного просто не хватает на оперативное согласование работ, отчего процесс сильно замедляется.
Небольшой офтоп. У нас есть отдельная статья про бутылочные горлышки: там мы рассказали, как их выявлять с помощью инструментов Канбан Метода. Также рекомендуем прочесть нашу статью про пропускную способность – это еще одна метрика Канбан Метода, отслеживание которой позволяет оптимизировать скорость выполнения задач организацией. А теперь вернемся к основной теме.
Какие плюсы авторитарного стиля:
  • Снижение риска, что что-то в процессе пойдет не по плану.
  • Более прогнозируемая и высокая продуктивность.
  • Результаты работ, которые скорее всего будут соответствовать требуемым критериям.
Какие минусы:
  • Большая нагрузка на руководителе, отчего он может выгорать, меньше уделять времени стратегическим задачам и т.д.
  • Снижение качества работ из-за потери сотрудниками возможности реализоваться. Тут негде развернуться творческой жилке, отчего работа выполняется просто «нормально».
  • Риск выбора не самого эффективного достижения цели. Допустим, сотрудник может лучше руководителя разбираться в каком-то узком вопросе, а руководитель считает себя умнее и заставляет сотрудника делать по-своему. Также теряется возможность поиска лучшего решения всеми участниками коллектива.
Но авторитарный стиль – всего лишь инструмент, грамотное использование которого сильно зависит от контекста. В некоторых ситуациях он будет работать лучше демократического и либерального стиля.
Когда использовать авторитарный стиль:
При делегировании неопытным сотрудникам. Если поручить работу джуну, ему нужно сразу дать настолько развернутое ТЗ, чтобы при выполнении задачи у него не осталось никаких разночтений и белых пятен. Иначе его понесет куда-то не туда. Также для перестраховки лучше заранее договориться о контрольных точках проверки выполнения задачи и их крайних сроках.
При решении типовых, а также циклических задач. Проще написать инструкцию, по которой низкоквалифицированные сотрудники будут делать что-то, чтобы это потом не пришлось переделывать.
Лайфхак. Если руководителю нужно использовать авторитарный стиль, отчего ему предстоит принимать много работ, этот процесс также можно делегировать. Для этого нужно поставить перед собой в качестве фильтра управленца поменьше. Еще нужно подготовить для него ясные и недвусмысленные критерии приемки работ. После понадобится пару-тройку раз перепроверить всю цепочку процесса – если все хорошо, можно сразу принимать конечный результат с внедренными правками от другого руководителя, если те требовались. Но можно ли такой подход называть авторитарным стилем – вопрос.
Вообще, если контекст подразумевает использование авторитарного стиля управления, лучше заранее все стандартизировать, регламентировать и делегировать руководителям меньшей руки. Иначе при масштабировании растущего бизнеса руководителю станет очень больно.
А теперь к демократическому стилю.
👉Читайте также: «Методологии управления проектами: топ 12 популярных систем»

Демократический стиль управления

Сенаторы Древнего Рима коллективно решают, что будут кушать на обед в своем опенспейсе. 386 год до н.э.
Несмотря на то, что последнее слово всегда за руководителем-демократом, он постоянно совещается со своими подчиненными. Иерархия в такой общности выражена не столь ярко, как в авторитарной системе – сотрудники общаются с руководителем в более свободном ключе.
В демократической системе у сотрудников «расширенные права» – они сами могут выбирать инструменты для выполнения задачи и устанавливать крайние сроки, если те удовлетворяют конечным требованиям руководителя.
Какие плюсы у демократического стиля управления:
  • Менее стрессовый эмоциональный фон в коллективе. Как ни крути, люди – ключевой ресурс коллектива (простите за цинизм). Все живые существа любят свободу и люди не исключение. Даже если неволя выражена не в физической изоляции, а абстрактных условностях (требованиях, дедлайнах, постоянных проверках), человек все равно себя чувствует подавленным. Отсюда вытекает следующее преимущество.
  • Более высокое качество выполнения работы. Этот инсайт мы уже уловили из результатов исследования, о котором рассказывали в начале статьи. Достаточная свобода мотивирует исполнителя искать более эффективные решения – ведь так интереснее работать. А если слишком стеснять сотрудника, он начнет делать все механически: лишь бы работу принял тот умник, что задал такие критерии.
  • Более элегантные и эффективные решения задач. Если руководитель открыт к предложениям сотрудников, он открыт к удачным идеям, которые могли ему самому не прийти в голову. Такой подход особенно важен, если руководитель не является экспертом в области решения задачи – тогда точно нужно совещаться с кем-то поопытнее, кто работал над этим своими руками.
А какие минусы:
  • Долгое принятие решений. Порой команда может уйти от темы обсуждения, начать спорить между собой или просто долго «мусолить» задачу, принося компании убыток, выраженный в бездарно потраченном времени целой группы сотрудников. Но, кстати, проблему можно решить, если фасилитировать переговоры. На эту тему у нас есть отдельная статья: «Что такое фасилитация и зачем ее внедряют компании».
  • Карт-бланш для недобросовестных сотрудников. Если в вашей команде есть люди, которых волнует исключительно собственное благополучие, они будут выбивать для себя более удобные условия. Скажем, сотрудник может загружать себя работой только на 50 % от своего потенциала. Или нарочно предлагать «ленивые» способы решения задач, отчего результат будет хуже. Но с такими сотрудниками нужно работать дополнительно, пытаясь их наставить на «праведный» путь или прощаться. Если ваша команда состоит из порядочных и проактивных людей, таких проблем не будет.
Когда использовать демократический стиль. Когда сотрудники достаточно опытны и проактивны, чтобы не стоять у них над душой.
👉Читайте также: «Agile, Scrum, Kanban и Waterfall – что выбрать вашему бизнесу»

Либеральный стиль управления (попустительский)

Либеральный руководитель на созвоне делится мнением по ходу проекта. Наши дни
Руководитель либерального стиля несет ответственность лишь за конечный результат – в остальном он дает полную свободу своим сотрудникам. Такой руководитель не ставит себя выше подчиненных, общаясь с ними на равных. Поэтому участники команды могут даже где-то поправить руководителя и взять ответственность за осуществление своего решения.
Тут можно процитировать пару принципов из Agile-манифеста:
  • «Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.»
  • «Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.»
И такой стиль руководительства действительно может работать хорошо, если в команде работают не 10-11-летние дети.
Какие плюсы у либерального стиля управления:
  • Минимальные затраты ресурсов на контроль процессов и проверку результатов. Руководитель может выделить команде все что ей нужно для решения задачи и заниматься чем угодно – команда подхватит.
  • Наиболее качественный результат. Если в команде профессионалы с высоким эмоциональным интеллектом – они проявят инициативу и покажут класс.
Какие минусы:
  • Большой риск провалить работы. Либеральный стиль управления нельзя использовать с сотрудниками, к которым не сформировалось прочное доверие.
В каком случае использовать либеральный стиль. Если команда или подчиненный – высококлассный профи. Под профессионализмом тут понимаются не только хард-, но и софт-скиллы.
И постепенно напрашивается мысль – может стоит чередовать все стили руководительства? Отвечаем: да. И об этом следующий раздел нашей статьи.
👉 Читайте также: «Постигаем гибкие методологии: что такое Agile и почему все хотят по нему работать»

Почему нужно уметь менеджерить во всех стилях

Кому-то может это и не понадобится, но это в идеальном мире, где руководитель вечно сидит на одном месте и руководит одними и теми же подчиненными. Вернее, не в идеальном мире, а наоборот – в каком-то чистилище. Скорее всего, состав подчиненных у руководителя все же будет со временем меняться. Причины тому могут быть разными: смена работы из-за больших амбиций, рост бизнеса или ряд других, менее значимых изменений во внешней среде.
Главная причина, по которой хороший управленец должен отточить все управленческие стили – он должен быть готов к изменениям в системе, чтобы сохранить контроль над ней.
Например, если в штат руководителя пришел джун, а все остальные участники – прожженные спецы, не беда. Руководитель будет пристальнее за ним следить, применяя авторитарный стиль управления. Но только до того момента, пока джун не станет опытнее – тогда вожжи можно будет отпустить, чтобы дать джуну больше способы для самореализации. И, разумеется, перестать тратить свой ресурс на ненужный контроль.
В общем, тут все просто. Разберем же напоследок менее популярные классификации стилей управления, чтобы повысить вашу насмотренность. Хороши они или нет – решать вам.

Какие еще есть классификации стилей управления

Управленческая решетка Блэйка-Мутона

Это концепция, разработанная в Университете штата Огайо. Позже, в 1964 году, ее доработали американские экономисты – Роберт Блэйк и Джэйн Мутон.
Идея такова. Управленцев можно оценить по двум критериям – степени учета интересов сотрудников и степени стремления к результату. По каждому критерию управленцу можно поставить от 1 до 9 баллов, исходя из чего он подойдет под один из пяти стилей руководства.
Иллюстрация взята из Википедии
Какие особенности выделяются у стилей в концепции:
  • Примитивное руководство. Это худший стиль. Его представители имеют низшую оценку по показателям, поскольку не заботятся ни о людях, ни о процессах. Такой руководитель сосредоточен лишь на удержании своей позиции.
  • Авторитарное руководство. Такой руководитель сфокусирован на задачах, но полностью игнорирует сотрудников.
  • Организационное руководство. Так называют баланс между заботой о людях и задачах. Лидер заинтересован в успехе, но не настаивает на жестких критериях, что приводит к средним результатам.
  • Социальное руководство. Руководитель сфокусирован на сотрудниках, что создает дружественную атмосферу. Но слабый контроль за задачами снижает производительность.
  • Командное руководство. Это стиль, которым одарены руководители с высшим баллом по обоим критериям. Такие управленцы одинаково здорово следят и за процессами, и за командой.
Сама концепция хорошо отражает руководительскую необходимость в балансе между интересами команды и задачами, но ее тяжело объективизировать. Непонятно, как объективно оценить руководителя по этой шкале – нет выраженной системы критериев. Также непонятно, зачем быть средним руководителем, если можно стать идеальным – всего-то нужно заработать максимальный балл по каждому из критериев. Но это утопия.

Теория мотивации Макгрегора (теория X и Y)

Теория мотивации состоит из двух отдельных теорий – X и Y. Они противоположны друг другу.
Теория X гласит, что сотрудники ленивы, избегают ответственности, и их нужно постоянно контролировать.
Теория Y гласит, что сотрудники амбициозны и способны работать самостоятельно. Им предоставляется свобода действий, что способствует внутренней мотивации.
В конечном счете, суть теорий сводится к тому, что сотрудники не хотят работать не из-за врожденных качеств, а из-за плохих условий труда. Компания и ее руководители должны позаботиться о создании среды, в которой сотрудники развивали бы дисциплину и проактивность.

6 эмоциональных стилей руководства

Эта модель возникла совсем недавно – в 2006 году. Над ней работали американские ученые из сфер психологии и управления – Дэниел Гоулман, Ричард Боязис и Анни Макки. Модель была впервые упомянута в книге «Primal Leadership», авторами которой ученые и являются. Кстати, на русский книгу тоже перевели, она называется «Эмоциональное лидерство. Искусство управления людьми на основе эмоционального интеллекта».
Небольшой оффтоп: Дэниел Гоулман известен как популяризатор концепции эмоционального интеллекта, которая обретает всю большую популярность: например, эмоциональный интеллект учитывают при трудоустройстве в Google.
Какие стили руководства входят в концепцию:
  • Визионерский стиль. Такой руководитель задает общие цели, но не указывает пути их достижения, давая свободу сотрудникам для экспериментов и новых идей.
  • Наставнический стиль. Здесь основное внимание уделяется развитию сотрудников и их продуктивности, а также объединению их личных целей с целями компании.
  • Аффилиативный стиль. Исповедники этого стиля делают акцент на гармонии и сближении членов команды для улучшения морального климата и коммуникации. Однако это может снизить производительность.
  • Демократический стиль. Такой руководитель полагается на мнения команды для принятия коллективных решений. Эффективен, когда требуется собрать разные взгляды, но в кризис может замедлить процесс.
  • Направляющий стиль. В этом случае руководитель высоко поднимает планку и требует ей соответствовать. С таким стилем можно достичь выдающихся результатов, но он может подорвать уверенность сотрудников.
  • Командующий стиль. Этот стиль жесткий и авторитарный, отчего встречается в основном в военной сфере. Эффективен только в кризисных ситуациях, но в долгосрочной перспективе снижает удовлетворенность сотрудников.
По нашему мнению, эти стили имеют право на существование, но они применимы к еще более частным случаям, нежели классические стили Курта Левина.
Подытожим. Хороший руководитель использует тот или иной управленческий стиль в зависимости от ситуации – тогда его управление будет максимально эффективным. Чтобы управленец рос, ему нужно учиться быстро анализировать ситуацию и адаптироваться под нее.
И самое-самое последнее. Если вашему бизнесу нужно внедрение современных управленческих практик, обратитесь за бесплатной консультацией в Neogenda.
]]> Контрольная диаграмма: как с ее помощью визуализировать отклонения в производственном процессе http://neogenda.ru/blog/m8f5y1kmd1-kontrolnaya-diagramma-kak-s-ee-pomoschyu http://neogenda.ru/blog/m8f5y1kmd1-kontrolnaya-diagramma-kak-s-ee-pomoschyu?amp=true Tue, 08 Oct 2024 21:44:00 +0300 Мария Савельева Контрольная диаграмма (Control Chart, диаграмма контрольных точек или контрольная карта) была создана еще в 1924...

Контрольная диаграмма: как с ее помощью визуализировать отклонения в производственном процессе

Контрольная диаграмма (Control Chart, диаграмма контрольных точек или контрольная карта) была создана еще в 1924 году Уолтером Шухартом – американским экономистом, работавшим над теорией управления качеством. Несмотря на почтенный возраст, диаграмма до сих пор пользуется популярностью в менеджменте.
Контрольная диаграмма – это визуальный инструмент, используемый для отслеживания хода рабочего процесса и его оптимизации. На диаграмме видно, сколько времени уходило на рабочие задачи в тот или иной период времени. Благодаря этому можно выявить отклонения от нормы, чтобы устранить их, а также снизить риск их появления в будущем.
Примерно так выглядит контрольная диаграмма
Далее в статье:
  • что включает в себя контрольная диаграмма;
  • зачем анализировать контрольную диаграмму;
  • как это делать.
Но перед этим пару слов о себе. Neogenda – это консалтинговая компания. Мы помогаем компаниям освоить современные подходы и методы менеджмента. На нашем счету более 100 управленческих кейсов, 5 000 учеников и 40 лет практики. Наши клиенты – это Сбер, МТС, Тинькофф, Билайн, Raiffeisen Bank, Магнит, Яндекс, Авито, Азбука Вкуса и другие компании, которые вам скорее всего тоже известны. Если вы считаете, что ваш бизнес может стать прибыльнее за счет грамотного внедрения современных управленческих практик – обратитесь за бесплатной консультацией в Neogenda.
👉 Читайте также: «Что такое управление рисками и почему это важно»

Что включает в себя контрольная диаграмма

С момента создания контрольных диаграмм, появилось большое количество их разных вариаций. Их используют не только в менеджменте, но и в медицине, науке, а также еще в ряде других дисциплин. Но даже если говорить о сфере управления, контрольные диаграммы могут различаться из-за особенностей интерфейса сервиса, в котором их можно составить.
Например, так выглядит контрольная карта в Jira. Источник: atlassian.com
А так в сервисе Kaiten. Источник: kaiten.ru
Тем не менее, любая контрольная карта будет включать в себя ряд элементов, которые мы разберем ниже. Рассмотрим, какие элементы может включать в себя контрольная диаграмма, используемая в менеджменте.
Чуть дополнили первоначальную контрольную диаграмму, сейчас будем ее разбирать
Что включает в себя контрольная диаграмма (основные и дополнительные элементы):
  • Шкала оси X – на ней расположены даты завершения задач.
  • Шкала оси Y – здесь указана временная шкала, которая отображает, за сколько времени была выполнена та или иная задача. Чаще всего измеряется в днях. Если говорить о Канбан-метриках, чаще всего на ней смотрят Lead Time и Cycle Time. К этому мы еще вернемся в разделе про анализ контрольной диаграммы.
  • Точки – это выполненные задачи, время выполнения которых и анализируется на диаграмме. Положение точки на оси X чаще всего обозначает дату, в которую она была завершена, а положение на оси Y – количество дней, прошедших с взятия задачи в работу до ее сдачи заказчику.
  • Средняя – это линия, которая указывает среднее время, необходимое для на выполнение задачи. Чаще всего это арифметическое среднее, вычисленное из времени выполнения предыдущих задач за определенный период, достаточный для статистически достоверных расчетов. В зависимости от интерфейса вашего ПО для управления проектом или продуктом, вам может отображаться еще и скользящая средняя.
  • Верхняя и нижняя контрольная границы. Тут немного сложнее. Верхняя граница — это арифметическое среднее + 3 среднеквадратических отклонения, а нижняя граница — это арифметическое среднее — 3 среднеквадратических отклонения. Если не погружаться в дебри математики, то это границы, в которых отклонения показателей считаются допустимыми. То есть, если задача выполнилась быстрее или медленнее среднего значения, но в рамках контрольных границ — это допустимое отклонение в системе. Если значение вышло за эти границы — это аномалия.
  • SLA. Иногда вместо средней и контрольных границ указывается SLA. Это время, которое зафиксировано в соглашении об уровне услуг. То есть, это может быть максимально возможное время на выполнение задачи, которое вы обсудили с заказчиком.
Итак, мы разобрали, что может включать в себя контрольная диаграмма. Далее расскажем о том, зачем и как ее смотреть.
👉 Читайте также: «Управление бэклогом продукта: методы, инструменты и советы»

Зачем анализировать контрольную диаграмму

Представим, что ваша производственная система отработала какое-то продолжительное время, за которое выполнила некоторое количество задач. На основе этих данных вы можете построить контрольную диаграмму, чтобы:
  • Вовремя увидеть какие-то отклонения в процессе. Например, увидеть, что по каким-то причинам ваши задачи в последнее время стали выполняться дольше, чем обычно. Так вы сможете быстрее предпринять какие-то действия по устранению помех в процессе.
  • Выявить определенные закономерности в ваших процессах и построить по ним гипотезы, чтобы их подтвердить или опровергнуть. Например, вы можете обратить внимание, что на графике происходят какие-то аномальные всплески, в рамках которых задачи выполняются дольше. Например, такое может возникать при тестировании перед масштабным обновлением приложения, во время которого «выползают» всякие дефекты и команда тратит много времени на их устранение.
  • Спрогнозировать производительность вашей команды. Скажем, если вы построили диаграмму за двухнедельный период, вы можете увидеть, сколько ваша производственная система выполнила задач за это время. По сути, это значение является пропускной способностью вашей системы.
👉 Читайте также: «Как управлять временем производства с помощью WIP-лимитов»

Как анализировать контрольную диаграмму

Итак, давайте еще раз посмотрим на какой-нибудь упрощенный пример контрольной диаграммы.
Еще пример
На диаграмме видно, что большинство выполненных задач находится в зоне контрольных границ, но 3 задачи выступают за их пределы. Кроме того, видно, что некоторые задачи находятся близко к средней, а некоторые задачи расположены выше или ниже ее, ближе к контрольным границам.
Если задача находится в пределах контрольных границ – это нормальное поведение системы. В этом случае действует правило трех сигм. Оно звучит так: с крайне высокой вероятностью случайная величина не отклонится от своего среднего значения более, чем на три сигмы. А сигма – это среднеквадратическое отклонение, про которое мы уже рассказывали выше. Соответственно, верхняя и нижняя контрольная границы = + и — 3 сигмы.
Что делать: можно ничего не делать, такие показатели считаются допустимыми. Но если вы хотите улучшить свою систему и сделать Lead или Cycle Time запросов еще меньше, то вам нужно серьезно заняться улучшением процессов. Вам нужно искать узкое звено производственной системы.
Узкое звено производственной системы – это этап рабочего процесса с самой низкой пропускной способностью. Нужно увеличить пропускную способность в этом этапе, чтобы вся система стала работать быстрее, но уперлась в другое узкое звено. Как это может выглядеть: вы наняли еще одного программиста, чтобы на этом этапе быстрее проходило больше задач и не тормозились другие проекты.
Если задача находится за пределами контрольных границ – это аномалия.
Что делать: разбираться отдельно в этой ситуации, чтобы понять, почему задача делалась так долго. Нужно анализировать ход задачи, смотреть, какой Cycle Time у каждого из ее этапов, чтобы понять, на каком из них она задержалась и почему. Например, заболел заказчик и долго не мог принять задачу, отчего она долго находилась на этапе «Приемка». Cycle Time этапа «Приемка» вырос, как и вырос весь Lead Time задачи.
А ситуаций, когда задача делается слишком быстро, практически не возникает..
Теперь давайте рассмотрим примеры поведения системы, которые с большой вероятностью могут повстречаться вам в жизни. Они будут характерно выражены на диаграмме.
👉 Читайте также: «Системный подход к использованию Канбан: разбираемся как нам поможет STATIK»

Частые паттерны контрольной диаграммы

Затруднения в производственном процессе

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

Ускорение процесса

В этом случае Lead Time задач будет снижаться.
Паттерн, противоположный предыдущему
Например, такое может быть, если для работы над продуктом только собрали команду. У нее ушло некоторое время на то, чтобы сработаться и выполнять задачи быстрее.

Стабильная система

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

Скопления задач

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

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

Напутствие
Анализируйте контрольную диаграмму по разным срезам. Например, вы можете изучить Cycle Time каждого из циклов вашего производственного процесса. Также вы можете сравнить контрольные диаграммы у задач разного рода. Или еще сценарий: можно сравнить сотрудников одной должности и понять, кто из них работает продуктивнее. Экспериментируйте, чтобы выявлять полезные инсайты.
А если вам необходимо профессиональное внедрение современных управленческих практик – обратитесь за бесплатной консультацией в Neogenda.
]]> Что такое продукт, в чем его отличия от проекта и что значит слово «продуктовый» http://neogenda.ru/blog/ph1xyptei1-chto-takoe-produkt-v-chem-ego-otlichiya http://neogenda.ru/blog/ph1xyptei1-chto-takoe-produkt-v-chem-ego-otlichiya?amp=true Thu, 10 Oct 2024 21:50:00 +0300 Артур Нек У людей, которые слабо знакомы с миром IT, слово «продукт» ассоциируется с какой-то едой –...

Что такое продукт, в чем его отличия от проекта и что значит слово «продуктовый»

У людей, которые слабо знакомы с миром IT, слово «продукт» ассоциируется с какой-то едой – по себе сужу и думаю, что прав. Это как в детстве, когда мама говорила: «Сходи в магазин, купи продуктов». Сейчас бы я про себя подумал: «Каких продуктов, мама, ты хоть представляешь, сколько это будет стоить?!» Так что же такое продукт и что может быть продуктом?
С точки зрения бизнеса, продукт – это нечто, создаваемое для удовлетворения потребностей или желаний целевой аудитории, а также получения прибыли. Можно сказать, что это классическое определение продукта в маркетинге. Продуктом может быть физический товар, услуга, программное обеспечение или даже информация. В общем, и булка хлеба, и сервис Spotify – продукты.
Что вы еще узнаете:
  • что вмещает в себя понятие «продукт»;
  • как можно классифицировать продукты по разным признакам;
  • что такое жизненный цикл продукта и почему продукт не может существовать вечно;
  • чем продукты в IT отличаются от проектов и что значит понятие «продуктовый».
Прежде, чем перейти к сути, коротко расскажем о себе. Neogenda – это консалтинговая фирма, которая специализируется на внедрении современных управленческих практик. Мы работали с такими гигантами как Тинькофф, Сбер, Яндекс, Точка, X5 Group и многими другими компаниями, о которых вы точно слышали. Если вы хотите достичь лучших результатов за счет совершенствования бизнес-процессов – обратитесь за бесплатной консультацией в Neogenda. Мы оказываем более 100 различных услуг: от обучения персонала до реорганизации бизнеса.
👉Читайте также: «Что такое роадмап проекта, как его сделать и в чем его отличие от продуктового роадмапа»

Что вмещает в себя понятие «продукт» и из чего он состоит

Мы выяснили: люди используют продукты, чтобы удовлетворить свои потребности или желания. Но, чтобы охарактеризовать продукт, недостаточно знать его полезное действие. Ведь одну задачу могут решить разные продукты: скажем, шуруп можно закрутить как отверткой, так и шуруповертом.
Потребителю все равно, как продукт решает задачу: главное, чтобы он делал это хорошо и выгодно для него. Клиент покупает продукт, если тот обладает для него достаточной ценностью. Ценность продукта – это соотношение его стоимости к полезному действию. То есть, если продукт хороший и при этом продается по выгодной цене, потребитель его купит. Полезное действие продукта может выражаться в разных свойствах: функциональности, качестве, престижности, соответствию трендам и так далее.
Важно понимать, что ценность продукта субъективна – она зависит не только от него, но и от потребителя. Например, двум людям по разным причинам может не нравиться одна и та же модель авто.
Чтобы создать ценный продукт, нужно точно знать, что именно нужно вашей целевой аудитории. Если попадете в яблочко и продукт будет выгодным, его оторвут с руками и ногами

Пятиуровневая модель Котлера-Келлера

Чтобы было проще выявить разные свойства, которые делают продукт ценным, можно использовать пятиуровневую модель Филипа Котлера и его коллеги Кевина Келлера. Котлер – выдающийся американский экономист и маркетолог, который является одним из родоначальников классического маркетинга. Его книга «Основы маркетинга» имеет статус культовой: по ней преподают в университетах. В общем, модели можно доверять, пока кто-то не придумал более удобную классификацию.
Единственное, модель рассказывает не о продуктах, а о товарах. Но это смежные понятия, которые во многом означают одно и то же. Если говорить, чем отличается продукт от товара, то можно сказать, что товар – всегда физический объект, а продукт – это некая ценность, которую покупают пользователи. Но поскольку товар – это всегда продукт, созданный для продажи, можно выявить ценность и у товара.
В общем, «товар» является частным от более широкого понятия «продукт». Но, несмотря на это, модель Котлера-Келлера, классифицирующая товары, применима и к продуктам.
Наглядная схема уровней, из которых состоит продукт
Из каких уровней состоит продукт, если исходить из модели Котлера-Келлера:
  • 1. Основная польза.
Это главная задача, которую потребитель выполняет с помощью продукта.
Пример. Основная функция приложения доставки еды – заказ еды с доставкой онлайн.
  • 2. Базовый продукт.
Сюда относятся функции, которые, по мнению потребителя, точно должны быть у продукта. Мнение потребителя складывается из стандартов, которые задают другие, такие же продукты.
Пример. В приложении Яндекс Еда есть возможность заказа из разных ресторанов, фильтры по типу кухни, рейтинги ресторанов, их меню, возможность отслеживания статуса заказа и так далее. Если на рынок выходит новый агрегатор доставки еды, искушенные пользователи ожидают, что в нем будут все эти фичи. Поэтому запускать новый продукт нельзя без качеств продукта, устоявшихся на рынке – он разочарует потребителей, потому что он хуже, нежели продукты конкурентов.
  • 3. Ожидаемый продукт.
Так называют функции и характеристики, которые пользователи ожидают от продукта.
Пример. От приложения доставки еды ожидают, что его курьер приедет с заказом быстро и ничего не напутает.
  • 4. Дополненный продукт.
В этом случае речь идет о функциях, которых нет у конкурентов. Они должны расположить клиента к продукту.
Пример. У приложения может быть чат-бот для помощи в выборе блюд, который будет отвечать на вопросы клиента, предоставляя информацию о меню и ингредиентах блюд.
  • 5. Потенциальный продукт.
Так называют все изменения, которые компания может внести в свой продукт в будущем. Изменения направлены на повышение удовлетворенности клиентов и удержание их вовлеченности за счет постоянного улучшения продукта. Как правило, клиенты даже не могут представить, что продукт может обладать подобной возможностью.
Пример. Использование AR для показа блюд в реальном размере и виде перед заказом. Люди смогут увидеть, как блюдо будет выглядеть на их столе. Или ИИ, который будет создавать персонализированное меню на основе вкусов и предпочтений пользователя, а также анализа данных о его здоровье.
В общем, продукт может быть сколь угодно сложным и решать сразу много задач. Чтобы лучше усвоить особенности сложного продукта и его устройства, можно выделить еще одну сущность – подпродукт. Чаще всего так называют часть продукта, которая удовлетворяет потребность, отличную от основной части продукта. Например, подпродуктом приложения ВКонтакте может быть сервис VK Музыка, который является частью общего сервиса, но при этом даже имеет свое отдельное приложение. Еще важной отличительной чертой подпродукта будет наличие собственной ключевой метрики. Можно предположить, что ключевая метрика сервиса ВКонтакте – количество пользователей, а у VK Музыки это будет количество платящих пользователей.
А какие виды продуктов можно выделить? Здесь мы также обратимся к привычной нам экономике с ее классификацией товаров, которая подойдет и для продуктов. Выделим самое важное, чтобы не надушнить тут излишней теорией.
👉 Читайте также: «Agile, Scrum, Kanban и Waterfall – что выбрать вашему бизнесу»

Классификация продуктов

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

По поведению потребителя

  • Повседневного спроса.
Сюда относятся те продукты, которыми мы пользуемся каждый день: например, смартфон, сервис подписки на музыку или гель для душа. Продукты повседневного спроса можно дополнительно разделить на два типа: постоянного и импульсивного спроса. Продукты постоянного спроса – это кофе, который каждый день вы покупаете в кофейне рядом с работой. Продукты импульсивного спроса – это безделушки на Wildberries, которые вы покупаете, чтобы поднять свой уровень дофамина.
Если говорить о digital-продуктах, то продукт постоянного спроса – это соцсети, а продукт импульсивного спроса – какая-нибудь онлайн-игра.
  • Тщательного выбора.
Это дорогие продукты, которые призваны служить долго: поэтому их подбирают обдуманно, сравнивая плюсы и минусы у разных вариантов. Пример такого продукта: автомобиль.
  • Пассивного спроса.
Это те продукты, о которых потребитель не знает, либо не задумывается до того момента, пока этот продукт ему не понадобится. Пример: страхование КАСКО для авто, которое никому не нужно до момента покупки автомобиля.
👉 Читайте также: «Управление портфелем проектов: как устранить неразбериху в проектах вашего бизнеса»

По длительности использования

  • Кратковременного пользования.
Это продукты, которые заканчиваются за один или несколько циклов использования, после чего нужно брать новый продукт. Если говорить о физических продуктах, то это пища или средства личной гигиены, а если о цифровых – токены нейросети Midjourney, которые нужно докупать.
  • Долговременного пользования.
Так называют продукты, которые служат долго. Если говорить о цифровых продуктах, это может быть ПО с лицензией бессрочного использования: например, программа Adobe Photoshop.

По бизнес-модели

  • B2B (Business to Business): это взаимодействие между компаниями: например, производителями и их поставщиками. Пример продукта: маркетплейс, на котором регистрируются селлеры, чтобы продавать свои товары.
  • B2C (Business to Consumer): между компанией и конечным потребителем. Пример продукта: тот же маркетплейс, ведь он ориентирован и на конечных потребителей, что покупают на нем товары.
  • C2B (Consumer to Business): модель, при которой потребители предлагают товары или услуги бизнесу. Пример: фриланс-платформа, где люди предлагают свои услуги компаниям.
  • C2C (Consumer to Consumer): взаимодействие между конечными потребителями. Пример: classified-платформа для обмена или продажи товаров между пользователями, такая как Avito.
  • B2G (Business to Government): взаимодействие между бизнесом и государственными учреждениями. Пример: Единая информационная система в сфере закупок, на которой государственные учреждения публикуют свои закупки, а компании могут подавать заявки на участие в тендерах.
  • G2B (Government to Business): взаимодействие между государственными учреждениями и бизнесом. Пример: Госуслуги, на которых есть функции для бизнеса: например, регистрация юридического лица.
  • G2C (Government to Consumer): взаимодействие между государственными учреждениями и гражданами. Пример: те же Госуслуги, только в данном случае речь идет о их сервисах для физических лиц.
Иногда встречаются смешанные формулировки бизнес-моделей: например, B2B2C. К такой модели можно отнести маркетплейс, который работает и с селлерами и с конечными потребителями.
👉 Читайте также: «Постигаем гибкие методологии: что такое Agile и почему все хотят по нему работать»

Жизненный цикл продукта

Ни один из продуктов не может существовать вечно – виной тому изменения во внешней среде. Пример: магнитофоны, которые уступили современным акустическим системам, работающим от компьютера или умным колонкам. Продукты могут устаревать из-за высокой конкуренции, развития технологий, изменений в потребительском поведении и много чего еще. Поэтому важно знать концепцию жизненного цикла продукта и применять ее у себя. А еще постоянно изучать конкурентов.
Жизненный цикл продукта – это концепция, описывающая стадии, через которые проходит продукт от момента его разработки до выхода из рынка.
На схеме отражены стадии жизненного цикла продукта, а также зависимость прибыли и объема продаж продукта от конкретной стадии
Интересный факт: вы молодец, если ваш продукт прошел все стадии и принес прибыль вашей компании. Примерно 9 из 10 продуктов умирают на стадии его выхода на рынок, так и не оправдывая ожиданий владельца. И далеко не факт, что это потому, что продукт плохой – на успех влияет множество различных факторов. Например, у стартапа может просто не хватить бюджета на продвижение: он не успеет выйти на окупаемость до зрелости, отчего расходы сильно превысят доходы и продукт уйдет из рынка.

Стадии жизненного цикла продукта

  1. Разработка. На этом этапе происходит исследование идеи, а также проектирование и тестирование MVP – минимально жизнеспособной версии продукта, наделенной основными функциями.
  2. Выход на рынок. На данном этапе основные работы ведутся над продвижением продукта, чтобы вывести его на рынок. Задача продвижения: разрекламировать новый продукт в той отрасли, к которой он относится или вообще сформировать спрос для продукта из инновационной отрасли. Продажи будут низкими, так как потребители пока плохо знакомы с продуктом.
  3. Рост. Продукт начинает набирать популярность и продажи растут. В этот период компания будет увеличивать бюджеты на продвижение. Если продукт физический, то с ростом спроса на него кампания будет масштабировать производство. Или постоянно работать над улучшением продукта, если он цифровой. Если продукт сформировал новую нишу, примерно в это же время на рынок начнут выходить его конкуренты. Пример: анонс ИИ-сервиса Claude после выхода Chat GPT.
  4. Зрелость. На этом этапе продажи достигают своего пика, а рынок становится насыщенным. Конкуренция усиливается, отчего компания будет наращивать ценность продукта или снижать цены, чтобы удержать потребителей. На этом этапе важно хорошо проанализировать конкурентов, чтобы улучшить продукт и разработать маркетинговую стратегию, в которой вы сможете остроиться от конкурентов. Сделав это, вы будете зарабатывать больше с продажи продукта
  5. Спад. Продажи начинают снижаться из-за изменения предпочтений потребителей, а также появления новых технологий или продуктов. Стадию спада нужно спрогнозировать заранее, чтобы во время ее начала уже работать над новым продуктом, который соответствовал бы изменениям на рынке. Многие компании теряют прибыль как раз из-за того, что не учитывают стадию спада спроса на свой продукт.
  6. Уход с рынка. На этом этапе продукт окончательно выводится с рынка. Чаще всего продукт уводят в тот момент, когда работа над ним вот-вот станет убыточной. Чтобы правильно управлять процессом ухода, важно обеспечить плавный переход клиентов на новый продукт. Так получится минимизировать негативное воздействие на клиентов. Для этого компания должна активно продвигать новые продукты, а также информировать потребителей о прекращении производства старого.
Фух, с дидактической частью разобрались, теперь перейдем к самому интересному.

В чем отличие проекта от продукта и что значит понятие «продуктовый»

В IT сейчас есть проектные и продуктовые менеджеры. И те, и те занимаются по сути одним и тем же – контролем команды и ходом разработки цифровых продуктов: сайтов или приложений.
Неопытный человек, изучив вакансии разных менеджеров на сайте, может не увидеть разницы. Даже многие работники цифровой отрасли, те же маркетологи или дизайнеры, до сих пор не могут понять, чем они отличаются и часто используют термины некорректно. Например, я встречал веб-студии, где менеджеров, которые вели проекты, почему-то называли продуктовыми 🙂
И вообще: тут и там стали все чаще использовать слово «продуктовый», добавляя его к чему ни попадя. Например, появились продуктовые маркетологи – чем они отличаются от обычных?
А вот чем. Мы уже знаем, что такое продукт: что-то ценное, со своим жизненным циклом, по завершению которого продукт «умирает». А проект – это какая-то деятельность, которая имеет начало и конец. Это деятельность с установленными границами, по завершению которых проект считается выполненным. И в этом и есть отличительная черта столь разных понятий: если проект имеет установленный конец, то работы над продуктом ведутся вплоть до отрицательного события – «смерти в зародыше» или в окончании всего жизненного цикла.
Из этого следует, что проектные и продуктовые команды отличаются между собой подходами: проектные команды завершают согласованные работы в срок, а продуктовые команды работают над продуктом вплоть до его ухода из рынка. При этом в рамках работы над продуктом могут выполняться отдельные проекты. Над такими проектами могут работать специалисты из продуктовой команды или подрядчики на аутсорсе.
Вот и выходит, что продуктовые маркетологи, дизайнеры и другие сотрудники – это те, кто работают в продуктовой команде, постоянно работая над задачами, связанными с продуктом. Их ключевое отличие в том, что работают в рамках Agile-подхода – непрерывного процесса, где работа над продуктом ведется постоянными итерациями. В этом случае организационный процесс команды выстраивается в рамках фреймворков, предназначенных для работы над продуктом, таких как Scrum.
Вот и все. Если хотите узнать подробнее, как именно выстраивается работа над продуктом, рекомендуем к прочтению статьи, в которых мы пишем на эту тему:
А если вы вдруг осознали, что вам нужна хорошая продуктовая команда, но вы не знаете, как правильно выстроить организационные процессы – обратитесь за бесплатной консультацией в Neogenda. Мы внедряем современные управленческие практики в крупные компании, за счет чего они быстрее и эффективнее достигают поставленных целей.
Немалая часть информации для статьи была взята из выступления Елены Кузнецовой «Что такое продукт».
]]> Кто такой Project Manager и чем он занимается http://neogenda.ru/blog/0drub9bn21-kto-takoi-project-manager-i-chem-on-zani http://neogenda.ru/blog/0drub9bn21-kto-takoi-project-manager-i-chem-on-zani?amp=true Wed, 16 Oct 2024 21:54:00 +0300 Артур Нек При создании нового проекта тяжело контролировать все процессы: следить за командой, генерировать идеи и успевать...

Кто такой Project Manager и чем он занимается

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

Кто такой project manager

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

Чем занимается Project manager

Ставит задачи команде. Создание любого проекта состоит из нескольких задач. А каждая задача — из нескольких подзадач. Роль проджект-менеджера — разбить проект на подзадачи и объяснить каждому члену команды, что нужно сделать. А затем — установить сроки, в которые задача должна быть выполнена.
Планирует сроки и ресурсы. Чтобы успеть в срок, project manager создает подробный план проекта и определяет, сколько времени уйдет на выполнение каждой подзадачи. Также он распределяет людей, деньги и другие ресурсы. А еще учитывает возможные риски.
Контролирует бюджет проекта. Менеджер проектов должен контролировать бюджет проекта, вести переговоры по ресурсам и оценивать стоимость задач, чтобы не потратить больше оговоренной суммы.
Контролирует выполнение задач. Он проверяет ход решения задачи и определяет, успевает ли команда сделать все в срок. Если что-то идет не по плану, project manager его корректирует. Например, перебрасывает больше ресурсов на решение первоочередной задачи.
Общается с командой и заказчиками. Project manager — связующее звено между заказчиком и командой. Он регулярно общается с клиентом и рассказывает о ходе работы. Также проводит встречи с командой, чтобы знать, на каком этапе находится проект.
Ведет документацию. Специалист ведет документацию с описанием процессов и архитектуры продукта. Разрабатывает стандарты и шаблоны. А также контролирует документооборот, следит за подписанием счетов и договоров, готовит отчеты.

Чем проджект менеджер отличается от продакт менеджера?

Специалистов часто путают и думают, что они решают одинаковые задачи. На самом деле это не так. Чтобы понять различия было проще, давайте представим процесс строительства дома.
В этом случае проджект менеджер — человек, который следит за стройкой. Он заказывает материалы и нанимает рабочих. А в процессе контролирует, чтобы дом построили к сроку.
А продакт менеджер работает шире — он решает, каким будет этот дом. Где он будет построен, сколько в нем будет комнат и в какой планировке. Он думает, кто будет жить в доме. И что этим людям нужно.
Получается, продакт менеджер генерирует идею и максимально ее прорабатывает. А project manager помогает эту идею осуществить. То есть, работает с конкретной задачей. И когда ее выполняет — переходит к следующей.
Отличия продакт и проджект-менеджера

Какими навыками должен обладать хороший проджект менеджер

Все навыки можно разделить на 2 группы:
  1. Универсальные — те, которые нужны любому специалисту.
  2. Профессиональные — те, которые нужны именно проджект-менеджеру.
Универсальными навыками считаются:
Стрессоустойчивость. Один из самых важных факторов, потому что иногда нужно быстро вносить правки в план, переделывать задачи и контактировать с большим количеством людей. И если не подходить к этому с холодной головой, можно быстро получить выгорание.
Организационные способности, чтобы планировать и расставлять приоритеты. Вести за собой команду и делать так, чтобы в коллективе не было проблем.
Коммуникативность, чтобы общаться с заказчиками и клиентами. Доносить свою мысль и правильно объяснять, что нужно от человека.
Владение английским языком от уровня B2 (Upper-Intermediate) и выше. Большинство сервисов, в которых работают проджект-менеджеры — зарубежные. И для работы с ними нужно понимание английского, терминов и сленга. А если компания работает в несколько странах — для коммуникации между отделами.
Профессиональные навыки — еще одна важная часть умений. От них зависит, с проектами какой сложности справиться project manager и какого результата от него можно ожидать. Профессиональные навыки можно разделить на 2 группы:
  • те, что относятся к управлению проектами;
  • те, что связаны со спецификой отрасли.
Для работы с проектами хороший специалист должен:
Знать методы управления проектами. В проджект-менеджменте есть разные подходы к работе: Waterfall, Agile, Scrum, Kanban. Проджект-менеджер должен уметь работать с каждым из методов и выбирать подходящий под конкретную задачу. Например, Waterfall подходит для четких задач. Agile — для гибких проектов. Scrum помогает работать короткими циклами, а Kanban помогает визуализировать процесс работы.
Обладать навыками тайм-менеджмента и приоритизации. Проджект-менеджер умеет планировать рабочий день и верно определять сроки выполнения задач. В этом ему помогают техники тайм-менеджмента вроде матрицы Эйзенхауэра, 2-минутного правила или метода Помодорро. В приоритизации специалист использует методы критического пути, MoSCoW-анализ и др.
Типичный рабочий день проджект менеджера (шутка)
Анализировать и оценивать риски. Для этого специалисты используют спираль рисков, которая показывает ранжирование рисков в зависимости от степени их вероятности и влияния на проект. Используют SWOT-анализ, чтобы определить слабые и сильные стороны проекта и т. д.
Работают с инструментами для управления задачами. Чтобы организовывать работу команды. Для этого проджект-менеджеры настраивают доски в Битрикс или других CRM-системах и продумывают логику распределения задач.
Визуализируют информацию. Например, через диаграммы Ганта, которые показывают очередность и сроки выполнения задач. Также они строят интеллект-карты или наглядно распределяют обязанности в команде с помощью матриц ответственности.
Работают с данными. Проджект-менеджеру полезно понимать основы работы с базами данных, чтобы уметь делать простые SQL-запросы для получения данных или создания отчетов.. Это важно при интеграции систем, работе с аналитикой или оптимизации процессов, где базы данных играют ключевую роль.
Уметь определять стейкхолдеров (заинтересованные стороны). Менеджер проектов составляет карту стейкхолдеров — документ, где подробно расписаны все заинтересованные стороны, их ожидания, влияние на проект и степень заинтересованности в нем.
Специфические навыки перечислить не получится — для каждой отрасли они свои. Например, в IT хороший проджект-менеджер знает терминлогию, умеет писать и читать код. Знает фреймфорки, библиотеки и понимает процессы разработки. В eCommerce он понимает процессы складского учета, принципы управления заказами, умеет работать с CRM-системами и т. д.

Сколько зарабатывают проджект-менеджеры

По данным сервиса GetMatch, медианная зарплата проджект-менеджеров равна 200 000 рублей. Большая часть специалистов получает около 150 000 рублей, но есть и те, кто получает больше полумиллиона в месяц.
А по данным Хабр Карьеры, в среднем менеджер проектов зарабатывает от 170 000 руб., плюс премия. Зарплата стажёра начинается от 54 000 руб., начинающий специалист получает от 88 000 руб. Lead может получать 320 000 руб. и больше.

Как стать проджектом

Посещать тренинги и консультации. Например, в Neogenda есть учебные программы, которые обучают современным методам менеджмента: Канбан, OKR, Agile, Scrum, Flight Level, SAFe, LeSS. На тренингах дают базу, которой хватит новичкам, а также делятся информацией для опытных специалистов. Дают доступ в Telegram чат со специалистами и предоставляют персонального менеджера.
Поступить в университет. Обучить профессии можно в РАНХиГС, МТИ, СПбГУ и др. Также можно пройти курсы переподготовки.
Читать статьи. Например, статьи в блоге Neogenda. Либо профессиональную литературу: Дж. Хигни «Основы проектного менеджмента. Классическое руководство», М. Барроуз «Канбан Метод. Улучшение системы управления», Р. Пихлер «Управление продуктом в Scrum. Agile-методы для вашего бизнеса», З. Шохова «Путь Scrum-мастера».

Плюсы и минусы работы Project manager

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

Что в итоге

  • Project Manager — это человек, который управляет проектом от начала до конца. Его задача — организовать работу команды, следить за выполнением задач и решать возникающие проблемы.
  • Project Manager должен уметь планировать, распределять ресурсы и контролировать сроки выполнения работы.
  • Project Manager ставит задачи команде, планирует сроки и ресурсы, контролирует выполнение задач и общается с командой и заказчиком. Он ведет документацию, разрабатывает стандарты и шаблоны, контролирует документооборот и готовит отчеты.
  • Продакт-менеджер и проджект-менеджер — разные профессии. Первый генерирует идею и максимально ее прорабатывает, а второй помогает эту идею осуществить.
  • Хороший проджект менеджер должен обладать стрессоустойчивостью, организационными способностями, коммуникативностью, владеть английским языком и знать методы управления проектами.
Если вам нужно обучить проджект-менеджера для процессов компании – обратитесь в Neogenda. Мы являемся экспертами по современным подходам и методам менеджмента. За нами более 100 успешных управленческих кейсов и 5 000 обученных сотрудников в таких компаниях, как Tinkoff, Яндекс, Авито, Сбер, Билайн, Skyeng и так далее. Оставьте заявку на бесплатную консультацию в Zoom – мы предложим лучшее решение для вашей задачи.
]]> Скрам или Канбан: что выбрать? http://neogenda.ru/blog/kx8ysngd91-skram-ili-kanban-chto-vibrat http://neogenda.ru/blog/kx8ysngd91-skram-ili-kanban-chto-vibrat?amp=true Thu, 17 Oct 2024 22:00:00 +0300 Алексей Пименов Типовой вопрос, который я часто слышу от новичков: В чем разница между Скрам и Канбан,...

Скрам или Канбан: что выбрать?

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

Как действовать в такой ситуации?

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

Почему Скрам?

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

Как начать использовать Скрам?

Для того, чтобы использовать Скрам, вам в первую очередь нужна команда специалистов, которые будут заниматься продуктом. Например, инженеры.
И к этой команде вам еще нужен Скрам Мастер.
Скрам Мастер — это в неком смысле командный психолог, задача которого наладить эффективную командную работу в рамках Скрама.
Также вам нужен Владелец Продукта — человек, на ком висит ответственность за тем, что должно быть сделано. Он должен прекрасно знать рынок и вести бэклог продукта, где собраны все запросы потенциальных клиентов к продукту в некотором упорядоченном списке.
И вот эта команда работает в итеративной манере, инкрементально поставляя функциональность клиенту.
Итерации длятся обычно от 2 до 4 недель, типовая итерация по рынку обычно 2 недели. Команда выбирает этот цикл и в нем работает.
Кроме того, необходимо проводить и другие события.
Ежедневный Скрам — это «статусные собрания», где вы инспектируете, как вы двигались к цели вашей текущей итерации и намечаете план (или меняете план), как двигаться к цели итерации до следующего собрания.
Также есть события, связанные с планированием итерации. События с анализом того, как вы поработали — ретроспектива итерации. Да и сами итерации в Скрам называются Спринтами.
Также есть события получение обратной связи от клиента, которое называется Обзор спринта.
Канбан Метод в свою очередь не диктует каких-то конкретных ролевых моделей и потребностей по формированию команды.
Это инструмент, который позволяет вам провести аудит текущих процессов, провести так называемую канбанизацию — описание текущего вашего процесса работы в виде канбан-системы.
Дальше там есть определенный набор мероприятий по поиску проблем, например: узких звеньев, ресурсов непостоянной доступности или зависимостей.
И инструментарий, который позволяет вам эти проблемы решать, такие как ограничение количества незавершенной работы, различные события, связанные с циклами получения обратной связи. Например, статусные собрания, где вы инспектируете, как у вас идет работа. Движутся ли запросы, которые вы реализуете, к финишу, что мешает им двигаться, кто требуется для следующих действий и т.п.
Есть определенный ряд событий, связанных с улучшениями процесса, где вы смотрите, что вы поставили клиенту, был ли клиент доволен, что стоит улучшить.
  • Концептуально Скрам предписывает определенный формат работы, задает костяк вашего процесса, и это называется фреймворк.
  • Канбан скорее про изучение того, как вы работаете сейчас, найти проблемы и попытаться их устранить.
Эти два подхода можно у себя совмещать. Один из частных случаев совмещения этих подходов называется скрамбан. Не многие знают, но у скрамбана есть автор и есть даже определение.
Автором является Кори Ладас, а определение Скрамбана — это использование Канбан Метода в зрелом Скрам-процессе.
Какая здесь идея? Все просто! Вы используете скрам, он приносит пользу и вы реализуете продукт и совершенствуете свой производственный процесс, но в какой-то момент времени инструментов скрама вам может начать не хватать, чтобы достигать целей клиента, то вам нужны дополнительные инструменты.
Начните использовать Канбан Метод, не разрушая Скрам-процесс, то есть не отменяя ни одну из Скрам-практик или Скрам-событий.
Этот процесс работы называется Скрамбан. Как только вы отказались от чего-то, что входит в состав скрама, это уже не будет Скрамбаном, это будет уже каким-то вашим своим производственным процессом.
Если вам требуется консультация или консалтинг бизнеса по внедрению одной из методологий управления — обратитесь в Neogenda. Оставьте заявку на бесплатную консультацию в Zoom, и мы поможем вашему бизнесу найти новые точки роста и оптимизировать процессы.
]]> Story Points в Scrum и Agile: что это и зачем нужно бизнесу http://neogenda.ru/blog/fyumcg32j1-story-points-v-scrum-i-agile-chto-eto-i http://neogenda.ru/blog/fyumcg32j1-story-points-v-scrum-i-agile-chto-eto-i?amp=true Tue, 22 Oct 2024 22:02:00 +0300 Артур Нек Узнайте, как правильно оценивать задачи в рамках Scrum и Agile, чтобы команда работала слаженно, а...

Story Points в Scrum и Agile: что это и зачем нужно бизнесу

Узнайте, как правильно оценивать задачи в рамках Scrum и Agile, чтобы команда работала слаженно, а ее продуктивность росла. Один из ключевых инструментов для этого — Story Points. Это особая метрика, которая помогает оценивать сложность и объем задачи. Кроме того, учитывает навыки и опыт.
Story Points позволяют взглянуть на задачи не с позиции времени. Можно учитывать другие факторы, такие как неопределенность, риск и уровень сложности. Однако не получится оценить стоимость задачи, потому что сторипоинты не привязаны к конкретным временным и денежным ресурсам.
В этой статье подробно разберем, что означают Story Points и как правильно ими пользоваться в ежедневной практике. Обсудим, как этот инструмент помогает эффективнее планировать и закрывать задачи в Agile-проектах.
А внедрить актуальные практики управления поможет консалтинговая компания Neogenda. Среди наших клиентов — Тинькофф, Сбер, Яндекс, Точка, X5 Group. Предлагаем более 100 услуг — обучим персонал и даже проведем реорганизацию, если нужно. Чтобы привести бизнес к результату, сделайте первый шаг — обратитесь за бесплатной консультацией к практикам Neogenda.

Что такое Story Points

Story Points — это относительная мера, которая помогает оценить, сколько нужно работать, чтобы решать задачи в Agile-проектах. Чаще всего инструмент используют в Scrum и Канбан. Чтобы стало понятнее: прием user story(пользовательская история) описывает «что» продукт должен сделать для пользователя, а Story Points в Agile помогают определить, «насколько сложно» это сделать.
Относительная оценка помогает сравнивать разные задачи проекта между собой и не отвлекаться на точные временные затраты. Так, субъективность становится меньше, к тому же пропадает давление, которое вызывают точные дедлайны, и можно лучше прогнозировать этапы проекта в целом.
Чтобы оценить задачи, их сравнивают с уже выполненными. Для этого используют относительные категории сложности. Например, если одной задаче дали оценку в 1 сторипоинт, то задача с оценкой 3 сторипоинта должна быть как минимум втрое сложнее или дольше по времени.
При работе со Story Points оценка задач командой опирается на три фактора:
  1. сложность задачи — насколько трудно выполнить ее технически;
  2. объем работы — сколько действий или этапов нужно пройти, чтобы завершить задачу;
  3. неопределенность — насколько точно известны все требования и возможные проблемы.
Пример 1. Допустим, у нас появилась задача: разработать новую страницу регистрации пользователей.
Сложность: относительно низкая — основные шаблоны уже есть.
Объем работы: средний — нужно создать новую форму, обработать данные, провести тестирование.
Неопределенность: небольшая, так как требования четко определены.
Оценка: 5 Story Points.
Пример 2. Задача: устранить проблему с безопасностью в системе аутентификации.
Сложность: высокая — баг связан с критической частью системы.
Объем работы: низкий — нужно изменить несколько строк кода.
Неопределенность: высокая — возможно, понадобится дополнительное исследование.
Оценка: 8 Story Points.
Пример 3. Задача: увеличить скорость обработки запросов к базе данных.
Сложность: средняя — нужно провести анализ и внести изменения в запросы.
Объем работы: высокий — предстоит обработать большое количество запросов.
Неопределенность: средняя — известно, что проблема есть, но точное решение не сразу очевидно.
Оценка: 13 Story Points.
Такая оценка задач в Scrum и Agile позволяет команде лучше планировать спринты и распределять ресурсы.

Почему Story Points лучше человеко-часов

Для управления проектами и разработки программного обеспечения оценку задач в часах традиционно использовали, чтобы определить объем работы и выяснить, сколько времени это займет.
Однако в последние годы концепция Story Points набирает все большую популярность. Рассмотрим, чем она лучше привычного подхода с человеко-часами:
  • Абстрагируется от времени. Сторипоинты измеряют сложность и объем работы в относительных единицах. Не привязываются к конкретному времени. Это позволяет команде сосредоточиться на сложности задач, а не на предположениях о том, сколько времени они займут, — обычно здесь все крайне субъективно и изменчиво.
  • Учитывает неопределенность. Если оценивать задачу в Story Points, можно учитывать связанные с ней сложности, риски, неопределенности. А в человеко-часах легко переоценить время, которое нужно, чтобы решить проблему. Сторипоинты позволяют более гибко подходить к оценке.
  • Дает сравнительную оценку. Благодаря Story Points можно быстро сравнивать задачи, определять их относительную сложность. Планировать и распределять задачи становится проще — можно быстрее определить, что задача в два раза сложнее другой, и не пытаться точно спрогнозировать время выполнения.
  • Стимулирует командную работу. Оценка задач в Story Points часто связана с командным обсуждением, а это помогает лучше понять, что вообще требуется, и выстроить правильную коммуникацию. При этом оценка в человеко-часах больше направлена на индивидуальные показатели и не всегда учитывает коллективный опыт.
  • Адаптируется к изменениям. Когда в проекте что-то меняется, Story Points можно быстрее подстроить под новые условия. Если требования становятся другими или возникают новые сложности, команда может легко пересмотреть оценки. При этом она будет опираться на накопленный опыт и новые данные, но не станет пересчитывать предполагаемое время выполнения.
  • Оптимизирует процессы. Благодаря анализу прошедших спринтов и точности оценок в Story Points можно повышать эффективность и прицельнее планировать будущую работу. Чем опытнее команда, тем проще ей не только предсказывать сложность задач и свою производительность, но и настраивать процессы.
В отличие от человеко-часов, Story Points позволяют командам эффективнее управлять проектами, улучшать коммуникацию и адаптироваться к изменениям. Это делает планирование и выполнение задач более прозрачными и гибкими.

Какие преимущества у Story Points

Story Points — популярный инструмент оценки задач со множеством преимуществ, которые помогают командам эффективнее планировать работу и адаптироваться к изменениям:
  • Оценка сложности задач, а не времени
Как уже упоминали выше, Story Points — это оценка задач по их относительной сложности и объему работы, а не в часах и днях. Это позволяет команде сфокусироваться на усилиях, которые нужны, чтобы выполнить задачу. Не придется предсказывать точные сроки, что зачастую бывает сложно, если в проекте нет штатной гадалки с магическим шаром.
  • Адаптация к неопределенности
Story Points отлично учитывают неопределенность и риски, которые возможны, пока выполняется задача. Поскольку оценка не привязана к жесткому времени, команда легче приспосабливается к изменяющимся условиям или непредвиденным ситуациям.
  • Универсальность оценки разных типов задач
Задачи в проекте могут быть как простыми, так и крайне сложными. Story Points позволяют сравнивать их друг с другом. И на это не влияет специфика или тип задачи — разработка, тестирование, дизайн или что-то другое. Так что Story Points можно назвать универсальным инструментом.
  • Понимание количества времени
Когда команда накапливает опыт, она может оценить время выполнения задачи и начинает лучше понимать, что именно успеет выполнить за спринт. Значит, это повышает точность планирования и помогает избежать перегрузки или недогрузки.
  • Уменьшение давления на команду
Когда команда оценивает задачи в часах, то может ощущать давление, ведь нужно уложиться в определенные временные рамки. Story Points позволяют оценивать работу более абстрактно, поэтому стресс снижается, а гибкость в выполнении задач — растет.
  • Улучшение командной синхронизации
Поскольку задачи в Story Points часто оценивают коллективно, это налаживает общение внутри команды. Помогает лучше понимать как объем, так и сложность работы. Совместное обсуждение позволяет добиваться того, чтобы все члены команды понимали цель проекта и его этапов.
  • Учет производительности команды
Story Points — инструмент, с которым можно измерять и отслеживать производительность команды через такую метрику, как скорость (velocity). Это позволяет планировать спринты, прогнозировать завершение проекта и видеть прогресс по мере выполнения задач.
Пример графика Velocity (скорость команды), на котором отображены сторипоинты в сервисе Kaiten. Источник

Какие недостатки у Story Points

Несмотря на то, что Story Points широко применяют в Scrum и Agile, у этого подхода есть и свои недостатки:
  • Субъективность оценки
Story Points основаны на том, как команда воспринимает сложность задач. Такой подход легко назвать субъективным. Разные команды могут по-своему интерпретировать конкретную задачу, ведь даже внутри одной команды мнения часто расходятся. Поэтому возникают сложности, когда нужно сравнивать производительность команд или оценивать прогресс на протяжении нескольких спринтов.
  • Трудности при адаптации новых участников
Для новых участников команды может быть непросто сразу освоиться с такой системой оценки, как Story Points. Особенно если они привыкли к другим подходам. Новичкам нужно время, чтобы понять, как команда определяет относительную сложность задач, поэтому полноценно включиться в работу они смогут не сразу.
  • Непостоянство масштаба
Ключевой вызов, который бросают Story Points,— то, что у них нет четко определенного масштаба. Поскольку эта мера не привязана к конкретным единицам времени или точным метрикам, оценка в сторипоинтах может смещаться. Так происходит, например, когда команда становится опытнее и когда условия проекта меняются.
  • Неудобство для внешних заинтересованных лиц
Если клиенты или руководители не знакомы с Agile-подходом, они с трудом поймут, что такое Story Points. Им может быть сложно соотнести систему оценки с реальными сроками и ресурсами, а это усложняет коммуникацию и отчетность.
  • Ограниченная применимость для долгосрочного планирования
Story Points хорошо работают на коротких дистанциях, таких как спринты. Но могут быть менее полезны, когда нужно ставить долгосрочные цели или планировать крупные проекты.
  • Риск фокуса на скорости
Story Points могут стимулировать команды концентрироваться на том, как быстро они выполнят задачи, а качество продукта при этом уходит на второй план. Такой подход может снижать внимание к важным аспектам, таким как тестирование, документация или улучшение архитектуры.
Чтобы Story Points действительно помогали планировать, а не создавали дополнительные сложности, важно учитывать контекст проекта, организационную культуру команды, цели.

Какие существуют методы оценки задач в Story Points

Эталонная оценка «38 попугаев»

Метод «38 попугаев» подразумевает, что задачи сравнивают с неким эталонным объемом работы. Суть вот в чем. Команда выбирает какую-то одну задачу, но такую, которую точно знает, как выполнять. Она и становится точкой отсчета, например, в 5 Story Points. Чтобы оценить другие задачи, определяют, больше или меньше усилий относительно эталона потребуется для их реализации.
Этот подход напоминает сценку из мультфильма «38 попугаев», где длина измерялась в попугаях: один элемент — попугай — задает меру для сравнения.
Пример. Допустим, эталонную задачу оценивают в 5 Story Points. Значит, задачу, которая требует в два раза больше усилий, оценят в 10, а задачу, которая немного проще, — в 3 или 2 Story Points.
Теперь детальнее. Представим, что в команде есть эталонная задача — создание формы для регистрации на сайте. Эту задачу оценят в 5 Story Points, потому что она требует проработки интерфейса, валидации данных, подключения к серверу и тестирования.
Дальше рассмотрим более сложную задачу — разработку личного кабинета для пользователя. Здесь уже больше функций: авторизация, интеграция с базой данных, возможность редактирования профиля и загрузки файлов. Поскольку работа в этом случае значительно сложнее, задачу можно оценить в 10 Story Points.
Для сравнения возьмем более простую задачу — добавление новой кнопки на существующую страницу и ее стилизация. Здесь работы уже меньше, не нужна сложная логика или взаимодействие с базой данных, поэтому задаче можно присвоить 2 или 3 Story Points.

Относительная оценка по методу Фибоначчи

Этот метод использует последовательность чисел Фибоначчи — 1, 2, 3, 5, 8, 13, 21 и т.д. Чтобы оценить задачи по их относительной сложности и объему работы, используют числа этой шкалы.
Особенность метода вот в чем: каждое следующее число — это сумма двух, стоящих перед ним. С ростом чисел различие между оценками увеличивается, что помогает точнее разделять задачи по степени сложности, особенно когда они становятся крупными.
Пример. Простая задача, которую можно выполнить за несколько часов, получит оценку 3. Более сложная, на которую потребуется несколько дней, оценят на 8. А задача, которая не до конца понятна и требует значительных ресурсов, может получить оценку 21.
Теперь добавим деталей и рассмотрим задачи, связанные с подготовкой к корпоративному мероприятию.
Простая задача — заказать ручки, блокноты и остальные канцелярские принадлежности для участников. Это стандартная и доступная задача, которую можно выполнить за несколько часов. Просто нужно связаться с поставщиком и оформить заказ. Оценка — 3 по методу Фибоначчи.
Более сложная задача — организовать трансфер для участников мероприятия из разных точек города. Здесь потребуются координация с транспортными компаниями, а еще учет расписания и количества людей. Это займет несколько дней работы. Такую задачу можно оценить в 8 Story Points.
Задача с высокой неопределенностью — разработка программы мероприятия с приглашенными спикерами, где необходимо согласовать их участие, подготовить технические средства и учесть множество других факторов. Здесь есть разные переменные, которые требуют больших ресурсов и времени. Поэтому оценка может быть равна 21.

Оценка по размеру футболок

Метод «Размер футболок» предполагает оценку задач по категориям: XS (extra small), S (small), M (medium), L (large), XL (extra large) и т.д. Этот инструмент дает более абстрактные оценки, которые подходят для этапов планирования, когда команда не до конца понимает всех детали задачи. Каждый размер символизирует относительный объем работы и сложность задачи.
Пример. Очень простую задачу, которую можно решить быстро, команда оценит как XS. Средняя задача, на которую нужно потратить день-два, получит оценку M. Крупная и сложная задача, которая может потребовать значительных усилий или длительного времени, — L или XL.
Давайте теперь рассмотрим задачи по организации фестиваля на открытом воздухе.
Очень простая задача (XS) — закупить одноразовую посуду для фуд-кортов. Это стандартная задача, она не требует много времени или ресурсов. Чтобы ее быстро решить, нужно заказать товары у проверенных поставщиков.
Средняя задача (M) — координация работы волонтеров во время фестиваля. Здесь уже распределение обязанностей, составление графиков и обеспечение людей инструкциями. Это займет день или два и потребует умеренных усилий.
Крупная задача (L) — аренда сцены, звукового и светового оборудования, привлечение подрядчиков, которые все установят и будут обслуживать на протяжении всего фестиваля. Здесь необходимо согласовать множество деталей, включая логистику, технические требования и безопасность. Это делает задачу более сложной и ресурсозатратной.
Очень крупная задача (XL) — обеспечение безопасности мероприятия. Нужно работать с охранными агентствами, местными властями, составить план эвакуации, организовать медицинские посты.
Эта задача требует значительных усилий, координации различных служб и может занять недели подготовки.

Как оценить размер задачи в Story Points

1. Определите, какие размеры использовать
Сначала команда должна договориться, какие значения Story Points (SP) будет использовать, чтобы оценивать задачи. Чаще всего выбирают последовательность чисел Фибоначчи, но можно выбрать любую другую шкалу, которая подходит проекту. Здесь главное — работать согласованно. Например, 1 SP может обозначать небольшую и понятную задачу, которую легко завершить за короткий срок, в то время как 13 SP — это задача с высокой степенью неопределенности и большим объемом работы.
2. Решите, что означает каждый размер
После выбора шкалы важно определить, что конкретно подразумевает каждое число. Нужно обсудить, что входит в понятия «сложность», «объем работы». Например, задачу на 2 Story Points можно определить как простую, с минимальными рисками и без потребности во внешней помощи, а для задачи на 8 Story Points нужно привлекать нескольких специалистов, проводить исследование и учитывать, что возможны непредвиденные трудности.
3. Выберите человека, который будет присваивать размер задачам
Чтобы процесс оценки задач был управляемым и последовательным, команда назначает человека, который будет координировать назначение Story Points. Это может быть scrum-мастер, технический лидер или любой сотрудник, который способен объективно оценивать задачи с учетом коллективного опыта и мнения всех участников.
4. Назначайте размер в Story Points для каждой задачи
Каждую задачу проекта нужно оценивать в Story Points до того, как команда начнет работу над спринтом. Во время планирования участники проекта обсуждают каждую задачу и вместе решают, какое количество Story Points присвоить задаче. Например, если задача «разработать интерфейс авторизации» кажется более трудоемкой, чем «настроить уведомления по электронной почте», то она получит больше SP.
5. Отслеживайте размеры в таск-трекере
Когда команда назначает задачам Story Points, необходимо фиксировать эти данные в таск-трекере. Это позволит отслеживать прогресс команды в реальном времени и видеть общую картину выполнения задач. Также это помогает анализировать, насколько быстро получается выполнять задачи, и лучше планировать будущие спринты.
Пример как сторипоинты выглядят на доске Kaiten. Источник
6. Анализируйте работу команды
После завершения нескольких спринтов нужно проанализировать, насколько точно команда оценивает задачи в сторипоинтах. Например, если участники систематически недооценивают сложность задач на 5 Story Points, то критерии оценки нужно скорректировать. Анализ поможет команде лучше планировать работу и увеличить общую производительность.
Как избегать типичных ошибок при оценке в Story PointsКогда команда использует сторипоинты, она может допускать ошибки. Это негативно сказывается на точности оценки и эффективности работы. Но каждую ошибку можно предотвратить:
  • Ошибка — недостаточное понимание задачи. Команда оценивает задачу, но в требованиях и условиях до конца не разобралась.
Как избежать. Тщательно проанализируйте требования и обсудите задачу с участниками проекта до начала оценки. Убедитесь, что каждый осознает, что нужно делать.
  • Ошибка — игнорирование опыта команды. Когда не получается учитывать предыдущий опыт и знания команды, можно недооценивать или же переоценивать сложность задач.
Как избежать. Опирайтесь как на прошлые проекты, так и на аналогичные задачи. Обращайтесь к знаниям и опыту членов команды для более точной оценки.
  • Ошибка — неоправданная точность. Попытка максимально точно оценивать задачи создаст лишь иллюзию точности, когда в реальности она может быть незначительной.
Как избежать. Оценка в сторипоинтах должна быть приблизительной и учитывать неопределенности. Используйте диапазоны или категории, например, по методу «Размер футболок».
  • Ошибка — игнорирование неопределенностей и рисков. Если не учитывать возможные риски и неопределенности, можно неправильно оценивать задачи и занижать их сложность.
Как избежать. Включите риски и неопределенности в процесс оценки и обсуждайте их с командой.
  • Ошибка — субъективность и личные предпочтения. Если оценивать задачи на основе личных предпочтений или предположений, можно получить предвзятые результаты.
Как избежать. Применяйте объективные критерии и согласовывайте оценки с другими членами команды. Используйте технику Planning Poker (покер планирования), чтобы свести субъективность к минимуму.
  • Ошибка — недостаточное обновление оценок. Если не обновлять оценки, когда меняются требования и условия, планирование не будет соответствовать реальному объему работы.
Как избежать. Регулярно пересматривайте и обновляйте оценки задач по мере изменений в проекте.
  • Ошибка — отсутствие прозрачности и плохая коммуникация. Когда команде не хватает открытости, а с коммуникацией между участниками проблема, возникают недоразумения и неправильные оценки.
Как избежать. Обеспечьте открытую коммуникацию и прозрачность в процессе оценки. Регулярно обсуждайте с командой волнующие вопросы по проекту.
  • Ошибка — прокрастинация. Это когда команда откладывает оценку задач на потом или тратит слишком много времени на обсуждение сложностей, а решение при этом не принимает.
Как избежать. Устанавливайте дедлайны для планирования и оценки задач, чтобы соблюдать критерии, согласованные внутри команды.
Чтобы правильно управлять процессом оценки в Story Points, не пренебрегайте внимательностью, четким пониманием задач и эффективной коммуникацией. А чтобы внедрить современные управленческие практики в бизнес, обратитесь за бесплатной консультацией в Neogenda.
]]> Классы обслуживания в Канбан: ставим класс задачам http://neogenda.ru/blog/o3ul6uh8f1-klassi-obsluzhivaniya-v-kanban-stavim-kl http://neogenda.ru/blog/o3ul6uh8f1-klassi-obsluzhivaniya-v-kanban-stavim-kl?amp=true Thu, 24 Oct 2024 09:15:00 +0300 Мария Савельева Любая производственная система, будь то продуктовая команда или штат сотрудников, имеет свои ограничения в производительности....

Классы обслуживания в Канбан: ставим класс задачам

Любая производственная система, будь то продуктовая команда или штат сотрудников, имеет свои ограничения в производительности. И хорошо, если это ограничение известно: скажем, измеряется пропускная способность системы, за счет чего понятно, сколько запросов система может выполнять в определенный период времени. С этими данными заказчик и команда понимают, что они вынуждены выбирать, над чем работать сейчас, а что – отложить на потом. Чтобы планировать очередность выполнения работ, в Канбан методе используют классы обслуживания.
Класс обслуживания (Сlass of Service) – это категория, которую можно назначить входящему запросу, чтобы определить очередность его выполнения для достижения максимальной выгоды бизнесом.
Внедрив классы обслуживания, можно игнорировать сиюминутные хотелки и не только
Далее в статье:
  • зачем нужны классы обслуживания, если есть старая добрая приоритизация;
  • что такое стоимость задержки и какие у нее есть паттерны;
  • какие бывают классы обслуживания: рассказываем на примерах;
  • как внедрить классы обслуживания в свою систему.
Если вам необходимо внедрение современных управленческих практик – обратитесь в Neogenda. За нами более 100 успешных управленческих кейсов и более 5 000 обученных сотрудников в таких компаниях, как Tinkoff, Яндекс, Авито, Сбер, Билайн, Skyeng и так далее. Оставьте заявку на бесплатную консультацию – мы предложим индивидуальное решение, с которым ваша команда достигнет лучших результатов.
👉 Читайте также: «Как управлять временем производства с помощью WIP-лимитов»

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

Кто-то из читателей может про себя, или даже вслух, воскликнуть: «Да зачем мне эти ваши классы обслуживания, если есть приоритизация задач? Неужели я сам не пойму, что важно, а что – нет?»
А мы хотим спросить: от чего вы отталкиваетесь, приоритизируя задачи?
Чтобы вам было проще, приведем несколько критериев, которые часто используют для той самой приоритизации:
  • По очередности поступления. Кто первый прибежал с запросом к исполнителю – тот и папа. Остальные встают в очередь.
  • По крайнему сроку сдачи запроса. Если задача «горит» – ее нужно выполнять в первую очередь, очевидно же. А если в органайзере уже висят какие-то задачи, то нужно сначала доделать их, а потом браться за новые.
  • По старшинству руководства. Если с запросом приходит более старший менеджер – сначала нужно делать это, а потом остальное.
  • По ожидаемой прибыли. В этом случае будет учитываться, насколько ценным для бизнеса будет выполнение того или иного запроса. Например, если ожидается, что разработка какой-то функции должна сделать продукт более интересным для пользователей, за счет чего повлиять на рост его продаж и принести больше прибыли, ее нужно внедрять в первую очередь.
Как видите, приоритизировать запросы можно по совершенно разным критериям. Самое интересное начинается, когда исполнителю поступает несколько запросов, которые конфликтуют между собой по разным критериям приоритизации. Например, у сотрудника висит горящая задача, а к нему приходит топ-менеджер, который требует от него взяться на другую задачу. В этом случае сотруднику самому приходится решать, что выполнять в первую очередь, а что – отложить. В конечном счете, ответственность за очередность выполнения задач будет на сотруднике, а его выбор будет трудно спрогнозировать. Из-за этого будущее компании тоже становится туманным: например, может «отвалиться» клиент, про которого забыли на какое-то время.
Но, даже если в компании выстроена единая, ясная система приоритизации, она все равно будет работать плохо. Использование любой системы приоритизации подразумевает, что менеджер планирует очередность выполнения запросов исполнителями в определенный момент. Но со временем важность выполнения задач может меняться, а работа по приоритизации не учитывает изменения эффекта от выполнения запросов в динамике.
Скажем, какие-то задачи могут до определенного момента быть неважными, а потом резко стать очень важными. Например, рефакторинг кода продукта, который придется сделать с ростом нагрузки.
Делать его заранее невыгодно – есть вещи поважнее. Делать его слишком поздно – убыточно, потому что компания теряет прибыль от тормозящего продукта.
Если менеджер приоритизирует запросы, он оценивает их важность на текущий момент, отчего приоритизация теряет смысл. Со временем одни запросы становятся более важные, чем другие, а еще прилетают новые запросы, которые конкурируют в важности со старыми. А еще может случиться какой-нибудь форс-мажор, из-за которого придется делать что-то еще. Например, из РФ начнет уходить какой-нибудь сервис: в один момент придется отложить все задачи и заняться переездом с одного сервиса на другой.
Поэтому в Канбане считается, что упорядочивание беклога – бесполезная трата времени. Нужно брать самый важный запрос в работу здесь и сейчас, когда на это появился свободный ресурс.
По мнению Канбан-экспертов, приоритизация запросов поощряет наличие ролей в компании, которые выполняют ненужную работу по координации, за счет чего увеличивают транзакционные издержки выполнения запросов, проходящих через систему. Подобная бессмысленная деятельность в Канбан называется «отходами».
Не так быстро, Райан
Альтернативное мнение от Neogenda. Приоритизация нужна, если ее выполнять правильно и к месту. Скажем, в том же Scrum спринты планируют заранее, чтобы команда настроилась на работу и быстрее доносила ценность продукта на рынок. Некоторые функции продукта могут быть слишком комплексными – если менять очередность выполнения задач на ходу, велика вероятность, что какое-то крупное обновление продукта выйдет очень нескоро. Как правило, спринты длятся от двух недель до месяца – такого горизонта планирования достаточно, чтобы сосредоточиться на чем-то одном, оставив при этом возможность своевременно реагировать на внешние изменения.
Но вернемся к Канбану. Мы выяснили, что приоритизация бесполезна, но планировать ход работ как-то нужно. Для этого в Канбане считаются стоимость задержки выполнения разных задач, на основе которой решают, что делать в первую очередь. Расскажем об этом подробнее.
👉 Читайте также: «Системный подход к использованию Канбан: разбираемся, как нам поможет STATIK»

Что такое стоимость задержки и какие у нее есть паттерны

Стоимость задержки (Cost of Delay) – это метрика, которая выражается в денежном эквиваленте и указывает, сколько компания потеряет денег, если не выполнит тот или иной запрос вовремя.
Приведем упрощенный пример. Представим, что есть некий платный сервис, у которого случился форс-мажор: затопило серверную. На воссоздание сервера ушла неделя: в это время сервис был недоступен для пользователей, отчего не приносил прибыль. Если мы можем рассчитать, сколько денег мог бы принести рабочий сервис, эта сумма и будет являться нашей стоимостью задержки.
Если медлить с починкой серверов, стоимость задержки будет все больше с каждым днем. Эти изменения можно отобразить на графике.
Скриншот взят из книги «Канбан метод. Базовая практика» эксперта Neogenda – Алексея Пименова
По горизонтали на графике отражено время, а по вертикали – прибыль, которую можно было бы заработать, если б мы выполнили запрос вовремя.
Условно, синяя линия отображает прибыль, если мы выполним запрос прямо сейчас, а красная – если выполним его через неделю. Если сравнить линии по вертикали, видно, что промедление стоит денег – показатель прибыли у красной линии будет меньше в любой точке на горизонтальной оси.
Чаще в жизни все сложнее: такие графики редко бывают линейными. Но со временем разными специалистами были выявлены часто встречающиеся разновидности графиков, которые стали устоявшимися паттернами. Их и называют паттернами стоимости задержки – разберем каждый из них.
  • Ускоренный.
Паттерн «Ускоренный». Этот и последующие скриншоты с паттернами тоже взяты из книги Алексея Пименова
В этом случае прибыль моментально растет в момент поставки, после чего дальше не меняется. Скажем, такое может произойти при внедрении какой-нибудь скидки, которая разово увеличит количество продаж продукта.
  • Фиксированная дата.
Паттерн «Фиксированная дата»
Здесь прибыль тоже растет буквально в момент, но не сразу после внедрения, а в определенную дату. Скажем, это может быть внедрение акции, приуроченной к Черной Пятнице.
  • Регулярный.
Паттерн «Регулярный»
В этом случае мы видим, что прибыль меняется нелинейно – и так чаще всего и бывает в реальной жизни. В начале она растет медленнее, потом набирает обороты, а под самый конец снова замедляется.
Такое может быть, если вы выпустили на рынок новую функцию продукта, которая привлекла небольшое количество новых пользователей. Эти пользователи оценили функцию и рассказали о продукте более широкой аудитории, благодаря чему стало приходить больше новых пользователей и прибыль начала расти быстрее. Но после того, как вся заинтересованная аудитория стала пользователями вашего продукта, прибыль перестала расти.
  • Нематериальный.
Паттерн «Нематериальный»
Запросы, относящиеся к этому виду, принесут прибыль только через определенное время, и то, с определенной вероятностью.
Эти паттерны мы разобрали неспроста – они напрямую влияют на скорость выполнения запросов. По сути, по ним и определяют, к какому классу обслуживания отнести тот или иной запрос.
Расскажем о последних подробнее.
👉 Читайте также: «7 видов канбан-каденций: что это такое, советы, как проводить встречи»

Какие бывают классы обслуживания: рассказываем на примерах

Классы обслуживания используют в двух целях: чтобы определять приоритетность выполнения запросов и четко определять, как именно обрабатывать запросы, относящиеся к тому или иному классу.
Разные типы работ могут относиться к разным классам обслуживания: в этом плане каких-то закономерностей нет.
В основном, классы обслуживания соответствуют паттернам стоимости задержки, о которых мы рассказали выше. Но количество классов обслуживания может зависеть от конкретной организации или бизнеса: например, из-за специфики бизнеса могут добавиться дополнительные классы обслуживания.
Типы работ и классы обслуживания, к которым они могут относиться
  • Ускоренный.
Запросы этого класса лучше выполнять как можно раньше, поскольку они почти что моментально влияют на прибыль. Сюда можно отнести как поломки, так и какие-то активности, которые позволяют заработать здесь и сейчас.
Кстати, это единственный класс обслуживания, который позволяет пренебречь WIP-лимитами при выполнении задачи.
  • Фиксированная дата.
Запросы такого типа лучше выполнять в тот момент, когда времени осталось ровно столько, чтобы успеть к дедлайну. Такую дату начала работ называют последним ответственным моментом (Last Responsible Moment). Не стоит брать запросы этого класса в работу заранее – компания упустит прибыль, которую могла бы получить в это же время, выполнив какой-нибудь другой запрос.
Для того, чтобы сдать такой запрос вовремя, нужно знать, сколько времени он может находиться в работе. Из-за форс-мажоров и недостаточного количества данных для прогноза всегда есть риск ошибиться с крайним сроком.
Чтобы узнать реальное время от взятия задачи в работу до сдачи ее заказчику, в Канбан методе используют метрику Lead Time. Подробнее о этой метрике мы рассказали в статье «Lead Time и Cycle Time» – рекомендуем к прочтению. Если коротко, то мы не можем быть на 100 % уверены в том, что выполним запрос к определенному времени – мы можем лишь построить прогноз с определенной долей вероятности. Знание своего Lead Time позволяет строить эти прогнозы, чтобы вычислить последний ответственный момент, в который нужно брать запрос в работу.
  • Регулярный.
Как правило, такие запросы выполняются поочередно, если у них примерно одинаковая стоимость задержки. Но только в том случае, если в системе нет запросов, относящихся к паттерну «Ускоренный» или запросов, которые нужно выполнить к фиксированной дате – у них будет более высокий класс обслуживания.
  • Нематериальный.
Запросы этого класса выполняются тогда, когда у исполнителя появляется свободное время – промедление с их выполнением не приносит вреда бизнесу. Но за такими запросами нужно следить, потому что со временем они могут переквалифицироваться в «Ускоренные».
Например, у CMS интернет-магазина заказчика вышло новое обновление, которое нужно установить, но на качество работы сайта это никак не влияет – обновление отложили. После заказчику понадобилось внедрить на сайт определенную функцию, которая реализована в виде готового модуля, доступного на маркетплейсе CMS. Но чтобы установить этот модуль, нужно обновить магазин до последней версии, а уже сам модуль способен обеспечить заказчика прибылью в короткий срок. Следовательно, из паттерна «Нематериальный» задача переквалифицировалась в паттерн «Ускоренный».
Иногда у производственной системы может не быть каких-то классов обслуживания из вышеперечисленных, а иногда могут быть и дополнительные. Все зависит от специфики бизнеса.
А теперь к самой интересной, прикладной части – расскажем, как подружить вашу организацию со всем этим.
👉 Читайте также: «Что такое управление рисками и почему это важно»

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

1. Познакомьте заказчика с паттернами задержки.
Покажите им графики, объясните, что такое стоимость задержки и расскажите, чем может быть чревато несвоевременное выполнение тех или иных задач.
2. Определите типы рабочих элементов.
Классифицируйте задачи по какому-либо признаку. Пример был на скриншоте выше.
3. Задайте подходящие классы обслуживания.
Скорее всего, у вас будут стандартные классы обслуживания из списка выше.
4. Пропишите к каждому классу соглашение об уровне обслуживания (SLA).
Соглашение об уровне обслуживания – это правила выполнения запросов такого или иного класса, которые могут быть документально зафиксированы. SLA положительно влияет на доверие со стороны заказчика. Там указывают время реагирования на запрос того или иного класса и время на его выполнение.
5. Работайте, анализируйте ход работ и при необходимости корректируйте ваши действия.
Главная цель Kanban – постоянное улучшение рабочих процессов. Изменения поощряются, если они приводят к росту.
Если вам нужно внедрить Канбан метод в компанию – обратитесь в Neogenda. Мы являемся экспертами по современным подходам и методам менеджмента. За нами более 100 успешных управленческих кейсов и 5 000 обученных сотрудников в таких компаниях, как Tinkoff, Яндекс, Авито, Сбер, Билайн, Skyeng и так далее. Оставьте заявку на бесплатную консультацию в Zoom – мы предложим лучшее решение для вашей задачи.
]]> Как ставить цели по методологии SMART http://neogenda.ru/blog/yfvirve5n1-kak-stavit-tseli-po-metodologii-smart http://neogenda.ru/blog/yfvirve5n1-kak-stavit-tseli-po-metodologii-smart?amp=true Tue, 29 Oct 2024 09:22:00 +0300 Андрей Сидоренко «Нам лидов побольше, конверсию до небес и кликов с 6 нулями, пожалуйста». Звучит логично, но...

Как ставить цели по методологии SMART

«Нам лидов побольше, конверсию до небес и кликов с 6 нулями, пожалуйста». Звучит логично, но не очень понятно. С кликами еще можно разобраться, а какой смысл в целях лидов побольше и конверсии до небес — непонятно. Но эту проблему можно решить — достаточно разобраться в методе SMART и переформатировать цели по этой методологии.
Методология SMART — способ постановки целей и задач в управлении. Методологию придумал консультант по менеджменту Джордж Доран в 1981 году. Главная идея Дорана была простой: он считал, что цели должны быть ясными и понятными. Также важно, чтобы их можно было измерить — только так можно понять, достигнута цель или нет.
Изначально SMART-цели использовались в бизнесе. Менеджеры применяли их для постановки целей компаниям и сотрудникам. Со временем метод стал популярным и в других сферах. Теперь его используют в образовании, спорте и даже повседневных задачах.

Как поставить цель по методологии SMART

Сначала разберемся, как SMART расшифровывается. Каждая буква — критерий достижения цели. Цель должна быть:
Specific — конкретная;
Measurable — измеримая;
Achievable — достижимая;
Relevant — значимая;
Time bound — ограниченная во времени.
Разберемся подробнее.
Specific. Означает, что цель должна быть конкретной и определенной. То есть цель нужно сформулировать точно, чтобы ее нельзя было интерпретировать по-разному.
Иначе смысла не будет: один отдел решит, что «добавить всплывающее окно» означает разработать какой-то лид-магнит и увеличить базу контактов. А другой решит, что это отличный способ показать миру новый мем с котами.
Так не надоТак можно
Так можноДобавить всплывающее окно с лид-магнитом N для сбора базы email-адресов
Measurable. Означает, что цель должна быть измеримой. Это даст понять, достигнута она или нет.
Важно не переусердствовать с цифрами: увеличивать доход кратно это прекрасно. Но вряд ли возможно, если до этого несколько лет получалось зарабатывать на 10–15% больше ежемесячно.
Так не надоТак можно
Заработать в 2025 году больше, чем в 2024 Заработать в 2025 году на 20% больше, чем в 2024
Achievable. Означает, что цель должна быть достижимой. Нет смысла ставить конкретную и измеряемую цель, но с невозможными цифрами. Например, вряд ли получится увеличить количество посетителей в блоге с 1 млн до 50 в месяц за год.
Чтобы поставить достижимую цель, нужно:
Представлять примерные сроки. Обязательно реалистичные. Например, нельзя увеличить число визитов в блог с 10 тысяч до 15 за неделю, если с 5 тысяч визитов до 10 блог шел месяц.
Рассуждать объективно. Например, учитывая свой или чужой опыт и средние цифры по рынку. Потому что вряд ли получится увеличить число конверсий за месяц вдвое благодаря контент-маркетингу, если до этого показатели росли на 20-30% процентов ежемесячно.
Ставить недостижимые цели не запрещено, но это может демотивировать команду. Сотрудники устанут, выгорят от работы и вряд ли захотят в следующий раз работать на полную. Но и занижать цели не стоит — это снизит производительность команды.
Чтобы представить реальную цель, можно провести SWOT-анализ и понять, готова ли команда к работе. Также не помешает анализ конкурентов — это даст примерный ориентир по целям.
Relevant. Означает, что цель релевантная и значимая для компании. Она должна вписываться в общие задачи и долгосрочные планы. Понять значимость цели помогает простой вопрос: «зачем она нужна?».
Если в ответ не входит упоминание потребностей или приоритетов компании, значит цель не нужна.
К примеру, компания хочет повысить узнаваемость бренда и лояльность аудитории. В этом вряд ли поможет новый логотип, сделанный в нейросетях. А вот работа над UX/UI сайта, покупка рекламы или создание контент-стратегии достижению целей явно пойдет на пользу.
Так не надоТак можно
Сделать логотип Улучшить пользовательский опыт на сайте, чтобы увеличить конверсии на 20% в следующем квартале
Time bound. Означает, что цель должна быть ограничена по времени. У цели должен быть четкий дедлайн или временные рамки для выполнения.
На этот счет есть поговорка: если у задачи нет дедлайна, значит она не будет выполнена никогда. Никакая конкретика, измеримость или релевантность не поможет — без дедлайна задача навсегда уйдет в долгий ящик.
Чтобы четко оценить сроки, нужно:
  • Оценить объем задач и доступных ресурсов. Не нужно быть чересчур оптимистичным и рассчитывать на сверхпроиводительность компании.
  • Разделить цель на этапы. Например, запуск медиа на подготовку контент-стратегии, формирование редакции, определение цели блога и т. д.
  • Учесть внешние факторы. Чтобы понять, какие внешние обстоятельства могут влиять на выполнение задачи. Например, что случится, если поставщик задержит выгрузку товара.
  • Сравнить с прошлым опытом.
Осталось главное — понять, как эти цели поставить. Для этого нужно подробно ответить на несколько вопросов — так вы поймете, что вам действительно нужно делать.
КритерийНа какие вопросы нужно ответить, чтобы сформулировать цель
Specific — конкретная
  • Что именно нужно изменить или улучшить?
  • Какие шаги нужно предпринять?
  • Какой результат будет считаться успешным?
  • Кто будет участвовать в достижении этой цели?
Measurable — измеримая
  • Как можно оценить успех?
  • Какие показатели позволят отследить прогресс?
  • Как часто нужно проверять результаты?
  • Какой уровень показателей можно считать приемлемым?
Achievable — достижимая
  • Достаточно ли ресурсов для достижения цели?
  • Какие знания или навыки необходимы для выполнения задачи?
  • Есть ли преграды на пути к цели?
  • Как можно справиться с рисками?
Relevant — значимая
  • Почему эта цель важна для меня или команды?
  • Как это повлияет на текущие задачи?
  • Какие выгоды мы получим при достижении цели?
  • Не создаст ли эта цель конфликт с другими?
Time-bound — ограниченная во времени
  • В какие сроки нужно достигнуть результата?
  • Есть ли внешние факторы, которые могут замедлить процесс?
  • Реальны ли эти сроки?
  • Как будет измеряться временной прогресс?

Преимущества методики SMART

Реальные приоритеты выходят на первый план. Часто компании ставят десяток целей сразу и не разбивают их на категории важности. В итоге тратят много сил и ресурсов на задачи, которые не принесут значительного результата.
Но что действительно важно?
SMART заставляет концентрироваться на том, что действительно важно. Ведь когда все цели четко прописаны и измеримы, команда не будет распыляться. Сотрудники сконцентрируются и поймут, за что браться в первую очередь.
Команда понимает, что от нее хотят. Еще одна проблема — когда руководство требует каких-то показателей, но команда не знает, каких. В итоге делают все подряд и подгоняют цифры под желаемые.
Система SMART помогает донести реальные цели до команды. Ведь когда перед глазами лежит конкретная задача, все понимают, к чему они идут и что от них требуется.
Все рассчитывают свои ресурсы. Пятилетка за 4 года это хорошо, но сложно для сотрудников. Со временем производительность падает, люди уходят на больничные и становятся отстраненными. А компания тратит лишние деньги на задачи, которые никогда не будут выполнены.
SMART помогает реально взглянуть на вещи, сэкономить деньги и силы работников.
Менеджеры все контролируют. В хаосе сложно разобраться. Непонятно, куда подвинуть задачу, как заменить работника или что проверить, когда не видишь всей картины.
Обычный рабочий день в компании, которая не использует SMARTОбычный рабочий день в компании, которая не использует SMART
SMART раскладывает задачу на маленькие этапы. По каждому этапу проставляется дедлайн и назначается ответственный. Если что-то пойдет не так — можно будет подвинуть сроки, поменять этапы местами или усилить команду.
У команды растет мотивация. Сложно работать, когда не видишь результата. Особенно, если цель глобальная: вроде бы решил десяток задач, но нужно решить еще 1000, чтобы все получилось. В этом случае одну глобальную цель можно разбить на несколько поменьше.
Например, компания хочет увеличить клиентскую базу на 48% за год. Вместо того чтобы сразу поставить такую цель, они ставят SMART-цель на первый квартал: «Мы увеличим количество новых клиентов на 12% за три месяца благодаря 5 новым каналам продаж».
Клиенты и партнеры видят, что компания трудится. Если клиент приходит с задачей «чтобы деньги были», хочет знать, когда эти деньги будут. Ответ «скоро» вряд ли его устроит. Зато ему точно понравится «Мы увеличим продажи вашей продукции на 20% в течение 6 месяцев».
А если не понравится — вы вместе сможете поставить измеримую цель и задать сроки.

Недостатки методики SMART

Ограничивает креативность и гибкость. Это может привести к тому, что команда будет стараться выполнить план, но не решить задачу. Например, рекламщикам могут поставить план — создать 10 рекламных креативов за месяц с конверсией в 5%. Задача возможная, вот только для создания креативов может понадобится больше времени: на продумывание идеи, тестирование и т. д. А если у команды на первом месте будут жесткие рамки, она может работать по шаблону, чтобы просто успеть в срок.
Количество в этом случае будет важнее качества.
Идеальный баланс найти сложно, но можно
Сужает фокус. Эта проблема похожа на ограничение креативности: когда компания концентрируется на слишком узких проектах, это может помешать увидеть картину в целом.
Например, если команда решит увеличить продажи конкретного продукта на 15% и сконцентрируется только на нем, может упустить новый тренд и недозаработать за счет низких продаж других товаров.
Может навредить команде. Если поставить недостижимую, сложную SMART-цель, сотрудники долгое время могут перерабатывать. Заниматься тем, что им не нравится и в итоге — выгорать.
Плохо адаптируется под ситуацию. Еще одна проблема методики SMART. Когда конечная цель и способы ее достижения детально прописаны, команде сложно поменять фокус и работать в других направлениях.
К примеру, у команды была цель увеличить охваты в блоге на 30% за 3 месяца только за счет рекламы в соцсетях. Но через месяц алгоритмы соцсетей меняются и стратегия перестает работать. Из-за привязанности к целям работа может остановится. Придется ставить проект на паузу, изучать новые алгоритмы.
Фокусирует внимание на краткосрочных успехах. Например, компания может поставить цель увеличить число клиентов на 10% за квартал. В таком случае логично сфокусироваться на быстрых способах привлечения клиентов. А стратегии, которые требуют больше времени, но принесут лучшие результаты в будущем — проигнорировать.
В результате компания выиграет в краткосрочной перспективе, но в долгосрочной потеряет часть потенциальных клиентов.
Получается, главный недостаток методики SMART — фокус на краткосрочных и среднесрочных целях. Для постановки долгосрочных целей техника не подходит, потому что не рассчитана на гибкий подход и адаптацию.

SMART vs GROW vs OKR

GROW и OKR — еще одни популярные методики достижения целей. Но применять их стоит в разных ситуациях.
GROW ориентирован на коучинг и саморазвитие. Он помогает людям в постановке индивидуальных задач. Каждая буква отвечает за отдельное действие:
  • Goal — постановка цели.
  • Reality — анализ своей текущей ситуации
  • Options — выбор лучшей стратегии.
  • Will — конкретный план действий.
В отличие от SMART, GROW не сосредоточен на чётких метриках. Он больше подходит для обсуждения пути по достижению целей.
OKR подходит для постановки целей, ориентирован на достижение конкретных результатов.
Разница в том, что OKR фокусируется на амбициозных целях (Objectives) и ключевых результатах (Key Results). И эти цели могут корректироваться в зависимости от ситуации — это создает более гибкий подход. Еще одно отличие — в OKR нет таких жестких рамок, как в SMART.
Все методики можно использовать параллельно. Например, раз в полгода давать сотрудникам индивидуальные цели по GROW. Затем переходить к конкретному планированию кратко- и среднесрочных целей по SMART. А самые больше и глобальные цели ставить по OKR.
Есть и другие методы постановки целей. Но если рассказывать про все — получится отдельная статья. Поэтому мы покажем их в таблице и кратко объясним, чем они схожи с SMART и чем отличаются.
Метод Схожесть с SMART Отличие от SMART
OKR (Objectives and Key Results) Помогает устанавливать цели и отслеживать результаты. Ориентирован на достижение конкретных результатов. Фокусируется на долгосрочных целях, допускает гибкость в корректировке ключевых результатов и сроков.
CLEAR (Collaborative, Limited, Emotional, Appreciable, Refinable) Направлен на постановку целей и улучшение командной работы. Акцент на совместное достижение целей, эмоциональную вовлеченность и возможность корректировки целей.
HARD (Heartfelt, Animated, Required, Difficult) Помогает чётко формулировать задачи. Больше внимание уделяется значимости целей. Фокусируется на эмоциональной связи с целью, сложности задачи. Не требует измеримых или конкретных целей.
FAST (Frequently discussed, Ambitious, Specific, Transparent) Помогает формулировать конкретные и амбициозные цели. Уделяет внимание частому обсуждению целей и прозрачности, меньше фокусируется на временных рамках и измеримости.
Balanced Scorecard (Сбалансированная система показателей) Помогает устанавливать измеримые цели и контролировать выполнение задач. Ориентирован на стратегическое управление, балансирует между финансовыми и нефинансовыми показателями.

Давайте пробовать

Теория это хорошо, но пришло время поставить цель на примере реальной задачи. Допустим, наша компания продает программное обеспечение (CRM-системы и облачные решения для безопасности данных), другим компаниям и мы хотим увеличить продажи в 2025 году.
Конкретика есть — увеличить продажи. Теперь определимся, насколько больше мы хотим продать.
Последние 2 года компания стабильно увеличивала продажи на 10% ежегодно. В конце 2024 года мы проанализировали положение и поняли, что:
  • У нас появились новые технологии, которые делают наше ПО лучше, чем у конкурентов.
  • Выходим на новый рынок продаж, где есть спрос на ПО.
  • Практически заключили соглашения с новыми дистрибьюторами, что увеличит количество продаж.
  • Расширили отдел поддержки, поэтому удовлетворенность и лояльность клиентов растет.
Исходя из такой информации, цель получить на 15% больше продаж звучит реалистично.
Чтобы отслеживать метрики, будем собирать данные с помощью CRM-систем, Google Analytics, систем финансового учета и т. д., а затем визуализировать цифры в Microsoft Power BI.
Дальше продумаем, достижима ли цель и хватает ли на нее ресурсов.
В команде есть специалисты — разработчики, QA-специалисты, маркетологи и др. Все нужные ключевые кадры недавно завершили другие проекты и могут подключиться к этому. Денег на развитие тоже хватает.
Главное — цель значимая. Она поможет расширить клиентскую базу, увеличить выручку и повысить прибыльность. Вырастет узнаваемость бренда. Кроме того, компания сможет реинвестировать часть прибыли и повысить лояльность клиентов. В долгосрочной перспективе это еще больше увеличит прибыль компании.
Со временем мы определились еще в самом начале — весь 2025 год. Осталось разбить задачу на несколько маленьких этапов и для каждого продумать примерный дедлайн.
В первом квартале 2025 года будет сделан упор на планирование и подготовку:
  • анализ текущих ресурсов;
  • создание рекламных кампаний;
  • обучение отдела продаж;
  • привлечение новых клиентов.
К концу марта нужно будет запустить рекламу и подготовить отдел продаж к притоку клиентов.
Во 2 и 3 квартале придется работать с новыми и существующими клиентами. В этом время важно следить за прогрессом, поэтому раз в месяц будут проводиться контрольные встречи.
В 4 квартале компания сосредоточится на максимизации продаж. Все также будут проводиться встречи с промежуточными отчётами по ключевым метрикам.
Это один из примеров поставленной цели по методологии SMART. Из этого описания понятно, что хочет компания. Как она этого добьется и когда.

Несколько ошибок, которые мешают достижению целей

Игнорируют внешние факторы. Многие забывают про то, что происходит вокруг. Например, вы хотите увеличить продажи на 30%. Но не учли, что скоро сезон отпусков. Люди будут меньше покупать, поэтому цель может не сработать.
Не считают ресурсы. Часто компании ставят крутые цели, но забывают про ресурсы. Например, кто-то хочет разработать и выпустить приложение за месяц, но забывает, что в штате всего два разработчика. Сначала нужно считать, сколько людей, денег и времени нужно на достижение цели. А только потом ставить цель.
Не привязывают цель к общей стратегии. Бывает, что цель сама по себе хорошая. Но она никак не связана с общим планом компании. Например, компания решила создать приложение для общения. Но если она продает трубы, зачем ей это нужно. Каждая цель должна помогать общему делу.
Ставят слишком много целей сразу. Для команды из 5 человек 10 крупных целей на месяц это хорошо, но вряд ли осуществимо. Команда не сможет сфокусироваться, в итоге часть целей не доведет до конца, а за часть даже не возьмется. А первое правило методологии SMART — не рассказывать про методологию SMART качество важнее количества.
Также важно ставить простые цели. Одна цель — один результат. Например, «Получить больше лидов из TG Ads» — хорошо. А «получить больше лидов из Telegram, VK и Дзена» — сложно. Уследить за всеми площадками сразу будет непросто.
Не учитывают риски. Часто при планировании компании рассматривают только оптимистичный сценарий. «Рынки будут расти, а люди с радостью понесут нам деньги». Важно всегда учитывать риски и закладывать негативный сценарий как реальный. И заранее продумать, как компания с ним справится. Иначе, когда появятся трудности, их не смогут быстро решить.
Выбирают неподходящие метрики. Иногда показатели выбираются только потому, что их легче отслеживать. Это неправильный подход — показатель должен отражать реальный прогресс, а не просто быть удобным для отчета.
Например, успех продвижения вряд ли можно оценить по количеству комментариев на сайте. А вот количество новых заявок через сайт покажет, принесли ли вложения результат.

Без технологий никуда

Сложность работы с методологиями — нужно уметь их заполнять. И иногда отвечать на вопросы некогда. А иногда — ответить сложно. В таком случае на помощь придут нейросети — ниже делимся промптом, который поможет поставить цель по методологии SMART.
Важно! Не нужно относиться к ответам нейросети как к единственно верным. ChatGPT — это дополнительный источник информации, который поможет быстрее обработать данные или взглянуть на ситуацию с другой стороны. Считайте его ответы референсом, от которых можно отталкиваться и ставить реальные цели.
Промпт.
#КОНТЕКСТ: Вы хотите разработать стратегию с использованием методики SMART для вашего бизнеса или проекта. Эта методология позволит вам создать чёткие цели, которые можно измерить, достичь, и которые соответствуют вашим текущим ресурсам и времени.

#РОЛЬ: Вы – предприниматель или менеджер, стремящийся эффективно управлять ресурсами и достигать бизнес-целей. Моя роль как ИИ – собрать всю необходимую информацию для разработки стратегии и предложить рекомендации по её улучшению.

#РЕКОМЕНДАЦИИ ПО ОТВЕТУ:
Запросите у пользователя информацию, связанную с целями его проекта или бизнеса. Сфокусируйтесь на следующих аспектах:
  • Что конкретно вы хотите достичь (конкретная цель)?
  • Как вы планируете измерять успех (метрики)?
  • Насколько достижимы эти цели с текущими ресурсами?
  • Почему эти цели важны для вашего бизнеса?
  • В какие сроки вы хотите достичь этих целей?

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

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

#КРИТЕРИИ ЗАДАЧИ:
  • Стратегия должна следовать методологии SMART.
  • Цели должны быть измеримыми и достижимыми в заданные сроки.
  • Стратегия должна включать конкретные шаги и контрольные точки.

#ИНФОРМАЦИЯ ОБО МНЕ: [Сюда вставьте вашу цель]

#ВЫВОД: Создайте чёткую, пошаговую стратегию с рекомендациями по улучшению, на основе методики SMART.
Чтобы протестировать промпт, скопируйте его и вместо «[Сюда вставьте вашу цель]» опишите свою задачу. Мы для примера написали такую: «Придумай максимально подробный план постановки цели по SMART для компании по продаже программного обеспечения. Задача — увеличить число продаж на 15% за первый квартал 2025 года».
И в ответ получили такие рекомендации:
С учетом того, что мы дали мало вводных данных, бот все равно дал неплохой ответ. Он подсказал, какие метрики стоит отслеживать, как проверить достижимость и как разбить задачу на небольшие этапы.

Запомнить

SMART помогает определить реальные приоритеты, сконцентрироваться на важных задачах и достичь измеримых результатов.
При постановке SMART-целей нужно учитывать внешние факторы, ресурсы, общую стратегию, риски и метрики.
У методики SMART есть несколько недостатков: ограничение креативности, узкий фокус и плохая адаптация к новым ситуациям.
SMART можно комбинировать с другими методиками вроде GROW, OKR или Balanced Scorecard.
И самое-самое последнее. Если вашему бизнесу нужно внедрение методологии SMART, обратитесь за бесплатной консультацией в Neogenda. Мы предоставляем разные услуги: от обучения ваших сотрудников лучшим управленческим практикам до полной реорганизации процессов вашего бизнеса.
]]> Ключевые показатели Scrum: 7 метрик, которые помогают оценить эффективность в Agile http://neogenda.ru/blog/s5knutmpz1-klyuchevie-pokazateli-scrum-7-metrik-kot http://neogenda.ru/blog/s5knutmpz1-klyuchevie-pokazateli-scrum-7-metrik-kot?amp=true Tue, 05 Nov 2024 11:40:00 +0300 Артур Нек Разберитесь, зачем проверять и оценивать эффективность команд в Agile. Scrum метрики проекта — это мощный...

Ключевые показатели Scrum: 7 метрик, которые помогают оценить эффективность в Agile

Разберитесь, зачем проверять и оценивать эффективность команд в Agile. Scrum метрики проекта — это мощный инструмент, который помогает видеть прогресс, находить проблемы и налаживать работу.
Чтобы улучшить производительность и создать оптимальную рабочую среду, важно понимать и применять эти показатели. В статье рассмотрим основные Agile метрики, среди них и метрики эффективности проекта, и метрики эффективности команды, например, капасити и велосити. Расскажем, без какого процесса будет сложно управлять проектами, оценивать производительность и принимать разумные решения.
А если нужно внедрить современные методы стратегического менеджмента в ваш бизнес, есть консалтинговая компания Neogenda. Наш подход уже оценили Сбер, Яндекс, Точка, X5 Group, Тинькофф и другие бренды. Обучаем сотрудников, проводим реорганизацию — помогаем решать более 100 задач бизнеса. Чтобы достичь желаемых результатов в вашем деле, начните с бесплатной консультации от практиков Neogenda.

Скорость команды (Velocity)

Ключевая метрика в Scrum Framework и Agile. Помогает измерить, насколько продуктивна команда, и определяет объем работы, с которым участники команды справляются за спринт. Позволяет понимать, сколько задач они смогут закрыть в будущем. Как правило, скорость измеряют в Story Points или часах.

Как рассчитывать velocity команды

В конце спринта проанализируйте, сколько Story Points (часов, если выбрали их) ушло на задачу. Важно учитывать только те задачи, которые получилось сделать полностью и которые принял заказчик.
Подсчитайте общее количество Story Points или часов за все завершенные задачи. Например, если за спринт успели завершить три задачи с оценками 5, 3 и 2 Story Points, то общая скорость составит 10 Story Points.
Сохраните полученное значение как скорость для этого спринта.

Какие преимущества у Velocity

  • Прогнозирование. Метрика Velocity позволяет предсказывать, сколько задач получится закрыть в будущем. Если команда знает свою среднюю скорость, она может планировать объем работы на предстоящие спринты.
  • Оценка производительности. Анализ скорости на протяжении нескольких спринтов помогает командам увидеть, выросла производительность или, наоборот, снизилась.
  • Управление ожиданиями. Когда специалисты знают свою скорость, они могут называть заказчикам более реалистичные сроки, за которые справятся с задачами.

Диаграмма сгорания задач (Burndown Chart)

Это графический инструмент, который в Scrum помогает контролировать шаги команды в рамках спринта либо проекта. Диаграмма демонстрирует объем оставшейся работы (Burndown Chart). Так, команда понимает, насколько близки к финалу задачи.
Как работает Burndown Chart
  1. Оси X, Y — первая показывает временной интервал на задачу спринта, а вторая — остаток работы, которая измеряется в сторипоинтах, часах или других выбранных величинах.
  2. Идеальная линия работы показывает образцовую производительность команды. На графике это наклонная прямая, которая начинается с общего объема работы на оси Y и прямой линией опускается до нуля к концу спринта.
  3. Фактическая линия показывает, как команда выполняет задачи на самом деле. Она обновляется каждый день и отражает текущий прогресс.

Какие преимущества у диаграммы сгорания задач

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

Метрика Capacity (емкость)

В Agile и Scrum Framework помогает измерить объем работы, который команда может сделать за обозначенный период времени, например, за спринт. С этой метрикой проще учитывать реальное количество доступных ресурсов, чтобы планировать свои задачи эффективнее.

Как рассчитывать Capacity

Для каждого участника команды нужно определить доступные рабочие часы на период спринта. Например, если спринт длится 10 дней, и каждый день у разработчика есть 6 часов, то доступное время на спринт — 60 часов.
Учитывайте все выходные, отпуска, больничные или участие в дополнительных мероприятиях, таких как обучающие курсы или командные встречи, которые могут снизить рабочее время.
После того, как определили рабочее время для каждого участника, сложите все часы, чтобы получить общую емкость команды.
Если команда использует Story Points, можно провести приблизительную оценку емкости в Story Points на основании прошлого опыта команды, соотношения рабочего времени и выполненных задач.
Пример. Допустим, в команде 5 участников и каждый из них доступен 30 часов за спринт, тогда общее доступное время будет равно 5×30 = 150 часов. Если 20% времени уходит на встречи и другие обязательства, фактическая Capacity будет 150×0.8 = 120 часов.

Какие преимущества у Capacity

Планирование на основе реальной загрузки. Capacity позволяет планировать задачи с учетом фактической доступности участников и при этом избегать перегрузки или недогрузки.
Прогнозирование выполнения. Метрика помогает команде определить, сколько задач реально можно закрыть в течение спринта.
Гибкость в планировании. Учитывать Capacity особенно полезно, когда меняется состав команды или индивидуальная загруженность участников. Это позволяет оперативно корректировать объем задач.
Прозрачность и управляемость. Capacity дает возможность команде и заинтересованным лицам четко понимать, сколько ресурсов доступно, и эффективно ими управлять.

Накопительная диаграмма потока (Cumulative Flow Diagram)

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

Как работает Cumulative Flow Diagram

  1. Ось X представляет временной промежуток, например, дни спринта. Ось Y — сколько задач получили конкретный статус.
  2. На диаграмме отображаются статусы: «Запланировано» (To Do), «В работе» (In Progress), «Завершено» (Done).
  3. В процессе работы задачи в каждом статусе накапливаются и создают график. Это позволяет видеть, как работа перемещается между состояниями.
Пример накопительной диаграммы потока из сервиса Kaiten

Преимущества накопительной диаграммы потока

  • Визуализация положения дел. Cumulative Flow Diagram показывает командам количество задач в каждом состоянии. Это помогает быстро оценить общее состояние работы.
  • Выявление узких мест. Если на диаграмме видно, что количество задач «В работе» сильно увеличилось, это может говорить о недочетах, которые нужно исправить.
  • Управление потоком работы. Диаграмма помогает определить, как долго задачи находятся в каждом статусе. Благодаря этому команды могут оптимизировать свои методы работы и повышать эффективность.

Метрика удовлетворенности участников команды прошлым спринтом

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

Как работает метрика удовлетворенности участников команды прошлым спринтом

  • Чтобы собрать данные, проведите опрос, который может включать как открытые, так и закрытые вопросы. Участники команды оценивают разные аспекты: общую удовлетворенность работой в спринте, ощущение команды как единого целого, качество выполнения задач, эффективность общения внутри команды, уровень поддержки и сотрудничества.
  • Участники могут применять числовую шкалу, например, от 1 до 5, чтобы выразить свое мнение по каждому вопросу.
  • После опроса команда должна обсудить результаты на ретроспективе, чтобы выделить положительные моменты и области для улучшения.
Преимущества метрики удовлетворенности участников команды прошлым спринтом
  • Выявление проблем. Инструмент помогает командам заметить проблемы, которые могут негативно сказываться на работе и моральном состоянии участников.
  • Развитие командной динамики. Если обсуждать результаты опроса, можно наладить коммуникацию и создать плодотворную атмосферу в команде.

Время выполнения задачи (Cycle Time)

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

Как рассчитывать Cycle Time

  1. Определите начальную точку — зафиксируйте, когда команда начинает работать над задачей. Можно ориентироваться на момент, когда задача переходит в статус «В работе».
  2. Определите конечную точку — зафиксируйте, когда задачу принял заказчик.
  3. Чтобы узнать, сколько времени задача занимает, определите разницу между конечной и начальной точками.
Здесь нужен примитивный график — отрезок с двумя точками. Первую точку подписать «Начало работы над задачей», вторую — конец работы над задачей». Точки объединить фигурной скобкой и по центру Cycle Time

Какие преимущества у Cycle Time

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

Метрика Wasted Time

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

Как рассчитать Wasted Time

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

Какие преимущества у Wasted Time

  • Выявление проблемных зон. Метрика помогает команде найти области проекта, которые приводят к потерям времени. Это может быть неоптимальная организация встреч, частые изменения требований или медленная коммуникация с заказчиками.
  • Повышение эффективности. Когда команда понимает, на что тратит время впустую, у нее появляется возможность оптимизировать свои процессы. Например, можно сократить длительность и количество встреч или убрать лишние процедуры.
  • Улучшение планирования. Анализ временных потерь помогает точнее определять, сколько времени нужно, чтобы выполнить задачи. Будущие спринты удобнее планировать с учетом этой информации.
  • Повышение прозрачности. Введение метрики помогает команде видеть реальную ситуацию и создать среду, в которой можно открыто обсуждать проблемы.
  • Фокус на ключевых задачах. Благодаря учету потерянного времени команда начинает фокусироваться на важных задачах и избегать лишних переключений и отвлечений.

Груминг в ИТ: уточнение и приоритизация задач

Груминг Бэклога — это процесс в Scrum, который состоит из регулярного обсуждения и уточнения задач. Обычно его проводит владелец продукта. От этого процесса зависит, насколько качественными и точными будут метрики эффективности проекта и команды.
Груминг в Scrum включает в себя:
  • Обсуждение задач — команда и владелец продукта обсуждают существующие задачи, уточняют детали и требования.
  • Приоритизацию — задачи сортируют по степени важности и срочности, чтобы команда могла сосредоточиться на самых значимых.
  • Оценку — команда оценивает объем работы для каждой задачи, чтобы точнее рассчитывать метрики.
Все эти факторы работают в комплексе и помогают успешно реализовывать проекты и поддерживать высокую эффективность команд. А чтобы интегрировать современные методы управления в свой бизнес, обратитесь за бесплатной консультацией в Neogenda.
]]> Lead Time и Cycle Time: время производства и время цикла http://neogenda.ru/blog/zy8zjcsg91-lead-time-i-cycle-time-vremya-proizvodst http://neogenda.ru/blog/zy8zjcsg91-lead-time-i-cycle-time-vremya-proizvodst?amp=true Tue, 12 Nov 2024 11:44:00 +0300 Мария Савельева Начнем с небольшого вступления для понимания контекста. (далее…)

Lead Time и Cycle Time: время производства и время цикла

Начнем с небольшого вступления для понимания контекста.
Если ваша компания успешно выполняет какую-нибудь интеллектуальную работу, например, разработку сайтов, у вас нет отбоя от заказчиков. Они, то и дело, предлагают выполнить еще какой-нибудь проект. Но вы не можете взяться за все, поскольку ваш рабочий ресурс ограничен и из-за этого входящей работы поступает больше, чем ваша организация может выдавать.
Из-за этого, чтобы обезопаситься от срыва дедлайнов, нужно отклонять часть запросов от заказчика. Думаем, не нужно объяснять, почему нельзя срывать дедлайны: от этого страдает ваша репутация и вы лишаете заказчика пользы, на которую он рассчитывает.
Контролировать поток входящих запросов помогает Канбан Метод. О производительности системы можно судить только оценочно, поэтому в Канбане есть несколько метрик. Две из них – Lead Time и Cycle Time. Отслеживание этих метрик позволяет спрогнозировать срок сдачи работ – эти данные можно передать заказчику, чтобы он также мог прогнозировать сроки выполнения своих задач.
Если бы Канбан Метод внедрили в «Дэйли Бьюгл»
Далее расскажем все об этих метриках.
Если вам необходимо внедрение современных управленческих практик – обратитесь в Neogenda. За нами более 100 успешных управленческих кейсов и 5 000 обученных сотрудников в таких компаниях, как Tinkoff, Яндекс, Авито, Сбер, Билайн, Skyeng и так далее. Оставьте заявку на бесплатную консультацию в Zoom – мы предложим индивидуальное решение, с которым ваша команда достигнет лучших результатов.
👉 Читайте также: «Что такое управление рисками и почему это важно»

Lead Time и Cycle Time: в чем разница

Lead Time (время производства) – это время от принятия обязательств до сдачи готового результата заказчику. То есть, Lead Time начинается, когда вы говорите заказчику «Берем в работу», а не от момента, когда вы реально взяли задачу в работу. Также это не фактическое время, которое потребовалось на выполнение запроса, а все время, прошедшее со старта работ до сдачи работы заказчику.
То есть, в это время входят все перекуры, кофе-брейки, разговоры у кулера, паузы на согласование и так далее.
Cycle TIme (время цикла) – это время прохождения задачей каких-либо этапов на Канбан-доске: например, от этапа «В работе» до этапа «Готово». Здесь, как и в случае с Lead Time, учитывается все время, не только рабочее. Отслеживание Cycle Time позволяет выявить затруднения на каком-нибудь конкретном этапе Канбан-доски. Бывает, что какой-то этап длится слишком долго – имеет смысл его изучить, чтобы понять, почему так.
Примечание. Иногда Cycle TIme считают как время с фактического взятия запроса в работу до его сдачи заказчику, но это неправильная трактовка.
Схематичное отображение Lead Time, которое показал наш эксперт Алексей Пименов в своей видеолекции «Производственный процесс глазами Канбан-практика». Видно, что в Lead TIme включено как время фактической работы, так и время простоя запроса. Но здесь есть небольшой нюанс: на графике запрос сразу взят в работу, хотя в случае с Lead Time такое возможно только тогда, когда заказчик отправил запрос, а организация сразу согласилась его выполнить и начала по нему работать
👉 Читайте также: «Диаграмма сгорания (Burndown Chart): как управлять ходом разработки»

Как спрогнозировать Lead Time и Cycle Time

У разных задач Lead Time и Cycle Time будет разным. На показатель будут влиять как особенности задачи, так и количество одновременных процессов в системе. Поэтому метрики анализируются не по каждой задаче в отдельности, а по диапазону значений всех задач за определенный временной период. Чтобы отследить диапазон значений, данные по Lead Time и Cycle Time можно собрать в гистограмму времени цикла.
Простой пример гистограммы времени цикла с данными, выраженными за определенный временной период: например, месяц. На оси X указано количество дней, которые потребовались для выполнения задачи, а на оси Y указано количество выполненных задач. То есть, мы можем увидеть, что 8 задач были выполнены за 2 дня, 9 задач – за 3 дня и так далее
С помощью гистограммы можно понять, сколько времени у вас реально может уйти на выполнение запроса, если речь о Lead Time. Или на прохождение запросом какого-то этапа вашего производственного процесса, если анализируется Cycle Time.
Первое, что дает узнать гистограмма времени цикла – это прогнозируемое время выполнения задачи. Представим, что в нашем примере на скриншоте мы замеряем Lead Time одного из рабочих процессов компании.
На примере мы видим, что большинство задач были выполнены максимум за 7 рабочих дней. Но в графике есть аномалии – одна задача была выполнена за 11 дней, а другая – за 12.
А теперь представим, что заказчик обращается к нам с новым запросом и спрашивает: «За сколько дней вы сделаете мою задачу?» Первое, что мы должны сделать: узнать, какая вероятность прогноза его устроит. Если он скажет, что стопроцентная, мы ответим, что задача точно будет выполнена за 12 дней, поскольку у нас был и такой печальный опыт. Хотя обычно мы выполняем задачи быстрее, а долгий срок выполнения задачи был связан с аномалией: например, долгим согласованием со стороны заказчика.
Но можно построить прогноз и с вероятностью в 75 %, и в 50 %, отчего прогнозируемое время выполнения задач будет меньше. Ведь на диаграмме явно видно, что в 50 % случаев задача точно будет выполнена раньше, чем за 7 дней. Такие вероятности, выраженные в процентах, называют процентилями. Например, если мы строим прогноз срока выполнения запроса в 50 % случаев, мы вычисляем 50-й процентиль.
Чаще всего для прогнозирования срока выполнения запроса используют 85-й процентиль. Он достаточно большой, чтобы выдать прогноз с хорошей достоверностью. Но он не учитывает аномалии, когда что-то пошло не так и выполнение запроса задержалось. В нашем примере 85-й процентиль будет где-то в районе 6 дней. Для более точного прогнозирования чаще всего вычисляют 98-й процентиль.
Та же гистограмма с отмеченным 85-м процентилем. Отметим, что данные считались на глаз, но в каком-нибудь сервисе управления проектами с поддержкой инструментов Канбан Метода они будут считаться автоматически
Теперь разберем частые примеры данных, выраженных в гистограмме времени цикла и расскажем, что они могут значить.
👉 Читайте также: «Управление бэклогом продукта: методы, инструменты и советы»

Популярные примеры гистограмм и их трактовка

Гистограмма «с хвостиком».
Тут видно, что большинство задач выполняются в первые дни, но также есть задачи, что растягиваются на более долгий период времени
В целом, на примере более-менее благоприятная картина: большинство задач заканчиваются в срок, но есть и те задачи, которые были сделаны за более долгое время. Чтобы оптимизировать рабочий процесс, нужно изучить задачи, завершенные за более длительный срок и понять, почему они настолько затянулись. Далее нужно устранить проблему растягивания сроков выполнения задач, чтобы «хвостик» исчез.
Гистограмма «забор».
На этой гистограмме видно, что время выполнения задач распределено примерно равномерно
Если время выполнения задач отражается равномерно на графике, это свидетельствует о том, что в организации нет четких требований к соблюдению дедлайнов. Такие данные бессмысленно анализировать до той поры, пока в организации не начнут ставить задачам крайние сроки и соблюдать их.
Гистограмма с высокими столбцами в начале.
Здесь видно, что большинство задач выполняется в первые пару дней – но хорошо ли это?
Если в начале гистограммы расположены один или два столбца, которые заметно выше других, нужно изучить природу этих задач. Скорее всего, это какие-то мелкие поручения, которые искажают общую картину и делают аналитические данные необъективными. Вероятно, их стоит отделить от основного массива задач в гистограмме.
Гистограмма с несколькими пиками.
Если у гистограммы несколько пиков, чаще всего это значит, что на ней отображаются разнородные задачи, которые относятся к разным производственным процессам. Они могут проходить разные пути, также они могут отличаться друг от друга по трудоемкости.
Тут видно, что у гистограммы есть 2 пика: в самом начале и ближе к концу
Итак, мы разобрали популярные примеры данных гистограмм и рассказали о возможных трактовках данных. Теперь поделимся тонкостями эффективного анализа метрик.
👉 Читайте также: «5 самых важных Agile-метрик и 11 второстепенных»

Как анализировать Lead Time и Cycle Time

Самое главное – нужно анализировать не обобщенные показатели, а частные, по различным срезам. Это могут быть срезы по разным производственным процессам, разным типам задач, разным сотрудникам, разным заказчикам и так далее.
Примерно так могут различаться данные по Lead Time и Cycle Time у разных производственных процессов
Сначала следует проанализировать Lead Time, а уже следом – начать смотреть Cycle Time у разных этапов производственного процесса. Часто бывает, что Lead TIme растягивается из-за какого-то одного долгого этапа: например, согласования руководителем. Выходит, чтобы это заметить, нужно сравнить между собой Cycle Time у разных этапов производственного процесса и обратить внимание, что запросы долго висят именно на согласовании.

Как оптимизировать показатели Lead Time и Cycle Time

Первое правило Канбанского клуба – не брать сразу в работу поступающие запросы. Ведь вы не сможете просрочить выполнение запроса, если вы его не взяли в работу, верно? Синк эбаут ит.
Вместо этого нужно предупреждать стейкхолдера о том, что вы приняли к сведению, что нужно выполнить такой-то запрос. Если он не идет с запросом к кому-то другому, вы держите его у себя до лучших времен. Такой беклог запросов в Канбане называется Upstream Backlog.
Еще один скриншот из видео Алексея Пименова, на который мы уже ссылались выше. Здесь видно, что Upstream Kanban заканчивается на Commitment Point – точке соглашения принятия запроса в работу. А Downstream Kanban – это этапы процесса от взятия запроса в работу до его выполнения
Далее вы можете приоритизировать задачи из беклога, чтобы брать в работу самые важные или ценные из них.
После этого, чтобы не брать в работу слишком много запросов, неплохо бы отслеживать еще одну метрику – пропускную способность. Если коротко, то это количество выполненных запросов за определенный временной период. Например, максимально вы можете выполнять 20 запросов в месяц – это будет вашей месячной пропускной способностью. И вот: если вы сейчас работаете над 13 запросами, вы понимаете, что можете взять в работу еще 7 запросов.
Что ж, вот вы и начали брать в работу посильное количество запросов, за счет чего улучшили свои показатели Lead Time и Cycle Time. Далее можно дополнительно оптимизировать метрики, отслеживая в ваших процессах этапы, которые отнимают слишком много времени. Отыскав их и поняв причину задержек, вы сможете сделать рабочий процесс еще более эффективным. Для этого используют еще ряд Канбан-инструментов, о которых мы рассказываем в других статьях: например, WIP-лимиты.
Ну а если вы не хотите во все это погружаться, но вам нужно оптимизировать рабочие процессы, обратитесь за бесплатной консультацией в Neogenda. Мы успешно внедряем в бизнес современные управленческие практики и помогаем достигать компаниям лучших результатов.
]]> Эффект бутылочного горлышка в бизнесе: как выявить и устранить «узкие места» в производственных процессах http://neogenda.ru/blog/b392hrjmb1-effekt-butilochnogo-gorlishka-v-biznese http://neogenda.ru/blog/b392hrjmb1-effekt-butilochnogo-gorlishka-v-biznese?amp=true Thu, 14 Nov 2024 12:58:00 +0300 Мария Савельева Многим руководителям знакома ситуация, когда в работе накопилась буквально лавина задач и все они застряли...

Эффект бутылочного горлышка в бизнесе: как выявить и устранить «узкие места» в производственных процессах

Многим руководителям знакома ситуация, когда в работе накопилась буквально лавина задач и все они застряли на одном из этапов. Скопившиеся задачи могут тормозить другие процессы вплоть до полной остановки всех работ. Такой процесс называется эффектом «бутылочного горлышка» или «bottleneck» и требует определенных управленческих действий для разрешения ситуации и предотвращения ее возникновения в будущем.
Бутылочное горлышко или узкое место (англ. bottleneck) — это ситуация в производственных процессах, когда скапливается много нерешенных рабочих элементов и они тормозят или парализуют весь производственный процесс.
Можно провести аналогию с банкой компота, которую нужно перелить в кувшин. В ней есть элементы разного размера: мелкие ягоды, крупные яблоки и жидкость, также и рабочие задачи есть крупные, есть небольшие, а есть пятиминутные. Чтобы перелить компот в кувшин, фрукты должны пройти через горлышко. Если горлышко узкое, то содержимое компота соберется в кучу, заблокирует проход и перелить его не удастся. Крупные и средние элементы встанут поперек всего и даже жидкости (самым коротким или пятиминутным задачам) не получится попасть в кувшин (готовые задачи).
Точно так же и в рабочих процессах бутылочное горлышко указывает на узкое место, где скорость производства или исполнения ограничивается, либо полностью останавливается. Проблема возникает тогда, когда нарушен баланс между входящим и выходящим потоками задач.
Поиск и устранение узких мест является важной управленческой задачей по оптимизации процессов. Если вам требуется анализ бизнес-процессов — обратитесь за бесплатной консультацией в Neogenda. Мы детально разберем ваш случай и предложим лучшее решение.
Далее в статье:
  • какие есть виды узких мест;
  • причины появления бутылочных горлышек;
  • какие есть негативные последствия для команды при появлении узких мест;
  • как найти проблему в производственных процессах;
  • как устранить проблему.

Виды узких мест в производственных процессах

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

Причины появления узких мест

Узкие места в рабочих процессах могут возникать по разным причинам и важно понимать, что их возникновение может зависеть сразу от нескольких факторов.
Рассмотрим подробнее несколько основных причин возникновения bottleneck:
  • Недостаток ресурсов. Одной из основных причин появления узких мест является недостаток ресурсов, таких как оборудование, материалы, технологии или персонал. Если какого-то из этих ресурсов не хватает для оптимальной работы, это может привести к замедлению или парализовать процессы.
  • Неоптимизированные процессы. Если рабочий процесс не оптимизирован и содержит излишние шаги, может быть так, что порядок действий не соответствует логике исполнения задачи, что также может создать узкое место. Например, излишняя бюрократия или согласования могут замедлить процесс и создать «узкое горлышко».
  • Недостаточная подготовка персонала. Отсутствие необходимых навыков и знаний у сотрудников ведет к замедлению процесса.
  • Неправильное использование технологий. Время от времени узким местом может стать неправильное использование технологий или программного обеспечения. Например, если система управления складом не настроена правильно или не соответствует потребностям предприятия, это может привести к замедлению выпуска продукции.
  • Неэффективное управление. Отсутствие эффективного управления процессами и отсутствие контроля над выполнением задач также способны создать узкие места. Плохая координация действий между отделами или недостаточный мониторинг процессов могут привести к снижению производительности.
Понимание причин возникновения узких мест поможет выявлять их на ранних стадиях и принимать меры для их устранения.

Негативные последствия эффекта бутылочного горлышка для команды

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

Как найти узкие места в процессах

Самый важный шаг в нахождении узких мест — визуализация рабочих процессов.
Если в команде внедрен Канбан Метод, то на доске будет наглядно видно, на каком из этапов появилось большое скопление карточек.
Визуализация задач на Канбан доске и выявления этапа с эффектом бутылочного горлышка
На примере выше видно, что самым узким местом является этап «в работе» и «на правках» — на них происходит основное создание продукта разными исполнителями, и внесение итоговых правок перед релизом. Этапы «на редактуре», «на повторной редактуре», «вычитка и корректура» и «проверка куратором» имеют совсем небольшое количество карточек и периодически могут простаивать в ожидании прихода задач на свой этап.
Еще один вариант визуализации — изучить Накопительную диаграмму потока.
Пример расчета пропускной способности команды с помощью Накопительной диаграммы потока
Диаграмма потока наглядно показывает количество задач на всех этапах в разрезе выбранного периода. Отдельно можно рассчитать, сколько задач за выбранный период времени команда может выполнить (пропускная способность). Из примера выше видно, что пропускная способность за 10 дней составляет 2 задачи.
Для более глубокого анализа процессов можно выполнить следующие шаги:
  • Провести анализ данных и отчетов. Изучить ключевые показатели, такие как время выполнения задач, издержки материалов, количество брака и другие метрики, чтобы определить области, где возможно наличие узких мест.На проблемные места может указать Контрольная диаграмма. На ней будут наглядно видны задачи, которые вызвали затруднения или были выполнены позже обещанного срока.
Контрольная диаграмма с задачами, которые вызвали проблемы при выполнении
  • Провести опрос сотрудников. В ходе беседы с сотрудниками могут быть выявлены не очевидные на первый взгляд проблемы. Члены команды могут подробно рассказать о трудностях и подсветить проблемы, с которыми они сталкиваются.Например, может оказаться, что ключевой сотрудник часто уходит на больничный, во время отсутствия его некому заменить и процессы встают. Решением может быть расширение штата и прием сотрудника с теми же функциями, либо увольнение текущего сотрудника и прием нового на его место.
  • Наблюдать за ходом выполнения процессов изнутри. Процессы можно изучать не только по отчетам и рассказам команды, но и «пощупать» их изнутри. Встав на место специалиста можно увидеть места где происходят простои, задержки или возникают проблемы во время выполнения.
  • Использовать методы управления качеством. При анализе можно применить методы управления качеством, такие как диаграмма Парето (Pareto chart), Диаграмма Ишикавы (cause-effect diagram, fishbone diagram), контрольные листы и прочие инструменты для выявления возможных узких мест в производственных процессах.
Выявив причины возникновения проблем по задачам с помощью таких инструментов, как Контрольная диаграмма, можно построить диаграмму Парето, она более наглядно покажет наиболее частые из проблем.
Высота столбцов покажет частоту возникновения проблем.
Диаграмма Парето или Кривая Парето для выявления частоты возникновения проблем в производственных процессах
Еще один инструмент — диаграмма Иcикавы, или так называемая диаграмма «рыбьей кости». На диаграмме происходит кластеризация всех возникающих проблем и узких мест по категориям.
Диаграмма Ишикавы или «рыбьей кости» с отображением проблем по категориям
Если вы хотите узнать больше о том, какие бывают ключевые Agile-метрики, читайте нашу статью «5 самых важных Agile-метрик и 11 второстепенных». В ней мы делимся самыми популярными метриками и способами их применения.

Как устранить проблему

Для устранения проблем, выявленных при анализе узких мест, стоит следовать пошаговой инструкции:
  • Расставить приоритеты для выявленных проблем. Нужно определить, какие из выявленных проблем являются наиболее критическими для решения. Оцените степень их влияния на производственные процессы и достижение целей компании.
  • Сформировать команду для решения проблем. Соберите команду или назначьте ответственных специалистов, которые будут заниматься устранением проблем. Включите в команду представителей различных отделов или подразделений, обладающих необходимыми знаниями и опытом.
  • Разработайте план действий. На основе анализа выявленных причин разработайте конкретный и структурированный план действий для устранения проблемы. Определите шаги, ресурсы, ответственных и сроки, необходимые для исправления ситуации.
  • Внедрите необходимые изменения. После разработки плана действий приступайте к внедрению изменений. Обеспечьте поддержку руководства и участие всей команды в процессе изменений.
  • Анализируйте результаты изменений. Организуйте систему мониторинга и контроля внедренных изменений. Следите за эффективностью мероприятий по устранению проблем и корректируйте план по устранению, если это необходимо.
  • Проведите обучение персонала. Для сотрудников стоит провести презентацию внедренных изменений, объяснить причины, по которым это было необходимо, и познакомить команду с новыми условиями и новыми процессами.
  • Оценить результаты изменений. После внедрения изменений стоит сравнить текущую производительность и эффективность команды с исходными показателями и оценить, насколько успешно были устранены «узкие места».
Если вам требуется помощь в выстраивании производственных процессов или консалтинг бизнеса — обратитесь в Neogenda. Более 100 компаний получили результат и решили задачи менеджмента на всех уровнях компании благодаря работе с нами. На бесплатной консультации мы детально изучим задачи вашего предприятия и предложим наилучшее решение.
]]> Фреймворк LeSS — SCRUM для крупных компаний: как внедрять, преимущества, реализация http://neogenda.ru/blog/4du581ont1-freimvork-less-scrum-dlya-krupnih-kompan http://neogenda.ru/blog/4du581ont1-freimvork-less-scrum-dlya-krupnih-kompan?amp=true Tue, 19 Nov 2024 16:07:00 +0300 Артур Нек Узнайте, как LeSS (Large Scale Scrum) помогает справиться с масштабированием Scrum, улучшить коммуникацию и ускорить...

Фреймворк LeSS — SCRUM для крупных компаний: как внедрять, преимущества, реализация

Узнайте, как LeSS (Large Scale Scrum) помогает справиться с масштабированием Scrum, улучшить коммуникацию и ускорить разработку.
В условиях, когда скорость и гибкость разработки продуктов являются ключевыми факторами успеха, масштабирование Scrum становится необходимостью для крупных организаций. Методология LeSS предлагает структуру, которая позволяет крупным компаниям эффективно применять принципы и практики Scrum на больших масштабах.
В этой статье мы рассмотрим принципы, преимущества и этапы реализации LeSS Scrum, его отличия от традиционного Scrum, а также возможность внедрения этого фреймворка в организацию, чтобы добиться ощутимых результатов.

Что такое LeSS и история его создания

Agile LeSS, или Large Scale Scrum, возник в начале 2000-х годов, когда многие крупные организации осознали преимущества применения Agile и Scrum. Однако, при попытке внедрения на масштабах, столкнулись с проблемами.
Большая/растущая компания — это всегда про увеличение числа сотрудников и команд. Добавляются роли, усложняется иерархия, появляется сложность взаимодействия между участниками структуры. Необходимо как-то справиться и с большим объемом работы. И тут компании осознали, что стандартные методы Scrum недостаточно эффективны и приводят к увеличению бюрократии и сложности процессов.
Именно в такой ситуации Крейг Ларман и Бас Водде, опытные консультанты по Agile и Scrum, начали свои исследования с целью создания фреймворка, который бы позволил крупным компаниям эффективно масштабировать Scrum. Они провели около 600 экспериментов и результатом стал LeSS — фреймворк, который объединяет принципы Scrum, учитывает размеры и потребности крупных организаций и, в отличие от Scrum, позволяет координировать работу множества команд, работающих над одним продуктом.
Проще говоря, LeSS — это тот же Scrum, не улучшенная, а адаптированная под масштаб его версия. LeSS помогает упростить продуктовую реализацию, улучшить коммуникацию между командами, ускорить процесс разработки и повысить качество продуктов.

Основы LeSS

Основные принципы LeSS довольно минималистичны, их всего 10. Это не руководство по внедрению, но они дают хороший фундамент для работы и имплементации LeSS.
  • Простота и минимализм
В названии книги LeSS Scrum: More with Less отражается вся суть методики: добиться большего через меньшее. LeSS полагается на существующие правила и руководства Scrum, но стремится упростить процессы для больших корпораций и избежать ненужной сложности.
  • Эмпирическое управление процессами
Процесс разработки в LeSS строится на обратной связи, то есть на постоянной адаптации и улучшении на основе опыта.
  • Прозрачность
LeSS поддерживает открытость и доступность информации для всех участников процесса разработки, что способствует более эффективной коммуникации и принятию обоснованных решений.
  • Ориентация на клиента
Основное внимание уделяется ценности, создаваемой для конечного пользователя.
  • Мышление Lean
LeSS вдохновлен принципами Lean Thinking. Это минимум избыточных процессов и максимум создания ценности для клиента. Другими словами, этот фреймворк стремится не к идеальности и эффективности, а, скорее, к упрощению процессов и гибкости.

Структура в LeSS

LeSS Scrum состоит из двух основных фреймворков: LeSS (Less Basic, стандартный) и LeSS Huge (огромный, гигантский).
  1. LeSS Basic используется для координации работы двух-восьми команд (10–50 человек), работающих над одним продуктом.
  2. LeSS Huge Framework предназначен для еще более крупных организаций, в которых над одним продуктом работают десятки команд. Здесь команд восемь и более (50–6000 человек и более). LeSS Huge сохраняет ту же структуру ролей, но включает Area Product Owners.
Суть этих фреймворков одинаковая, они отличаются лишь структурой и планированием спринтов.

Роли в LeSS

Ключевые роли — такие же как и в Scrum: владелец продукта (Product Owner), команды разработчиков и Scrum-мастер, но все же масштаб потребовал здесь некоторой корректировки. Примечательно, что в LeSS не существует понятия Scrum-команда.

Владелец продукта

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

Команды

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

Scrum-мастер

Scrum-мастер поддерживает команды, помогая устранять препятствия и обучая их принципам Agile, Scrum и LeSS. Его функция немного расширена, так как необходимо поддерживать координацию между командами. Вполне возможно, что каждая команда имеет своего скрам-мастера.

APO

В контексте LeSS Huge вводится роль Area Product Owner — владельца продукта по области (APO), который курирует более узкий объем работы для конкретной команды или нескольких команд. Он координирует задачи с верховным владельцем продукта, является его представителем и обеспечивает выполнение задач, ориентированных на клиента.

Заинтересованные стороны и клиенты

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

Отличие LeSS от традиционного Scrum и Safe

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

Product Backlog в LeSS

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

Спринты

В LeSS сохраняются основные церемонии Scrum (ежедневные скрам-встречи, уточнение бэклога продукта, планирования, обзоры спринтов), но они адаптированы для работы на больших масштабах. Какие-то элементы могут проводиться на уровне одной команды, но в LeSS важна координация, поэтому общие встречи для всех команд имеют особое значение.
Например, в LeSS вводится общая ретроспектива для всех команд, чтобы улучшить всю систему в целом. То же самое с уточнением продукта (Product Backlog Refinement): есть Team-level PBR, Multi-team PBR, а также вводится Overall PBR — Общее уточнение бэклога продукта.
Планирование спринта в LeSS делится на два этапа:
  1. Общее планирование спринта, где решают, на какие элементы разделить бэклог продукта. На этой встрече достаточно присутствовать представителям команд и Владельцу продукта.
  2. Здесь уже каждая Feature-команда создает свой спринт, бэклог спринта, взаимодействуя с другими командами.

Сравнение LeSS и SAFe

Кроме LeSS, есть и другие популярные Agile-фреймворки по масштабированию, например, Scaled Agile Framework® (SAFe). Оба фреймворка основываются на принципах Scrum, включают идеи Lean и ориентацию на клиента. Однако у них есть значительные различия в подходе к организационной структуре и ролям.
LeSS фокусируется на упрощении организационной структуры, оставаясь адаптивным и гибким. Это подтверждается тем, что основные роли в LeSS — владелец продукта, команды разработчиков и Scrum-мастер — сохраняются (кроме введения APO).
SAFe, напротив, требует дополнительных ролей и структурных изменений, таких как Release Train Engineer (RTE), Solution Train Engineer (STE) и владельцы эпиков (Epic Owners). SAFe включает множество артефактов и процессов, что может требовать значительных организационных изменений, к которым не все компании могут быть готовы. Вместо Scrum, на уровне команд в SAFe используется ScrumXP (процесс, созданный сообществом SAFe, похожий на Scrum), поэтому SAFe не позиционирует себя как фреймворк Scrum.
Таким образом, выбор между LeSS и SAFe зависит от потребностей компании и готовности к изменениям: LeSS подходит для тех, кто стремится к гибкости и минимализму, в то время как SAFe предлагает более структурированный и формализованный подход.
SAFe and Scaled Agile Framework являются зарегистрированными товарными знаками Scaled Agile, Inc.

Реализация LeSS в крупных компаниях

Подготовка к внедрению LeSS

Перед началом внедрения LeSS компания должна тщательно подготовиться, чтобы обеспечить успешный переход и минимизировать риски:
  • Проанализировать текущие процессы и структуру, чтобы определить области, требующие изменений и улучшений.
  • Определить цели и ключевые показатели эффективности (KPI).
  • Убедиться, что члены команд обладают набором разнообразных навыков, так как наличие кросс-функциональных команд является обязательным для LeSS.
  • Заручиться поддержкой топ-менеджеров и команд.

Внедрение

Нет четкого руководства по внедрению LeSS, невозможно выполнить какие-то определенные шаги и получить идеальную работающую структуру организации. LeSS — больше про принципы, адаптацию и эмпиризм. Можно следовать рекомендациям и плану, но главное — заложить основные правила LeSS в работу. Лучше начинать с одной продуктовой группы.
Ваш план по внедрению может выглядеть примерно так:
1. Обучение и тренинги для команд:
  • Проведение начальных обучающих сессий для всех команд и стейкхолдеров.
  • Если необходимо — обучение Scrum-мастеров и Владельца продукта особенностям работы в рамках LeSS.
2. Принятие структур и практик LeSS:
  • Создайте поддержку и инфраструктуру: Обеспечьте наличие необходимых инструментов, ресурсов и поддержки со стороны Agile-коучей для успешного внедрения LeSS, можно привлекать волонтеров.
  • Изменение структуры организации, избавление от ненужных ролей, создание кросс-функциональных команд.
  • Определение продукта и его критериев готовности.
  • Создание единого бэклога продукта, управляемого одним владельцем продукта. Бэклог продукта следует регулярно пересматривать и обновлять.
  • Реализация регулярного планирования, обзора и ретроспективы спринтов. Эти мероприятия должны проводиться регулярно и в них должны участвовать все члены команды и заинтересованные стороны.
  • Внедрение гибких практик, таких как непрерывная интеграция и непрерывное развертывание. Эти методы помогают быстро выявлять и устранять проблемы, гарантируя, что продукты всегда актуальны и соответствуют потребностям клиентов.
3. Начальная фаза (пилотный проект):
  • Выбор одной или нескольких команд для пилотного проекта, чтобы протестировать LeSS в действии.
  • Проведение первых спринтов с использованием LeSS, анализ результатов и внесение необходимых корректировок.
  • Оценка успехов и выявление возможных проблем и препятствий.
4. Масштабирование на другие команды и департаменты:
  • Расширение использования LeSS на другие команды, основываясь на опыте пилотного проекта.
  • Обеспечение поддержки и координации между командами через встречи и другие механизмы.
  • Постоянное улучшение процессов на основе обратной связи и анализа результатов.

Ключевые инсайты и рекомендации

Советы по успешной реализации LeSS

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

Пример успешного внедрения LeSS: кейс BMW

BMW Group решила внедрить LeSS для разработки систем автономного вождения и ADAS (Advanced Driver Assistance Systems). Основными целями были:
  • Сокращение координационных накладных расходов между различными департаментами.
  • Уменьшение количества передач задач между командами и ролями.
  • Повышение эффективности и гибкости разработки в условиях высокой неопределенности.
Процесс внедрения выглядел так:
  1. В апреле 2016 года создается новое подразделение для разработки систем автономного вождения, объединяющее несколько департаментов. Однако это приводит к увеличению координационных затрат и необходимости пересмотра организационной структуры.
  2. В период с июня по декабрь 2016 года руководство ADD (Autonomous Driving Department) разрабатывает новую рабочую модель и организационную структуру.
  3. В апреле 2017 года был организован однодневный вводный воркшоп с Mark Bregenzer, который вдохновил участников и создал импульс для дальнейших изменений. Позже было проведено четырехдневное обучение для руководителей по системному мышлению и организационному дизайну.
  4. В мае 2017 создаются две ключевые команды: команда миграции и executive team. Команда миграции состояла из менеджеров и сотрудников разных уровней, а executive team включала старших руководителей, отвечающих за стратегическое направление и поддержку изменений.
  5. В июне 2017 года было принято решение внедрить LeSS. Постепенно они пришли к фреймворку LeSS Huge, отдельно выделяя Департамент Коучинга и компетенций.
Результаты:
  • Благодаря внедрению новой модели, удалось существенно сократить время и ресурсы, затрачиваемые на координацию между командами и департаментами.
  • Команды стали быстрее адаптироваться к изменениям и эффективнее реагировать на новые требования, что особенно важно для разработки сложных продуктов, таких как системы автономного вождения.
  • Вовлечение всех уровней организации в процесс изменений позволило улучшить коммуникацию и сотрудничество, что в конечном итоге привело к повышению общей продуктивности.
Внедрение LeSS Huge в BMW Group показало, что слаженная работа команд и постоянное улучшение процессов могут значительно повысить эффективность разработки и качество конечного продукта. Стоит отметить, что на момент описания кейса в 2019 г. внедрение LeSS еще продолжалось.

Заключение

Фреймворк LeSS предлагает мощный и гибкий подход к масштабированию Scrum для крупных компаний. Внедрение LeSS позволяет компаниям эффективно управлять большими проектами, улучшать качество продуктов, ускорять их разработку и более эффективно использовать ресурсы.
Структура и принципы LeSS Scrum помогают улучшить коммуникацию между командами, обеспечить прозрачность процессов и сосредоточиться на создании ценности для конечного пользователя.
]]> Что такое поток и как его измерить? http://neogenda.ru/blog/dkmiee56l1-chto-takoe-potok-i-kak-ego-izmerit http://neogenda.ru/blog/dkmiee56l1-chto-takoe-potok-i-kak-ego-izmerit?amp=true Mon, 25 Nov 2024 16:49:00 +0300 Артур Нек Как ответить на вопрос: «Когда работа будет сделана?» Можем ли мы назвать точные сроки выполнения...

Что такое поток и как его измерить?

Как ответить на вопрос: «Когда работа будет сделана?» Можем ли мы назвать точные сроки выполнения работы, учитывая непредсказуемость работы, связанной с интеллектуальной деятельностью?
Способны ли мы предвидеть, сколько времени потребуется на выполнение отдельной задачи, понимая наличие множество других задач?
Возможно ли предугадать, что не будет нюансов, вызванных дефектами, зависимостями, внутренними препятствиями или внешними факторами, которые повлекут за собой сдвижку сроков выполнения?
Один из самых быстрых, легких и наиболее надежных подходов к ответу на вопрос «Когда работа будет сделана?» — это составить вероятностный прогноз.
Прогноз — это предположение, основанное на ретроспективных данных о производительности. Предположение содержит несколько возможных исходов и их вероятность. И нам потребуются данные и метрики, чтобы построить модель для прогнозирования. Когда мы говорим о работе в которой уже удалось организовать поток, построить такую модель получится гораздо легче.
Так что же такое поток, и самое главное, почему он так важен? Настроив поток и уделив внимание его основным метрикам, вы сможете закончить работу в управляемый, предсказуемый срок, но также и принимать грамотные решения основанные на данных.

Что такое поток?

Представьте себе: вы стоите на контрольно-пропускном пункте в аэропорту. Что Вам напоминает процесс? Система безопасности в аэропорту — это стандартизированная система. Люди проходят этапы этой системы шаг за шагом: готовятся к паспортному, идут к ленте, достают все свои электронные устройства, ставят багаж на ленту, проходят сканнер, забирают багаж с другого конца ленты, кладут все электронные устройства обратно и идут дальше.
На пропускную способность системы (количество людей, которые могут пройти досмотр одновременно), влияет множество факторов: количество пунктов досмотра, число свободных работников, скорость обработки данных для проведения досмотра и др.
Существует множество ситуаций, которые могут прервать поток. Кто-то один долго выкладывает телефон или прочие электронные устройства. Или на ком-то срабатывает металлоискатель, этому пассажиру приходится отойти, достать все из карманов и снова пройти контроль. Или же досмотр проходит пассажир с ограниченными возможностями, которому может понадобится помощь.
Чем больше людей проходит через систему, тем больше вероятность, что процесс займет больше времени, чем обычно.

Понимание потока в интеллектуальной работе

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

Как измерить рабочий поток

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

Время цикла

Итак каждый раз, когда Вы договариваетесь с клиентом о новом заказе, первый вопрос, на который Вам нужно ответить — «Когда всё будет готово?». Что действительно важно для наших клиентов: первое — получат ли они заказанный товар или услугу в принципе, и второе — сколько им придется ждать.
Во время работы мы запускаем таймер с того момента как работа была принята, и останавливаем его, когда работа выполнена.
Временной отрезок между точкой принятия обязательств и точкой отдачи обязательств называется временем цикла.
Время цикла — это величина того, сколько времени потребуется на получение желаемого товара или услуги клиентом. Анализ времени цикла и его изменений является эффективным инструментом для оценки предсказуемости рабочего процесса. Также это даст вам возможность понять, соответствует ли рабочий процесс вашим ожиданиям и ожиданиям клиента.

Пропускная способность

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

Количество незавершенной работы

Третьей метрикой потока является количество незавершенной работы (англ. WIP). Она отражает взятый (обещанный), но не законченный объем работ. Эта метрика влияет на время, которое потребуется для достижения результата по каждой задаче, которую мы производим за определенный промежуток времени.
Поэтому для обеспечения результативности потока очень важно поддерживать WIP и стремиться к его постоянству. Обеспечив постоянство данной метрики, мы сохраним нужное время цикла и объем выполненных работ.
Взаимосвязь основных метрик потока отражена через закон Литтла. Всегда помните, что изменение одной метрики потока неизбежно повлияет на другую (или же на все) метрику.
Стоит учитывать данную взаимосвязь для реализации простых стратегических решений, которые повысят скорость вашей работы.
Например, сократив число задач, над которыми вы работаете, вы ускорите их выполнение. Если WIP снижается, также снижается и время цикла, а объем выполненных работ растет, а это именно то, к чему мы стремимся для достижения эффективного потока.

Среднее время незавершенной работы (старение запросов)

Последняя метрика потока, и ,на мой взгляд, самая важная — это среднее время незавершенной работы.
Согласно закону Литтла, поддержание стабильности рабочих процессов зависит от двух факторов: количества вашей незавершенной работы и среднего времени незавершенной работы. Если выбирать что важнее, то главным все таки является постоянство каждой: предсказуемость систем определяются вашей способностью поддерживать постоянное количество незавершенной работы и среднее время незавершенной работы.
Среднее время незавершенной работы и время цикла по сути одно и тоже, только при расчете времени цикла учитываются завершенные задачи, в то время как при расчете среднего времени незавершенной работы — начатые, но не выполненные задачи.
Для расчета времени цикла не имеет значение ваше текущее количество незавершенной работы. У Вас может быть очень низкое среднее время цикла, если вы откладываете какую то работу в процессе, однако если вы в конечном итоге завершаете ее, среднее время цикла сильно поднимется. Вот почему так важно отслеживать среднее время незавершенной работы и регулярно сравнивать его со средним временем цикла.
Лучше всего, чтобы эти метрики были примерно равны.
Всегда лучше рассматривать эти метрики вместе, как они соотносятся друг с другом, являясь частями потока.
Если вы ускорите выполнение какой то отдельной задачи, вы можете ничего не получить с точки зрения результата потока. Мы никогда не советуем ускорять работу бездумно, если пострадает качество результата системы. Ведь повышение приоритета одной задачи всегда стопорит выполнение всей остальной работы.
Не пытайтесь улучшить хоть какую-то из этих метрик в отдельности, лучше используйте их вместе для того, чтобы лучше понять не только то, как проходит работа в вашей системе, но и использовать для оценки своей производительности.
Теперь пора взяться за дело! Начните отслеживать основные показатели потока, а также то, как принимаемые вами решения влияют на эффективность работы. Отмечайте, как меняются ваши рабочие процессы с течением времени, лучше всего раз в две недели, чтобы понять, приносят ли ваши идеи по улучшениям положительные результаты.
]]> Приоритеты в Kanban http://neogenda.ru/blog/0noo3c5jo1-prioriteti-v-kanban http://neogenda.ru/blog/0noo3c5jo1-prioriteti-v-kanban?amp=true Thu, 21 Nov 2024 17:15:00 +0300 Мария Савельева Узнайте, как эффективно приоритизировать задачи в Kanban. Получите советы по управлению рабочими потоками и повышению...

Приоритеты в Kanban

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

Введение

Представьте себе такую ситуацию: крупная компания разрабатывает новое программное обеспечение, а команда разработчиков завалена множеством задач — от исправления ошибок до внедрения новых функций. В какой-то момент становится ясно, что нужно расставить приоритеты, иначе невозможно эффективно управлять временем и ресурсами. Подобное случается в любом проекте, особенно в условиях быстро меняющихся обстоятельств и ограниченных ресурсов. И в большинстве случаев традиционного тайм-менеджмента бывает недостаточно.
Именно здесь на помощь приходит Kanban. Канбан позволяет не только визуализировать рабочий процесс, но грамотно организовать приоритизацию задач распределение ресурсов. В отличие от Scrum или Waterfall, Канбан Метод отличается гибкостью и возможностью адаптации к текущим потребностям и изменениям на проекте.

Основные проблемы при отсутствии приоритезации задач

1. Перегрузка задачами и снижение производительности.
Без системы приоритетов команды могут просто добавлять элементы в список задач / бэклог, не оценивая важность, что приводит к снижению эффективности работы. Многозадачность без четких приоритетов затрудняет движение к завершению, что замедляет общий процесс.
2. Увеличение времени выполнения задач и затягивание проектов.
Неправильная расстановка приоритетов может привести к задержкам в выполнении проектов, что вызывает недовольство клиентов и увеличивает расходы. Проекты длятся дольше и становятся дороже, что негативно сказывается на бизнесе.
3. Зависимость от интуитивных решений.
Принятие решений на основе интуиции или догадок может быть ненадежным. Важно выбирать задачи, приносящие наибольшую пользу клиентам и бизнесу, что требует тщательного анализа и оценки.
4. Снижение автономии команды.
Зависимость от менеджера или скрам-мастера для определения приоритетов снижает автономию команды. Это может препятствовать созданию самоуправляемых и мотивированных команд, которые являются важным элементом успешного бизнеса.
5. Отсутствие четких целей задач.
Задачи без ясно определенных целей не приносят значимой пользы и расходуют ресурсы. Эффективная приоритезация помогает направлять усилия команды на задачи, которые действительно важны.
Создание списка приоритетных задач помогает командам лучше понимать, на чем следует сосредоточиться в первую очередь.Именно поэтому важно внедрить эффективные техники расстановки приоритетов, которые мы рассмотрим в следующих разделах.

Значение приоритезации в Канбан

Приоритезация задач в Канбан — это не просто расстановка задач по порядку их выполнения. Это сложный процесс, который включает оценку срочности, важности и стоимости задержки каждой задачи. Например, если задержка в выполнении задачи может привести к финансовым потерям, она становится приоритетной. Такой подход помогает командам сосредоточиться на наиболее важных и срочных задачах, обеспечивая максимальную эффективность и своевременное выполнение проектов.
Приоритет — это наше отношение к задаче и что мы с ней делаем.
Десять лет назад Дэвид Андерсон призывал Канбан-сообщество отказаться от слов «приоритет» и «приоритизация». Он объяснял это следующим образом: «Мы не выполняем конкретные действия по определению приоритетности работ для систем Канбан. Вместо этого мы практикуем динамическую расстановку приоритетов, выбирая элементы работы на месте, основываясь на риске или других желаемых результатах, таких как объективность, хорошее обслуживание клиентов или ценность». В своей статье Дэвид говорит о том, что слово «приоритет» на самом деле артефакт, который маскирует реальную информацию о таких рисках как стоимость задержки, требуемые навыки, возможный ущерб и так далее.
Instead of the term, and the activity of, ¨prioritization¨, we prefer the explicit terms of selection, scheduling, sequencing, and class of service
Вместо термина и деятельности “приоритизация” мы предпочитаем четкие термины: “отбор”, “планирование”, “определение последовательности” и “класс обслуживания”.
В мире бизнеса и проектов слово «приоритизация» звучит часто, поэтому в нашей статье мы будем использовать данный термин.

Основные методы приоритезации задач

  • Определение последовательности (Sequencing) — расстановка по предпочтениям, постановка в очередь.
  • Планирование (Scheduling) — определение времени начала работы (по расписанию или согласно дедлайну).
  • Отбор (Selection) — выбор в пользу одного варианта перед другими возможными.
  • Классы обслуживания (Classes of service) — политика, включающая очередь, обычно определяется риском и/или стоимостью задержки.

Определение последовательности

Это механизм расстановки приоритетов, который определяет порядок элементов, имеющихся в вашем бэклоге. Некоторые задачи из списка будут срочными, другие могут подождать, а есть и такие, которые вообще не будут обрабатываться. Такой подход к определению последовательности задач называется триаж.
Первоначально термин триаж (от французского слова triage, означающего «сортировка» или «отбор») использовался в медицинской практике для классификации пациентов по степени необходимости в медицинской помощи, особенно в условиях чрезвычайных ситуаций, когда ресурсы ограничены. Если полевой госпиталь перегружен, если спрос слишком велик, а врачей, хирургов, коек и т. д. не хватает, естественно, возникает проблема: сейчас, потом или вообще не надо. Это три категории сортировки: кто получает лечение немедленно, кто — позже, а кто не получает его вообще.
Сам по себе триаж появляется естественным образом, как только вы сталкиваетесь с ситуацией, что задач много, а ресурсов не хватает, и нужно сделать выбор. Чтобы определить, какой элемент важнее других, и выстроить их в соответствующую последовательность, необходимо разработать механизм, определяющий порядок следования всех элементов в пуле на основе их ценности. Лучше всего разработать систему управления рисками, основанную на стоимости задержки, рыночных возможностях, технического долга или их сочетании.

Планирование

Процесс планирования задач включает в себя определение момента начала работы, чтобы уложиться в намеченные сроки и гарантировать завершение к заданному сроку.
Важно: если приступить слишком рано, можно упустить возможность заняться другими перспективными проектами/задачами. Однако если начать слишком поздно, возникает риск задержки и невыполнения обязательств. Чем дольше откладывать начало работы, тем выше вероятность срыва сроков. Поэтому необходимо найти оптимальный момент для старта.
Чтобы определить лучшее время для начала работы, следует обратиться к прогнозу вероятности выполнения задачи. Например, используя Cycle Time Scatterplot (диаграмма распределения времени цикла), которая показывает, сколько времени потребовалось для выполнения каждого рабочего элемента в прошлом и каково вероятное время выполнения любых будущих задач такого же размера.
Например, дедлайн для задачи установлен 1 сентября, а прогноз показывает, что вероятность завершения работы в течение 20 дней составляет 99%, а в течение 10 дней — 85%, то оптимальный диапазон для начала работы будет с 12 по 22 августа. Таким образом, начав задачу в этот период, можно с высокой вероятностью (не менее 85%) успеть завершить её вовремя.
Таким образом можно поддерживать стабильность системы и улучшить предсказуемость выполнения задач. Это позволяет более точно планировать и управлять ресурсами.
👉Читайте также: «5 самых важных Agile-метрик и 11 второстепенных»

Отбор

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

Классы обслуживания

Classes of Service (CoS) — это метод классификации задач по их важности и срочности. В зависимости от бизнес-приоритетов, задачи могут быть разделены на несколько категорий:
  • Expedite (Срочные): задачи, требующие немедленного выполнения 100-процентной отдачи, как говорится — «нужно было еще вчера». Они имеют наивысший приоритет и обходят все остальные элемент в очереди, так как связаны с огромными рисками для проекта. Этому классу разрешается нарушить WIP-лимит (количество одномоментных незавершенных задач в процессе). Желательно, чтобы в работе находился только один такой срочный элемент, чтобы не нарушать баланс в работе.
  • Fixed Date (Фиксированная дата): задачи с жесткими сроками выполнения. При их планировании важно учитывать дедлайны, чтобы не допустить задержек. В таких элементах обычно высокая стоимость задержки. Проекты, попадающие в этот класс, требуют детального прогнозирования и тщательного рассмотрения перед принятием решения.
Standard (Стандартные): обычные задачи без жестких сроков и срочности. Они выполняются в порядке поступления, если не появляется более приоритетных задач. Основная часть рабочих элементов находится здесь, и для них используется FIFO (first in, first out) — первым пришел, первым ушел.
Intangible (Нематериальные): задачи, не имеющие непосредственного влияния на бизнес или клиента. Они выполняются в последнюю очередь, если есть время и возможность. Здесь обычно совсем невысокая стоимость задержки, но хитрость в том, что эти задачи могут резко перейти в другой класс, если долгое время не обращать на них внимание.
По усмотрению, можно добавить классы обслуживания, но их должно быть не больше шести. Использование классов обслуживания помогает командам быстро определять приоритеты и принимать решения о порядке выполнения задач, что особенно важно в условиях ограниченных ресурсов. Важно, что у каждого класса есть четкая политика действий, что само себе уже является бонусом: нет необходимости в человеке, который будет определять приоритетность, и это позволяет создавать эффективные самоорганизованные команды.
Классы обслуживания могут стать вашим лучшим другом при принятии решений о планировании и расстановке приоритетов. Применение классов обслуживания обеспечивает большую гибкость для вас и ваших клиентов, одновременно оптимизируя экономический результат и управляя рисками. Специалисты Neogenda подскажут, как наиболее эффективно использовать классы обслуживания в рамках Канбан.

Важные метрики

Cost of Delay (Стоимость задержки)

Cost of Delay (CoD) — это метод оценки экономических потерь, связанных с задержкой выполнения задачи. CoD помогает командам понять, насколько выгодно выполнить работу раньше, чем позже, и насколько рискованно откладывать или игнорировать ее. Этот метод включает:
  1. Упущенные выгоды: потери, связанные с отсутствием продукта или функции на рынке;
  2. Прямые затраты: дополнительные расходы, возникающие из-за задержки, такие как штрафы или неустойки;
  3. Снижение удовлетворенности клиентов: негативное влияние на репутацию компании или отношения с клиентами.
Для расчета стоимости задержки используется формула: Стоимость задержки = Потеря за временной промежуток x Длительность задержки. Например, если задача приносит $1,000 в день, а задержка составляет 5 дней, стоимость задержки будет $5,000.
Когда CoD высок, вам необходимо планировать свои мощности таким образом, чтобы начать работу раньше и завершить проект с большей эффективностью, даже если это приведет к задержке других проектов с меньшей стоимостью задержки. Этот подход позволяет командам объективно оценивать приоритеты и принимать обоснованные решения.

WSJF (Weighted Shortest Job First)

WSJF — соотношение стоимости задержки к размеру задачи. Этот подход помогает выбирать элементы, которые принесут наибольшую ценность за наименьшее время. Формула для WSJF выглядит следующим образом:
WSJF = Cost of Delay / Job Size
Где:
  • Cost of Delay — сумма потерь от задержки.
  • Job Size — размер задачи, обычно выраженный в человеко-часах или других единицах работы.
Задачи с наибольшим значением WSJF имеют наивысший приоритет. Этот метод позволяет максимально эффективно использовать ресурсы и время команды, уделяя внимание задачам с наибольшей отдачей.

Work In Progress (WIP)

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

Визуализация и управление рабочими потоками

Эффективное управление задачами в Канбан невозможно без визуализации рабочего процесса. Визуальные инструменты помогают командам видеть общую картину, отслеживать прогресс и выявлять узкие места.
Использование Канбан-досок
Канбан-доска является основным инструментом визуализации задач в Канбан. Она состоит из колонок, каждая из которых представляет собой этап рабочего процесса: стандартные — To Do (Запланировано/Бэклог), In Progress (В процессе), Done (Выполнено), или же адаптированные под конкретные потребности вашей команды. В каждой колонке размещаются карточки задач, которые перемещаются по мере их выполнения. В канбан-доске обязательно учитываются WIP лимиты. Канбан-доска позволяет визуально расставлять приоритеты, перемещая задачи по мере их выполнения и выделяя те, которые требуют немедленного внимания.
Визуализация с помощью канбан-доски помогает каждому человеку в команде ясно видеть, что сделано, что в работе и что предстоит сделать. Это упрощает принятие решений и способствует лучшему управлению ресурсами.
CFD (Cumulative Flow Diagram)
Это графический инструмент, который показывает количество задач на каждом этапе рабочего процесса с течением времени. CFD помогает командам отслеживать прогресс, выявлять узкие места и анализировать производительность.
Стандартно ось X отображает временные промежутки (дни, недели, месяцы), а ось Y показывает количество задач на каждом этапе. Каждая цветная область на диаграмме представляет собой количество элементов на конкретном этапе.
CFD позволяет легко увидеть, где в процессе возникают задержки, сколько времени занимает выполнение задач на каждом этапе и как изменяется объем работы с течением времени. Анализируя эти данные, команды могут принимать решения о том, как оптимизировать рабочий процесс и улучшить производительность.
Swimlanes для улучшения организации
Swimlanes (плавательные дорожки) — это горизонтальные линии на Канбан-доске, которые помогают разделить задачи по категориям или типам работ. Например, задачи могут быть разделены по проектам, типам работ (ошибки, новые функции, технический долг) или приоритетам.
Использование Swimlanes помогает командам лучше организовать задачи и отслеживать прогресс по различным направлениям. Это также способствует более ясному распределению ресурсов и ответственности среди членов команды.

Практические советы по улучшению приоритезации

Эффективная приоритезация задач в Канбан требует постоянного анализа и улучшения рабочих процессов. Следующие практические советы помогут командам оптимизировать приоритезацию и повысить общую производительность.
1. Регулярные обзоры и адаптация процессов.
Одним из ключевых принципов успешного управления задачами является регулярный анализ, адаптация рабочих процессов и пересмотр приоритетов. Важно проводить регулярные ретроспективы и встречи для обсуждения текущих результатов и выявления проблем. Эти встречи позволяют:
  • оценить, насколько эффективно применяются выбранные методы приоритезации;
  • обсудить возникшие сложности и предложить пути их решения;
  • поделиться наблюдениями о том, как изменения в приоритезации влияют на общую производительность и удовлетворенность клиентов.
Регулярные обзоры помогают командам оставаться гибкими, эффективно расставлять приоритеты и быстро адаптироваться к изменениям в проекте или бизнес-окружении.
2. Ограничение WIP (Work In Progress)
Ограничение количества задач, находящихся в работе, помогает командам сосредоточиться на завершении текущих работ и избегать перегрузки. Установка WIP лимитов способствует:
  • Снижению времени переключения между задачами, что увеличивает эффективность работы.
  • Улучшению качества выполнения, так как команда может сосредоточиться на меньшем количестве задач.
  • Быстрому выявлению и устранению узких мест в процессе, так как задачи не накапливаются в одной из колонок канбан-доски.
Важно регулярно пересматривать и корректировать WIP-лимиты, чтобы они соответствовали текущим возможностям и приоритетам команды.
3. Анализ зависимости задач
Иногда задачи могут иметь зависимости, которые необходимо учитывать при их приоритезации. Например, задача по разработке новой функции может зависеть от завершения работ по обновлению инфраструктуры. Учет таких зависимостей помогает:
  • Оптимизировать последовательность выполнения задач, избегая задержек.
  • Правильно распределять ресурсы и время, учитывая возможные риски и препятствия.
  • Улучшить координацию между командами и отделами, особенно в больших проектах.
4. Учет потребностей клиентов и бизнеса
Приоритезация задач должна учитывать не только внутренние факторы, но и потребности клиентов и бизнеса. Для этого важно:
  • Регулярно собирать обратную связь от клиентов и учитывать её при расстановке приоритетов.
  • Учитывать стратегические цели компании и их влияние на приоритеты задач.
  • Использовать данные и аналитику для оценки того, какие задачи принесут наибольшую ценность клиентам и компании.

Заключение

Успешное управление задачами в Канбан требует внимательного подхода к приоритезации, визуализации процессов и использования аналитических инструментов. Приоритезация помогает командам сосредоточиться на наиболее важных и срочных задачах, что способствует эффективному использованию ресурсов и времени.
Для успешного внедрения и адаптации Канбан в вашей команде рекомендуется начать с простых инструментов и метрик, постепенно вводя более сложные методы по мере приобретения опыта. Постоянное обучение и анализ данных являются ключевыми факторами для достижения успеха и повышения эффективности.
Помните, что Канбан — это не просто тайм-менеджмент и инструмент управления задачами, но и философия, ориентированная на непрерывное улучшение и адаптацию к изменениям. Следуя рекомендациям и лучшим практикам, изложенным в этой статье, вы сможете создать динамичную и продуктивную рабочую среду, которая будет способствовать успеху вашего проекта и удовлетворению потребностей клиентов. Помните, команды, которые начинают с определения приоритетных целей, обычно достигают лучших результатов, поскольку сосредотачиваются на наиболее важных аспектах работы.
]]> Кик офф встреча: зачем она нужна и как заложить основу успешного проекта http://neogenda.ru/blog/0b5lbtala1-kik-off-vstrecha-zachem-ona-nuzhna-i-kak http://neogenda.ru/blog/0b5lbtala1-kik-off-vstrecha-zachem-ona-nuzhna-i-kak?amp=true Tue, 26 Nov 2024 06:36:00 +0300 Артур Нек Чтобы проект оказался эффективным, важно начать с четкого понимания целей, согласованных ожиданий и слаженной команды....

Кик офф встреча: зачем она нужна и как заложить основу успешного проекта

Чтобы проект оказался эффективным, важно начать с четкого понимания целей, согласованных ожиданий и слаженной команды. Для этого компании используют kick-off meeting, или установочную встречу.
Установочная встреча — это первое официальное собрание, на котором команда и ключевые участники проекта обсуждают цели, задачи, план действий и распределение ролей.
Действительно ли это нужно? Реально ли сразу приступить к выполнению задач? Кик-офф встреча может показаться формальностью. Но на самом деле это важный инструмент, который помогает собрать участников проекта и заложить фундамент для успешной работы: согласовать ключевые моменты, выявить риски, выстроить общую стратегию и эффективно взаимодействовать.
В статье разберем, зачем нужна кик-офф встреча, как к ней подготовиться и как провести, чтобы обеспечить проекту лучший старт.
А внедрить современные управленческие практики в ваш бизнес поможет Neogenda. Обучили уже более 5 000 сотрудников Tinkoff, Яндекс, Авито, Сбер и других компаний. Оставьте заявку на бесплатную консультацию, и в формате Zoom-встречи мы подберем подходящее решение, чтобы повысить эффективность вашей команды.

Зачем проводить кик офф митинг

Кик-офф встреча важна для каждого проекта, потому что помогает:
  • Формировать общее понимание проекта. Благодаря кик-офф встрече команда может быстрее определить цель проекта и его основные этапы.Пример. Компания-разработчик приложений организовала kick-off встречу, чтобы начать новый проект. Это позволило команде получить общее видение и обсудить, какие функции будут приоритетными для первой версии продукта. Участники могли задать вопросы по проекту и обсудить с командой свои ожидания.
  • Определить роли и ответственность. Во время kick off проекта важно назначить роли и зоны ответственности каждого.Пример. В компании «Х» новый проект по разработке экологичного продукта обсуждали совместно с основателем и исполнительным партнером (founder и executive partner). На встрече распределили обязанности между участниками: отдел маркетинга занялся продвижением, а инженерная команда — технической реализацией. Это позволило четко обозначить, кто за что отвечает.
  • Построить команду и улучшить взаимодействие. Знакомство с командой на кик-офф встрече позволяет наладить общение и взаимопонимание.Пример. В компании «М» на установочной встрече участники нового проекта знакомились и обсуждали свои задачи. Это помогло им построить доверительные отношения с самого начала и создать командный дух. Состояние удовлетворения команды возросло.
  • Создать повестку и план мониторинга. Участники собираются,чтобы обсудить повестку встречи и спланировать ключевые этапы мониторинга проекта.Пример. Компания «Е» начала проект по снижению углеродного следа. На кик-офф встрече обсудили основные цели и временные рамки. Это позволило всем участникам проекта понять, как будет проходить мониторинг и какие задачи нужно выполнить в первую очередь.
  • Выявить и обсудить возможные риски. Участники могут обсудить потенциальные риски и разработать стратегии, чтобы их минимизировать.Пример. Проект по разработке инновационного строительного материала начался с kick off meeting, на котором участники выявили возможные проблемы с поставками. Благодаря этому команда смогла подготовиться и разработать план на случай задержек.

Как подготовиться к кик офф встрече

Чтобы kick off встреча оказалась полезной для всех участников и заложила основу для плодотворного проекта, важно правильно к ней подготовиться:
1. Соберите информацию и установите цели
Подготовка начинается с детального сбора данных о проекте и установления четких целей. Например, перед запуском проекта по разработке облачного ПО менеджеры собирали информацию о потребностях клиента, технических требованиях и сроках выполнения. Это позволило участникам понять цель проекта и определить конкретные задачи для команды.
2. Составьте план кик-офф встречи
  • Определите основные темы. Например, если компания запускает проект по строительству энергоэффективных домов, план может включать обсуждение требований к материалам и соблюдению экологических стандартов.
  • Назначьте ведущего встречи. Установите ответственного человека, который будет руководить кик-офф встречей и следить за тем, чтобы команда обсуждала только самое важное.
  • Подготовьте вопросы для обсуждения. Сформулируйте вопросы, которые помогут уточнить цели, роли участников и выявить потенциальные риски.
  • Определите срок для каждого вопроса. Установите продолжительность обсуждения для каждой темы, чтобы встреча прошла структурировано и уложилась в запланированное время.
3. Подготовьте кик-офф презентацию
Кик офф презентация — это основной инструмент, который помогает представить проект команде и создать общее видение: донести основные цели и задачи, распределить роли и обсудить потенциальные риски.

Как проходит кик-офф встреча

Kick-off встреча — это структурированное событие, которое проходит в несколько этапов. Каждый из них играет важную роль в успешном запуске проекта и помогает участникам четко понимать его цели и задачи. Рассмотрим эти этапы:
1. Приветствие и знакомство с командой
Встречу начинают с приветствия и краткого знакомства с командой. Ведущий может представить себя и других ключевых участников, чтобы создать позитивную атмосферу.
Пример. В компании «Н» на этом этапе каждый участник по очереди рассказывает о своем опыте и роли в проекте. Это помогает настроиться на совместную работу и улучшить взаимодействие в команде.
2. Краткое описание проекта
Следующий шаг — описать проект в общих чертах. Важно, чтобы участники понимали его суть и цели.
Пример. Ведущий представил проект по разработке нового программного обеспечения и объяснил, какие проблемы он решает для клиентов и каковы его ключевые преимущества. Это позволило участникам лучше понять контекст проекта и его значимость.
3. Установление целей встречи
На этом этапе нужно четко обозначить цель стартовой встречи. Для этого ведущий объясняет, что в ходе кик-офф встречи участники должны обсудить ключевые этапы, распределить роли и выявить возможные риски.
Пример. В компании «К» определили, что цель установочной встречи — согласовать дедлайны задач и распределить ответственность между членами команды.
4. Назначение ролей и обсуждение задач
После того, как установили цели, важно обсудить роли участников и задачи, которые необходимо выполнить,чтобы избежать путаницы и дублирования усилий. Важно, чтобы каждый понимал свои обязанности и ответственность.
Пример. Менеджер проекта подробно объяснил, что отдел разработки будет отвечать за технические аспекты, а отдел маркетинга — за продвижение.
5. Обсуждение рисков и способов их минимизации
На этом этапе кик-офф встречи команда должна выявить потенциальные риски и обсудить, как снизить их вероятность. Участники могут задавать вопросы по проекту и делиться своими соображениями о возможных трудностях.
Пример. В компании «С» команда обсудила риски, которые связаны с поставками, и разработала планы действий на случай задержек.
6. Завершение встречи и определение следующих шагов
На финальном этапе ведущий подводит итоги обсуждения и определяет следующие шаги. Важно закрепить сроки выполнения задач и добиться того, чтобы участники понимали свою ответственность.
Пример. После обсуждения команда согласовала, что следующее собрание, на котором обсудят промежуточные этапы, пройдет через две недели.

Что еще обсудить на кик-офф встрече

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

Кто ведет кик-офф проекта

Ведущий кик-офф встречи играет важную роль, потому что помогает создать подходящую рабочую атмосферу и понять цели проекта.
Обычно это человек, который обладает достаточным опытом и знаниями. Ведущим может быть проектный менеджер, руководитель команды или старший специалист, который будет отвечать за реализацию проекта. Важно, чтобы этот человек пользовался авторитетом в команде и умел общаться.
Перед ведущим кик-офф встречи стоит несколько задач:
  • Разработать четкую повестку мероприятия, которая будет включать основные темы и порядок их обсуждения.
  • Задавать нужное направление дискуссии, следить за тем, чтобы все участвовали примерно поровну и не отклонялись от темы.
  • Создавать атмосферу открытости и доверия, которая позволит участникам свободно делиться мнениями и идеями.
  • Следить за тем, чтобы все основные вопросы участники команды успели обсудить в отведенное время.
  • Подвести итоги встречи, выявить ключевые решения и согласовать дальнейшие шаги.
Чтобы эффективно провести кик-офф митинг, ведущий должен:
  • Быть уверенными и позитивными. Это помогает создать благоприятную атмосферу и сделать так, чтобы каждый воспринимал встречу положительно.
  • Слушать участников. Активное слушание позволяет находить важные мнения и идеи, а еще показывает, что точки зрения всех членов команды достойны уважения.
  • Сохранять фокус. Умение возвращать разговор к основной теме, если обсуждение начинает отклоняться, помогает поддерживать продуктивность встречи.
  • Фиксировать результаты. Важно отмечать ключевые моменты обсуждения и решения, чтобы после встречи можно было обратиться к записям и следовать намеченным шагам.

Вместо итога

Кик-офф встреча — это важный этап в начале любого проекта. Она задает тон для всей дальнейшей работы и помогает разобраться в целях, распределить роли участников и обсудить организационные моменты. Правильная подготовка, активное участие всех членов команды и грамотное ведение встречи позволяют избежать недоразумений и настроить всех на успешное сотрудничество.
Если стремитесь грамотно управлять проектами и оптимизировать бизнес-процессы, обратитесь за бесплатной консультацией в консалтинговую Neogenda. Поможем создать эффективные стратегии, обеспечить бесперебойное взаимодействие в команде и достичь поставленных целей.
]]> Что такое дедлайны и как ими управлять http://neogenda.ru/blog/rz033jiek1-chto-takoe-dedlaini-i-kak-imi-upravlyat http://neogenda.ru/blog/rz033jiek1-chto-takoe-dedlaini-i-kak-imi-upravlyat?amp=true Wed, 27 Nov 2024 06:40:00 +0300 Артур Нек Дедлайн — это четко установленный срок выполнения задачи. Благодаря дедлайнам все знают к какому сроку...

Что такое дедлайны и как ими управлять

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

Какие дедлайны бывают

Дедлайны делят по срочности, принципу постановки и постановщику.

Виды дедлайнов по срочности

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

Виды дедлайнов по принципу постановки

Здесь выделяют еще 2 вида: поэтапные и повторяющиеся.
Поэтапный дедлайн — когда большой проект разбивают на несколько маленьких частей-этапов. Для каждого этапа ставят свой промежуточный срок сдачи. Так проще контролировать процесс, видеть прогресс и вовремя замечать, если что-то идет не так.
Пример поэтапных дедлайнов — запуск корпоративного блога. Чтобы уложиться в срок, нужно разбить подготовку на этапы:
  • за Х недель определить концепцию, рубрики и целевую аудиторию блога;
  • за Y недель найти авторов, заказать дизайн и верстку;
  • за Z недель подготовить первые 10 статей, отредактировать и оформить их;
  • протестировать блог, настроить метрики и формы подписки.
Повторяющийся дедлайн — когда для разных работ ставится единый срок, за который они должны быть выполнены.
Пример — разработчик пишет код для нового функционала приложения, а дизайнер рисует для него иконки и экраны. И оба должны сдать работу одновременно.
А еще дедлайны делят на внутренние и внешние. Внутренние — это те, что устанавливаются внутри компании. Внешние — те, что исходят от заказчика.
Параметр Внутренние дедлайны Внешние дедлайны
Кто устанавливает Руководитель проекта, команда Заказчик, клиент, регуляторы
Влияние на репутацию Внутри компании На рынке, среди клиентов
Последствия срыва Выговор, лишение бонусов Штрафы, пени, потеря контрактов
Приоритетность Средняя, можно сдвигать Высокая, нельзя нарушать
Гибкость сроков Высокая, можно менять Низкая, зафиксированы в договорах
Фокус контроля Больше на качестве Больше на сроках

Зачем нужны дедлайны

Глобально, ответ простой, — чтобы понимать, какую задачу, зачем, для кого и к какому сроку решаем. Но еще дедлайны приносят много косвенной пользы.
Сотрудники могут эффективно планировать работу и расставлять приоритеты. Когда у задачи есть четкий срок, люди понимают что нужно сделать в первую очередь. Они фокусируются на важном, а не на срочном. И это не мы придумали, а американский психолог доктор Эдвин Локк. Он доказал, что конкретные и измеримые цели повышают производительность.
А если работать без дедлайнов, большая часть дня будет уходить на срочные дела вроде ответа по электронной почте. На важные дела не будет хватать времени и сил.
Есть метод — «съесть лягушку». Где «лягушка» — большая, сложная или неприятная задача. А «съесть лягушку» — это взяться за эту задачу с утра.
Дедлайны мотивируют и дисциплинируют, не дают откладывать дела на потом. Когда не знаешь сроков, кажется, что времени еще много и задача решится сама собой. А потом наступает 3 часа ночи и осознание, что проект нужно передать уже в 9 утра.
Но когда есть дедлайны и когда за ними следят — работают продуктивнее. Особенно, когда работы много, но она равномерно распределена в течение дня. Это доказывает эффект Зейгарник — склонность лучше запоминать незакрытые дела и стремиться их выполнить. Чем больше маленьких дедлайнов, тем больше намерение справиться с ними.
С дедлайнами проще отслеживать прогресс проекта. Когда сотрудники видят сколько задач уже выполнено и сколько осталось, понимают реальное положение дел. Они могут отдохнуть и все равно успеть в срок, а могут приложить больше усилий, чтобы завершить все вовремя.
Дедлайны улучшают отношения с клиентами. К компании, которая не срывает сроки, отношение всегда лучше. Например, если маркетологи запускают рекламную кампанию в намеченный срок и успевают привлечь клиентов к сезону распродаж. Либо производство выпускает продукцию по графику и магазины вовремя получают товар. И еще много других факторов помогают в одном: повышают лояльность клиентов и партнеров.

Как правильно устанавливать дедлайны

Чтобы дедлайны работали, нужно соблюдать несколько принципов:

Оценивать сложность задачи и продумывать основные этапы

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

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

Нельзя требовать от команды невозможного и сжимать сроки до предела. Слишком жесткие сроки могут демотивировать команду и привести к выгоранию. А слишком мягкие — расслабить и снизить продуктивность.
Чтобы определиться со временем, лучше спросить сотрудников, сколько времени им нужно на выполнение проекта. Можно опираться на прошлые проекты, использовать специальные методики оценки вроде PERT или привлечь экспертов.
Когда определитесь со сроками, согласуйте их с командой. Обязательно нужно учесть их замечания и скорректировать план. Иначе сотрудники быстро выгорят от большого количества работы, потеряют интерес к проекту. Будут саботировать план или искать отговорки, чтобы не работать.
Совет. Если никак не получается соблюсти сроки, возможно, в компании проблемы:
  1. Процессы работают неэффективно. Например, одну и ту же задачу согласовывают несколько человек. Либо общение по одной и той же задаче идет в разных каналах — кто-то точно потеряет сообщение. Чтобы решить проблему, процессы нужно пересмотреть самостоятельно или нанять проджект-менеджера, сходить на экспертную консультацию.
  2. От одной задачи зависит бизнес. Например, пока корректор не вычитает статью, ее не опубликуют на сайте. На такой случай должен быть запас статей, чтобы выход материалов не останавливался.
  3. Не хватает сотрудников. И выполнять задачу просто некому. Это значит, что пора расширять команду. Либо перераспределять ресурсы.

Распределять ресурсы

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

Добавлять буферы

Буферы — дополнительное время на непредвиденные обстоятельства. Обычно это 20-30% от основной оценки.
Например, если по расчетам проект займет 100 дней, добавьте еще 20-30 дней про запас. Они могут не понадобиться, но лучше перестраховаться.
Важно! Буфер должен быть один. А выставляет его ответственный по проекту. Если каждый сотрудник будет сам назначать себе буфер, работа над дизайном даже одной кнопки растянется в несколько раз.
Все потому, что люди склонны откладывать дела на потом и, как следствие, работать дальше в режиме срочности. А иногда — опаздывать по срокам.

Учитывать возможные риски и препятствия

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

Дробить задачу на подзадачи со своими дедлайнами

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

Определять редлайн

Редлайн — это контрольная точка перед наступлением дедлайна. Обычно редлайн устанавливают за несколько дней до наступления дедлайна. Это что-то вроде репетиции сдачи проекта, которая помогает выявить и исправить ошибки до финального отчета.
Иногда руководители проектов озвучивают редлайн как окончательный срок. Это мотивирует команду работать быстрее и сдать проект раньше реального срока. Но, с другой стороны, времени на подготовку может оказаться очень мало и это скажется на качестве, а также на состоянии сотрудников.
Обычно такой способ применяют к командам, которые периодически не успевают по срокам.
Работать будет проще, если использовать метод Помодорро: заводите таймер на 25 минут, приступаете к работе. Когда время заканчивается, отдыхаете 5 минут. И так несколько раз подряд

Определять критерии готовности проекта

Пропишите, что именно должно быть сделано к дедлайну. В каком виде сдаются результаты, как проверяется качество. Какие метрики и показатели нужно достичь.
Например:
  • Код полностью протестирован и не выдает ошибок.
  • Дизайн утвержден заказчиком и соответствует брендбуку.
  • Сайт грузится за 1 секунду, проходит аудит по чек-листу.

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

Чтобы все понимали, ради чего нужно укладываться в сроки и к чему приведет промедление. К примеру, если вовремя не сдать отчет в налоговую, компании выпишут штраф и заблокируют счета (даже те, с которых сотрудникам платят зарплату).
Когда все будет готово, перенесите дедлайны в вашу систему управления проектами или таск-трекер (Jira, Asana, Битрикс).
Поставьте уведомления и напоминалки. Сделайте так, чтобы дедлайны были всегда на виду и контролировались автоматически.

Как ставить дедлайны для задач, с которыми раньше не работали

Выше мы разобрали идеальный пример: когда задача понятна и с ней работали раньше. Теперь разберемся, как определиться с дедлайнами для задачи, которую раньше не решали.
Разбейте большую задачу на более мелкие и понятные части. Постарайтесь разбить задачу так, чтобы отдельные части были знакомы вам и команде.
Например, команде поручили разработать мобильное приложение для доставки еды, хотя она специализируется на разработке интернет-магазинов.
Если разбить умения команды на части, выяснится, что она может делать каталоги товаров и корзину покупок. Раньше команда часто делала личные кабинеты пользователей, добавляла на сайты отслеживание геолокации и интегрировала платежные системы.
Программисты писали серверную часть и знают как наладить обмен с базой данных. А дизайнеры верстали адаптивную мобильную версию.
В итоге большая и непонятная задача превращается в несколько маленьких, браться за которые не страшно — раньше их уже решали.
Воспользуйтесь методом экспертной оценки. Соберите команду опытных специалистов и попросите их независимо друг от друга оценить время на задачу. Возьмите среднее от их оценок за основу. Либо максимальную оценку, чтобы подстраховаться.
Главное — найти надежных экспертов
Заложите в дедлайн двойной буфер на непредвиденные сложности. Если в типовых проектах вы закладываете 20-30% резерва, то здесь стоит дать все 40-60%. Чтобы ни одна проблема точно не помешала сдать проект в срок.
Постарайтесь выделить в проекте базовый минимум, без которого он теряет смысл. И опционные «хотелки», без которых можно обойтись. Для базового минимума поставьте отдельный дедлайн. А дополнительные фичи вынесите в следующие итерации. Так вы снизите риск превратить проект в долгострой.
Допустим, компания делает сайт для онлайн-школы иностранных языков. Базовый минимум тут — каталог курсов с описанием и ценами, форма записи и оплаты, личный кабинет ученика. Без этих функций сайт не сможет принимать платежи и обслуживать клиентов.
А вот интерактивное расписание занятий, онлайн-тесты для проверки уровня, блог с советами по изучению языка — это все «хотелки». Их можно вынести в следующие итерации и запустить через время после релиза.

Вместо заключения: советы по соблюдению дедлайнов

Чтобы дедлайны реально работали, нужно всегда держать их в фокусе внимания. Недостаточно один раз поставить сроки и забыть про них до дня Х. Нужно постоянно сверяться с планом, отслеживать прогресс, предупреждать возможные риски. Оптимально делать это в привязке к коротким итерациям, как в Scrum. Или на ежедневных митингах, как в Kanban.
Всегда стоит применять декомпозицию — разбивать большую задачу на более мелкие подзадачи. И ставить для них дедлайны.
При первых признаках того, что дедлайн может быть сорван — информировать команду и заинтересованные стороны. Не нужно замалчивать проблему или надеяться, что сотрудники решат поработать бесплатно и без выходных. Лучше упростить задачу или перераспределить ресурсы и справиться вовремя, чем подвести заказчика.
Важно анализировать причины случившихся и потенциальных срывов дедлайнов. Искать нужно непосредственные причины, а не поверхностные — Вася смотрит рилсы не потому, что лентяй. А потому, что делать нечего (может, чуть-чуть и лентяй).
Если вам нужно обучить проджект-менеджера для процессов компании — обратитесь в Neogenda. Мы являемся экспертами по современным подходам и методам менеджмента. За нами более 100 успешных управленческих кейсов и 5 000 обученных сотрудников в таких компаниях, как Яндекс, Авито, Сбер, Билайн, Skyeng и так далее. Оставьте заявку на бесплатную консультацию в Zoom – мы предложим лучшее решение для вашей задачи.
]]> Что такое дерево целей проекта и как его составить http://neogenda.ru/blog/rxo2llpmf1-chto-takoe-derevo-tselei-proekta-i-kak-e http://neogenda.ru/blog/rxo2llpmf1-chto-takoe-derevo-tselei-proekta-i-kak-e?amp=true Fri, 29 Nov 2024 06:52:00 +0300 Андрей Сидоренко Чтобы запустить новую услугу, расширить компанию или нарастить прибыль, нужно все распланировать. Поставить цель, определиться...

Что такое дерево целей проекта и как его составить

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

Что такое дерево целей

Дерево целей — это схема, которая показывает все цели компании или проекта и то, как их достичь. Сверху схемы стоит главная цель, а от нее отходят подцели и конкретные задачи по достижению этих подцелей.
Схема называется деревом, потому что главная цель — это ствол, от которого отходят ветви — подцели первого уровня. От ветвей отходят ветви поменьше — это подцели второго уровня. Так главная цель дробится, пока не дойдет до листьев — конкретных и мелких задач по достижению главной цели.
Примерно такие деревья целей делают в разных компаниях
Такая структура позволяет увидеть всю систему целей в одном месте, понять их взаимосвязь и последовательность достижения. Дерево целей делает большую и сложную цель более понятной и достижимой.
Допустим, руководитель компании хочет организовать большую конференцию. Конференция — это ствол. От него отходят крупные ветви — подцели. Например,«привлечь спонсоров», «собрать 1000 участников», «подобрать интересных спикеров».
От этих веток отходят более мелкие. Например, для ветки «привлечь спонсоров» это будет «составить список потенциальных спонсоров» или «разработать спонсорские пакеты». Еще более мелкие веточки — конкретные шаги. В случае со спонсорами — «найти контакты спонсоров», «назначить встречи» и «подготовить презентацию».
Такое дерево целей получилось в компании
В компаниях обычно есть цели трех уровней. Стратегические — самые главные, долгосрочные. Отвечают на вопрос «куда идем».
Например, стать лидером рынка. Тактические — те, что нужны для достижения стратегической цели. Отвечают на вопрос «каким образом идем». В примере с лидером рынка стратегическая цель — выйти на новые рынки сбыта. И операционные — конкретные действия. Отвечают на вопрос «что делаем». Например, провести рекламную кампанию.
Все три уровня целей видны в дереве. Главная цель — это ствол. Тактические — крупные ветки. А операционные — мелкие веточки. Причем каждый отдел компании видит только свои ветви.
Допустим, цель компании — увеличить прибыль на 20%. Для этого отдел маркетинга должен привлекать новых клиентов. Его тактические цели — запустить рекламу и обновить сайт. А операционные — составить план кампании, найти подрядчиков, подготовить контент.
Производственный отдел отвечает за другую часть дерева. Его цель — снизить себестоимость продукции. Для этого нужно выполнить тактические цели: оптимизировать процессы и найти новых поставщиков. И операционные: провести аудит, составить новые договоры, обучить персонал.

Чем цели отличаются от задач

Цель — это результат, который вы хотите получить. А задача — конкретное действие, которое нужно выполнить, чтобы приблизиться к цели.
Пример цели: увеличить выручку компании на 20% за год. Задачи для этого: провести рекламную кампанию, обучить менеджеров по продажам, выпустить новый продукт, выйти на новые рынки.
Критерий сравнения Цель Задача
Масштаб Более широкий, общий результат Конкретное действие или набор действий
Временные рамки Может быть как измеримой, так и качественной Краткосрочная перспектива, четкие сроки
Измеримость Может быть как измеримой, так и качественной Всегда конкретна и измерима
Структура Может включать множество задач Является частью достижения цели
Формулировка Отвечает на вопрос «Чего мы хотим достичь?» Отвечает на вопрос «Что конкретно нужно сделать?»
Результат Описывает желаемое состояние Описывает конкретное действие
Гибкость Более гибкая, пути достижения могут меняться Менее гибкая, конкретный способ выполнения

Зачем использовать дерево целей

Чтобы определить и структурировать цели компании или проекта. Работает все просто: вы берете главную цель и разбиваете ее на подцели и конкретные задачи. В результате видите, что нужно делать, чтобы достичь желаемого результата.
Чтобы расставить приоритеты. Вы будете видеть, какие цели важнее и срочнее. И понимать, как они связаны между собой.
Чтобы планировать и распределять ресурсы. Под каждую цель и задачу вы определяете, что нужно: деньги, время, люди, оборудование. И устанавливаете реалистичные сроки.
Чтобы улучшить коммуникацию в команде. Все будут видеть общую картину и понимать, куда двигается компания. Каждый будет знать свою роль и то, как его работа влияет на результат.
Чтобы отслеживать прогресс. Дерево целей позволяет регулярно сверяться с планом и смотреть, все ли идет по графику. И, если нужно, вносить коррективы.

Принципы работы с деревом целей

Начинайте с главной цели

Она будет стволом дерева. Цель должна быть понятной и измеримой. Поэтому ее лучше формулировать по методике SMART. Это значит, что цель должна быть:
  • Конкретной (Specific). Например, не просто «увеличить продажи», а «увеличить продажи продукта А на 30% в регионе Б за 3 квартал».
  • Измеримой (Measurable). Должны быть четкие критерии, по которым вы поймете, достигли цели или нет. В нашем примере это 30% и 3 квартал.
  • Достижимой (Achievable). Цель должна быть реалистичной, учитывать ваши ресурсы и ограничения. Например, маленькой региональной фирме не стоит ставить цель обогнать Apple по прибыли.
  • Значимой (Relevant). Цель должна быть важна для бизнеса и соответствовать общей стратегии. Иначе зачем ее вообще достигать?
  • Ограниченной по времени (Time-bound). Есть золотое правило — задача без дедлайна не будет выполнена никогда. Поэтому обязательно ставьте временные рамки. В нашем примере это 3 квартал.
Чтобы достигать цели было проще, их стоит ставить по методологии SMART
Подробнее о постановке целей по SMART читайте в этой статье.
Кроме SMART, для постановки целей можно использовать фреймворк OKR (Objectives and Key Results). Его суть в том, что для каждой цели (Objective) вы определяете ключевые результаты (Key Results) — измеримые показатели, которые покажут, насколько цель достигнута.
Например, цель «Увеличить продажи продукта А» может иметь такие ключевые результаты:
  • Достичь выручки X млн рублей.
  • Привлечь Y новых клиентов.
  • Увеличить средний чек на Z%.
Главное отличие OKR от SMART — в фокусе результат, а не процесс. Вы концентрируетесь не на том, что нужно сделать, а на том, что нужно получить в итоге.

Выделяйте главные подцели

Главные подцели — это самые крупные ветви дерева. Их тоже стоит ставить по методике SMART или OKR.
Совет. Для одной цели ставьте несколько способов достижения. То есть, каждую большую подцель разбивайте минимум на 2-3 подцели или задачи поменьше.
Допустим, ваша цель — увеличить продажи на 30% за квартал. Этого можно добиться разными способами:
  • Запустить рекламную кампанию и привлечь новых клиентов.
  • Расширить ассортимент и предложить клиентам новые продукты.
  • Обучить продавцов техникам продаж, чтобы они эффективнее работали с клиентами.
  • Улучшить качество продукта, чтобы клиенты чаще возвращались и рекомендовали вас друзьям.
  • Ввести программу лояльности, чтобы стимулировать повторные покупки.
Каждый из этих вариантов — отдельная подцель. Они все ведут к одному результату: увеличить продажи на 30%.
Каждую подцель можно разбить еще на несколько задач. Например, для подцели «Запустить рекламную кампанию» задачи могут быть такими:
  • Определить целевую аудиторию и каналы продвижения.
  • Разработать концепцию рекламной кампании и подготовить материалы.
  • Выделить бюджет на рекламу и найти подрядчиков.
  • Запустить кампанию и отслеживать результаты.
Если что-то пойдет не так с одним вариантом (например, не сработает реклама), у вас будут другие пути (расширить ассортимент, обучить продавцов и т. д.). Это повысит вероятность того, что цель будет достигнута.

При постановке подцелей и задач применяйте декомпозицию

Декомпозиция — это разделение целого на части. В менеджменте под ней подразумевается разбиение сложной цели на простые, которые удобнее оценить и выполнить. Декомпозиция нужна, чтобы сделать путь к цели более понятным и управляемым.
Представьте, что ваша цель — пробежать марафон. Звучит сложно и невыполнимо. Но если разбить ее на задачи, становится проще:
  • Купить кроссовки и спортивную одежду.
  • Составить план тренировок.
  • Бегать 3 раза в неделю, постепенно увеличивая дистанцию.
  • Правильно питаться.
  • Пройти медобследование перед марафоном.
  • Зарегистрироваться на забег.
То же самое работает и в бизнесе. Берете большую цель → дробите ее на несколько маленьких задач → выполняете каждую → радуетесь.

Приоритезируйте подзадачи

Выбирайте, какие задачи нужно решать в первую очередь, а какие могут подождать. Приоритезировать задачи можно разными методами.
Первый — метод Эйзенхауэра. Он предлагает делить все задачи на 4 группы: важные и срочные, важные но не срочные, не важные, но срочные, не важные и не срочные.
В первую очередь нужно делать задачи из первой группы. Они больше всего влияют на достижение цели. Затем — важные, но не срочные. Это стратегические задачи, которые принесут пользу в долгосрочной перспективе. Не важные, но срочные можно делегировать или выполнять в последнюю очередь. А не важные и не срочные — смело вычеркивать из списка.
Второй метод — расстановка приоритетов по RICE. Метод оценивает каждую задачу по четырем параметрам:
  • Reach — скольких пользователей или клиентов затронет результат задачи.
  • Impact — насколько сильно результат повлияет на целевой показатель.
  • Confidence — насколько вы уверены в своих оценках Reach и Impact.
  • Effort — сколько времени и ресурсов потребует выполнение задачи.
Заполненная матрица RACI будет выглядеть примерно так
Чем выше Reach, Impact и Confidence и чем ниже Effort, тем выше приоритет задачи. Для каждого параметра ставится оценка, например, от 1 до 5. Затем оценки перемножаются по формуле (Reach x Impact x Confidence) / Effort. Задачи с наибольшим результатом — самые приоритетные.
Третий метод — MoSCoW. Он делит задачи на 4 категории:
  • Must have (должно быть сделано) — критически важные вещи, без которых проект или продукт не имеет смысла. Они должны быть реализованы в первую очередь и в полном объеме.
  • Should have (следует сделать) — важные требования, которые не являются критичными. Их желательно реализовать, но при недостатке времени или ресурсов ими можно пожертвовать.
  • Could have (можно сделать) — требования, которые желательны, но необязательны. Они реализуются, только если останется время после Must и Should.
  • Won’t have (не будет сделано) — наименее приоритетные требования, которые не вписываются в рамки текущего проекта или релиза. Они откладываются на будущее или отбрасываются совсем.
Принцип метода — сначала делать Must, потом Should, потом Could. И не брать в работу Won’t. Это позволяет сосредоточиться на самом важном и не тратить время на второстепенные или неуместные задачи.
Распределяйте задачи по квадратам, чтобы определить их важность было проще
Четвертый метод — WSJF (Weighted Shortest Job First). Он учитывает два фактора:
  • Стоимость задержки (Cost of Delay) — сколько мы потеряем, если не выполним задачу прямо сейчас. Здесь учитываются потенциальный доход, риски, затраты на задержку и т. д.
  • Длительность (Job Duration) — сколько времени потребуется на выполнение задачи.
Приоритет по WSJF рассчитывается как Cost of Delay / Job Duration. Чем выше Cost of Delay и чем ниже Job Duration, тем выше приоритет задачи. То есть, в первую очередь делаем то, что принесет наибольшую выгоду за наименьшее время.
Можно применять и другие методы. Например, метод взвешенной оценки, в котором оценивают несколько альтернатив и выбирают самую лучшую из всех. Либо правило Парето, которое гласит: 20% усилий принесут 80% результата.

Проверяйте логику и взаимосвязь

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

Какие сервисы помогут построить дерево целей

Интеллект-карты. Они делают план в виде иерархической структуры. Вы можете быстро вносить изменения и дополнения. Сделать интеллект карты можно на платформе Xmind, MindManager или в Figma. Сервисы поддерживают совместную работу в команде.
Если нужно включить в дерево целей большой объем информации, его лучше сделать в таблицах.
Для управления задачами на этапе реализации плана хорошо подходят Канбан-доски. В них удобно отслеживать статус задач и видеть, кто чем занимается и на каком этапе находится проект. Канбан-доски можно сделать в Yandex Tracker, Битрикс24 и др.

Преимущества дерева целей

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

Недостатки дерева целей

Цели и задачи часто меняются. Появляются новые идеи, возникают непредвиденные обстоятельства. Чтобы дерево не потеряло смысл, его нужно регулярно обновлять. Добавлять новые ветки, убирать неактуальные, менять приоритеты.
Сложно поддерживать дерево в больших проектах. Когда целей и задач много, за всеми уследить непросто. Нужен человек, который будет отвечать за актуальность дерева. Иначе все быстро запутается и превратится в неработающую схему.
Субъективность. Ведь дерево составляют люди. А у каждого свое видение и свои приоритеты. Кто-то может ошибиться при определении главной цели. Либо неправильно оценить важность конкретных задач.

Что в итоге

Дерево целей — схема, которая показывает все цели компании или проекта и путь к их достижению. Главная цель — ствол, от которого отходят подцели первого уровня, затем второго и так далее до конкретных задач.
Дерево целей помогает увидеть всю систему целей, их взаимосвязь и последовательность.
Цели и задачи должны быть конкретными, измеримыми, достижимыми, значимыми и ограниченными по времени. Для постановки целей можно использовать SMART или OKR.
Главные подцели — самые крупные ветви дерева, их также следует ставить по SMART или OKR.
Все задачи нужно приоритезировать. В этом помогут методы Эйзенхауэра, MoSCoW, RICE, WSJF, выбор альтернатив или правило Парето.
Дерево целей помогает сформулировать цели правильно, упорядочить мысли и идеи. Не упустить важные детали, облегчить коммуникацию с командой и расставить приоритеты.
Чтобы составить дерево целей было проще — вот краткий чек-лист:
  1. Сформулируйте главную цель — четко, конкретно, измеримо. Она должна быть понятна каждому в команде и не вызывать вопросов. Например, «Увеличить выручку на 20% за год» вместо «Улучшить финансовые показатели».
  2. Разбейте главную цель на 2-5 подцелей первого уровня. Проверьте, чтобы они были сбалансированы и охватывали разные аспекты. Подцели должны быть необходимы и достаточны для достижения главной цели. Для каждой цели и подцели определите измеримые критерии успеха.
  3. Каждую подцель первого уровня разбейте на 2-5 подцелей второго уровня или задач. Они должны быть более конкретными и отвечать на вопрос «Что нужно сделать, чтобы достичь цели уровнем выше?». Если подцель слишком объемная и размытая — дробите дальше.
  4. Продолжайте разбивать цели на подцели, пока не дойдете до уровня конкретных действий, которые можно ставить исполнителям. Это должны быть простые задачи, понятные каждому, с четкими сроками и критериями выполнения.
  5. Убедитесь, что дерево логично, связно и ведет к достижению главной цели.
  6. Расставьте приоритеты. Ориентируйтесь на важность и срочность задач. То, что сильнее всего влияет на достижение главной цели и имеет ближайшие сроки — в первую очередь.
  7. Поделитесь деревом целей с командой, убедитесь, что всем все понятно. Каждый должен знать, какие цели стоят перед компанией и какой вклад он может внести.
И самое-самое последнее. Если вашему бизнесу нужно внедрение дерева целей, обратитесь за бесплатной консультацией в Neogenda. Мы предоставляем разные услуги: от обучения ваших сотрудников лучшим управленческим практикам до полной реорганизации процессов вашего бизнеса.
]]> PEST-анализ: ключ к стратегическому развитию бизнеса http://neogenda.ru/blog/b6k3efa071-pest-analiz-klyuch-k-strategicheskomu-ra http://neogenda.ru/blog/b6k3efa071-pest-analiz-klyuch-k-strategicheskomu-ra?amp=true Tue, 03 Dec 2024 07:08:00 +0300 Андрей Сидоренко Узнайте, как своевременно подстраиваться под динамичность внешней среды, чтобы дело развивалось, а компания не терялась...

PEST-анализ: ключ к стратегическому развитию бизнеса

Узнайте, как своевременно подстраиваться под динамичность внешней среды, чтобы дело развивалось, а компания не терялась на фоне конкурентов. На бизнес всегда влияет много всего: и законодательные требования, и социум, и технологические тренды. Анализ этих факторов дает возможность детально рассмотреть объемную картину рынка и разобраться как строить стратегию на долгий срок.
Расскажем что такое PEST-анализ, чем он полезен, какие факторы учитывает. Разберетесь в его основных аспектах, видах и сможете понять, как этот инструмент помогает обнаруживать риски и находить скрытые возможности для развития.
Если задумываетесь о том, чтобы внедрить проверенные управленческие практики и строить эффективные процессы, обратитесь за помощью к команде Neogenda. У нас за плечами сотня успешных кейсов, мы работали с лидерами рынка, такими как Tinkoff, Яндекс и Сбер. Специалисты Neogenda подберут индивидуальные решения для вашей компании. Запишитесь на бесплатную консультацию и узнайте как масштабировать бизнес.

Что такое PEST-анализ

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

Зачем используют PEST-анализ

PEST-анализ предприятия — это способ определить, какие конкретно внешние факторы среды могут давить на бизнес или действовать на него благоприятно. С ним компании не только заранее замечают возможные угрозы, но и вовремя начинают пользоваться возможностями. Пест-анализ помогает:
  • Замечать и оценивать риски, чтобы успеть подготовиться к изменениям, например, к новым требованиям от государства.
  • Находить перспективы роста, например, внедрять популярные технологии.
  • Понимать изменения в обществе и считаться с социальными трендами, от которых может зависеть спрос.
  • Оптимизировать стратегию, опираясь на реальные и предполагаемые условия внешней среды.
Как компании поможет PEST-анализ? Пример: допустим, владелец кафе замечает – в городе скоро откроется много других ресторанов и кафе и ужесточаются требования к санитарным нормам. Он хочет детально разобраться как эти изменения могут отразиться на его бизнесе.
Анализирует политические, экономические, социальные, технологические факторы и видит: усиление санитарных норм требует дополнительных расходов. В то же время становится ясно, что появился тренд на здоровое питание, значит можно изменить меню и привлечь новых посетителей. С помощью PEST-анализа владелец кафе получает полную картину внешней среды и осознает, что нужно подготовиться к предстоящим изменениям и продумать стратегию.

Какие у PEST-анализа плюсы и минусы

Ожидаемо, что PEST-анализ (Pest Analysis) имеет свои светлые и темные стороны. Их важно понимать, чтобы оптимально использовать этот метод.

Плюсы PEST-анализа

Систематический подход

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

Выявление угроз и точек роста

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

Улучшение стратегического планирования

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

Актуальность и универсальность

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

Углубленное понимание рынка

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

Минусы PEST-анализа

Субъективность

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

Необходимость периодического обновления

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

Неиспользование внутренних аспектов

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

Ограниченность глубины анализа

Хотя PEST-анализ подходит для общего обзора внешних факторов, он не позволяет глубоко проанализировать конкретные аспекты.
Пример. Поставщик программного обеспечения провел PEST-анализ и узнал, что технологии быстро развиваются. Однако, он не углубился в анализ конкурентов. Это помешало ему выявить, как именно конкуренты используют новейшие технологии.

Трудности в интерпретации

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

Какие факторы включает проведение PEST-анализа

Политические факторы (Political)

Охватывают законодательные и правительственные силы, которые могут значительно воздействовать на бизнес. Политические факторы PEST-анализа:
  • Законы и нормативно-правовой контроль. Поправки в налоговом законодательстве, трудовом праве или экологических нормах могут напрямую повлиять на операционную работу организации. Например, новые законы о минимальной заработной плате, вероятнее всего, увеличат расходы бизнеса.
  • Политическая стабильность. На территориях с нестабильной политической ситуацией компании могут столкнуться с потерей активов или ограничением доступа к ресурсам. Например, иностранные инвесторы могут избегать вложений в страны с высокой политической нестабильностью.
  • Государственная поддержка. Субсидии и гранты могут помочь определенным секторам, таким как зеленая энергетика или технологии. Если компания понимает эти аспекты, она может воспользоваться господдержкой.

Экономические факторы (Economic)

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

Социальные факторы (Social)

Рассматривают общественно-культурные трансформации, которые могут повлиять на поведение потребителей:
  • Изменения в образе жизни. Такой социально-культурный фактор, как растущий интерес к ЗОЖ, увеличивает спрос на экопродукты и фитнес-услуги.
  • Демографические перепады. Старение населения или увеличение доли молодежи в обществе влияют на предпочтения и потребности клиентов. Например, молодые люди смотрят в сторону современных гаджетов, в то время как пожилые люди более заинтересованы в медицинских услугах.
  • Социальные тренды. Такие тенденции, как экологическая ответственность или устойчивое развитие, ценятся в обществе все больше и часто становятся определяющими при выборе бренда.

Технологические факторы (Technological)

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

Какие бывают виды PEST-анализа

PEST-анализ — это гибкий инструмент, который можно адаптировать и расширять в зависимости от специфики бизнеса, цели исследования и изменяющихся условий на рынке. Существует несколько его модификаций:
1. SLEPT-анализ (Social, Legal, Economic, Political, Technological) — форма PEST-анализа с юридическими (Legal) факторами. Позволяет более детально оценивать как государственные инициативы могут влиять на предпринимательство.
2. PESTEL-анализ (Political, Economic, Social, Technological, Environmental, Legal) подразумевает дополнительные факторы: экологические (Environmental) и юридические (Legal). Учитывает как экоизменения и законодательство в этой сфере влияют на бизнес.
3. PESTELI-анализ (Political, Economic, Social, Technological, Environmental, Legal, Industrial) добавляет отраслевой фактор (Industrial) к предыдущему варианту. Особенно актуален для предпринимателей, которые работают в определенной сфере, где вскоре что-то может поменяться.
4. STEEPLE-анализ (Social, Technological, Economic, Environmental, Political, Legal, Ethical) — еще одна вариация PEST-анализа, но с этическими (Ethical) факторами. Помогает учитывать коммерческие интересы и свою социальную ответственность. Это важно в условиях сегодняшнего бизнеса.
5. PESTEELI-анализ (Political, Economic, Social, Technological, Environmental, Legal, Ethical, Industrial) — это расширенный вид PESTELI, включает все ранее упомянутые аспекты. Самый детализированный вариант, который позволяет учесть все влияния внешней среды. Особенно полезен для крупных компаний с разветвленной структурой и множеством направлений.
6. LONGPEST-анализ (Local, National, Global — Political, Economic, Social, Technological) представляет собой улучшенную версию классического PEST-анализа. При этом LONGPEST исследует факторы на трех уровнях: местном, национальном, глобальном. Актуально для компаний, которые стремятся попасть на международные рынки или укрепить свои позиции в разных регионах. Такой подход помогает учитывать локальные потребности и особенности, оценивать риски и точки роста на национальном уровне, прогнозировать глобальные тенденции.

Как делать PEST-анализ

Рассмотрим два основных способа провести PEST-анализ: простой и сложный. У каждого есть свои особенности.
Первый вариант
1. Соберите информацию. Начните с рассмотрения политических, экономических, социальных и технологических факторов, которые могут повлиять на ваш бизнес. Для этого изучите отчеты, новости, рыночные исследования и другие источники.
2. Сделайте таблицу. Чтобы восприятие собранной информации было проще, таблица PEST-анализа должна включать четыре колонки — для всех типов факторов: политические, экономические, социальные, технологические.
3. Заполните таблицу. В каждой колонке укажите основные аспекты, которые вы обнаружили до этого. Например, в колонке «Политические факторы» можно указать изменения в налоговом законодательстве или новые нормы, которые затрагивают вашу отрасль.
4. Проанализируйте результаты. Просмотрите таблицу и определите что важнее для вашего бизнеса. Не игнорируйте потенциальные угрозы и перспективы, которые могут возникнуть.
Это довольно быстрый и доступный способ. Подходит для небольших компаний и стартапов, которые хотят получить общее представление о внешней среде.
Второй вариант
1. Определите факторы. Начните с выявления ключевых политических, экономических, социальных, технологических факторов, которые затрагивают вашу организацию.
2. Оцените возможности. Для этого опирайтесь на следующие параметры, добавляйте по 1 баллу за каждый:
a. Complementary (Дополнительный) — насколько этот фактор способствует достижению целей компании;
b. Large (Значительный) — степень влияния фактора на успех фирмы;
c. Accessible (Доступный) — легкость использования в интересах бизнеса;
d. Lasting (Долговременный) — как долго аспект останется актуальным и полезным.
3. Оцените опасности. Для этого опирайтесь на другие параметры, вычитайте 1 балл за каждый:
a. Unmitigated (Абсолютный) — насколько фактор не поддается смягчению либо управлению;
b. Significant (Значительный) — уровень угрозы, которую фактор несет бизнесу;
c. Undefended (Незащищенный) — вероятность защиты от данного фактора, если она слабая или отсутствует;
d. Lasting (Долговременный) — как долго этот фактор будет угрожать компании.
5. Создайте итоговую таблицу. В ней укажите отдельные столбцы для перспектив роста и опасностей. Это поможет вам четко видеть, какие факторы требуют внимания и на какие следует ориентироваться в будущем.
Этот способ позволяет лучше понять, как внешние факторы влияют на бизнес. Позволяет снижать риски, внедрять возможности и на базе этого разрабатывать стратегии. Подходит для компаний, которые ведут дела в быстро меняющихся отраслях или с разными странами.

Что в итоге

PEST-анализ — полезный инструмент для оценки внешних факторов, которые могут влиять на бизнес. Помогает компаниям подстраиваться под нестабильные условия рынка.
Однако, чтобы использовать новые данные максимально эффективно и оптимизировать бизнес-процессы, предпринимателям нужны современные управленческие практики. Внедрить их поможет Neogenda. Сделайте первый шаг к успешному будущему вашего бизнеса — оставьте заявку на бесплатную консультацию, и наши практики подскажут подходящее направление для вашей компании.
]]> Объяснение процесса пополнения в Канбане http://neogenda.ru/blog/14r8z93fd1-obyasnenie-protsessa-popolneniya-v-kanba http://neogenda.ru/blog/14r8z93fd1-obyasnenie-protsessa-popolneniya-v-kanba?amp=true Thu, 05 Dec 2024 07:31:00 +0300 Мария Савельева Взятие обязательства по новой задаче в Канбане называется пополнением.

Объяснение процесса пополнения в Канбане

Взятие обязательства по новой задаче в Канбане называется пополнением.
Традиционно в управлении проектами решение об очередности задач принимает руководитель. Этот подход основан на тактике «пушинга» (проталкивания), когда новые задачи добавляются в работу без анализа текущей загрузки и задач в процессе. Такой подход часто приводит к перегрузке команды и неравномерности в рабочем процессе.
В Канбане всё устроено иначе. Чтобы решить, какую задачу взять в работу следующей, используется процесс пополнения.

Что такое пополнение Канбана?

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

Создание Точки принятия обязательств

Прежде чем задача попадёт в работу, команда должна быть уверена в ее ценности для клиента и возможностях успешного выполнения. Точка принятия обязательств — это этап, на котором задача переходит из статуса необязательной к обязательной. Обычно это происходит на встрече по пополнению (подробнее о ней ниже) и визуализируется на Канбан-доске.
Точка принятия обязательств обычно отмечается линией между колонками на доске, например, между «Бэклог» и «Сделать»/«Готово к запуску»/«Выбрано». После её пересечения команда берётся за выполнение задачи.

Upstream и Downstream-процессы

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

Рекомендации для эффективного пополнения

Установите WIP-лимиты

WIP-лимиты (Work In Progress) ограничивают количество задач, выполняемых одновременно. Это предотвращает перегрузку Downstream-процесса и повышает стабильность системы.

Установите минимальный лимит пополнения

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

Встреча по пополнению

Встреча по пополнению — одна из 7 Канбан-каденций, направленных на улучшение рабочего процесса. Её цель — определить, какие задачи команда возьмёт в работу.

Организация встреч по пополнению

1. Когда проводить?
Частота зависит от объёма задач и скорости их выполнения. Если приоритеты задач часто меняются, встречи стоит проводить чаще.
Нужно определиться, как часто брать новую работу: еженедельно, раз в две недели или раз в месяц. Это зависит от характера рабочего процесса, объема задач и скорости выполнения. Лучше выбирать небольшие объемы, чтобы повысить производительность команды и быстрее выводить ценность на рынок.
2. Что обсуждать?
  • Доступные задачи, их приоритеты, дедлайны и риски.
  • Потенциальные развилки и зависимости.
3. Кто участвует?
Вначале — только команда.
Но по мере того, как ваша организация будет приобретать опыт в Канбане, вы можете приглашать на встречи других заинтересованных лиц или даже клиентов, над проектом которых вы работаете. Это позволит вам обеспечить более высокий уровень прозрачности рабочего процесса и покажет клиенту выгоду, которую он может получить.

Цели встречи

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

Итог

Для эффективного процесса пополнения в Канбане необходимо:
  1. Установить Точку принятия обязательств.
  2. Организовать регулярные встречи по пополнению.
На встречах команда должна:
  • Определять приоритет задач.
  • Учитывать риски и зависимости.
  • Оставлять время для доработки задач.
  • Убедиться в готовности к выполнению.
Эти шаги помогут стабилизировать процесс и увеличить продуктивность команды.
]]> Диаграмма Ганта для планирования проекта: как создать план проекта с помощью диаграммы Ганта http://neogenda.ru/blog/522jboyv01-diagramma-ganta-dlya-planirovaniya-proek http://neogenda.ru/blog/522jboyv01-diagramma-ganta-dlya-planirovaniya-proek?amp=true Tue, 10 Dec 2024 07:35:00 +0300 Артур Нек Начните использовать диаграмму Ганта в своих проектах уже сегодня!

Диаграмма Ганта для планирования проекта: как создать план проекта с помощью диаграммы Ганта

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

Что такое диаграмма Ганта

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

Основные элементы диаграммы Ганта

1. Ось времени: горизонтальная линия, делящаяся на временные интервалы (дни, недели, месяцы).
2. Список задач: вертикальная колонка слева, где перечислены все задачи проекта.
3. Полосы задач: горизонтальные полосы, показывающие продолжительность каждой задачи.
Пример диаграммы Ганта
1. Ось времени:
— Неделя 1
— Неделя 2
— Неделя 3
— Неделя 4
2. Задачи:
— Задача 1: Исследование (1 неделя)
— Задача 2: Разработка (2 недели)
— Задача 3: Тестирование (1 неделя)
— Задача 4: Внедрение (1 неделя)
3. Визуализация:

Подготовка к созданию диаграммы Ганта

Определение целей проекта

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

Идентификация задач

Разделите проект на конкретные задачи. Это можно сделать с помощью мозгового штурма или анализа предыдущих проектов.
Способы разбивки проекта на задачи:
  • декомпозиция: деление крупных задач на более мелкие;
  • использование шаблонов для типовых проектов.

Оценка времени выполнения задач

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

Учет ресурсов и ограничений

Убедитесь, что вы учитываете доступные ресурсы (люди, оборудование) и возможные ограничения (бюджет, сроки).
Установление зависимостей между задачами
Зависимости между задачами показывают как одна задача влияет на другую, помогают определить последовательность выполнения задач и избежать задержек.
Примеры зависимостей:
  • параллельные задачи: задачи, которые могут выполняться одновременно;
  • последовательные задачи: задачи, которые должны выполняться одна за другой;
  • start-to-start: задачи, которые нельзя начать, пока не начнется предыдущая задача;
  • finish-to-finish: задачи, которые нельзя закончить, пока не закончится другая задача;
  • finish-to-start: задачи, которые нельзя начать, пока не закончится предыдущая задача.

Как создать диаграмму Ганта

1. Выберите инструмент: вы можете использовать Excel, Google Sheets или специализированные программы для управления проектами, такие как Microsoft Project, Trello или Asana.
2. Создайте таблицу: введите список задач и соответствующие даты начала и окончания.
3. Добавьте график: используйте условное форматирование или встроенные функции для визуализации продолжительности задач.

Как построить диаграмму Ганта в Excel

Есть 2 способа сделать диаграмму Ганта в Excel.

Скачать готовый шаблон

Создайте новый документ и в строке «поиск шаблонов в сети» напишите «Гант»
После чего выберите удобный для себя вариант шаблона
Вставьте в шаблон свои фактические параметры, после чего Excel сделает диаграмму сам

Сделать диаграмму Ганта в Excel самостоятельно

Построить диаграмму Ганта в Excel можно следующим образом:

1. Подготовьте данные

Для построения проектной диаграммы потребуется таблица с исходными данными.
Например, вот такая
Задержка может быть положительной, когда есть пауза между этапами. И отрицательной, когда новый этап начинается до окончания предыдущего.
Формула расчета даты окончания этапа
+1 в формуле, если в ячейке «Задержка» стоит «0». В остальных случаях к единице прибавляем стоящую там цифру.

2. Создайте диаграмму

Выделите данные (включая заголовки) и перейдите на вкладку «Вставка»
Выберите линейчатую диаграмму с накоплением
Получившиеся горизонтальные столбцы справа от таблицы

3. Настройте диаграмму

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

4. Настройте оси

Теперь, для более удобного восприятия, инвертируем вертикальную ось, чтобы этапы шли сверху вниз.
Кликаем правой кнопкой мыши по окну оси и выбираем «формат оси»
В открывшемся окне ставим галочку «обратный порядок категорий»
Теперь вид у диаграммы такой
Осталось настроить горизонтальную ось. Проделываем с ней то же самое.
В группе «Параметры оси» вводим дату начала первого этапа, чтобы убрать пробел в начале диаграммы
Заполняем необходимые в вашем случае значения «цена основных делений» (у меня 7 дней) и «цена промежуточных делений» (у меня 1 день). Если ваш проект на год или два, основные и промежуточные деления можно делать покрупнее.
Здесь же, в группе «выравнивание», можно задать направление текста, а в группе «число» – выбрать формат даты.
Диаграмма Ганта готова
Можно изменить цвета, добавить заголовок и любые другие элементы дизайна по вашему вкусу.

Мониторинг и обновление диаграммы Ганта

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

Примеры использования диаграммы Ганта

Диаграмма Ганта может быть использована в различных областях и для разных типов проектов. Вот несколько примеров:
1. Строительство:
  • планирование этапов строительства здания, включая проектирование, получение разрешений, строительство фундамента, возведение стен и отделку.
2. Разработка программного обеспечения:
  • установление сроков для этапов разработки, тестирования и внедрения нового программного продукта, а также для исправления ошибок.
3. Маркетинговые кампании:
  • планирование различных этапов маркетинговой кампании, таких как исследование рынка, разработка контента, запуск рекламы и анализ результатов.
4. Организация мероприятий:
  • управление задачами при подготовке конференции или другого события: выбор места, бронирование спикеров, создание расписания и продвижение мероприятия.
5. Научные исследования:
  • планирование этапов исследования, включая литературу, сбор данных, анализ и публикацию результатов.
6. Образовательные проекты:
  • разработка учебного курса: создание учебных материалов, проведение лекций и семинаров, оценка студентов.
7. Производственные процессы:
  • оптимизация производственного процесса, включая закупку материалов, сборку продукции и контроль качества.
8. Управление изменениями:
  • внедрение новых технологий или процессов в организации: обучение сотрудников, тестирование новых систем и оценка результатов.
Эти примеры демонстрируют гибкость диаграммы Ганта и ее применение в различных сферах деятельности.

Плюсы и минусы диаграммы Ганта

Преимущества использования диаграммы Ганта

Диаграмма Ганта имеет несколько значительных преимуществ, которые делают ее популярным инструментом для управления проектами:
  • Визуализация. Она предоставляет наглядное представление о проекте, позволяя легко увидеть временные рамки и последовательность задач.
  • Простота использования. Диаграмма Ганта интуитивно понятна и легко воспринимается, что облегчает понимание хода проекта как для команды, так и для заинтересованных сторон.
  • Планирование сроков. Позволяет установить четкие сроки выполнения задач и следить за их соблюдением.
  • Отслеживание прогресса. С помощью диаграммы можно легко отслеживать выполнение задач и выявлять задержки.
  • Определение зависимостей. Этот этап помогает выявить, какие задачи зависят друг от друга, чтобы учесть это при планировании работ.
  • Коммуникация. Упрощает общение между членами команды и заинтересованными сторонами, предоставляя общее представление о статусе проекта.
  • Гибкость. Позволяет вносить изменения в план, что делает ее полезной для адаптации к изменяющимся условиям.
  • Исторический анализ. Диаграммы могут служить для анализа прошлых проектов, что помогает в будущем улучшить планирование и управление.
Эти преимущества делают диаграмму Ганта эффективным инструментом для управления проектами в различных отраслях.
Если вам требуется помощь в выстраивании бизнес-процессов и консалтинг — обратитесь в Neogenda. Мы внедряем современные управленческие практики в крупные компании, за счет чего они быстрее и эффективнее достигают поставленных целей.

Недостатки использования диаграммы Ганта

Диаграмма Ганта — это полезный инструмент для визуализации проектов, но у нее есть и недостатки:
  • Сложность в больших проектах. При большом количестве задач диаграмма может стать перегруженной и трудночитаемой.
  • Трудности с изменениями. Внесение изменений в сроки или задачи может потребовать значительных корректировок всей диаграммы.
  • Не учитывает ресурсы. Диаграмма Ганта не показывает какие ресурсы задействованы в каждой задаче, что может затруднить управление ресурсами.
  • Проблемы с точностью. Если задачи имеют неопределенные сроки или могут изменяться, диаграмма может быстро устареть.
  • Линейный подход. Она предполагает линейное выполнение задач, что не всегда соответствует реальности, особенно в сложных проектах.
  • Трудности с оценкой времени. Оценка продолжительности задач может быть субъективной и не всегда точной, что влияет на всю диаграмму.
Эти недостатки могут ограничить использование диаграмм Ганта в определенных контекстах, поэтому важно рассматривать их как часть более широкой системы управления проектами.
Читайте также статью: «Что такое Scrum-спринты в управлении проектами: гайд»
]]> Ласло Бок: отделяйте цели от зарплат http://neogenda.ru/blog/9zt960yi71-laslo-bok-otdelyaite-tseli-ot-zarplat http://neogenda.ru/blog/9zt960yi71-laslo-bok-otdelyaite-tseli-ot-zarplat?amp=true Thu, 12 Dec 2024 07:39:00 +0300 Артур Нек Как использовать OKR для обеспечения роста, вовлеченности и устойчивости...

Ласло Бок: отделяйте цели от зарплат

Как использовать OKR для обеспечения роста, вовлеченности и устойчивости
OKR (от англ. Objectives and Key Results — цели и ключевые результаты) — методика синхронизации и мониторинга целей на всех уровнях: организации, команды, человека.
Может показаться нелогичным, но OKR не должны быть напрямую связаны с вознаграждением или бонусами. Бывший вице-президент по работе с персоналом Google Ласло Бок подробно объясняет, почему это важно, и рассказывает, как мотивировать команду не только деньгами.

Урок от Google: провал или успех?

В 2011 году компания Google запустила Google+ — амбициозную социальную сеть, предназначенную стать конкурентом Facebook. В лучшие моменты над ней трудились более 1 000 инженеров. Однако, когда «G+» не достиг целей по вовлеченности клиентов и доле рынка, работу над ним свернули.
В других компаниях это бы сочли дорогим провалом, но Google оценили проект иначе из-за нового подхода к вознаграждению сотрудников.
Чтобы это понять, нужно разобраться в системе OKR, которая определяла стратегию и обеспечивала эффективность Google. У команды Google+ были цели и метрики, связанные с количеством пользователей, но провалы в их достижении не наказывались штрафами. Бонусы в Google в основном рассчитывались по коэффициенту, привязанному к уровню прибыли компании.
«Вы не можете установить коэффициент меньше 100%, потому что это деморализует тех, кто не имеет отношения к провалу», — объясняет Ласло Бок, бывший вице-президент по работе с персоналом в Google (2006-2016).
Независимо от участия в проекте Google+, зарплата сотрудников не уменьшалась. Это считалось справедливым: провал мог быть вызван внешними факторами, а не действиями команды.

Противоречивый принцип

Бок настаивает: цели и ключевые результаты должны быть полностью отделены от вознаграждения.
Этот принцип может показаться нелогичным — зачем ставить цели, если их достижение не поощряется? И можно ли добиться прозрачного процесса, когда все видят цели и цифры?
Спойлер: да, и Google понял это на своем опыте.
«Однажды, — рассказывает Бок, — Google привязал показатели OKR по использованию продукта непосредственно к вознаграждению людей. Люди начали обманывать систему, чтобы получить свои бонусы. Таким образом, сама идея привязки денежных стимулов к достижению ключевых результатов была признана пагубной как для продукта, так и для культуры в целом», — говорит Бок.

Как избежать «порочных мотиваций»

Рассмотрим пример плана продаж. Если продавец с годовой целью в 1 млн долларов работает ради премии в 10 000, его усилия могут принести пользу компании. Однако система создает побочные эффекты:
  • сотрудники могут гнаться за объемами продаж, забывая о прибыли;
  • заключать контракты с краткосрочной выгодой, игнорируя долгосрочные риски;
  • сосредотачиваться на наиболее прибыльных клиентах, забывая про другие важные сегменты.
Вот, что говорит Бок: «Вы можете абсолютно точно платить сотрудникам отдела продаж согласно планам. Вы хотите, чтобы показатели продаж были частью их OKR. Но помните, что любой план стимулирования продаж создает порочные стимулы, независимо от того, привязан он к OKR или нет».
Поэтому OKR помогают уточнить цели. Например, вместо метрики средняя стоимость лицензии можно добавить показатель общее количество лицензий.

Определение целей

Именно здесь на помощь приходят простые механизмы OKR. Рабочие цели редко сводятся к сырой выручке — их можно уточнить с помощью ключевых результатов, которые дополняют или уточняют то, чего пытается достичь человек и организация. Это помогает понять, как именно добиться поставленной выручки.
Например, вместо того чтобы установить OKR в виде средней стоимости за одну лицензию, можно добавить метрику общего количества лицензий. А вместо цели по общим продажам, целью может стать достижение продаж в 5 разных отраслях.
Какими бы ни были цели и ключевые результаты, они должны быть значимыми и амбициозными — такими, которые побуждают людей выкладываться, не ожидая, что все цели будут достигнуты на 100%. В Google, например, нормой считается достижение целей на 60-70%.
Но это не универсальное правило, поэтому просто взять текущие показатели и добавить к ним 30% — нельзя посчитать амбициозной целью.

Формирование эффективных целей

OKR как для отдельных сотрудников, так и для организации в целом, должны сочетать показатели эффективности и цели более высокого порядка, формирующие и укрепляющие культуру компании.
«В Google у продавцов были OKR, включающие план продаж», — рассказывает Ласло Бок. Но они также дополнялись и другими показателями.
Более широкие OKR могут затрагивать изменение жизни клиента, подходов компании или рынка. Например, цель создать команду мирового класса может быть связана с такими ключевыми результатами, как повышение разнообразия подходов к продажам в команде не менее чем на 2 новых метода.
Или же с измерением показателей некоммерческой деятельности, например, оценки лидерских и тренерских навыков внутри команды.
«Именно так продавцы, не выполнившие план, могут получить премию, — объясняет Бок. — Потому что всегда есть другие важные вещи, которые требуют внимания, помимо выполнения плана по продажам».

Сочетайте правильно

Правильное сочетание OKR — это ключ. Включение клиентских или корпоративных выгод в набор из двух-трех целей для каждого сотрудника создает качественные обсуждения и укрепляет корпоративную культуру.
«Если вы внедряете OKR в своей организации, — советует Бок, — выделите одну финансовую цель, а остальные используйте для решения других насущных задач. Изначально упростите финансовую цель, дополнив её балансирующими ключевыми результатами».
В идеале у вас должен быть один экономический OKR, один культурный и один — ориентированный на эффективность. Можно добавить и личный OKR. Главное — учитывать корпоративную культуру и заботиться о её основе.

Точность — элемент «магии OKR»

В отличие от других систем, как S.M.A.R.T. («конкретные, измеримые, достижимые, релевантные и ограниченные по времени»), OKR избегают как излишней обобщённости, так и фокусировки на лишении сотрудников бонусов за недостижение показателей.
Ранний рост Google — яркий пример. Если бы целью было просто привлечь больше трафика, компания могла бы добиться множества кликов, добавив на страницу некачественные результаты, заставляющие пользователей переходить на следующие страницы. Это плохой стимул, поэтому добавлялся балансирующий ключевой результат, минимизирующий время, проведенное пользователями на странице.
В итоге была создана система метрик, которая уравновешивает качество и количество. Если кто-то подумает, что несколько целей — это слишком сложно и непонятно, на чем именно сосредоточиться, на качестве или количестве, у Бока есть простой ответ:
«Мы наняли умных и талантливых людей. Давайте делать и то, и другое».

Внутреннее превосходит внешнее

Наполеон Бонапарт сказал: «Солдат будет долго и упорно сражаться за кусочек цветной ленточки».
Суть в том, что людей мотивируют не только деньги или слава, но и внутренние ценности — автономия, мастерство, цель. Это подтверждается в книге «Драйв» Дэниела Пинка.
Пример из Google — фильм «Лев», номинированный на «Оскар» в 2016 году. Главный герой использовал карты Google, чтобы найти своих родителей спустя 25 лет разлуки. Эта история вдохновила сотрудников компании, напомнив им, как их продукт помогает людям.

Мудрость в вопросах поощрения

Бок ссылается на исследования, показывающие, что бонусы по результатам работы часто не обеспечивают долгосрочной мотивации.
«Добавляя стимулы, вы получаете краткосрочный рост производительности, но со снижением бонусов сотрудники начинают уходить».
Эксперименты показали: те, кому обещали денежное вознаграждение за решение головоломок, снижали свои усилия после получения бонуса. Их результаты становились хуже, чем у контрольной группы, где вознаграждение не обещалось.
В Google каждый сотрудник может рассчитывать на премию, зависящую от результатов работы компании. Однако исследования показывают: зарплата ценится больше, чем бонусы, ведь люди недооценивают их будущую стоимость на 80%.

Связь через историю

Истории помогают связывать людей с целями. Это могут быть рассказы о героях, злодеях, о том, как вы вдохновляете или спасаете жизни.
Эти повествования должны быть частью управления и приоритетов, устанавливаемых через OKR. Исследования показывают, что только треть людей видит смысл в своей работе. Но те, кто находит смысл, в среднем работают продуктивнее на 21 %, становятся счастливее и ведут более насыщенную жизнь.
Или, как выразился Ласло Бок: «Это всё то прекрасное, что может произойти».
Хотите внедрить OKR и достичь результатов? Мы в Neogenda поможем настроить систему, определить цели и ключевые метрики, чтобы ваша команда работала слаженно и уверенно двигалась к успеху. Начнем бесплатной консультации?
]]> Управление конфликтами в команде http://neogenda.ru/blog/0sb8ps6f01-upravlenie-konfliktami-v-komande http://neogenda.ru/blog/0sb8ps6f01-upravlenie-konfliktami-v-komande?amp=true Fri, 20 Dec 2024 08:02:00 +0300 Артур Нек Бывает, что кто-то из команды вечно опаздывает на созвоны или сдает работу не вовремя. Из-за...

Управление конфликтами в команде

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

Что такое конфликт и почему он возникает

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

Откуда берутся конфликтные сотрудники

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

Как распознать конфликтного сотрудника на собеседовании

Обратите внимание на то, как кандидат отзывается о бывших коллегах и начальниках. Если он охотно критикует их и обвиняет в своих неудачах — это тревожный звоночек. Скорее всего, в новой команде он тоже будет перекладывать ответственность.
Поинтересуйтесь, как кандидат отстаивает свою точку зрения. Спросите о ситуациях, когда ему приходилось убеждать коллег или руководство в своей правоте. Конфликтные люди часто не умеют спокойно и аргументированно доносить свою позицию. Они срываются на эмоции, переходят на личности или давят авторитетом.
Попросите кандидата рассказать о своем опыте работы в команде. Как он поступал, если его идеи отвергали? Как реагировал на критику? Готов ли был идти на компромиссы ради общего результата? Ответы на эти вопросы многое скажут о его умении сотрудничать и договариваться.
Чтобы понять, врет человек или нет, обратите внимание на невербальные сигналы. Если кандидат слишком напряжен, избегает зрительного контакта, нервно жестикулирует, возможно, он не вполне искренен или чувствует себя некомфортно в оценке ситуации. А это может быть признаком неуверенности в себе и повышенной конфликтности
Запросите рекомендацию у предыдущего работодателя. Задать можно 3 вопроса:
  • Почему уволился из компании?
  • Взяли ли бы еще раз на работу?
  • Какие минусы есть у соискателя (людей без минусов не бывает).

Польза конфликтов

Конфликты — это не всегда плохо. Они могут принести команде большую пользу, потому что в спорах и столкновениях часто рождается истина.
Конфликты помогают выявить проблемы, которые мешают достижению целей. Представьте ситуацию: в отделе продаж возник конфликт между менеджерами из-за разных подходов к работе с клиентами. Один сотрудник делал упор на долгосрочные отношения и персонализированный сервис, а другой — на быстрые продажи и агрессивный маркетинг. В итоге они начали спорить и выяснять, чья стратегия приносит больше денег.
Благодаря этому конфликту руководитель отдела понял, что в компании нет единых стандартов обслуживания клиентов и четких критериев эффективности менеджеров. Это мешало команде слаженно работать и достигать общих целей по выручке.
Он провел серию встреч с командой и выработал единый подход, совместивший лучшее из обеих стратегий. А еще установил понятные KPI для оценки результатов.
Компромисс — лучший исход событий
Конфликты стимулируют развитие компании и внедрение новых фишек. Теперь представьте другую ситуацию. Компания Х должна запустить новый продукт на рынке. В компании есть отдел маркетинга, в котором команда разделилась на 2 лагеря. Первый хочет делать ставку на агрессивный маркетинг, второй — на нативную рекламу и контент-маркетинг.
Чтобы отстоять свою точку зрения, обе команды проводят исследования рынка, изучают опыт конкурентов, придумывают нестандартные ходы. В итоге сотрудники понимают, что лучше совместить оба подхода, но сделать ставку на нативную рекламу и контент-маркетинг. И только небольшую часть ресурсов направить на агрессивный маркетинг.
Конфликты помогают укрепить отношения в команде. Конечно, если конфликт конструктивный. Когда люди слушают друг друга и решают проблему вместе, они становятся более сплоченной командой и лучше работают сообща.
Конфликт будет конструктивным тогда, когда стороны будут спокойно общаться и думать, как его урегулировать. Принимать обоснованные решения вместо того, чтобы доказывать свою правоту.
В остальных случаях конфликт будет деструктивным. Выявить такой конфликт помогут признаки:
  • каждый сотрудник отстаивает только свою точку зрения и не пытается решить проблему;
  • стороны шантажируют или запугивают друг друга. Например, грозят штрафами, увольнениями или другими санкциями;
  • стороны используют «грязные» способы борьбы: скрывают информацию, обманывают;
  • одна из сторон отказывается взаимодействовать, чтобы разрешить конфликт.
Наличие хотя бы одного признака из этих говорит о том, что конфликт может стать деструктивным и неуправляемым.

Последствия неуправляемых конфликтов

Если конфликты в команде не решать, а замалчивать или игнорировать, ситуация может быстро выйти из-под контроля.
❌ Атмосфера в коллективе неизбежно ухудшится, снизится эффективность командной работы. Вместо работы сотрудники будут ругаться, вести интриги и всячески портить друг другу жизнь. Нормальная коммуникация нарушится и ни о какой взаимопомощи не будет идти речи.
В команде всегда нужно поддерживать оптимизм, чтобы сотрудники справлялись со своими задачами
Какое-то время это не будет влиять на процессы – пока люди не начнут терять мотивацию и выгорать. Мало кто захочет изо дня в день приходить туда, где личный вклад не ценится, а ошибки воспринимаются как нечто недопустимое. Туда, где идеи не находят отклика, а промахи становятся поводом для обвинений. Люди перестанут чувствовать свою причастность к общему делу и действовать сообща.
❌ Часть сотрудников может уволиться. Особенно, если это опытные специалисты, чьи навыки и опыт востребованы в других компаниях, где нет токсичной рабочей среды.
Так считаем не мы, а люди. По опросам РБК, почти половина (47%) россиян готовы уволиться из компании в случае конфликтов с коллегами. А около трети респондентов (31%) уволились бы из-за конфликта с непосредственным руководителем
❌ Негативные последствия касаются не только внутренних процессов. Конфликты в команде = хаос и отсутствие работы. А если компания плохо работает, ее репутация может пострадать. Партнеры захотят обратиться к конкурентам, которые работают лучше и успевают в срок.
Итог всех конфликтов — потеря денег. Пока сотрудники вместо работы выясняют отношения, бизнес-процессы простаивают. Либо выполняются некачественно. Компании теряют деньги и партнеров.

Роль руководителя и менеджера в решении конфликтов

Обычно конфликты в команде решает HR-специалист или менеджер по персоналу. Но если компания небольшая, этим может заниматься сам руководитель. От действий руководителя/менеджера зависит, перерастет ли рабочий спор в затяжной конфликт или его удастся быстро решить.
Хороший менеджер должен уметь вовремя распознавать конфликты. Не ждать, пока они станут очевидными для всех, а замечать первые тревожные сигналы. Например, распознавать резкий тон в общении, пренебрежение к мнению коллег, формирование «группировок» в команде.
Задача менеджера — создать условия для конструктивного диалога. Организовать встречу конфликтующих сторон на нейтральной территории, установить четкие правила общения, следить за соблюдением регламента. Важно, чтобы каждый участник конфликта мог высказать свою позицию.
При этом менеджер должен оставаться беспристрастным. Он обязан выслушать все точки зрения. Показать, что интересы и аргументы каждого важны и будут учтены при принятии решения.
Когда все выскажутся, нужно помочь найти решение. Предложить компромисс или организовать мозговой штурм, чтобы команда сама нашла выход из ситуации. Главное — не навязывать свое мнение.
Затем нужно обозначить, кто и что должен сделать, в какие сроки. Убедиться, что все участники конфликта поняли и приняли эти договоренности. А потом проследить, чтобы они действительно выполнялись, а не остались на бумаге.
Как решить конфликт в команде

Шаги по управлению конфликтами

1. Выявить конфликт на ранней стадии

Конфликты редко возникают на пустом месте. Обычно им предшествуют определенные признаки: напряженность в общении, групповое деление, ухудшение дисциплины. Чем раньше вы их заметите, тем легче будет предотвратить эскалацию. Поэтому будьте внимательны к атмосфере в команде и не игнорируйте тревожные сигналы.
Распознать конфликт помогут эти сигналы:
  • Выгорание. Люди теряют энтузиазм, становятся апатичными и безразличными к работе.
  • Жалобы. Руководителю, в отдел кадров или в соцсетях. Сотрудники открыто выражают разочарование компанией и руководством.
  • Беспорядок. Сотрудники сопротивляются новым процессам или отказываются от старых. Командная работа разлаживается, руководителю все сложнее контролировать ситуацию.
Это ранние сигналы конфликтов. Если их не распознать, наступят последствия:
  • Прогулы. Сотрудники начинают избегать неприятной обстановки. Часто отсутствуют на рабочем месте под разными предлогами. Например, берут больничные и отгулы.
  • Текучесть кадров. Ценные сотрудники уходят к конкурентам или меняют сферу.
  • Судебный процесс. Недовольный сотрудник может обратиться к юристам и подать на компанию в суд. Если компания проиграет, ей придется выплатить компенсацию и оплатить сам суд.

2. Прояснить суть и причины конфликта

Поговорите индивидуально со всеми вовлеченными. Дайте каждому возможность высказать свою позицию без перебиваний и оценок. Задавайте уточняющие вопросы, чтобы лучше понять точку зрения и интересы сторон. Отделяйте факты и реальные проблемы от эмоций и субъективных интерпретаций.
Конфликтные ситуации неизбежно связаны с эмоциональными реакциями участников. Гнев, обида, страх и другие сильные эмоции будут сильно затруднять конструктивный диалог. Поэтому нужно развивать навыки управления собственными эмоциями и эмоциями других людей.
Сохранять спокойствие, не поддаваться на провокации, создавать атмосферу психологической безопасности и доверия.
Существует много подходов к совместному решению проблем. Один из таких — Гарвардский метод.
Его суть заключается в том, чтобы сфокусировать внимание сторон не на занимаемых ими позициях, а на реальных интересах и потребностях. Задача — найти взаимовыгодные варианты решения, опираясь на объективные критерии.
Гарвардский метод предполагает последовательное прохождение нескольких этапов:
  • отделение людей от проблемы;
  • концентрация на интересах, а не на позициях;
  • разработка взаимовыгодных вариантов;
  • использование объективных критериев.
Представим, что в отделе маркетинга возник спор между дизайнером и копирайтером о концепции нового рекламного буклета. Дизайнер настаивает на минималистичном стиле с упором на визуальную составляющую, а копирайтер хочет подробно расписать преимущества продукта и разместить больше текста. Каждый считает свой подход лучшим и не желает уступать.
Чтобы разрешить конфликт, менеджер поступил так:
  1. Отделил людей от проблемы. Подчеркнул, что оба сотрудника ценны для команды и их мнения важны. Предложил вместе объективно взглянуть на ситуацию не переходя на личности.
  2. Сфокусировался на интересах, а не на позициях. Через активные вопросы помог дизайнеру и копирайтеру осознать, что их общая цель — создать эффективный буклет, который привлечет клиентов и поможет продать продукт. Это их истинный интерес, а стиль оформления — лишь занятая позиция.
  3. Выработал взаимовыгодные варианты. Предложил сотрудникам придумать несколько концепций буклета, которые бы совмещали визуальную привлекательность и информативность в разных пропорциях. Один из вариантов — изменить формат буклета, чтобы удовлетворить потребности обеих сторон.
  4. Использовал объективные критерии. Для оценки вариантов он опирался на конкретные показатели: соответствие буклета целевой аудитории, совместимость с фирменным стилем, убедительность аргументов, читабельность текста, лаконичность дизайна. Главное — сделать выбор на основе этих критериев, а не личных предпочтений.
В итоге дизайнер и копирайтер смогли найти компромиссное решение: часть информации вынесли на сайт, а в буклете оставили самое важное и подкрепили яркими визуальными образами.
Когда в команде нет конфликтов, все лучше делают свою часть работы

3. Организовать конструктивный диалог сторон

Когда поймете суть конфликта, организуйте совместное обсуждение. Выберите нейтральное место и удобное для всех время. Установите четкие правила: не перебивать, говорить о своих чувствах и интересах, избегать обвинений и оскорблений.
В самом диалоге можно участвовать 2 способами:
1. Фасилитация. Нейтральный сотрудник (менеджер/руководитель) слушает суть спора и предлагает пути решения. При этом не выносит окончательное решение — его принимают участники конфликта. На эту тему у нас есть отдельная статья: «Что такое фасилитация и зачем ее внедряют компании».
2. Посредничество. В этом случае вместо менеджера или руководителя третьей стороной выступает незаинтересованный сотрудник или внешний специалист. Главное, чтобы у этого человека не было конфликта с обеими сторонами. Третья сторона может посмотреть на конфликт иначе и предложить нестандартное решение. Но окончательное решение все равно останется за участниками конфликта.

4. Найти взаимовыгодное решение

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

5. Закрепить договоренности и проконтролировать выполнение

Напишите, кто и что должен сделать, в какие сроки. Оговорите последствия невыполнения обязательств. Определите, как вы будете контролировать реализацию договоренностей. При необходимости проводите промежуточные встречи, чтобы поддержать выполнение плана и вовремя среагировать на возможные трудности.
Всем этим принципам и методам можно и нужно обучаться с помощью специальных тренингов, изучения литературы, обмена опытом с более опытными коллегами.
А еще вы можете обратиться в Neogenda — консалтинговую фирму, которая занимается внедрением современных управленческих практик. На нашем счету работа с такими компаниями как Тинькофф, Сбер, Яндекс, Точка, X5 Group и так далее. Мы оказываем более 100 различных услуг – от обучения персонала до реорганизации бизнеса. Если вы хотите, чтобы мы взялись за ваши процессы – обратитесь к нам за бесплатной консультацией.
Проактивные методы предотвращения конфликтов
✅ Установите командные нормы и ценности. Это поможет всем придерживаться единых правил и принципов работы. Договоритесь о том, что для вас важно — уважение, открытость, взаимопомощь.
✅ Поощряйте членов команды свободно выражать свои мысли и идеи. Проводите регулярные встречи, где каждый может поделиться своим мнением и обсудить возникающие вопросы. Создайте атмосферу, в которой люди не боятся говорить о проблемах и вместе искать решения.
✅ Учите сотрудников давать и принимать конструктивную обратную связь. Это помогает выявлять и решать потенциальные проблемы на ранних стадиях. Обратная связь должна быть конкретной, своевременной и сфокусированной на поведении, а не на личности. То есть нужно обсуждать конкретные действия и их последствия, а не личные качества или характер человека.
✅ Поощряйте совместную работу и взаимопомощь. Организуйте тимбилдинги и неформальные мероприятия, чтобы сплотить команду.
✅ Проводите тренинги по эффективной коммуникации, активному слушанию, управлению эмоциями. Учите сотрудников конструктивно разрешать разногласия — фокусироваться на проблеме, а не на человеке, искать взаимовыгодные решения.
Помогайте сотрудникам фокусироваться на проблемах, а не на самих себе

Что в итоге

  • Основные причины конфликтов: разные цели и ценности, плохая коммуникация, личная неприязнь, борьба за ресурсы.
  • Распознать конфликтного сотрудника можно по его общению с коллегами и начальниками, а также по его поведению на собеседованиях.
  • Сотрудники могут становиться конфликтными из-за личных проблем, профессионального выгорания, недооценки их вклада или несоответствия команде.
  • Проблемы могут начаться с приходом нового руководителя или изменением стиля управления.
  • Негативные последствия конфликтов: ухудшение атмосферы в коллективе, снижение эффективности работы, потеря мотивации и выгорание сотрудников.
  • Роль руководителя и менеджера в решении конфликтов – распознавать конфликты на ранней стадии, создавать условия для конструктивного диалога, помочь найти решение, следить за выполнением договоренностей.
Не стоит бояться конфликтов. Они — неизбежная часть работы любой команды. Главное — научиться видеть в них возможности для роста и правильно их использовать.
]]> Что такое бизнес-процесс и как он помогает управлять командой http://neogenda.ru/blog/3drz1kjcb1-chto-takoe-biznes-protsess-i-kak-on-pomo http://neogenda.ru/blog/3drz1kjcb1-chto-takoe-biznes-protsess-i-kak-on-pomo?amp=true Mon, 23 Dec 2024 08:05:00 +0300 Артур Нек Любую компанию можно представить как сочетание взаимосвязанных действий и операций, которые направлены на достижение целей....

Что такое бизнес-процесс и как он помогает управлять командой

Любую компанию можно представить как сочетание взаимосвязанных действий и операций, которые направлены на достижение целей. Успех бизнеса зависит не только от продукта или услуг, но и от того, насколько четко организованы эти процессы. Особенно когда конкуренция растет, а эффективность необходимо повышать.
Разберем что означает бизнес-процесс, его основные задачи и виды, рассмотрим структуру и описание бизнес-процессов, почему они влияют на стабильный рост компании и помогают оптимизировать ее работу.
А внедрить в ваш бизнес современные управленческие практики и улучшить производительность команды поможет Neogenda. У нас больше ста успешных кейсов и опыт работы с такими компаниями как Авито, Сбер, Skyeng. Чтобы получить индивидуальные решения для вашего бизнеса, оставьте заявку на бесплатную консультацию экспертов Neogenda.

Что такое бизнес-процесс

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

Какие задачи выполняют бизнес-процессы

Процессы предприятия нужны, чтобы получить определенный результат, например увеличить эффективность команды или минимизировать риски. Бизнес-процессы помогают:
  • Повышать эффективность работы фирмы
Систематизация и оптимизация деятельности позволяет компании тратить меньше времени и ресурсов.
Пример. На фабрике процесс внедрения обновленной схемы для закупки сырья помогает усовершенствовать взаимодействие с поставщиками и быстрее обрабатывать поставки. Это положительно влияет на весь производственный цикл.
  • Улучшать качество товаров или услуг
Бизнес-процесс помогает не только эффективно выполнять работу, но и постоянно ее улучшать.
Пример. В логистической компании появилась схема бизнес-процесса по контролю качества доставки. Сотрудники начали проверять сроки и условия перевозки. Это позволяет минимизировать случаи повреждения товара, соблюдать временные рамки и лучше обслуживать клиентов.
  • Снижать затраты и риски
Компания, которая умеет определять и анализировать этапы бизнес-процессов, может быстрее находить проблемные места и снижать возможные расходы.
Пример. Розничная сеть обнаружила, что на складах неправильно хранятся запасы, поэтому часть из них портится. Компания разработала и внедрила бизнес-процесс по управлению складскими запасами, чтобы сократить убытки и снизить риск потери товаров.
  • Повышать гибкость и адаптироваться к разным условиям
Четко структурированные бизнес-процессы помогают компании быстрее приспосабливаться к изменениям на рынке.
Пример. В IT-агентстве выстроили бизнес-процесс, чтобы быстро обновлять программное обеспечение, когда того требуют запросы клиентов или меняются технологии. Благодаря такому решению команда может оперативно добавлять функции или исправлять ошибки, но при этом сохранять актуальность продукта и повышать лояльность пользователей.
  • Работать прозрачно и согласованно
Бизнес-процессы помогают наладить связи между отделами, минимизировать недопонимание и ошибки.
Пример. В банке разработали бизнес-процесс, чтобы обрабатывать заявки на кредиты. Сотрудники разных отделов знают свои роли, поэтому работают согласованно и оперативнее рассматривают заявки. В результате удовлетворенность клиентов растет, репутация банка — тоже.

Какими могут быть виды бизнес-процессов

Бизнес-процессы фирмы можно разделить на несколько категорий. Это позволяет разобраться, как разные процессы взаимодействуют между собой, какие из них приносят прямую пользу клиенту, а какие поддерживают внутренние потребности компании. Рассмотрим, какие бизнес-процессы бывают:
  • Основные бизнес-процессы
Непосредственно связаны с созданием ценности для клиента и состоят из ключевых операций, без которых невозможна работа компании.
Пример бизнес-процесса. Для компании, которая производит мебель, основным процессом будет производство изделий — от закупки сырья до сборки и упаковки готовой продукции.
  • Сопутствующие бизнес-процессы
Дополняют основные и помогают поднять качество услуг или продукта, но сами по себе не создают ценность для клиента. Эти процессы поддерживают основные операции, обеспечивая их выполнение на более высоком уровне.
Пример. В компании по продаже электроники сопутствующим процессом будет техническое обслуживание и ремонт проданных устройств. Прямо не относится к продаже, но улучшает клиентский опыт и повышает лояльность.
  • Вспомогательные бизнес-процессы
Помогают поддерживать работу компании, но не связаны напрямую с производством продукта или услугой. Направлены на внутренние задачи, без которых трудно выполнять основные операции.
Пример. В логистической компании к такому процессу можно отнести бухгалтерский учет. Он не несет прямой выгоды клиентам, но позволяет контролировать финансы и обеспечивать бесперебойную работу.
  • Обеспечивающие бизнес-процессы
Создают такие условия, при которых остальные процессы могут функционировать. Обеспечивают необходимую инфраструктуру, технологии, ресурсы.
Пример. В IT-агентстве обеспечивающим процессом будет поддержка серверов и техобслуживание компьютеров сотрудников. Это позволяет всем отделам использовать доступные технологии и стабильные системы, чтобы продуктивно работать.
  • Управляющие бизнес-процессы
Отвечают за контроль и координацию всех остальных бизнес-процессов. Их основная цель — следить за тем, насколько качественно и эффективно работает организация в целом.
Пример. В производственной фирме управляющий процесс может включать стратегическое планирование и контроль за тем, как каждому отделу удается выполнять KPI. Руководство определяет задачи, приоритеты и следит за результатами, чтобы все процессы были согласованы и работали на общие цели компании.
  • Процессы развития
Нужны, чтобы компания росла и развивалась, внедряла новые технологии, расширяла продуктовую линейку, а сотрудники повышали квалификацию. Они помогают организации адаптироваться к изменяющимся условиям рынка и оставаться конкурентоспособной.
Пример. В онлайн-школе процессом развития может быть создание новых учебных программ и внедрение актуальных технологий обучения. Так, компания может расширять предложения и привлекать больше учеников.

Из каких элементов может состоять бизнес-процесс

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

Вход

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

Ресурсы

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

Управляющие действия

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

Исполнители

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

Владелец

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

Выход

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

Критерии оценки

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

В каком формате описывать бизнес-процесс

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

→ Текстовое описание

Это подробное изложение бизнес-процесса в виде текста, который затрагивает все ключевые этапы, роли и ресурсы. Этот формат удобно использовать когда нужно передать много информации и объяснить процесс детально. Текст помогает максимально полно раскрыть нюансы и пояснения. Однако, формат может оказаться неудобным для больших и сложных процессов.
Пример. Текстовое описание бизнес-процесса обработки заказов включает шаги от момента поступления заявки до доставки товара клиенту: «Шаг 1: Прием заказа через CRM-систему. Шаг 2: Подтверждение наличия товара на складе. Шаг 3: Подготовка к отправке и т. д.».

→ Табличное описание

В этом случае бизнес-процесс описывают в таблице, где каждый этап занимает отдельную строку. Табличное описание позволяет структурировать процесс и облегчает восприятие информации. Как правило, таблица включает такие столбцы: «Этап», «Действия», «Ответственные», «Входы» и «Выходы». Этот формат удобен для описания бизнес-процессов средней сложности и помогает быстро находить нужные данные.
Пример. В таблице для процесса найма сотрудников могут быть такие строки с этапами: «Публикация вакансии», «Отбор резюме», «Интервью». Можно указать ответственных лиц и результат каждого этапа. Это упрощает контроль и понимание процесса.

→ Графическое описание

Один из самых наглядных способов продемонстрировать бизнес-процесс. Это может быть бизнес-схема процесса или карта. Этапы изображены в виде блоков со стрелками, которые показывают какое действие за каким идет. Карта бизнес-процесса позволяет увидеть полную картину от входа до выхода. Графическое описание помогает визуализировать и проще воспринимать сложные процессы где важно осознавать взаимосвязи между этапами.
Пример. Карта бизнес-процесса для обработки клиентских обращений может включать блоки «Прием запроса», «Определение типа проблемы», «Решение проблемы» и «Закрытие обращения». Они будут соединены между собой стрелками, которые указывают последовательность и условия переходов между этапами.

Из каких элементов состоит правильное описание бизнес-процесса (пример)

1. Определение цели описания процесса. Чтобы сконцентрироваться на нужных аспектах и выбрать подходящий формат, важно понять, зачем вы хотите сделать описание. Анализ текущего состояния процесса, внедрение новых стандартов, обучение сотрудников или оптимизация работы — все это цели.
2. Сбор информации о процессе. На этом этапе важно собрать всю необходимую информацию о бизнес-процессе. Можно применять наблюдение, интервью с участниками процесса, анализ документации и текущих рабочих практик. Важно понять, как на самом деле выполняются действия, а не как они выглядят на бумаге.
3. Определение границ процесса. Необходимо четко установить, где начинается и заканчивается бизнес-процесс. Это поможет сосредоточиться на основных действиях и исключить ненужные детали. Определите входы и выходы процесса, а также участников.
4. Описание этапов процесса. После того, как определите границы, опишите каждый этап процесса, включая последовательность действий и ответственных исполнителей. Укажите, какие ресурсы и данные нужны, чтобы выполнить каждый шаг. А еще — возможные решения и условия переходов между этапами.
5. Идентификация рисков и трудностей. Теперь пора выявить вероятные затруднения и риски, которые могут возникнуть на каждом из этапов. Это позволит заранее разработать меры, чтобы их предотвратить и улучшить общую эффективность процесса.
6. Определение критериев оценки эффективности. Установите метрики и критерии, по которым будете оценивать эффективность процесса. Это могут быть количественные и качественные показатели.
7. Документирование процесса. Запишите все собранные данные и описания в удобном формате. Это может быть текстовое, табличное или графическое описание — зависит от сложности процесса и аудитории. Убедитесь, что описание смогут понять все заинтересованные люди.
8. Регулярный пересмотр и обновление описания. Бизнес-процессы могут меняться со временем, поэтому важно периодически пересматривать и обновлять их описание. Это позволит поддерживать актуальность информации и внедрять новые решения по мере необходимости.

Как внедрять бизнес-процессы

Как только вы описали и спроектировали бизнес-процесс, его можно внедрять:
1. Подготовьте команду
Эффективное внедрение начинается с подготовки сотрудников. Нужно рассказать о целях нового бизнес-процесса, роли каждого участника и ожидаемые результаты. Важно провести обучение и прояснить, как изменения скажутся на обязанностях. Это помогает уменьшить сопротивление и повышает уровень ответственности.
2. Запланируйте этапы внедрения
Часто бизнес-процессы внедряются постепенно, особенно в крупных компаниях или сложных проектах. Можно начать с пилотного запуска в одном отделе или на небольшом этапе, а затем масштабировать процесс на всю организацию. Такой подход помогает выявить возможные проблемы на ранней стадии.
3. Отслеживайте эффективность
После запуска нового процесса нужно регулярно проверять, насколько он себя оправдывает. Заранее определите ключевые показатели эффективности, которые позволят оценить, достигаются ли цели. Например, сокращение времени на выполнение задачи, улучшение качества обслуживания клиентов или повышение производительности.
4. Вносите корректировки
На этапе внедрения могут обнаружиться недоработки или неучтенные нюансы. Важно оперативно реагировать на такие моменты. Готовность адаптировать процесс к реальным условиям помогает сделать его более эффективным и результативным.

Что в итоге

Чтобы оптимизировать свою работу, улучшить качество услуг и повысить удовлетворенность клиентов, компаниям важно правильно понимать и структурировать бизнес-процессы. Это сложная работа, которая требует внимания.
Если хотите провести аналитику, наладить управление бизнесом и разработать эффективные бизнес-процессы, обратитесь в компанию Neogenda. Просто запишитесь на бесплатную консультацию, и наши эксперты найдут решение именно для вашего бизнеса.
]]> Как написать свою первую цель? http://neogenda.ru/blog/l0fsg95a21-kak-napisat-svoyu-pervuyu-tsel http://neogenda.ru/blog/l0fsg95a21-kak-napisat-svoyu-pervuyu-tsel?amp=true Wed, 25 Dec 2024 08:09:00 +0300 Андрей Сидоренко К этому моменту вы уже имеете неплохое представление о том, что такое OKR. Но чтобы...

Как написать свою первую цель?

К этому моменту вы уже имеете неплохое представление о том, что такое OKR. Но чтобы стать настоящим экспертом, нужно немного попрактиковаться, чем мы и займемся. Мы разберем, как написать работающий OKR, но разделим его на части. В этой части мы сосредоточимся на «О» — Objective (от англ. — цель).

Начало пути: важность первого шага

Помните, что это будет ваш первый опыт, поэтому цель может быть неидеальной и с ошибками. Главное — записать первые цели на бумаге, а дальше дорабатывать и улучшать их.
OKR описывают будущее состояние, к которому мы хотим прийти через определенный промежуток времени. Цель — это описание конечной точки, к которой мы пытаемся прийти.
Большинство организаций описывают высокоуровневую цель на год, но для начала мы возьмём более короткий промежуток: 90 дней. Почему?
  • Этот период достаточно длинный, чтобы сделать что-то значимое.
  • При этом риск «пойти не туда» минимален.
Некоторые выбирают 60 дней, а кто-то даже месяц. Мы остановимся на 90 днях — это наиболее распространённый вариант.

Как найти правильную цель?

Лично я, прежде чем что-то написать, люблю поразмышлять о миссии своей организации.
  • Почему мы здесь?
  • Почему эта команда собралась вместе?
  • Что это за «идеал», к которому мы все стремимся?
Цель — это та самая Северная звезда, ваш главный ориентир, к которому нужно стремиться. Попробуйте задать себе вопросы:
  • Что самое важное мы пытаемся сделать?
  • Что мы как организация пытаемся изменить?
  • Что мы хотим начать делать, а что прекратить?
  • Как для вас выглядит успех?
Все ответы на эти вопросы могут стать основой для составления списка приоритетов и потенциальных целей, из которых мы можем выбирать.
Мысли лучше зафиксировать на бумаге или в Google Doc. Главное — показать свои наброски коллегам. Поначалу делиться ими будет трудно, но обратная связь важна для улучшения.

Фокусируйтесь на главном

OKR не должны охватывать всё подряд. Их задача — сфокусировать внимание команды на самом важном. Если список целей длинный, сейчас подходящее время для сокращения, объединения и расстановки приоритетов.
Но конечная цель — найти 2-3 главные цели, которые имеют наибольшее значение и отвечают на те вопросы, с которых мы начали. Помните, что компромиссные цели всегда будут проигрывать узко направленным.

Запомните, OKR — это не навсегда

Так же стоит держать в голове, что OKR не вечны. Мы будем достигать их в течении только 90 дней.
По истечении этого срока нужно снова задать себе те же вопросы:
  • Что самое важное нам нужно сделать?
  • Что нам нужно изменить?
  • Что мы хотим видеть по-другому?
Этот подход помогает постоянно адаптироваться к изменениям, поднимать планку и совершенствоваться. Можно сказать, что так вы создаете основу для осуществления изменений в вашей организации. Вы входите в этот ритм, постоянно спрашивая о том, что важно, перестраивая и поднимая планку каждый раз, когда вы выполняете этот цикл.
Для некоторых команд и компаний, которые планируют свою работу на год или полгода, система постановки целей OKR позволяет адаптироваться и меняться чаще, и соответствовать изменениям, происходящим в мире.

Проверяйте свои цели

Поэтому, выполняя это упражнение, не торопитесь, ведь это ваш шанс решить, что важнее всего для вас и вашей команды. Сужая круг целей, вы можете задаться вопросом: а так ли они хороши? И поскольку вы делаете это упражнение прямо сейчас, вы можете задать себе вопрос:
1. Записанные мною цели просто описывают то, что мы уже и так делаем?
Если да, то подумайте надо дополнительными вариантами. Так как делая, то же самое, вы рискуете получить те же результаты, что и ранее, а они вас не устраивают. Цели на самом деле предназначены для описания того, что мы хотим изменить в нашей организации и команде.
2. Могу ли я описать изменения проще? Может быть, я могу использовать более понятный язык?
Ведь мозг и так отбросит все лишнее, оставив только суть, так давайте сделаем это с формулировкой цели заранее. Далее в этом уроке, мы поможем вам улучшить свой первый набросок. А по мере изучения материала будем учиться делать наши цели еще лучше и лучше.

Начнем писать

Теперь откройте блокнот, возьмите ручку и бумагу, откройте пустой документ Word или Google Doc — что удобнее. Настало время применить всё, о чём мы говорили, и записать первые цели.
Прежде чем мы начнем, позвольте мне повторить, что OKR должны быть написаны, переписаны и даже полностью удалены, если они не работают для вас. Не смотря на то, что начинать что-либо с нуля может быть страшно, все это лишь часть непрерывного процесса.

Подумайте о своей Полярной звезде

Как мы уже говорили, цели рождаются из вашей миссии.
  • Миссия — это большой, «идеал», над которым все работают вместе.
  • Цели — это конкретные задачи, которые нужно сделать для достижения миссии.
Это призывы к сплочению команды на следующий цикл. Джон Дорр иногда называет самую главную цель «Полярной звездой» команды.
Поэтому уделите время и запишите «Полярную звезду» вашей команды. Обычно это первый и самый важный шаг, который вы можете сделать.
Пример. Миссия в компании Allbirds — создавать лучшую, экологически чистую обувь. Или, как они говорят, «делать лучшие вещи лучшим способом».
Чтобы достичь этого, их главная цель — добиться самого низкого углеродного следа в своей отрасли.
Что сделать: Определите «Полярную звезду» или цель высшего уровня, которая будет направлять вас.

Определите приоритеты

Чтобы еще немного поразмышлять и заполнить список возможных целей, давайте определимся с тем, что наиболее актуально в ближайшие 30-90 дней. Можете задать себе такие вопросы:
  • Что мне нужно сделать для достижения Полярной звезды? Что изменить?
  • Какие самые важные вещи нам нужно сделать?
  • Что нам нужно начать делать в принципе или изменить?
  • Как выглядит хороших результат этого периода?
  • Какие у нас самые важные обязательства на данный период?
Что сделать: Используя вышеприведенные вопросы, составьте список возможных целей. Если вы напишете более пяти, сузьте список до трех самых важных на данный момент.

Проверьте свою работу

Когда цели записаны, обсудите их с коллегами. Полученные отзывы помогут сделать цели лучше. А дальше скорректируйте их. Например, если:
  • цель описывает значимые изменения по сравнению с тем, что мы имеем сейчас. Не совсем получается? Попробуйте выйти за рамки привычного для вашей команды. Цель должна быть смелой, чтобы описывать реальный рост, но при этом не быть абсолютно нереалистичной;
  • цель лаконична и написана простым языком. Она вдохновит мою команду. Не совсем то? Попробуйте избавиться от некоторых слов и сократить предложение до самых важных частей. Запоминающиеся цели — вдохновляющие цели!
Что сделать: Проверьте свои цели на соответствие по примеру выше. Скорректируйте их, если они не проходят проверку.

Вместо итога

OKR — это процесс. Не бойся переписывать или удалять неподходящие цели. Это шанс сконцентрироваться на главном и вдохновить команду на значимые изменения.
А если вы хотите внедрить OKR и достичь результатов, но не знаете с чего начать, мы в Neogenda можем помочь. Например, настроить систему, определить цели и ключевые метрики, чтобы ваша команда работала слаженно и уверенно двигалась к успеху. Начнем бесплатной консультации?
]]> Соединение цели и прибыли http://neogenda.ru/blog/xnl5flmss1-soedinenie-tseli-i-pribili http://neogenda.ru/blog/xnl5flmss1-soedinenie-tseli-i-pribili?amp=true Thu, 16 Jan 2025 08:11:00 +0300 Андрей Сидоренко Итак, вы записали на бумаге несколько целей, и сейчас мы рассмотрим их с разных сторон....

Соединение цели и прибыли

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

Разница между целями и задачами

Цели — это то, чего мы пытаемся достичь. Чтобы формулировать действительно эффективные цели, нужно сделать шаг назад и задать себе вопрос: «Для чего мы делаем эту работу? Каков итог, которого мы хотим добиться?»
Часто люди настолько увлечены процессом, что забывают о первоначальной цели существования их подразделения.
Второй важный пункт — проблема вовлеченности. Иногда лидер, гонясь за большими достижениями, может упускать, что сотрудники чувствуют себя не вовлеченными в общие цели компании.
Стратегия и видение организации могут казаться им чем-то далёким. Однако, если вы разбиваете стратегию компании на понятные и измеримые цели, это помогает напомнить сотрудникам, что успех возможен только благодаря вкладу каждого.

Внутренняя проверка целей

Теперь проведите аудит написанных целей. Спросите — связаны ли они со стратегией вашей организации?
Если нет, попробуйте ответить на следующие вопросы:
  • Для чего существует ваша организация?
  • В чём её предназначение?
  • Какова ваша бизнес-модель? Кто ваши клиенты, и за что они вас ценят?
  • Каковы ваши конкурентные преимущества?
  • Какие вызовы стоят перед вашей компанией, и как вы планируете им противостоять?
Используйте формулу для целей:
Что нужно сделать? Как это должно быть сделано? Какие есть ограничения?
Например: «Успешно выйти на рынок Китая». Здесь:
  • Что сделать — выйти;
  • Как — успешно;
  • Ограничение — рынок Китая.

Финансовая модель и прибыль

Почему прибыль важна?
Прибыль позволяет не только обеспечивать текущую деятельность, но и финансировать развитие компании. Даже для некоммерческих организаций финансовая составляющая важна как основа для устойчивого роста.
Разговор о прибыли для разных организаций может звучать по-разному:
  • Для коммерческой компании это финансовая модель с доходами и клиентскими каналами.
  • Для некоммерческой — это работа с пожертвованиями.
Очень важно, чтобы сотрудники понимали, как финансовая модель компании связана с ее целями.
Запомните, что финансовые показатели всегда являются следствием вашей деятельности. И не могут быть целью. Любая компания мечтает удвоить или даже утроить выручку, но самое важное — это понимание рычага, за счет чего этого получится достичь. Поэтому он и должен отражаться в цели.
Пример из коммерческой сферы. Предположим, отдел продаж хочет увеличить количество оплаченных чеков. Но одного желания недостаточно. Руководителю важно сфокусировать команду на конкретных действиях, которые приведут к результату.
Например: начать работать с новым клиентским сегментом или выходить на новый рынок.

Формулируем цели с учетом финансовой модели

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

Примеры финансовых моделей

Вот несколько примеров того, как организации обеспечивают себя и растут. Речь будет про юнит экономику.
  • Юридическая фирма. Зарабатывает, взимая почасовую оплату за защиту интеллектуальной собственности клиентов. Возможность роста — увеличение количества оплачиваемых часов.
  • Некомерческая организация. Привлекает средства на исследования болезни Альцгеймера. Рост возможен за счет расширения каналов привлечения пожертвований.
  • Университет. Получает доход от платы за обучение студентов, который идет на найм преподавателей и развитие лабораторий. Рост зависит от привлечения большего числа студентов и актуальности предлагаемых курсов.
  • Государственные структуры. Финансируются за счет налогов и развивают инфраструктуру. Успех можно измерять временем, которое жители проводят в парках, и уровнем их удовлетворенности.
Каждая из этих организаций имеет свой уникальный способ финансирования, но суть остается общей: понять, за счет чего вы обеспечиваете себя и что позволяет вам расти.
Попробуйте дополнить это предложение:
Мы содержим себя за счет ____, чтобы ____.

Финансовая модель и стратегические решения

Четкое понимание финансовой модели помогает команде принимать решения, которые соответствуют стратегии и долгосрочным целям. Люди начинают осознавать:
  • Почему мы не можем позволить себе что-то сейчас.
  • Почему важно работать с определенной категорией клиентов.
Это делает решения сотрудников более сильными и стратегически обоснованными.
👉 Что сделать: Потратьте время на разработку финансовой модели. Если вы работаете в крупной компании, подключите финансовый департамент и обсудите, какие направления могут стать рычагами роста.

Возвращаемся к «Почему»

У вас есть цели на бумаге, но давайте проверим, связывают ли они вашу миссию и прибыль.
Цели:
  1. Уже зафиксированы.
  2. Пройдена первая проверка.
  3. Теперь проверим, как они связывают цель и конкретные измеримые результаты.
Важно: прибыль может быть главной целью, а может и вовсе вас не волновать. Мы говорим о цели и измерениях, которые помогают двигаться вперед.
Цели = соединение амбиций с реальностью.

Связь с вашей целью

Миссия компании есть почти у всех. Иногда она задана извне, иногда формируется командой.
Примеры миссий:
  • Решать проблему голода.
  • Производить продукты, которые служат всю жизнь.
  • Делать лучшие хот-доги в Москве.
  • Для команды: обеспечивать самое быстрое обслуживание в сети.
Вопросы для размышления:
  • Какова моя роль или роль команды?
  • Кто мои «клиенты» и как они себя ощущают?
  • Чего я ожидаю от себя и команды?
  • Перед кем мы отчитываемся, какое давление ощущаем?
Формула для определения цели:
Мы здесь, чтобы __________. Мы делаем это, потому что __________.
👉 Задание: ответьте на вопросы и заполните пробелы, чтобы уточнить своё «почему».

Устойчивость и рост

Цели часто связаны с деньгами. Даже если это некоммерческая организация, у неё наверняка есть доходные ориентиры.
Подход:
  • Переходите от мышления «прибыль любой ценой» к мышлению устойчивости и роста.
  • Подумайте: что нужно для поддержания текущего уровня и для выхода за его рамки?
Пример формулы:
Мы поддерживаем себя с помощью _________, чтобы _________.
👉 Задание: заполните пробелы, чтобы уточнить, как ваша организация поддерживает устойчивость и растёт.

Цель и прибыль

Цели помогают объединить миссию компании и финансовые результаты.
Проверьте свои цели:
1. Посмотрите на текущие цели.
2. Задайте вопросы:
  • Связана ли цель с финансовым результатом?
  • Помогает ли она расти?
3. Если ответ «нет», пересмотрите цели и добавьте то, чего не хватает.
👉 Задание: проведите анализ целей, чтобы понять, как они связаны с миссией и ростом.

Видео о мотивах от Джона Дорра

Рекомендуем видео к просмотру:
Ключевые мысли из ролика:
  • Мотивы важны. Джон Дорр рассказывает, как его вдохновил отец, который научил детей самостоятельности и дал только образование.
  • Его мотив: поехать в Калифорнию, чтобы научиться создавать компьютерные компании.
  • Цели компаний часто выражаются в цифрах (продажи, отгрузки), но без страсти они теряют смысл.
  • Чтобы достичь успеха, нужно соединить цель и внутреннюю мотивацию команды.

Вместо итога

Если вы хотите внедрить OKR, настроить систему, определить цели и ключевые метрики и слаженно работать в команде, мы в Neogenda можем помочь. Давайте начнем бесплатной консультации.
]]> OKR и MBO: В чем разница? http://neogenda.ru/blog/cfboh3afm1-okr-i-mbo-v-chem-raznitsa http://neogenda.ru/blog/cfboh3afm1-okr-i-mbo-v-chem-raznitsa?amp=true Mon, 30 Dec 2024 08:17:00 +0300 Артур Нек Краткое содержание: MBO и OKR схожи в том, что обе системы формулируют цели и позволяют...

OKR и MBO: В чем разница?

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

В чем разница между OKR и MBO

MBO («Управление по целям») и OKR («Цели и ключевые результаты») — это популярные инструменты для постановки целей, используемые высокоэффективными командами. OKR произошел от MBO, поэтому системы имеют сходства: обе подразумевают планирование желаемых результатов работы.
Однако, ключевые различия заключаются в следующем:
  • MBO фокусируется на целях, в то время как OKR добавляет шаги к их достижению.
  • OKR предлагает больше независимости для членов команды, гибкость в корректировке целей и возможность пересматривать их чаще.
Благодаря статье вы узнаете:
  • об MBO и его ключевых характеристиках;
  • чем OKR отличается от MBO;
  • почему OKR лучше подходит для смелых и амбициозных команд.

Что такое MBO

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

Особенность MBO

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

Этапы работы в MBO

1. Постановка целей для отделов. Они должны соотноситься с глобальными целями компании.
2. Определение вклада каждого сотрудника в достижение целей цикла.

Пример работы с MBO

Примеры стандартных целей в MBO:
  • Повысить продажи на 10%;
  • Разработать годовой план обслуживания клиентов;
  • Собрать $2 млн через онлайн-площадки;
  • Улучшить взыскание долгов на 15%.

Минус MBO

Система не объясняет важность той или иной цели и не предлагает подходы к их достижению. В OKR такие же цели могли бы выглядеть иначе:
  • Увеличить долю рынка в регионе за счет продаж групповых лицензий;
  • Решить проблему первого касания для возврата клиентов;
  • Доказать соответствие продукта рынку, получив инвестиции;
  • Оптимизировать процесс взыскания.

Что такое OKR

OKR («Цели и ключевые результаты») — система, разработанная Эндрю Гроувом в 1970-х годах для компании Intel. OKR помогает четко определить, что компания считает успехом.
  • Цели показывают, что нужно достичь.
  • Ключевые результаты («KR») — как отслеживать прогресс. Каждая цель сопровождается 3–5 ключевыми результатами.
В отличие от MBO, OKR чаще пересматриваются, обычно раз в квартал. Пример OKR от компании Allbirds:
O — Снизить углеродный след компании.
  • KR1 — Перейти на безотходную логистику.
  • KR2 — Компенсировать 100% выбросов углекислого газа.
  • KR3 — Сделать 25% материалов компостируемыми.
  • KR4 — Перейти на 75% биоразлагаемых материалов.
Сотрудники имеют свободу выбора, как именно достигать ключевых результатов, но стремятся к одной цели.

7 основных отличий MBO от OKR

MBO стремится избежать рисков, OKR поощряет риск.

1. В основном, MBO стремятся к стабильности и предсказуемости.

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

2. MBO фокусируется на том, что нужно сделать, а OKR еще и на том, как это сделать.

В отличие от OKR, в MBO ваш путь к достижению цели не разделен на этапы. OKR делятся на 2 части: цель и набор нескольких ключевых результатов, необходимых для ее достижения. Более того, сильные OKR добавляют к вопросам «что» и «как» еще и вопрос «почему».

3. В MBO цели приватные, а в OKR они публичные.

В MBO цели — это в первую очередь личные цели. Обсуждение целей проходит между работником и менеджером наедине. Цели в OKR, в свою очередь, видны всем участникам рабочего процесса. Такая прозрачность толкает членов команды к сотрудничеству, потому что сообща они смогут лучше структурировать деятельность компании и решить возникающие конфликты. MBO, таким образом, тесно связана с HR-отделом – ведь в этой системе достижение цели связано с компенсацией для работника.

4. Годичный цикл MBO против квартального цикла OKR

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

5. В MBO высшее руководство навязывает цели работникам и не получает обратную связь.

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

6. MBO завязана на бонусах

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

7. В MBO цели выражаются количественно, в OKR количественно и качественно

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

Преимущества использования OKR

OKR работает лучше, чем MBO, если:
  • Вы хотите сосредоточить усилия компании. В OKR работа начинается с вопроса: «Что важнее сделать в ближайшие три месяца?». В OKR лидеры не только задают направление работы, они еще и снабжают команду необходимой информацией и ресурсами.
  • Вы хотите синхронизировать каждодневную деятельность компании с ее глобальными задачами. Долгосрочные цели разбиваются на много маленьких задач. OKR помогает многим компаниям не забывать о главном.
  • Вы хотите стимулировать новаторское мышление. OKR помогает компаниям и работникам стремиться к тому, что раньше они даже не считали возможным.
  • Вы хотите иметь несколько факторов успеха. Соединяя количественные цели с качественными, OKR спасает вас от урона, который может нанести принцип «Успех любой ценой».

Как внедрить OKR

В первую очередь, вы должны четко донести до ваших коллег, что такое OKR. Поделитесь примером успеха компаний, использующих OKR. Не нужно концентрироваться на выгодах, которые получит от OKR вся компания — уточните, как это улучшит деятельность и удовлетворит потребности конкретной команды, как это поможет команде справиться со всеми возникающими трудностями.
Далее разработайте 2-3 цели, а потом добавьте к каждой из них несколько ключевых результатов. Основываясь на нашем опыте, можем сказать, что не стоит переусердствовать и придумывать кучу целей — чем меньше, тем надежнее.
Хотя многие компании уже давно работают с MBO, у OKR есть множество преимуществ — в первую очередь, гибкость и многогранность. Тем не менее, MBO отлично подходят для достижения конкретных, узких целей.
И напомним — если вашему бизнесу нужно внедрение OKR, обратитесь за бесплатной консультацией в Neogenda. Мы предоставляем разные услуги: от обучения ваших сотрудников лучшим управленческим практикам до полной реорганизации процессов вашего бизнеса.
]]> OKR — это не обычное ведение бизнеса http://neogenda.ru/blog/m23nx39hm1-okr-eto-ne-obichnoe-vedenie-biznesa http://neogenda.ru/blog/m23nx39hm1-okr-eto-ne-obichnoe-vedenie-biznesa?amp=true Mon, 13 Jan 2025 08:20:00 +0300 Артур Нек OKR — это не просто способ фиксировать задачи, а инструмент, который помогает компании расти. Однако...

OKR — это не обычное ведение бизнеса

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

Ошибка №1. Включение в OKR всех задач

Одна из распространённых ошибок при внедрении OKR — попытка использовать их для фиксации всего, что происходит в организации. Это может выглядеть так: у одной команды сформулировано пять целей, или же к небольшому числу целей привязано слишком много результатов.
Джон Дорр напоминает: OKR — это не сумма всех задач. Когда вы пытаетесь включить в OKR всё и расти повсюду одновременно, вы нарушаете стратегический подход. Например, у вас 10 продуктовых команд, и логично кажется поставить план, чтобы каждая команда обеспечила рост на Х%. Но это ошибка фокусировки. Стратегия появляется только там, где есть четкий фокус в условиях ограниченных ресурсов.
Чем меньше у вас ресурсов, тем уже должен быть фокус. Нужно понять, за счёт чего компания будет расти в первую очередь или какую проблему вы хотите решить, чтобы ускорить развитие. Цели не должны быть простой суммой задач по каждому продукту — они должны приводить к значимым прорывам.
Цели описывают то, что нужно делать иначе, что нужно изменить. Это не «бизнес как обычно», где у каждого есть свои рутинные задачи. OKR задаёт более высокий приоритет изменениям, влияющим на повседневные задачи, добавляя к ним новые, особенные.
При этом отсутствие задачи в OKR не означает, что ее не нужно выполнять. Обязательные задачи живут рядом с OKR. Главное — понять соотношение между этими категориями.
На помощь приходит инструмент «Ретроспективный анализ». Например, у вас есть обязательства перед регулятором или ключевыми клиентами. Эти задачи обеспечивают жизнеспособность компании. Но если вы будете выполнять только их, то останетесь на месте. Чтобы развиваться, важно ставить в OKR прорывные цели, направленные на создание новых продуктов или улучшение текущих.

Ошибка №2: Смешение OKR и KPI

Вторая частая ошибка — включение всех KPI в OKR.
KPI — это показатели эффективности, отражающие жизнеспособность команды. Их может быть много: от времени безотказной работы до качества обслуживания клиентов. Они формируют своего рода приборную панель, показывая, что «машина едет».
OKR же выделяет приоритетные метрики на конкретный период, которые отслеживают изменения, а не текущее состояние.
Важно определить амбициозные метрики, обеспечивающие рост, и отвязать их от премий. Например, если ваша цель — увеличить число чеков, то KPI будет отражать сам результат, а в OKR нужно включить шаги к этому, например, привлечение клиентов из нового региона.
Но важным аспектом okr является выбор ключевых показателей эффективности, которые имеют приоритетное значение, особенно в предстоящем квартале, которые отслеживают изменения, которые вы пытаетесь провести.
Помните, что ключевые показатели эффективности хороши, здорово когда они есть, но не все из них нужно поставить в ваши OKR. Нужно определить те, что обеспечат вам рычаг роста, отвязать от премирования, определить планку амбициозности и двинуться вперед. Зачастую даже не сами эти показатели стоит ставить в OKR, а те вложенные, через которые вам будет легко отслеживать изменения и понимать свое влияние. Как в примере указанном ранее: вы хотите улучшить количество оплачиваемых чеков — это KPI, но достигнете вы этого, только от привлечения клиентов с нового региона — что является вложенной метрикой и может быть поставлено в OKR.
Простой тест, который вы можете использовать, чтобы понять, согласована ли ваша работа и задачи с OKR: на следующей встрече с командой, задайтесь вопросом, влияет ли OKR на приоритеты или они формируются от чего-то другого?
В случае, если команда движется исключительно своими KPI или сосредоточена на других показателях, возможно, их и нужно сделать OKR.
Еще один кейс, когда на планировании не уделяется нужного внимания OKR или про них даже забывают.
Это сигнал к тому, что вы поставили неправильные цели на предстоящий квартал. OKR не должны быть притянутыми за уши, чтобы требовалось сверх усилие напоминать о них.
Так что теперь внимательно проверьте свой список целей, это обычные ваши задачи? обычный бизнес или они действительно отражают то, что вы хотите изменить в своей организации?

Совет: выходите за рамки

OKR описывают не то, где мы находимся, а то, где хотим быть.
Приведем пример. Маркетинговая команда отвечает за привлечение новых клиентов в отдел продаж в компании по разработке программного обеспечения. Рассматривая возможные цели, директор по маркетингу записала следующие цели:
  • Регулярно контактировать с директором по продажам.
  • Определить оптимальный процесс работы с лидами.
  • Ежеквартально увеличивать посещаемость сайта.
После пересмотра стало понятно, что это не цели, а «привычный ход вещей».
В доработке появились новые формулировки:
  • Перестроить веб-сайт для увеличения конверсии.
  • Разработать контент-план, чтобы удвоить посещаемость блога.
  • Совместно с отделом продаж создать план конверсии лидов.
С помощью этих целей директор по маркетингу выходит за рамки того, что сейчас происходит в организации, и описывает изменения, которые она хотела бы увидеть, и то, что она хотела бы сделать. Благодаря такой четкой формулировке легче найти ключевые результаты, которые позволят воплотить цели в жизнь, а также четко объяснить своей команде, что должно произойти дальше.
Даже после постановки OKR легко вернуться к привычному ведению дел, но есть несколько индикаторов, которые можно использовать, чтобы убедиться, что этого не происходит. Для проверки можете задать себе вопросы:
  • Склонны ли вы упускать наличие ОКR на командных встречах?
  • Большая часть разговоров в команде сводится к поддержанию статуса-кво?
Если это так, то вновь сосредоточьтесь на своих ОКR.
Проверьте, правильные ли у вас ОКR. Если они не кажутся важными, возможно, они таковыми и не являются.

Итоги

  • OKR — это не сумма задач, а инструмент изменений.
  • OKR и повседневные задачи могут сосуществовать.
  • Игнорирование OKR на встречах или фокус на статус-кво — сигналы, что цели поставлены неверно.
  • Проверьте: действительно ли ваши OKR отражают желаемые изменения?
]]> Три принципа внедрения изменений по Канбан методу: как изменить вашу компанию http://neogenda.ru/blog/1op7yh98m1-tri-printsipa-vnedreniya-izmenenii-po-ka http://neogenda.ru/blog/1op7yh98m1-tri-printsipa-vnedreniya-izmenenii-po-ka?amp=true Mon, 13 Jan 2025 08:21:00 +0300 Андрей Сидоренко Применяя три принципа управления изменениями по Канбан методу, вы сможете успешно вести свою команду в...

Три принципа внедрения изменений по Канбан методу: как изменить вашу компанию

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

Три принципа внедрения изменений

Какие элементы корпоративной культуры свойственны компаниям, правильно практикующим Канбан? Метод предлагает три ключевых принципа:
  1. Начните с того, что вы уже делаете.
  2. Внедряйте изменения постепенно, согласовывая их с командой.
  3. Поощряйте лидерство на всех уровнях.
Разберем каждый из принципов подробнее.

1. Начните с того, что вы уже делаете

Самый сложный путь внедрения изменений — полностью изменить прежний подход. Это создаёт у команды ощущение, что её предыдущая работа была напрасной. Такой подход воспринимается как личное нападение.
Вместо этого сохраните то, что уже работает. Анализируйте процессы, пока они происходят, а не когда исчезнут. Они появились не случайно и уникальны для вашей компании. Это позволит извлечь полезные знания и оптимизировать работу.
Канбан сохраняет существующие роли, обязанности и иерархию. Как говорил Питер Сенге, «люди боятся не изменений, а того, что их заставят меняться». Используйте этот принцип, чтобы достичь прозрачности и взаимопонимания в команде. Каждый должен знать, как компания добивается лучших результатов.

2. Внедряйте изменения постепенно

Слово «трансформация» звучит слишком драматично. Резкие изменения часто вызывают эффект джей-кривой — сначала всё становится хуже. Если сопротивление команды превысит вашу уверенность, инициатива провалится.
Вместо трансформации стремитесь к эволюции процессов. Согласовывайте нововведения с командой. Начните с маленьких изменений, не несущих риска.
Важно:
  • чтобы команда чувствовала себя причастной к нововведениям;
  • показать всем, что изменения действительно ведут к улучшению результатов работы.
Чтобы испробовать этот принцип на практике, начните с небольших нововведений, не несущих в себе никакого риска. Одна маленькая победа последует за другой, и тем самым вы постепенно достигните желаемого результата.
Одна небольшая победа за другой приведёт к устойчивым результатам.

3. Поощряйте лидерство на всех уровнях

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

Почему Канбан помогает

Принципы Канбан метода помогают компании адаптироваться к изменениям без стресса и потерь. Не пытайтесь изменить всё и сразу. Сохраните существующий порядок, роли и политику, а затем продвигайте идею постепенных улучшений.
Создавайте культуру, где каждый может проявить лидерство и предлагать идеи. Это обеспечит поддержку команды и приведёт вас к новым высотам. Начинайте с малого и позволяйте изменениям укрепляться — только так можно добиться успеха.
]]> Канбан для управления продуктом: пять шагов сужения воронки клиентских запросов http://neogenda.ru/blog/9vcavz57l1-kanban-dlya-upravleniya-produktom-pyat-s http://neogenda.ru/blog/9vcavz57l1-kanban-dlya-upravleniya-produktom-pyat-s?amp=true Wed, 15 Jan 2025 08:22:00 +0300 Артур Нек Уделяете ли вы внимание действительно важным аспектам рабочего процесса? Даже если у вас отлично настроен...

Канбан для управления продуктом: пять шагов сужения воронки клиентских запросов

Уделяете ли вы внимание действительно важным аспектам рабочего процесса? Даже если у вас отлично настроен процесс поставки (Downstream), это не всегда гарантирует создание ценности.
Чтобы приносить реальную пользу клиентам и превращать их запросы в рабочие элементы, важно правильно фильтровать воронку входящих запросов — в Канбане они называются «опционы». Это основа для построения Восходящего Канбана (Upstream Kanban).
Процесс Upstream всегда будет уязвимым местом при создании ценности. Баланс между спросом и возможностями является ключевым элементом для быстрого и эффективного получения результатов. Именно на это необходимо ориентироваться при выполнении каких-либо действий.
Каким же образом можно добиться такого баланса при потоке постоянно поступающих запросов от клиентов? Как управлять работой в верхней части воронки, чтобы быть уверенным в правильности принимаемых решений? Об этом — в сегодняшней статье.

Что такое Восходящий Канбан?

Восходящий Канбан (Upstream) или Исследовательский Канбан (Discovery) — это процесс, на котором Канбан-фреймворк строит создание ценности. Это этап до разработки, где проводятся исследования и принимаются решения.
Изначально концепцию описал Патрик Стюарт в своей книге «Восходящий Канбан: краткое руководство», а затем она была развита в Канбан Университете.
Для чего это нужно?
Процесс Upstream делает рабочий процесс прозрачным, что улучшает гибкость и адаптивность компании. Его цель — управлять потоком запросов до точки принятия обязательств, сохраняя понимание ценности для клиента.
В Канбане существуют две системы — Восходящая и Нисходящая. Вместе они охватывают весь процесс: от идеи до передачи результата заказчику.
Например, для команд разработчиков исследования являются неотъемлемой частью работы. Рабочий процесс по восходящему потоку должен быть видимым и явным, ведь именно это повышает гибкость бизнес-процессов компании.
Процессом по нисходящему потоку управляет команда разработчиков, в то время как процессом по восходящему потоку управляют заинтересованные стороны, которым необходимо воплотить ту или иную идею в жизнь. Представители бизнеса и команда разработчиков должны эффективно сотрудничать на протяжении всего процесса создания ценности, а также разделять общее понимание идеи и ожидаемых результатов.

5 шагов сужения воронки опционов

Чтобы выстроить эффективный процесс, следуйте этим шагам:
  1. Составьте карту исследования.
  2. Определите точку принятия обязательств.
  3. Разработайте явные политики.
  4. Вводите регулярные собрания по пополнению.
  5. Определите точку убывающей отдачи.
Рассмотрим каждый шаг подробнее.

1. Составьте карту исследования

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

2. Определите точку принятия обязательств

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

3. Разработка явных политик

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

4. Введите регулярные собрания по пополнению

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

5. Определите точку убывающей отдачи

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

Обзор курса «Канбан для дизайна и инноваций»

Налаживание рабочего процесса по восходящему потоку подробно рассматривается курсе «Канбан для управления продуктом», который проводит Алексей Пименов. Курс состоит из 6 учебных модулей, которые посвящены практическому применению Восходящего Канбана.
В статье представлена лишь малая часть тех знаний, которые можно почерпнуть пройдя курс. «Канбан для управления продуктом» — это четкий план по повышению организационной зрелости путем эволюционных изменений. Маленькие последовательные шаги обеспечивают достижение заметных улучшении за очень короткий срок, так как они не встречают никакого сопротивления.
Делать задачи — прекрасно, но это не имеет смысла, если вы не уделяете должного внимания действительно важным аспектам рабочего процесса.
В большинстве случаев использование Канбан-метода сосредоточено на осуществлении процесса сдачи выполненной работы. Не попадайтесь в эту ловушку! Полноценное применение Канбана заключается в том, чтобы внедрить его принципы на каждом этапе рабочего процесса. Стремитесь к осуществлению рабочего процесса по восходящему потоку. Такое подход задаст верное направление к достижению устойчивой гибкости бизнес-процессов.
]]> 7 шагов к устойчивой предсказуемости http://neogenda.ru/blog/gsv27draz1-7-shagov-k-ustoichivoi-predskazuemosti http://neogenda.ru/blog/gsv27draz1-7-shagov-k-ustoichivoi-predskazuemosti?amp=true Fri, 17 Jan 2025 08:24:00 +0300 Артур Нек Как завоевать авторитет на рынке? Как создать репутацию профессионалов? Можем ли мы и наша команда...

7 шагов к устойчивой предсказуемости

Как завоевать авторитет на рынке? Как создать репутацию профессионалов? Можем ли мы и наша команда действительно гарантировать поставку нужного объема в определенные сроки? Есть ли у нас средства для достижения цели? Ответы на эти вопросы кроются в нашем умении задавать предсказуемые сроки выполнения работ и следовать им.
Каждый раз, когда я знакомлюсь с клиентом, первым делом спрашиваю: «С какими тремя главными проблемами вы сейчас боретесь?». И чаще всего слышу один и тот же ответ: «Отсутствие предсказуемости, отсутствие предсказуемости и ещё раз отсутствие предсказуемости».
Большинство менеджеров, с которыми мы работаем, хотят, чтобы процесс оценки был легче, занимал меньше времени и действительно работал. Им важно создать систему доверия и поддержки, а не заставлять персонал работать сверхурочно, назначая дедлайны «с потолка».
Такие менеджеры стремятся к тому, чтобы их команды уверенно выполняли больше задач, с минимальным субъективизмом, добиваясь наилучших результатов. Они хотят работать в предсказуемые сроки, соответствовать ожиданиям клиентов и интересантов. Но эта проблема остается нерешенной годами.

7 шагов к устойчивой предсказуемости

Дорожная карта устойчивой предсказуемости состоит из 7 шагов, каждый из которых строится на предыдущем.

Шаг 1. Осведомленность. Запустите потоковую систему

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

Шаг 2. Оценка. Изучите текущее состояние своего потока

Этот шаг требует работы с показателями потока и аналитикой. Изучите основные метрики: сроки выполнения задач, объёмы завершенной работы и оставшиеся задачи.
Используйте инструменты с развитым аналитическим функционалом, чтобы глубже анализировать данные и понимать их природу.

Шаг 3. Улучшения. Внедрите методы постоянного улучшения

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

Шаг 4. Консистентность. Добейтесь предсказуемости через оптимизацию рабочих процессов

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

Шаг 5. Направление. Приоритезация основанная на ценностях

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

Шаг 6. Выравнивание. Эффективно управляйте зависимостями

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

Шаг 7. Предсказуемость. Делайте уверенные прогнозы поставки.

Последний шаг — использование данных для создания точных прогнозов.
Предсказуемость достигается, только если управленческие практики взяты под контроль, а система поставки стабилизирована. В противном случае прогнозы превращаются в азартную игру.
Используйте данные прошлых периодов для прогнозирования, освоив инструменты, которые обеспечат надежные результаты.
]]> Парадокс управления: когда пришло время перестать управлять людьми http://neogenda.ru/blog/8si9e3rd71-paradoks-upravleniya-kogda-prishlo-vremy http://neogenda.ru/blog/8si9e3rd71-paradoks-upravleniya-kogda-prishlo-vremy?amp=true Sun, 19 Jan 2025 07:37:00 +0300 Артур Нек Управление людьми не всегда повышает эффективность работы. Почему? Всё просто: время, проведенное за рабочим столом,...

Парадокс управления: когда пришло время перестать управлять людьми

Управление людьми не всегда повышает эффективность работы. Почему? Всё просто: время, проведенное за рабочим столом, вовсе не гарантирует продуктивности. Производительность стоит оценивать по достижениям и результатам, а не по количеству рабочих часов, отмеченных в системе учета.

История Антона: почему управление людьми может быть ошибкой

Антон был одним из бэкенд-разработчиков отдела интеграции компании. Опытный программист, командный игрок, увлеченный поиском лучших решений, он, тем не менее, никак не мог вписаться в традиционный график работы с 9 до 6.
Однажды утром Антон пришёл в 9:15 с любимым капучино и круассаном. Его босс, стоя у стола, неодобрительно постукивал по часам:
— Антон, это неприемлемо! Я не могу вспомнить, когда ты последний раз пришел вовремя.
Антон не любил подчиняться бессмысленным правилам. Он спокойно ответил:
— Что ж, и вам доброе утро. Я что-то пропустил?
Конечно, он ничего не пропустил. Его рабочий календарь был проверен накануне, электронная почта просмотрена утром, а уведомления включены. Если бы что-то требовало его внимания, он бы это знал.
Однако начальник публично отчитал Антона перед коллегами:
— Твое опоздание подаёт плохой пример. Похоже, ты не справляешься с работой!
На следующий день Антон подал заявление об увольнении.
Ошибка босса заключалась в том, что он считал, будто удержание всех на рабочих местах гарантирует успех команды. Но чрезмерный контроль ведёт в тупик.

Мотивация, стоящая за управлением людьми

Современный подход к работе не соответствует традиционной модели «управления и контроля». Вместо этого необходимо изменить традиционные стратегии и подходы к управлению, чтобы обеспечить последовательное и прогнозируемое выполнение задач.
Так почему же мы продолжаем управлять людьми? Действительно ли мы верим, что контроль и тщательное использование каждой секунды рабочего времени наших сотрудников — лучший способ максимально эффективно использовать наши инвестиции? Несмотря на то, что менеджеры часто одержимы оптимизацией рабочего времени сотрудников, такая практика фактически препятствует достижению конечной цели — оптимизации нашей общей скорости выполнения задачи.
Задайте себе вопрос:
  • Считаете ли вы своих сотрудников лентяями?
  • Считаете ли вы, что они избегают работы или она им не нравится?
  • Уверены, что их нужно постоянно контролировать, чтобы добиться результата?
Если это так, то вам предстоит решить очень серьезную проблему.
Сотрудники — это ваша команда, а не простые исполнители. Они мотивированы, дисциплинированы и хотят добиваться результатов. Управление должно базироваться на доверии, а не на микроменеджменте.

Главное условие достижения устойчивой прогнозируемости

Как достичь прогнозируемости?
  • Доверяйте командам. Перестаньте управлять людьми и начните управлять потоком работы. У сотрудников есть задачи, сроки и цели — дайте им возможность работать автономно.
  • Создайте понятную систему. Чёткая политика и рабочие процессы позволяют принимать решения на всех уровнях.
  • Поощряйте инициативу. Лидерство сотрудников помогает улучшать процессы принятия решений и добиваться стабильных результатов.

Что имеет значение в конце дня

Не важно, находятся ли сотрудники за своими рабочими столами с 9 до 6. Не имеет значения, работают ли они в офисе, дома или на Бали в одних шортах. Все, стоит заботиться, — это поддержание прогнозируемости рабочей системы.
Ваша задача как лидера — убирать препятствия и помогать команде достигать целей.
Клиенты остаются с вами не из-за того, сколько времени вы работаем, а из-за уровня прогнозируемости, который вы им предоставляем.
Пока работа выполняется вовремя и качественно, команда будет достигать своих целей. Нет необходимости отслеживать часы. Практика отслеживания рабочего времени бесчеловечна и унижает их достоинство.
Я верю в создание благоприятной организационной культуры. Я верю, что люди хотят приходить на рабочее место, которое больше похоже на объединение, на рабочее место, где они могут быть среди друзей, где они могут проявить себя полностью.
Лидер должен вдохновлять, а не контролировать. Ваши сотрудники должны чувствовать, что руководитель стоит за ними и всегда готов поддержать. Это — сильнейший стимул.

Итог: управление потоком, а не людьми

Роль управления в будущем — не контроль, а создание условий для продуктивной работы. Управляйте процессами, вдохновляйте команды и создавайте значимый опыт — для сотрудников и клиентов.
]]> Всё ли Скрам-доска говорит о гибкости компании? http://neogenda.ru/blog/kb863k9js1-vsyo-li-skram-doska-govorit-o-gibkosti-k http://neogenda.ru/blog/kb863k9js1-vsyo-li-skram-doska-govorit-o-gibkosti-k?amp=true Tue, 21 Jan 2025 07:39:00 +0300 Артур Нек Однажды в разговоре с участниками...

Всё ли Скрам-доска говорит о гибкости компании?

Процесс накопления знаний в доминантных активностях
Однажды в разговоре с участниками Скрам-команды мы обсуждали подход к работе как процесс накопления знаний. Один из разработчиков, немного задумавшись, отметил:
— Но это ведь похоже на Водопад! Мы же практикуем Agile, а делаем всё то же самое в спринтах.
Во время одной из моих последних бесед с участниками Скрам-команды о представлении работы как процесса «накопления знаний» один из разработчиков, как многие до него, заметил: «Но это же очень напоминает Водопад! Мы же практикуем Agile, при этом мы делаем всё то же самое в спринтах».
После чего он накидал прототип их доски:
«Во время планирования спринта, — пояснил он, — мы выбираем истории, которые в него войдут, и формируем к каждой список подзадач. На доске каждая история получает отдельную строку, и то, что необходимо для выполнения одной истории, отображается в графе “Выбрано”.
Непосредственно во время работы мы переставляем задачи сначала в графу “В работе”, а после, когда выполним их, — в графу “Выполнено”. Когда все задачи оказываются в “Выполнено”, историю можно считать завершённой. Как видите, мы можем параллельно выполнять разные типы задач: разработку, тестирование и бизнес-анализ».

С чего всё началось…

— Интересно, — констатировал я, — а откуда берутся истории?
— Конечно, из Бэклога, — ответил разработчик.
Я взял маркер и добавил в таблицу новую колонку:
— Получается, мы можем и Бэклог поместить в отдельный столбик?
— Да, кажется, можно и так.
— Хорошо. Но как всё же там появились истории?
— Мы создаём их во время груминга, — начал он объяснять. — Когда у владельца продукта появляется новая идея или формируется требование, мы создаём Эпик в Бэклоге.
Два раза в неделю мы проводим груминг-встречи, где обсуждаем новый Эпик и делим его на истории. У нас есть «Критерии готовности к разработке», которые определяют максимальный размер истории, подходящий для спринта. Также есть «Критерии приемки», которые нужно определить, прежде чем история попадет в релиз.
Я снова взял маркер:
— Может, тогда представим это так?
— Ещё, — добавил он, — после груминга, но до планирования спринта, мы дорабатываем макеты для UI с UX-командой. Это тоже часть критериев готовности.
— Хорошо, понял. Добавим:

Что происходит с выполненными историями

— Истории в графе «Выполнено» уже доступны пользователям?
— Нет, не сразу. Мы выпускаем готовый продукт раз в месяц. До этого истории остаются в графе “Выполнено”, пока не начнётся регрессионное тестирование. Когда проблемы устранены, мы выпускаем продукт.
Я добавил в таблицу:

Feature toggle: включение фич для пользователей

— Часто вы выпускаете фичи для ограниченного круга пользователей?
— Да! Обычно это пилотные версии, видимые только членам команды. Если всё работает, мы включаем фичу для всех.
— То есть как? Нужно нажать кнопку?
— Процесс не автоматизирован, но несложный. Меняем настройки конфигурации и тестируем продукт.
Я добавил ещё один пункт:

Рабочий процесс от начала и до конца: действительно ли это напоминает Waterfall?

В конце разговора таблица выглядела так:
То, что начиналось как упрощенное описание, стало отражать весь процесс. Жизненный цикл продукта стал прозрачным.
Замечание разработчика, что процессы происходят «в голове», частично верно, но не описывает всей картины. Гибкие команды переключаются между дисциплинами, что нужно для успешного создания ПО.
Работа начинается до спринта и продолжается после, что делает процесс совместным. Определенные виды активности — ключевые, остальные — второстепенные.

Определение гибкости компании

Гибкость команды нельзя определить, просто взглянув на доску. Она зависит от:
  • Частоты перехода эпиков между этапами;
  • Скорости реализации и предсказуемости;
  • Частоты релизов фич.
Но главное — насколько процессы удовлетворяют потребности потребителей, пользователей и акционеров.
Хорошо спроектированная доска может показать слабые места и помочь компании стать гибче, если регулярно вводить изменения и анализировать результаты.
]]> Списки приоритетов не работают http://neogenda.ru/blog/vuxolxboe1-spiski-prioritetov-ne-rabotayut http://neogenda.ru/blog/vuxolxboe1-spiski-prioritetov-ne-rabotayut?amp=true Wed, 22 Jan 2025 07:44:00 +0300 Артур Нек Приоритизация — это примитивный инструмент, который не соответствует потребностям сложной и динамичной организации. Причина кроется...

Списки приоритетов не работают

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

Почему списки приоритетов неэффективны?

Бывало ли у вас такое: вы создаете приоритезированный список задач, но в итоге не приступаете к выполнению задач из его нижней части? Выполненные пункты кажутся случайными, а связь между задачами теряется? Возможно, позже начатая работа вытесняет более важные задачи?
Проблема в том, что приоритезированный список объединяет множество факторов, которыми нужно управлять, в одном месте. Однако он не предоставляет всей информации, необходимой для работы в сложной среде.
Как решить проблему? Разделите список на четыре составляющие

1. Удачные опционы

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

2. Принятие обязательств

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

3. Класс обслуживания

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

4. Распределение мощности

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

Вывод

Приоритезированные списки скрывают ключевую информацию, необходимую для управления в динамичной среде. Чтобы эффективно достигать целей организации, пора отказаться от стандартного списка и использовать четыре рычага управления. Эти рычаги работают в разное время и требуют участия разных людей, так как их использование зависит от текущих условий и доступа к информации.
]]> Покер планирование: как оценить сложность задачи http://neogenda.ru/blog/pro73ai1t1-poker-planirovanie-kak-otsenit-slozhnost http://neogenda.ru/blog/pro73ai1t1-poker-planirovanie-kak-otsenit-slozhnost?amp=true Thu, 23 Jan 2025 07:48:00 +0300 Если в компании всем надоели обычные встречи — попробуйте Planning Poker (покер планирование), которое проводится...

Покер планирование: как оценить сложность задачи

Если в компании всем надоели обычные встречи — попробуйте Planning Poker (покер планирование), которое проводится с помощью карт и напоминает игру в покер. Суть простая: участники проекта собираются вместе и с помощью карт оценивают сложность проекта. Это помогает понять, сколько времени и усилий потребуется на выполнение каждой задачи.
Как провести покер планирование — рассказываем в статье.
А внедрить современные управленческие практики в ваш бизнес поможет Neogenda. Обучили уже более 5 000 сотрудников Tinkoff, Яндекс, Авито, Сбер и других компаний. Оставьте заявку на бесплатную консультацию, и в формате Zoom-встречи мы подберем подходящее решение, чтобы повысить эффективность вашей команды.
Покер планирование — способ провести встречу с элементами геймификации

Когда нужно проводить покер планирование

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

Как проводить сессию покер планирования

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

Этап 1: подготовка

Ведущий выбирает задачи, которые нужно оценить. Приглашает всю команду разработки: программистов, тестировщиков, дизайнеров и других специалистов, которые работают над проектом.
В начале игры ведущий раздает каждому участнику колоду карт, которые выглядят как обычные покерные карты. Только вместо мастей и цифр на них — числа. Бывает несколько последовательностей чисел – перечислим основные.
Стандартная нумерация от 1 до 9 (и далее при необходимости).
Стандартная нумерация
Последовательность Фибоначчи, где первые числа — 0, 1 и 2, а каждое следующее — сумма двух предыдущих.
Нумерация Фибоначчи
Модифицированная последовательность Фибоначчи, где до числа 13 идет обычная последовательность Фибоначчи, а затем числа округляются.
Нумерация Фибоначчи с округлением
Использовать можно любую последовательность. Но в обычной есть недостаток — сложность задачи интерпретировать труднее. Все потому, что разница между цифрами небольшая и сложность проекта можно ошибочно занизить. Например, разница между 8 и 9 небольшая и подсознательно кажется, что задача не такая сложная.
А последовательность Фибоначчи лучше подчеркивает сложность, ведь между 8 и 13 разница более заметна подсознательно.
Каждое число в последовательности — это возможная оценка сложности задачи в Story Points.
Story Points (SP) — условные единицы сложности. Они нужны, чтобы сравнивать трудность разных задач между собой. Ведь одно дело — поправить кнопку на сайте, и совсем другое — написать личный кабинет с нуля.
Чтобы стало понятнее, вспомните калории — универсальную меру энергетической ценности пищи. Они позволяют сравнить между собой ценность бутерброда с мясом, яблока и стакана газировки.
Зная калорийность блюд, можно составлять сбалансированный рацион и контролировать вес.
Так же и с задачами в проекте. Одни измеряются в часах, другие — в строках кода, третьи — в количестве экранов. Чтобы сравнивать их было удобнее, нужно перевести все в SP.
Чем больше SP имеет задача, тем она сложнее. Например, поправить кнопку — это 1 SP. Сверстать несложную страницу — 3 SP. А сделать мобильное приложение — 50 SP.
Кроме чисел в игре есть дополнительные карты:
  • Бесконечность (∞) — задача глобальна и ее трудно оценить. Нужно разбить на более мелкие.
  • Знак вопроса (?) — нужны дополнительные вводные или участник не может ответить.
  • Чашка кофе (☕) — нужен перерыв.

Этап 2: встреча

Менеджер зачитывает первую задачу. Все слушают и прикидывают ее сложность. Затем каждый выбирает карту с подходящей оценкой и кладет ее на стол рубашкой вверх. Важно положить именно рубашкой вверх, чтобы остальные сотрудники не видели оценок друг друга и не подстраивались под чужое мнение.
Когда все определились, карты вскрываются. Оценки сравнивают между собой. Если они сильно разнятся, команда обсуждает причины. Те, кто дал самую низкую и высокую оценку, объясняют свою логику.
Допустим, команда обсуждает задачу «Добавить функцию поиска в приложение». Все выкладывают карты, и получается такой разброс: 2, 4, 5, 5, 13. Разработчик, который выбрал 13, должен обосновать свое мнение.
Он говорит, что поиск — это не просто строка ввода. Чтобы все корректно работало, нужно настроить индексацию данных и обработку языка запросов. Сделать так, чтобы поиск выдавал подсказки, учитывал опечатки и так далее.
Остальные участники слушают его аргументы и задают уточняющие вопросы. Может оказаться, что они просто не учли эти нюансы в своих оценках. Или, наоборот, у них есть идеи как упростить реализацию. В любом случае, завязывается дискуссия, которая помогает лучше разобраться в задаче.
То же самое происходит и с низкими оценками. Если кто-то поставил карту 2, то объясняет, почему он считает задачу такой простой. Возможно, он знает готовую библиотеку или фреймворк, который возьмет на себя большую часть работы. Или у человека уже есть опыт решения подобных задач и он знает короткий путь.
Затем проводится второй раунд. Все снова выбирают карты и вскрывают их. Скорее всего, в этот раз оценки будут ближе друг к другу, потому что сотрудники уже обменялись мнениями и увидели задачу с разных сторон. Раунды продолжаются, пока вся команда не придет к единому мнению.
А также — пока не кончатся все задачи, которые нужно оценить.
Цикл игры в покер планирование

Этап 3: составление и оценка задач бэклога

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

Где попробовать покер планирование

Можно заказать колоду карт и играть оффлайн. А можно запустить игру онлайн. Например, на Planningpoker.com, planningpokeronline.com, planningpoker.ru или planITpoker.com. На платных тарифах можно добавлять неограниченное количество пользователей и интегрироваться с Jira.

Преимущества покер планирования

✅ Покер планирование вовлекает всю команду в оценку задач. Часто сложность и длительность проекта оценивает только менеджер проекта или тимлид. Здесь же учитывается мнение каждого участника: программиста, тестировщика, дизайнера, копирайтера и др. Это полезно по двум причинам:
  • Разные люди могут по-разному понимать и интерпретировать требования к задаче. То, что одному кажется простым и очевидным, для другого может быть сложным и непонятным.
  • В команде могут быть специалисты с разным опытом проведения экспертизы. Например, Senior-разработчик, который уже сталкивался с подобными задачами, и Junior, который будет делать это впервые. Их оценки одной и той же задачи могут сильно отличаться.
Обе причины не поставят проект под угрозу, потому что специалисты узнают мнение друг друга на встрече, объяснят свое видение и придут к среднему значению.
✅ Метод снижает влияние «эффекта якоря». Эффект якоря означает, что первая озвученная информация (в нашем случае оценка) непропорционально влияет на последующие суждения.
Представьте, что вы проводите совещание по оценке задач. Менеджер проекта или тимлид описывает первую задачу и просит каждого высказать свое мнение. Первым выступает Senior-разработчик и говорит, что задача простая и займет не больше 4 часов. После этого остальные участники, скорее всего, будут отталкиваться от этой оценки. Даже если изначально они думали иначе, они могут подстроиться под мнение более опытного коллеги.
Из-за этого оценки могут получиться смещенными. Менее опытные разработчики будут ориентироваться на сеньоров, даже если те ошиблись. А люди, чье мнение отличается от большинства, могут побояться высказаться, чтобы не выделяться.
В покер планировании эффекта якоря нет, потому что никто в команде не знает чужое мнение до момента, пока карты не перевернут цифрой вверх.
✅ Покер планирование помогает лучше разобраться в задаче. Польза в том, что сотрудники не просто получают задачу от продакт-менеджера и прикидывают длительность работы в голове. Они обсуждают задачу всей командой и приходят к общему мнению по срокам работы.
Стандартная встреча без покер планирования

Недостатки покер планирования

❌ Покер планирование может затягиваться. Иногда обсуждения превращаются в долгие споры. Это отнимает много времени у команды и вместо работы над задачами люди тратят часы на оценку.
❌ В команде могут быть слишком активные участники. Те, кто часто говорят громче и увереннее других. Такие люди могут влиять на мнение коллег, давить на других авторитетом и снижать объективность оценок.
Для успешного покер планирования нужен опытный ведущий. Он должен уметь управлять обсуждением и решать конфликты. Без хорошего модератора встречи могут стать хаотичными. Найти такого специалиста бывает непросто.
❌ Иногда у команды не хватает информации или опыта. Например, если заказчик даст не всю информацию или продакт-менеджер забудет о чем-то важном. В таких случаях команда может неправильно оценить проект и заложить слишком мало времени или ресурсов.

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

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

Альтернативы покер планированию

Вместо покер планирования можно попробовать другие методики:
  • T-shirt sizing;
  • метод 100 долларов.
T-shirt sizing расшифровывается как «размер футболки». Смысл в том, чтобы сравнить сложность задач с размерами одежды: XS, S, M, L, XL. Вот что они означают:
  • Самая простая задача — XS. Например, исправить опечатку в тексте на сайте. На это уйдет до часа работы.
  • S — задача посложнее. Например, добавить новое поле в форму обратной связи. Для выполнения понадобится больше времени, поэтому размер задачи — S.
  • M — еще сложнее. Допустим, настроить интеграцию с платежной системой. Это может занять 2–3 дня.
  • L — более трудоемкие задачи. Например, разработать одностраничный сайт. Тут может уйти неделя или полторы.
  • XL — самые масштабные проекты. Вроде создания личного кабинета пользователя или мобильного приложения. Это может занять целый спринт, а то и парочку.
Метод 100 долларов тоже отлично подходит для расстановки приоритетов. Работает просто: представьте, что у вас есть 100 долларов, которые вы должны распределить между задачами. Чем важнее задача, тем больше денег вы на нее выделите. Чем больше денег выделено на задачу, тем больше ресурсов и времени нужно выделить на решение.

Что в итоге

Planning Poker (покер планирование) — техника оценки сложности и трудоемкости задач в проектах. Она помогает команде понять, сколько времени и усилий потребуется на выполнение каждой задачи.
Покер планирование стоит использовать, когда запускаете новый продукт, меняете задачи или старые метрики перестали работать.
Этапы покер планирования: подготовка, встреча и обсуждение, составление бэклога.
Покер планирование вовлекает всю команду в процесс обсуждения задачи, снижает эффект якоря и помогает лучше разобраться в задаче.
Недостатки покер планирования: обсуждение может затягиваться, а иногда точно оценить задачу не получится из-за нехватки информации или опыта.
]]> MVP: как проверить идею и сократить риски бизнеса http://neogenda.ru/blog/ag12ez7ka1-mvp-kak-proverit-ideyu-i-sokratit-riski http://neogenda.ru/blog/ag12ez7ka1-mvp-kak-proverit-ideyu-i-sokratit-riski?amp=true Tue, 28 Jan 2025 07:52:00 +0300 Артур Нек В сфере разработки продуктов важно не тратить впустую время с другими ресурсами. Именно поэтому концепция...

MVP: как проверить идею и сократить риски бизнеса

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

Что такое MVP

Аббревиатура MVP означает Minimum Viable Product — минимально жизнеспособный продукт. То есть вариант продукта с элементарным набором функций, которого хватит для выполнения его основной задачи. Цель MVP — без промедлений проверить работоспособность идеи в настоящей жизни, собрать обратную связь от пользователей и оценить перспективы проекта.
Важно понимать, что MVP — не просто упрощенная версия конечного продукта, а инструмент для тестирования. Он позволяет экономить ресурсы и сосредотачиваться на возможностях, которые на самом деле нужны людям.

Почему создание MVP важно для благополучного развития бизнеса

MVP помогает заложить прочный фундамент для правильного развития бизнеса. Вот почему эта методика играет такую важную роль:
1. Экономия ресурсов, в том числе времени. Чтобы создать полноценный продукт с разными опциями, нужны значительные инвестиции. MVP позволяет сфокусироваться на базовых функциях, которые станут наиболее ценными для ЦА. Это сокращает время на разработку — можно быстрее тестировать идею в реальных условиях.
2. Проверка гипотез и сведение рисков к минимуму. Бизнес часто строится на гипотезах о том, что нужно клиенту. MVP-тестирование помогает проверить работоспособность идеи перед тем, как ее начнут масштабировать. При таком подходе ниже риск запустить продукт, который может оказаться неактуальным.
3. Сбор обратной связи от пользователей. Минимально жизнеспособный продукт позволяет компаниям на ранних этапах получать обратную связь от целевой аудитории. Эти данные помогают понять, что действительно важно для клиентов, какие функции стоит развивать, а от каких лучше отказаться. Такой подход делает развитие продукта более точным и адаптивным.
4. Быстрый выход на рынок. MVP помогает компаниям представить рабочий продукт в кратчайшие сроки, чтобы обойти конкурентов. Это позволяет занять нишу на рынке до того, как появятся аналогичные решения.
5. Проверка бизнес-модели. MVP — это не только способ протестировать функции, но и возможность оценить жизнеспособность бизнес-модели в целом. Например, если компания создает продукт с подписной системой, тестирование MVP покажет, готовы ли клиенты платить за предлагаемый сервис.
6. Гибкость в развитии продукта. MVP дает возможность адаптироваться к запросам рынка и пользователей. На основе полученных данных компании могут менять направление разработки, корректировать стратегию и внедрять новые функции, которые отвечают потребностям клиентов.
7. MVP: примеры успеха. Многие крупные компании начинали с MVP. Первые версии таких гигантов, как Airbnb и Dropbox, были простейшими продуктами, которые лишь частично выполняли заявленные функции. Однако, благодаря ранней обратной связи и гибкому подходу эти компании смогли развить свои идеи до уровня мировых лидеров.

В чем разница между MVP и PoC

При разработке нового продукта часто используют и MVP (Minimum Viable Product), и PoC (Proof of Concept). Хотя оба подхода нацелены на проверку идеи, их цели – масштаб и методы отличаются.
PoC (Proof of Concept) — это «доказательство концепции», процесс или прототип, который нужен, чтобы проверить жизнеспособность идеи или технологии. При этом его создают не для взаимодействия с конечным пользователем. Задача PoC состоит в том, чтобы подтвердить, что технологию или метод можно реализовать на практике.
Основные отличия между PoC и MVP
Отличие PoC MVP
Цель Проверить, возможно ли технически реализовать идею. Это исследовательский этап, который часто фокусируется на технических аспектах Проверить, востребована ли идея на рынке. Это базовая версия продукта для взаимодействия с целевой аудиторией
Аудитория Исключительно внутренняя команда или инвесторы. PoC редко предоставляется конечным пользователям Тестирование на реальных пользователях и сбор обратной связи
Объем разработки Ограничен одной функцией или техническим решением, чтобы подтвердить возможность реализации Включает базовый набор функций, достаточный для выполнения ключевой задачи
Результат Отвечает на вопрос «это возможно?» Отвечает на вопрос «это нужно пользователям?»
Чтобы правильно использовать PoC и MVP в разработке, важно понимать, что эти подходы не исключают друг друга, а работают в связке:
  • Начните с PoC. На первом этапе убедитесь, что идея жизнеспособна с технической точки зрения. Решите, какие ресурсы и технологии потребуются для ее реализации.
  • Перейдите к MVP. После подтверждения концепции создайте минимально жизнеспособный продукт, чтобы протестировать его на реальных пользователях и получить обратную связь.
  • Синхронизируйте цели. Четко определите, какой этап разработки вы проходите, чтобы не смешивать задачи и результаты.
Правильное понимание различий между MVP и PoC помогает эффективно планировать разработку продукта, минимизировать риски и выводить на рынок востребованные решения.

Какие существуют типы минимально жизнеспособных продуктов

Разработка MVP может выполняться разными способами в зависимости от целей проекта, потребностей целевой аудитории и особенностей рынка. Minimum Viable Product — это не универсальный шаблон, а гибкий подход, который можно адаптировать под конкретные задачи. Рассмотрим основные типы MVP и их особенности:
  • Консьерж-MVP
Предполагает, что ключевые функции продукта будут выполнять вручную, без использования сложных технологий. Этот подход помогает проверить, готовы ли пользователи платить за услугу или решение. Если да, то можно инвестировать в автоматизацию.
Пример. Первые версии Airbnb. Основатели вручную связывали владельцев жилья с гостями через простую платформу, чтобы протестировать идею аренды домов и квартир напрямую.
  • Wizard of Oz MVP («Волшебник страны Оз»)
Этот подход похож на Консьерж-MVP, но с одним отличием: пользователи не знают, что функции продукта выполняются вручную. Создается впечатление, что продукт уже работает как полноценная автоматизированная система.
Пример. Первые версии Zappos. Основатель просто фотографировал обувь из магазинов, размещал снимки на сайте, а затем покупал и доставлял товары вручную после заказа.
  • Landing Page MVP
Это простой веб-сайт, который описывает идею продукта, основные функции и преимущества. Пользователи могут оставить свои контакты или оформить предзаказ. Это позволяет оценить уровень интереса к продукту.
Пример. Dropbox. Создатели использовали видеоролик и лендинг, чтобы объяснить концепцию продукта и собрать предзаказы.
  • Пилотный проект (Piecemeal MVP)
Разрабатывают из уже существующих решений и инструментов. Вместо создания нового продукта с нуля, используют готовые платформы, плагины или сервисы для тестирования идеи.
Пример. Groupon. Первые версии сайта использовали простые PDF-документы и готовые системы рассылки для организации групповых скидок.
  • Прототип MVP
Это базовая версия продукта, которая показывает его возможности и дизайн, но не всегда полностью рабочая. Прототип используют, чтобы продемонстрировать продукт инвесторам или потенциальным клиентам.
Пример. Первый iPhone от Apple был представлен как прототип, который показывал основные функции устройства.
  • Мобильное приложение или веб-сервис с базовыми функциями
Предполагает создание минимальной рабочей версии программного обеспечения с одной или двумя ключевыми функциями.
Пример. Первые версии ВКонтакте позволяли пользователям только создавать профиль и добавлять друзей. Не было множества дополнительных функций, таких как видеозвонки, игры и реклама.

Как выбрать подходящий тип MVP

Чтобы выбрать оптимальный тип MVP, нужно учитывать несколько факторов:
  • Цели проекта: вы хотите проверить идею, собрать данные или продемонстрировать продукт?
  • Ресурсы: у вас есть время и средства на разработку или лучше обойтись готовыми решениями?
  • Целевая аудитория: кто будет тестировать ваш продукт — пользователи, инвесторы или команды внутри компании?
Подход к созданию MVP должен быть гибким, чтобы закрывать конкретные задачи бизнеса. Каждый тип минимально жизнеспособного продукта помогает быстрее и эффективнее проверить идеи. А это ключевой шаг к созданию успешного решения.

Как создать и протестировать MVP

Эффективное создание MVP продукта — это несколько важных шагов:

Определите целевую аудиторию

Прежде чем приступать к разработке MVP, необходимо точно понять, кто будет использовать ваш продукт. Для этого:
  • Изучите, кто уже решает аналогичные задачи и как пользователи взаимодействуют с подобными продуктами.
  • Определите, кто ваш идеальный клиент. Это может быть описано через демографические характеристики, поведение, потребности и боли.
  • Выявите конкретные проблемы и задачи, которые эта аудитория сможет решить с помощью вашего продукта. Важно, чтобы MVP решал хотя бы одну значимую проблему целевой группы.

Выделите базовые функции

После того как определились с целевой аудиторией, нужно выделить те функции, которые будут наиболее важными для решения проблемы пользователей. Это базовые элементы для MVP. Чтобы правильно выбрать функции:
  • Проанализируйте все возможности, которые могут быть в финальной версии продукта. Отметьте те, которые прямо влияют на решение основной проблемы.
  • Исключите дополнительные опции, которые не критичны для базового решения. Их можно будет добавить позже, после тестирования и получения обратной связи.
  • Помните, что MVP предполагает минимализм. Чем меньше функций, тем проще будет протестировать идею и получить результаты.
Самое важное — сосредоточиться на главной задаче, которую ваш продукт должен решить.

Разработайте MVP

Точно определили, что будете делать? Можно приступать к разработке самого MVP. Этот этап нужно четко планировать и реализовывать по шагам:
  1. Проектирование и прототипирование. Начните с создания прототипа, который покажет, как продукт будет работать на базовом уровне. Его можно сделать простым, например, в виде макета в Figma. Главное — продемонстрировать основные функции.
  2. Выбор технологий и инструментов. Определите, какие технологии будете использовать. Это может быть как разработка с нуля, так и использование готовых платформ, например, чтобы сделать сайт или приложение.
  3. Создание базовой версии. Сделайте рабочую версию с минимумом функций, которые должны решать проблему пользователя.
  4. Тестирование внутренними пользователями. Прежде чем выпускать MVP на рынок, протестируйте его внутри команды или с участием небольшого круга доверенных людей. Это поможет выявить очевидные ошибки и улучшить продукт до его запуска.

Проведите тестирование MVP и проанализируйте обратную связь

Когда MVP готов, наступает важный этап тестирования. Здесь важно собрать как можно больше данных и отзывов от реальных людей, чтобы понять, насколько продукт решает их проблему:
  • Запустите MVP для ограниченного числа пользователей. Это может быть небольшой сегмент целевой аудитории или группы тестировщиков, которые готовы взаимодействовать с вашим продуктом.
  • Активно собирайте отзывы пользователей через анкеты, интервью или аналитические инструменты. Задавайте вопросы, чтобы узнать, что люди думают о продукте, какие функции им нужны, что не работает и как они используют продукт.
  • На основе собранной информации проведите анализ. Какие функции были наиболее востребованы? Какие проблемы не удалось решить? Это поможет понять, что необходимо улучшить в следующей версии.
  • С помощью полученной обратной связи адаптируйте продукт. Возможно, потребуется добавить новые функции, улучшить те, которые уже есть или даже изменить ключевые аспекты продукта.

Что в итоге

Создание MVP — это важный шаг на пути к успешному запуску нового продукта. Так, можно минимизировать риски, протестировать идеи и получить обратную связь от пользователей. При таком подходе легче создать востребованный продукт, который решает реальные задачи аудитории и увеличивает шансы компании на успех.
Чтобы на этом не останавливаться и внедрить современные подходы к управлению и развитию бизнеса, обратитесь в Neogenda. Мы специализируемся на обучении сотрудников, перестройке процессов и адаптации таких инструментов, как Канбан, OKR, Agile и Scrum, под ваши задачи. Наши клиенты — крупные компании, например Сбер, Яндекс и X5 Group. Опытные специалисты Neogenda помогут вам улучшить показатели и добиться значимых результатов. Начните изменения с бесплатной консультации — узнайте, какие шаги будут наиболее эффективными для вашего бизнеса.
]]> Все о регламентах: зачем нужны, как написать и внедрить в бизнесе http://neogenda.ru/blog/sn4t9sd0p1-vse-o-reglamentah-zachem-nuzhni-kak-napi http://neogenda.ru/blog/sn4t9sd0p1-vse-o-reglamentah-zachem-nuzhni-kak-napi?amp=true Tue, 28 Jan 2025 08:02:00 +0300 Артур Нек Регламент — один из ключевых инструментов для организации бизнес-процессов и эффективной работы команды. В крупных...

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

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

Что такое регламент

Регламенты — это внутренние нормативные акты, которые описывают порядок выполнения процессов, взаимодействие между сотрудниками и правила работы в организации. Их основная цель — обеспечить слаженность, эффективность и предсказуемость в деятельности компании.
Регламент нужен тем компаниям, которым важно стандартизировать и создать четкую структуру процессов, минимизировать ошибки. Это особенно актуально, когда работает много сотрудников или отделов.
Можно сказать так: регламент — это, простыми словами, набор правил и принципов, которые помогают компании работать по единому стандарту. Он определяет, как именно выполняются ключевые процессы, кто за что отвечает и какие шаги важно соблюдать.
Чем регламент отличается от инструкции? Несмотря на схожесть, это разные понятия.
Регламент описывает общий порядок выполнения процессов и взаимодействий. Он может включать цели, основные этапы, участников и их зоны ответственности. А инструкция — это подробное описание конкретных шагов, которые нужны для выполнения задачи.
Пример регламента — документ, который определяет, как отдел продаж взаимодействует с отделом логистики при оформлении заказов. При этом инструкция будет описывать пошаговые действия сотрудника для оформления документа в CRM-системе.

Зачем нужен регламент

Регламенты позволяют создать систему, в которой каждый участник знает свои обязанности и четко понимает что нужно делать. В управлении бизнесом без этого сложно. Вот несколько основных задач, которые выполняют регламенты в компании:
  • Систематизация процессов. Регламенты позволяют упорядочить бизнес-процессы и устранить хаос в работе компании.
  • Повышение эффективности. Когда процессы заранее стандартизированы и прописаны, сотрудники могут быстрее выполнять задачи и не терять времени на уточнения.
  • Снижение рисков. Регламент работы помогает избежать ошибок, которые связаны с человеческим фактором.
  • Упрощение контроля. Руководству проще следить за тем, как выполняются задачи, потому что регламент четко описывает, что и как нужно делать.
  • Адаптация сотрудников. Благодаря регламентам новые сотрудники могут быстрее освоиться в коллективе и понять, чего от них ждут.

Какие проблемы решает регламентация

Регламенты работы сотрудников помогают компании преодолеть такие проблемы:
  • Непонимание обязанностей. Без регламентов сотрудники могут не понимать свою роль и область ответственности, а это приводит к путанице и дублированию задач.
  • Потеря времени. Без четкой структуры команда может тратить время на поиски информации или долго выяснять как выполнить задачу. Регламенты помогают избежать таких ситуаций.
  • Низкое качество работы. Если нет стандартов, задачи будут выполняться по-разному, а это снижает качество работы.
  • Зависимость от конкретных сотрудников. Без регламентов компания может сильно зависеть от знаний и опыта отдельных работников, которые когда-нибудь могут уйти в другое место.
  • Конфликты и недоразумения. Отсутствие четкого распределения ролей и задач может привести к конфликтам между сотрудниками и отделами, а это в любом случае мешает развитию бизнеса.

Какие виды регламентов существуют

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

Административные регламенты

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

Технические регламенты

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

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

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

Из каких элементов состоит структура регламента

Чтобы регламент получился эффективным, нужна правильная структура. Рассмотрим основные элементы, которые должны быть в документе:
  • Введение. В этом разделе нужно описать цели и задачи регламента, его область применения и целевую аудиторию. Введение должно объяснять, зачем разработали этот документ и какие проблемы он решает.
  • Общие положения. Здесь должны быть определения ключевых понятий и описание принципов, на которых основывается регламент. Можно указать стандарты и нормы, которые компания будет использовать в процессе работы.
  • Цели и задачи регламента. В этом разделе нужно конкретизировать цели, которые команда должна достигнуть с помощью регламента. Здесь же определяют каких результатов ждут от его внедрения и использования.
  • Описание процесса. Этот раздел подробно описывает процесс, который регулируется регламентом — последовательность действий, этапы выполнения задач.
  • Ответственные лица и их обязанности. Здесь указывают сотрудников или подразделения, которые будут отвечать за выполнение определенных процессов. А еще указывают обязанности и зоны ответственности каждого участника.
  • Требования к документам и отчетности. В разделе прописывают требования к оформлению документов, отчетности, порядку их хранения и срокам.
  • Контроль за исполнением. Это описание того, как нужно будет контролировать соблюдение регламента. Указывают ответственных лиц, способы проверки выполнения задач, возможные санкции за нарушение.
  • Заключение и дополнения. Здесь дают рекомендации по применению регламента и уточняют как часто его будут пересматривать. Можно привести ссылки на другие нормативные акты или регламенты, с которыми связан этот.

Как пишется регламент: пошаговая инструкция

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

1. Определить цель и задачу регламента

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

2. Собрать информацию

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

3. Спроектировать структуру регламента

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

4. Написать текст регламента

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

5. Утвердить и согласовать

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

6. Внедрить

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

7. Контролировать исполнение

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

8. Обновлять и пересматривать регламент

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

Какие ошибки допускают компании при разработке регламентов

Разработка регламента — ответственный процесс. Рассмотрим распространенные ошибки, которые бывают на этом этапе и как их избежать:

Неопределенные цели и задачи регламента

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

Чрезмерная бюрократия и усложнение процессов

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

Сложный и перегруженный текст

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

Игнорирование реальных рабочих процессов

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

Игнорирование изменений и развития бизнеса

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

Недостаточное вовлечение сотрудников в процесс разработки

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

Какие у регламентов могут быть плюсы и минусы

Как и любой другой инструмент управления, регламенты имеют свои преимущества и недостатки:
Плюсы регламентов Минусы регламентов
Упорядочивание процессов и стандартов. Чтобы упорядочить рабочие процессы, регламенты стандартизируют их выполнение. Это особенно важно для крупных компаний, где множество сотрудников выполняют одни и те же задачи. Пример. В крупной компании регламент по документообороту помогает всем сотрудникам понимать, какие документы, в какой форме и с какой периодичностью нужно подготавливать. Это минимизирует количество ошибок.
Чрезмерная формализация и бюрократия. Когда регламент становится слишком детализированным, это может затруднить выполнение рабочих процессов и снизить гибкость команды. Пример. В компании регламенты стали слишком строгими, поэтому сотрудники чувствуют ограничения и работают медленнее. Потому что нужно соблюсти все правила, даже если это не всегда оправдано.
Повышение эффективности. Четко прописанные регламенты помогают сотрудникам работать быстрее, потому что они точно знают, что и как нужно делать. Пример. Регламент работы с клиентами в сфере продаж позволяет сотрудникам быстро понять как обрабатывать запросы. Это сокращает время на выполнение каждого этапа и повышает производительность.
Сложность адаптации в быстро меняющихся условиях. Регламенты могут стать обузой в условиях быстрого роста компании или динамичных изменений внешней среды. Если документ не обновлять вовремя, он может стать устаревшим и не соответствовать реальности. Пример. Если регламент, который касается маркетинга, разработали несколько лет назад, он может не учитывать новые каналы продвижения или то, как изменились за это время потребительские предпочтения.
Снижение рисков и ошибок. Регламенты снижают риски, которые появляются при нарушении внутренних процедур. А еще помогают избежать ошибок, которые могут возникнуть при неопределенности. Это особенно важно для таких процессов как финансы, безопасность и соблюдение законодательства. Пример. Регламент по технике безопасности на производстве помогает предотвратить несчастные случаи — он четко прописывает требования к охране труда и использованию средств индивидуальной защиты.
Риск излишней регламентации. Иногда компании пытаются регламентировать слишком много процессов. Даже те, которые не требуют четкого стандарта. Это может привести к перегрузке сотрудников, снижению их гибкости и уменьшению творческого подхода к решению задач. Пример. Когда компания разрабатывает регламенты для повседневных мелочей, например, как именно нужно отвечать на телефонный звонок, это может ограничить свободу сотрудников в принятии решений и снижать мотивацию.
Упрощение обучения и адаптации сотрудников. Регламенты играют ключевую роль в процессе адаптации новых сотрудников. Последние получают четкие инструкции по выполнению задач. Пример. Регламент, который описывает основные процессы компании, помогает новичкам быстрее освоиться, минимизирует время на обучение и ошибочные действия.
Необходимость постоянного обновления. Чтобы регламенты оставались актуальными, их нужно постоянно обновлять. А это усилия и время руководителей и сотрудников — то есть дополнительная нагрузка на организацию. Пример. Если компания расширяет свой ассортимент или меняет стратегию, нужно обновить множество внутренних регламентов. Все это может занять много времени и ресурсов.
Контроль и ответственность. Регламенты позволяют четко распределить роли и обязанности, а значит и установить ответственность за выполнение конкретных задач. Пример. Регламент по распределению обязанностей между отделами позволяет руководству отслеживать, кто и за что отвечает, и сразу вмешиваться, если что-то пошло не так.
Сопротивление сотрудников. В некоторых случаях сотрудники могут воспринимать регламенты как вмешательство в их работу или как дополнительную нагрузку. Это особенно актуально, если документ создают без учета мнений тех, кто будет с ним работать. Такой подход может вызвать сопротивление команды. Пример. Когда новый регламент по взаимодействию между отделами не учитывает мнения сотрудников, могут возникнуть конфликты, а сам регламент окажется неэффективным.

Как происходит внедрение регламентов в бизнес

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

1. Подготовиться к внедрению

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

2. Разработать регламент

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

3. Обучить сотрудников

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

4. Интегрировать регламент в рабочие процессы

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

5. Мониторить и оценивать эффективность

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

6. Справиться с сопротивлением сотрудников

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

Как адаптировать регламенты под особенности бизнеса

Учитывайте размер компании

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

Учитывайте отраслевые особенности

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

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

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

Учитывайте стадию развития компании

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

Взаимодействуйте с сотрудниками и вовлекайте их

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

Регулярно пересматривайте и обновляйте регламенты

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

Что в итоге

Регламенты помогают упорядочить рабочие процессы, улучшить взаимодействие между сотрудниками и повысить эффективность бизнеса. Если их правильно сформировать и внедрить, работа компании станет более прозрачной и системной.
Интеграция регламентов — это постоянный процесс, который помогает бизнесу расти, развиваться и достигать своих целей.
А если хотите внедрить современные подходы стратегического менеджмента, обратитесь в консалтинговую компанию Neogenda. Мы обучаем сотрудников, реорганизуем процессы и адаптируем Канбан, OKR, Agile, Scrum под ваши задачи. Среди наших клиентов — Сбер, Яндекс, X5 Group и другие крупные компании. Специалисты Neogenda помогут улучшить процессы и достичь целей бизнеса. Узнайте на бесплатной консультации, как начать трансформацию.
]]> Business model Lean Canvas: что это такое и как заполнить http://neogenda.ru/blog/0p3bc05p71-business-model-lean-canvas-chto-eto-tako http://neogenda.ru/blog/0p3bc05p71-business-model-lean-canvas-chto-eto-tako?amp=true Wed, 05 Feb 2025 09:48:00 +0300 Перед созданием бизнеса нужно разобраться с бизнес-моделью — планом, который описывает компанию и то, какую...

Business model Lean Canvas: что это такое и как заполнить

Перед созданием бизнеса нужно разобраться с бизнес-моделью — планом, который описывает компанию и то, какую ценность она создает. А главное — за счет чего получает прибыль.
Бизнес-модель помогает структурировать все ключевые элементы бизнеса: кто клиент, какие проблемы решает компания, как организованы доходы и расходы. Самый простой способ построить бизнес-модель на старте компании — заполнить Lean Canvas.
С его помощью можно легко тестировать идеи, быстро находить слабые места и вносить изменения в план развития. Это идеальный инструмент для стартапов и команд, которые хотят запустить успешный проект. Как работать с Lean Canvas — рассказываем в статье.
Бизнес-план — залог успешного бизнеса

Что такое Lean Canvas и чем он полезен

Lean Canvas создал Аш Маурья в 2010 году. Маурья взял за основу популярную модель бизнес-планирования Business Model Canvas Остервальда и адаптировал ее для стартапов и малых бизнесов. Основная идея была в том, чтобы упростить планирование и сосредоточиться на ключевых элементах бизнеса, которые важны на начальных этапах.
А сам Lean Canvas должен был стать инструментом, который поможет предпринимателям быстро протестировать свои идеи.

Lean Canvas vs Модель Остервальда

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

Когда лучше использовать Lean Canvas, а когда — модель Остервальда

Используйте Lean Canvas, если ваш проект находится на этапе идеи или раннего запуска. Этот инструмент помогает быстро сфокусироваться на главных деталях: кто ваш клиент, какие у него проблемы и как вы их решаете.
Допустим, стартап хочет запустить мобильное приложение для планирования задач. Lean Canvas поможет определить, какой сегмент аудитории надо обслуживать (например, фрилансеров), и какие гипотезы нужно протестировать (например, функция синхронизации с Google календарем).
Модель Остервальда лучше подходит для компаний, которые уже имеют устоявшийся рынок и хотят оптимизировать бизнес-процессы. Например, если компания управляет e-commerce проектом, модель Остервальда поможет прописать ключевые партнерства с поставщиками. Определить, какие каналы привлечения клиентов наиболее эффективны и проанализировать структуру доходов.
При этом Lean Canvas и модель Остервальда можно использовать вместе. Сначала в Lean Canvas можно сформулировать основные гипотезы. А после подтверждения гипотез перейти к модели Остервальда, чтобы углубиться в операционные детали.
Допустим, компания тестирует идею платформы для онлайн-курсов. В Lean Canvas она описывает сегмент (учителя и студенты), проблему (дорогие и сложные платформы), решение (простая и доступная платформа) и каналы продвижения (таргетированная реклама). После проверки гипотез она переходит к модели Остервальда, чтобы продумать:
  • как организовать партнерства с авторами курсов;
  • какие ресурсы понадобятся (сервера, команда поддержки);
  • как оптимизировать расходы.
Критерий Lean Canvas Business Model Canvas
Цель Быстрая проверка гипотез, фокус на запуске и итерациях Детальный анализ и планирование для устойчивого роста и масштабирования
Фокус Проблемы, решения, целевая аудитория, гипотезы Партнерства, ресурсы, операционные процессы, структура издержек
Вопросы, на которые отвечает Какие проблемы у клиента? Как их решить? Как заработать? Какие ресурсы и партнерства нужны? Как оптимизировать процессы? Какая структура доходов и затрат?
Подход к рискам Фокус на минимизацию неопределенности и тестирование гипотез Анализ существующих рисков в операционной деятельности и партнерствах
Когда использовать На этапе идеи, раннего запуска, для стартапов Для зрелых бизнесов, компаний на стадии роста или стабилизации

Как разработать Lean Canvas

Lean Canvas — это таблица, которая состоит из 9 блоков. Каждый блок — это пеработанные блоки из Business Model Canvas.
Каждый блок имеет свое название и назначение:
  1. Сегменты клиентов.
  2. Проблемы.
  3. Уникальное ценностное предложение.
  4. Решение.
  5. Каналы продвижения.
  6. Потоки доходов.
  7. Структура затрат.
  8. Ключевые метрики.
  9. Нечестное преимущество.
Эта модель используется для стратегического управления организацией, анализа и управления отдельным продуктом компании. Вот готовый шаблон Lean Canvas:
Шаблон Lean Canvas скачать
Вы можете поработать с ним в Figma. Но также подойдет и обычный шаблон для Google Таблиц:
Шаблон таблицы Lean Canvas
Все блоки шаблона лучше заполнить на мозговом штурме за 20–30 минут, не переключаясь на другие задачи. Если сотрудников много — увеличьте тайминг.
При заполнении блоков соблюдайте нумерацию. Сам шаблон можете перерисовать на листок бумаги или заполнить в любом онлайн-редакторе.

Сегментируйте клиентов

Разделите клиентов на группы по конкретным признакам. Например, при разработке платформы для email-маркетинга можно выделить владельцев малого бизнеса. Их цель — привлекать и удерживать клиентов через рассылки.
Затем создайте портрет идеального клиента. Опишите, кто он, чем занимается и что хочет получить. Например, владелец малого бизнеса работает над привлечением клиентов, вручную создает рассылки и тратит много времени на аналитику. Далее задайте себе вопросы:
  • Какую проблему он хочет решить? Например, создать профессиональную email-рассылку без навыков дизайна.
  • Что его раздражает в существующих решениях? Например, сложный интерфейс платформ или запутанная аналитика.
В результате получится что-то вроде такого: Алексей, 40 лет, владелец интернет-магазина аксессуаров. У него мало времени и нет опыта в маркетинге, но он хочет, чтобы его клиенты чаще возвращались. Ему нужна простая и интуитивно понятная платформа, которая поможет создавать рассылки за несколько минут.
Сегментация клиентов
Если пытаться делать один продукт для всех сразу, может получиться что-то непонятное. Продукт в целом будет рабочим, но не будет решать проблемы конкретных людей — пользоваться им не будет смысла.

Определите проблемы

Чтобы создать продукт, который нужен людям, необходимо понимать их реальные трудности. Для этого команда должна встать на место клиента и представить что его раздражает, мешает или огорчает.
Задача — выявить 1-3 болевые точки, которые объединяют целевой сегмент.
Чтобы выявить проблемы, на этапе брейншторминга команда анализирует типичного клиента: как он живет, что его беспокоит и почему он ищет решение. Для этого команда отвечает на такие вопросы:
  • Какие проблемы чаще всего испытывает клиент в сфере?
  • Что вызывает дискомфорт, замедляет или мешает ему достигать целей?
  • Какие альтернативные способы решения он использует сейчас?
Вернемся к примеру с платформой для автоматизации email-маркетинга. Типичный клиент сервиса — владелец малого бизнеса, который хочет удерживать клиентов через рассылки. Его проблемы могут быть такими:
  • Клиент без опыта в дизайне не знает как создать эффективные письма.
  • Существующие платформы слишком сложные и требуют много времени на настройку.
  • Трудно понять, какие рассылки работают, потому что аналитика громоздкая и непонятная.
Команда должна обсудить каждую деталь и уточнить, насколько она значима для клиента. Например, если основной барьер — сложность аналитики, можно продумать генерацию простых и наглядных отчетов о результативности писем.

Продумайте уникальное ценностное предложение

Ценностное предложение — это короткое и понятное описание, почему ваш продукт полезен клиенту. И чем он лучше продукта конкурентов.
Чтобы сформулировать ценностное предложение, начните с проблемы клиента. Подумайте, какую боль вы решаете и чем ваше решение отличается от других. Затем постарайтесь выразить это максимально коротко и ясно.
Проще всего это сделать по формуле:
«Что вы предлагаете + Для кого + Какую проблему решает продукт».
Например, «Сервис email-маркетинга с встроенными нейросетями для генерации контента».
Хорошее предложение должно быть конкретным и понятным. Избегайте абстрактных фраз вроде «высокое качество» или «лучший сервис». Лучше пишите о том, что клиент может увидеть или почувствовать.

Решите проблемы клиентов

Решение должно напрямую отвечать на ключевые проблемы клиента. Если вы определили несколько проблем, важно предложить решение хотя бы одной из них.
Чтобы описать решение, нужно использовать понятные и короткие формулировки. Придумать их можно по такой формуле:
«Что вы делаете + какую проблему решаете + как это работает».
Например:
«Мы упрощаем создание email-рассылок благодаря встроенной нейросети, которая создает контент для письма вместо вас».
«Платформа, которая сама определяет подходящее время для рассылки писем».
Если не можете определиться с проблемами и решением, попробуйте узнать о них у самих клиентов. Например, провести опросы и исследования, в которых пользователи сами поделятся своими идеями.
Когда клиент получил очередной опрос от компании
Определите каналы продвижения
Здесь нужно вернуться к портрету потенциального клиента и понять где он получает информацию. Там, где находится ваша ЦА, и нужно запускать рекламу.
Каналы можно сгруппировать по фактору. Например, платные или бесплатные. Либо их можно разделить на 3 этапа:
  1. До покупки — где клиент впервые узнает о вас (статьи, PR, вебинары).
  2. Во время покупки — как клиент взаимодействует с вашим продуктом (лендинги, демо-версии, консультации).
  3. После покупки — как вы поддерживаете интерес и повышаете лояльность (рассылки, кейсы, опросы).
Виды каналов продвижения компании
Например, если вы продаете инструмент для Agile-команд, ваша цепочка может выглядеть так: клиент видит рекламу вебинара в Telegram, проходит на сайт и скачивает бесплатный шаблон Kanban-доски. А затем получает серию писем с предложением купить полную версию инструмента.
Важно. При выборе канала продвижения учитывайте специфику продукта. Для сложных решений вроде ERP-систем, лучше работают вебинары и кейс-стадии, которые помогают клиенту разобраться с функциями. Для более простых продуктов, например, тайм-трекеров, достаточно контекстной рекламы и понятного лендинга с триальной версией.

Поймите, как вы будете зарабатывать

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

Оцените затраты

Затраты в бизнесе делятся на постоянные и переменные. Постоянные затраты не зависят от объема продаж. Например, аренда офиса или зарплаты сотрудников. Эти расходы нужны для работы бизнеса, даже если продажи временно упали.
Переменные затраты зависят от объема производства или продаж. Например, стоимости сырья, упаковки или комиссии поставщиков.

Определите ключевые метрики

Чтобы выбрать подходящие KPI, определите, какие результаты вы хотите измерить. Если запускаете SaaS-сервис, вас должны интересовать показатели удержания клиентов (Retention Rate) и средний доход на пользователя (ARPU). Если продаете товары, важны оборот и средний чек.
Не выбирайте слишком много метрик — это размывает фокус и создает лишнюю работу. Для старта достаточно 3 ключевых показателя.
Хороший KPI отвечает на три вопроса:
  1. Что измеряется? Например, количество новых клиентов за месяц.
  2. Как часто обновляется? Ежедневно, еженедельно или ежемесячно.
  3. Почему он важен? Если KPI помогает понять рост или проблему, это нужный показатель.
Для разных бизнесов подойдут разные метрики.
Тип бизнеса Метрика Описание
SaaS Ожидаемый доход (MRR) Сколько денег компания ожидает получить от подписок.
Коэффициент оттока (Churn Rate) Процент клиентов, которые перестали платить.
Пожизненная ценность клиента (LTV) Общий доход, который приносит клиент за все время использования.
E-commerce Коэффициент конверсии (CR) Процент посетителей сайта, сделавших покупку.
Средний чек (AOV) Сумма выручки от всех покупок, деленная на их количество.
Процент возвратов (Return Rate) Процент товаров, возвращенных клиентами от общего количества продаж.
Оффлайн-бизнес Движение покупателей (Foot Traffic) Количество посетителей в магазине.
Выручка от клиента (ARPU) Сумма, которую тратит один клиент за визит.
Коэффициент возвращаемости (Retention Rate) Как часто клиенты возвращаются в компанию.
Стартап Плата за действие (CPA) Стоимость привлечения одного клиента.
Процент активных клиентов (AR) Процент пользователей, начавших активно использовать продукт.
Вовлеченность (ER) Насколько часто пользователи взаимодействуют с вашим продуктом.

Найдите скрытое, нечестное преимущество

Нечестное преимущество — это то, что делает ваш продукт уникальным и выделяет его среди продуктов конкурентов. Такое преимущество можно создать за счет уникального опыта, технологий, бренда или связей.
Чтобы найти такое преимущество, задавайте себе разные вопросы:
  • Что есть только в вашем продукте, и что невозможно скопировать?
  • Есть ли у вашей команды опыт, который невозможно повторить?
  • Какие возможности вашего продукта уникальны и недоступны у конкурентов?
Как выбрать нечестное преимущество компании
Например, Slack в свое стал популярным не только благодаря функции чатов, но и благодаря простому интерфейсу. Он сразу понравился пользователям. Конкуренты могли создать похожие приложения, но им было сложно повторить весь пользовательский опыт.

Как Lean Canvas связан с бережливым стартапом и Agile-подходом

Lean Startup базируется на цикле «Идея — Тестирование — Выводы». Это означает, что вы формулируете предположения о том, как ваш продукт должен решать проблемы клиентов, проверяете их на практике и на основе полученных данных корректируете подход.
Lean Canvas значительно ускоряет этот процесс и указывает, какие аспекты бизнеса требуют проверки.
Например, в Lean Canvas вы выделяете основные проблемы клиентов, которые собираетесь решать, и уникальное ценностное предложение, которое их привлекает. Если на этапе тестирования выясняется, что клиенты не видят ценности в вашем продукте, вы возвращаетесь к этому блоку и вносите изменения. Вместо переработки всего бизнес-плана, вы корректируете лишь конкретные элементы.
Lean Canvas также связан с методологией Agile, которая строится на итерациях. Agile предполагает, что работа над продуктом разбивается на короткие циклы с регулярной проверкой результатов. Это позволяет вносить изменения по ходу работы и оперативно реагировать на обратную связь.
Lean Canvas в этом процессе выполняет роль карты, которая помогает команде видеть общий план работы. Каждый блок Lean Canvas показывает, какие задачи и приоритеты стоят перед командой.
Например, вы разработали MVP и тестируете его на ранних пользователях. С помощью Lean Canvas выяснили, что выбранный канал продвижения не привел к ожидаемым результатам. Поэтому вернулись к блоку «Каналы» и начали тестировать другой подход.

Плюсы Lean Canvas

Просто и быстро заполняется. В Lean Canvas не нужно разрабатывать длинные и сложные бизнес-планы. Вместо этого вы сосредотачиваетесь на ключевых элементах: аудитории, проблемах, решениях, доходах и затратах. И размещаете все на одном листе
Фокусируется на ключевых элементах бизнеса. В таблице Lean Canvas останется только то, что действительно важно для успеха. Например, в нее не вписывают варианты дизайна, UX и UI и т. д. Туда вносят только конкретные проблемы, способы их решения и методы заработка.
Как правильно составить Lean Canvas
Гибкий и адаптируемый. Если вы тестируете гипотезы и видите, что какие-то элементы не работают, вы просто обновляете соответствующий блок. Вам не нужно переделывать весь план — достаточно внести изменения в одном или нескольких разделах.
Помогает оценить необходимость идеи. Например, если вы не можете сформулировать уникальное ценностное предложение или выделить ЦА, возможно, саму идею о выпуске продукта нужно пересмотреть.

Типичные ошибки при работе с Lean Canvas

Слишком общие формулировки проблем и решений. Одна из самых распространенных ошибок — записывать проблемы и решения общими словами. Это делает модель бесполезной, потому что не позволяет фокусироваться на конкретных действиях.
Например, если в блоке «Проблемы» писать «Клиентам неудобно пользоваться текущими сервисами», это не даст никакой ясности. Вместо этого стоит уточнить: «Клиенты тратят больше 10 минут на поиск подходящего товара из-за неудобной навигации сайта».
Работа без тестирования гипотез. Еще одна частая ошибка — заполнять Lean Canvas, основываясь только на предположениях и не проверять их на практике. Проблемы, решения, ценностное предложение — все это гипотезы, которые нужно подтвердить.
Например, команда могла решить, что клиентам важна низкая цена. И вписала это в Lean Canvas. Но это оказалось неправдой — клиентов больше волнует скорость доставки. В итоге команда потратила бюджет на ненужные скидки, вместо того чтобы инвестировать в логистику.
Чтобы избежать этой ошибки, после заполнения Canvas проведите интервью с потенциальными клиентами, запустите тестовую рекламу или создайте MVP и соберите обратную связь. Это поможет вовремя скорректировать модель.
Не обновляют Canvas. Lean Canvas — это не статичный документ. Бизнес развивается, рынок меняется, гипотезы проверяются и уточняются. Если вы заполнили Canvas один раз и забыли о нем, модель быстро устареет и потеряет актуальность.
Каждый блок нужно регулярно просматривать. Например, раз в квартал проводить ревизию: что работает и что нужно изменить.

Что в итоге

  • Lean Canvas разработал Аш Маурья в 2010 году. Это упрощенная версия Business Model Canvas, созданная специально для стартапов. Lean Canvas помогает быстро протестировать идеи, сосредотачиваясь на ключевых аспектах: проблемах, решениях, клиентах и гипотезах.
  • Lean Canvas подходит для стартапов и начальных этапов. Он фокусируется на проблемах, решениях и гипотезах, помогая проверять жизнеспособность идей. Модель Остервальда, напротив, используется зрелыми компаниями. Она ориентирована на долгосрочную стратегию и анализирует партнерства, операционные процессы и затраты. Их можно комбинировать: сначала использовать Lean Canvas для проверки гипотез, а затем переходить к модели Остервальда для детального планирования.
  • Чтобы заполнить Lean Canvas, нужно пройтись по 9 блокам: сегменты клиентов, проблемы, уникальное ценностное предложение, решение, каналы продвижения, потоки доходов, структура затрат, ключевые метрики, нечестное преимущество.
  • Lean Canvas помогает формулировать и проверять гипотезы по циклу Lean Startup: «Идея — Тестирование — Выводы». Он также вписывается в Agile, где работа разбивается на короткие циклы.
  • Преимущество Lean Canvas в том, что он быстро заполняется. Модель сосредотачивает внимание на ключевых аспектах и легко обновляется. Этот инструмент помогает оценить необходимость идеи и позволяет быстро корректировать планы.
  • При заполнении Lean Canvas команды допускают разные ошибки: используют слишком общие формулировки, не тестируют гипотезы и не обновляют план.
Если хотите разобраться в Business model Lean Canvas лучше и разработать его для своей компании, обратитесь за помощью в Neogenda. Просто запишитесь на бесплатную консультацию, и наши эксперты помогут интегрировать модель в ваш бизнес.
]]> Что такое фреймворк SAFe и как с ним работать http://neogenda.ru/blog/eyoikktpb1-chto-takoe-freimvork-safe-i-kak-s-nim-ra http://neogenda.ru/blog/eyoikktpb1-chto-takoe-freimvork-safe-i-kak-s-nim-ra?amp=true Wed, 05 Feb 2025 10:05:00 +0300 Артур Нек SAFe — это фреймворк, который помогает координировать работу множества Agile- и не Agile-команд, управлять сложными...

Что такое фреймворк SAFe и как с ним работать

SAFe — это фреймворк, который помогает координировать работу множества Agile- и не Agile-команд, управлять сложными продуктами и интегрировать Lean-Agile подходы в компанию. Этот большой фреймворк, который состоит из 4 уровней и десятков элементов и управляется разными людьми. Его задача — скоординировать работу нескольких команд над одним продуктом.
Впервые SAFe появилась в 2011 году. С тех пор фреймворк постоянно развивается. В этой статье мы разберемся, как функционирует фреймворк SAFe, из чего он состоит и как его внедрить.
На момент создания статьи функционирует 6 версия SAFe — о ней и пойдет речь.
Графическое отображения фреймворка SAFe. Это все, из чего он состоит

Главный элемент управления в SAFe

В SAFe выделяют 2 основных компонента управления: элементы (Highlights) и события (Events). Элементы — ключевые части или особенности уровня (например, практики, артефакты, принципы), которые определяют как работает SAFe. Events — обязательные мероприятия, которые проводятся для координации работы, синхронизации команд и достижения поставленных целей.
Если упростить, то элементы — это «что важно», а события — это «что нужно сделать».
Чтобы не запутаться в количестве элементов и событий, в SAFe выделяют структурно-функциональную единицу – то, на основе чего работает фреймворк. Это называется Agile Release Train (ART).
ART — это большая команда, которая состоит из 5–12 команд поменьше. Обычно это около 50-125 человек. Все эти люди вместе работают над одним продуктом. Их цель — создать ценность для клиентов.
Например, при разработке приложения одна команда отвечает за дизайн, другая — за фронтенд, третья — за бекэнд и т. д. У каждой команды своя задача, но цель общая – выпустить приложение.
У ART есть несколько важных составляющих. Одна из них — Program Increment (PI). PI — это отрезок времени, который длится 8–12 недель.
В начале каждого PI проводится встреча, которая называется PI Planning. На встрече участвуют все команды. Их задача — обсудить что делать в предстоящем PI и решить, как они будут работать.
В конце каждой итерации проходит System Demo. На этой встрече команды показывают, что они сделали за прошедшую итерацию.
Структура ART
Получается, что в рамках ART работает несколько команд, которые постоянно коммуницируют между собой, решают задачи и оценивают чего у них получилось достичь.

Ключевые роли в SAFe

Чтобы ART работала и ценность для клиентов создавалась, в SAFe выделили ключевые роли – людей, которые отвечают за работу отдельных команд и разработку продукта в целом.
Ключевых ролей несколько:
  • Release Train Engineer (RTE) — человек, который отвечает за слаженную работу всего ART. Он помогает координировать действия разных команд, проводит митинг, решает возникающие проблемы и устраняет проблемы. Можно сказать, что RTE — это главный организатор и фасилитатор в ART.
  • Product Manager — человек, который определяет видение и стратегию развития продукта. Его задача понять потребности клиентов и придумать как продукт будет их закрывать. Он расставляет приоритеты для задач и формирует бэклог для всего ART.
  • Scrum Master — человек, который помогает командам работать эффективно. Для этого он проводит события Scrum, помогает команде улучшать свои процессы и устраняет препятствия в ее работе. Он также обучает команду практикам Agile и следит за тем, чтобы они правильно применялись.
  • Product Owner — человек, который отвечает за конкретную часть продукта. Участвует в PI Planning, синхронизируется с другими PO и управляет бэклогом.
Какие роли есть в ART и за что они отвечают
В SAFe главное, чтобы люди разных ролей сотрудничали между собой и старались добиться общей цели — выпустить продукт.
В SAFe есть и другие роли, специфичные для разных уровней. Но их очень много и на разбор каждой уйдет отдельная статья. Чтобы не растягивать материал, перейдем к другой важной части — уровням SAFe.

Уровни SAFe

Так как SAFe — это большой фреймворк, сделать его универсальным для любых команд нельзя. Потому что где-то над продуктом трудится 5 команд, а где-то — 50. И использовать все возможности и элементы SAFe для 5 команд нет смысла — это никак не поможет в работе над продуктом, а только растянет процессы и сделает их менее прозрачными.
Поэтому фреймворк разделили на уровни — отдельные конфигурации. Каждая из них помогает применить фреймворк в разных по размеру организациях и ситуациях.
Выделяют 4 конфигурации:
  • Essential;
  • Large Solution;
  • Portfolio;
  • Full.
Разберемся с каждой.

Essential

Essential — это основной уровень фреймворка SAFe. Он подходит для небольших компаний, где уже налажены базовые рабочие процессы и распределены роли для работы с Agile-подходами. На этом уровне работает от 5 до 12 команд.
Главный элемент на стадии Essential — это создание и работа элемента ART. А события — проведение Program Increment, PI Planning и System demo.
Для примера представьте IT-компанию, которая разрабатывает корпоративную CRM-систему. Компания решает внедрить Essential SAFe, чтобы улучшить процессы разработки и быстрее выпускать новые функции. Вот как она будет действовать:
  • Сформирует ART — постоянную команду, которая будет заниматься развитием CRM-системы. Включит в нее разработчиков, тестировщиков, аналитиков, дизайнеров и др. Создаст для ART отдельный бэклог, в который попадут все задачи по продукту.
  • Разделит работу над CRM на Program Increments. В начале каждого PI команда будет собираться вместе и планировать, какую функциональность они будут разрабатывать в течение этого времени. Они будут оценивать объем работы, выявлять риски и зависимости, а также договариваться о целях.
  • Проведет System Demo в конце каждого PI и посмотрит, чего удалось достичь.
SAFe — возможность построить самую слаженную команду
Но кроме ART, PI и System Demo на уровне Essentials выделяют и другие элементы.
Design Thinking — подход к разработке продуктов. Он включает несколько итераций и позволяет создавать решения, которые действительно нужны людям, жизнеспособны и устойчивы в долгосрочной перспективе.
Lean UX — метод разработки продуктов, при котором новая функциональность выпускается небольшими итерациями. Каждая итерация — это минимально жизнеспособный продукт, который можно протестировать на пользователях.
Continuous Delivery Pipeline — набор процессов и инструментов автоматизации. Они нужны, чтобы постоянно поставлять ценность клиентам.
Customer Centricity — образ мышления, при котором все внимание уделяется клиенту. Цель — создавать продукты, которые решают реальные проблемы пользователей и делают их довольными.
Iterations — более короткие отрезки времени (1–4 недели), которые задают ритм работы команд. За итерацию команда берет несколько задач из бэклога и полностью их выполняет.
Innovation and Planning (IP) Iteration — специальная итерация, которая проходит между PI. Она нужна для исследований, внедрения инноваций, планирования и обучения команды. По сути, это время, когда можно поэкспериментировать с новыми идеями и технологиями.
SAFe Scrum — вариант Scrum, адаптированный под нужды SAFe. Он содержит роли, события и артефакты, которые помогают командам постоянно поставлять ценность.
SAFe Team Kanban — метод организации работы команды, при котором задачи визуализируются на доске. Также вводится ограничение на количество одновременно выполняемых задач, что позволяет балансировать нагрузку и быстрее доставлять ценность.
Built-In Quality — набор инженерных практик вроде автоматического тестирования или непрерывной интеграции, которые помогают командам сразу создавать качественный код, а не тратить время на исправление дефектов.
DevSecOps — подход, при котором безопасность встраивается в процесс разработки. Специалисты по безопасности работают вместе с разработчиками и инженерами, чтобы учесть все риски и защитить продукт.
ART Flow и Team Flow — состояния, к которым стремятся ART и отдельные команды. Их суть — наладить процесс так, чтобы задачи не стояли в очереди, а плавно двигались от этапа к этапу, чтобы компания могла поставлять ценность клиентам и не тратила время на ожидание и бюрократию.
Все эти элементы — необязательные. Они дополняют работу ART и решают задачи, которые сам по себе ART не покрывает. Например, Design Thinking помогает понять, что именно нужно клиентам до начала разработки. Lean UX и Continuous Delivery Pipeline ускоряют выпуск функций — в результате команда не тратит месяцы на идею, а проверяет ее на реальных пользователях за пару недель. В общем, компания сможет работать на Essential уровне и с одним ART. Но чтобы процессы работали лучше и деятельность команд приносила больше пользы — может внедрять дополнительные элементы.
Все, из чего состоит Essential

Large solution

Large Solution используют, когда команда работает над очень сложным продуктом и задействует несколько ART. Например, создает систему для банка и задействует сразу десятки команд:
  • Команда безопасности делает защиту транзакций и шифрование данных.
  • UI/UX-команда проектирует интерфейсы мобильного приложения и личного кабинета.
  • Команда платежей настраивает мгновенные переводы между клиентами.
  • Юристы и аналитики следят, чтобы система соответствовала законам разных стран.
  • Интеграторы соединяют банковскую систему с внешними сервисами (например, с бюро кредитных историй).
Также Large Solution используют, когда есть зависимость от внешних поставщиков. Все потому, что поставщики могут работать по своим процессам, которые отличаются от Agile. И они вряд ли захотят перестраивать свои методы работы под нужды команды.
Large Solution учитывает эту особенность. В таких случаях поставщик становится частью общей схемы работы как элемент Supplier. Суть в том, что SAFe не требует от поставщиков полного перехода на Agile. Вместо этого команды выстраивают взаимодействие так, чтобы учесть особенности работы поставщика и в то же время синхронизировать его действия с общим планом. Например, согласовывают сроки поставок или определяют этапы проверки результатов.
Уровень Large solution состоит из нескольких важных элементов:
Solution Train (поезд решений) — объединяет множество команд для создания продукта. Это можно сравнить с поездом, где каждый вагон — отдельная команда со своими задачами. И у каждой команды общая цель — добраться до точки назначения.
Solution Intent — репозиторий инструкций для всех команд. Здесь пишут что должно уметь приложение, какие технологии команды должны использовать и как тестировать сервис.
Solution Train Flow — состояние, при котором каждый Solution Train обеспечивает непрерывный поток ценности для клиента. Т. е., когда задачи не застревают и переходят с одного этапа на другой.
Например, дизайнеры быстро согласовывают макеты, тестировщики не ждут код, а разработчики сразу видят ошибки. Для этого настраивают автоматические тесты и проводят короткие встречи каждый день.
Spanning Palette — использование дополнительного набора элементов, которые используются для решения разных задач. Например, Vision, Roadmap, OKR и др.
А чтобы взаимодействие между ART и поставщиками были эффективными, и должны произойти следующие события:
  • Pre-Plan (Предварительное планирование) — подготовительные действия, которые помогают Agile Release Trains (ART) внутри Solution Train согласовать планы и подготовиться к PI Planning.
  • Coordinate and Deliver (Координация и доставка) — описывает практики и артефакты SAFe, которые необходимы для поддержания синхронной работы Solution Train и обеспечения ценности на протяжении всего PI.
  • Solution Demo (Демонстрация решения) — объединяет результаты работы всех ART и поставщиков, входящих в Solution Train, в каждом PI. Эти результаты показывают клиентам и другим заинтересованным сторонам для оценки и получения обратной связи.
  • Inspect & Adapt (I&A) (Проверка и адаптация) — важное событие, где демонстрируется и оценивается текущее состояние готового интегрированного решения. После этого участники Solution Train обсуждают результаты и планируют улучшения через структурированный воркшоп по решению проблем.
  • Product Manager, Architect и RTE синхронизация — встреча, которая позволяет выяснить и решить проблемы у ART команд.
Без этих элементов и событий большие проекты могут проваливаться. Команды будут дублировать работу, терять требования заказчика и деньги.
Все, из чего состоит Large Solution

Portfolio

Portfolio — уровень SAFe, который помогает компании правильно распределять ресурсы и деньги. Позволяет принимать решения о том, в какие проекты или продукты стоит вкладываться, чтобы они соответствовали стратегическим целям компании и требованиям рынка. По сути, этот инструмент дает понимание что делать в первую очередь ради получения максимальной выгоды.
Представьте компанию, которая занимается разработкой программного обеспечения. У нее в портфеле несколько направлений: облачные хранилища, инструменты для разработки и решения в области кибербезопасности. Каждое направление — это отдельный бизнес со своей командой разработки, которая использует Essential SAFe.
Но топ-менеджменту компании нужно принимать стратегические решения в масштабах всей организации. Например, в какое направление инвестировать больше денег в следующем году. Может быть, стоит вообще запустить новую линейку продуктов для управления данными.
Принять решение помогает Portfolio SAFe. Он дает общую картину всех бизнесов и продуктов компании. Помогает расставить приоритеты, распределить ресурсы и синхронизировать цели.
В случае с разработчиком ПО аналитика показывает, что рынок кибербезопасности растет, а спрос на инструменты для разработки сокращается. Тогда на уровне портфеля принимается решение: сократить инвестиции в направление разработки инструментов, а освободившиеся деньги и людей направить на создание новых решений для защиты данных и предотвращения утечек.
При этом каждая продуктовая команда продолжает работать по Essential SAFe. Но их бэклоги и цели на PI теперь учитывают общую стратегию, полученную сверху. То есть автономность команд сохраняется, но их работа становится более скоординированной и нацеленной на успех всей компании.
Все, из чего состоит Portfolio

Full

Full SAFe — это самый полный уровень фреймворка SAFe. Он объединяет в себе все практики и инструменты, которые есть в Essential SAFe, Large Solution SAFe и Portfolio SAFe.
Цель Full SAFe — помочь большим компаниям внедрить принципы бережливого производства и гибкой разработки на всех уровнях.
Чтобы успешно масштабировать Lean и Agile в большой организации, Full SAFe включает несколько дополнительных элементов:
  • Lean Portfolio Management (LPM) — подход к управлению портфелем продуктов и инициатив, основанный на бережливом мышлении. Его суть в том, чтобы децентрализовать принятие решений и дать командам больше автономии. При этом все инициативы должны быть связаны со стратегическими целями компании и приносить ценность клиентам.
  • Continuous Learning Culture — культура, в которой постоянное обучение и эксперименты являются нормой для всех сотрудников. Компания поощряет развитие людей, обмен знаниями и внедрение инноваций.
  • Organizational Agility — способность организации быстро адаптироваться к изменениям рынка и новым технологиям. Чтобы стать по-настоящему гибкими, компании нужны кросс-функциональные команды, которые сами отвечают за создание и развитие продуктов. А также структура с минимумом иерархии и бюрократии.

Как внедрить SAFe в компанию

На официальном сайте SAFe есть дорожная карта по внедрению фреймворка в компанию. Карта состоит из 13 шагов.
  1. достичь переломного момента;
  2. обучить агентов изменений;
  3. создать центр экспертизы;
  4. обучить руководителей;
  5. организоваться вокруг ценности;
  6. создать план внедрения;
  7. подготовить запуск ART;
  8. обучить команды и запустить ART;
  9. настроить работу ART;
  10. запустить новые ART;
  11. улучшить управление портфелем;
  12. ускорить процессы;
  13. постоянно развиваться.

Преимущества SAFe

Позволяет бизнесу быстрее выводить продукты на рынок. Это происходит за счет параллельной работы команд. Разные отделы, например, разработка, дизайн и маркетинг, трудятся одновременно, и каждый отдел занимается своей частью продукта. В итоге продукт создается в разы быстрее, чем если бы команды делали все по очереди.
Улучшает качество продуктов. Все благодаря регулярному тестированию и правкам. Например, компания создает приложение, где разработчики регулярно добавляют новые функции. А тестировщики сразу их проверяют и если находят баги — отправляют на доработку.
Когда прилетел фидбек от тестировщиков
Снижает риски и затраты. Весь процесс работы разбит на короткие итерации, где каждые пару недель выходит новая версия продукта. Ее показывают клиентам и собирают отзывы. И если есть проблемы — их можно быстро исправить и не тратить месяцы на разработку продукта, который окажется никому не нужен.
Усиливает вовлеченность сотрудников. Люди постоянно взаимодействуют: обсуждают, спорят, находят компромиссы. Чувствуют себя командой, у которой общая цель. Это помогает создать сильную команду, которая помогает друг другу и решает проблемы вместе.

Недостатки SAFe

Сложность внедрения. SAFe включает множество ролей, элементов и событий, из-за чего его сложнее понять и внедрить. Поэтому компаниям требуется значительное время и ресурсы для адаптации к новым процессам.
Избыточная терминология. Фреймворк вводит множество новых терминов, некоторые из которых отличаются от привычных в Agile. Это может путать сотрудников, поэтому придется заложить время на дополнительное обучение.
Сохранение зависимостей между командами. SAFe признает наличие зависимостей между командами и активно работает над их минимизацией. Однако полностью устранить их не всегда удается, из-за чего процесс разработки может замедляться.

Что в итоге

  • SAFe — фреймворк для координации работы Agile- и не Agile-команд и интеграции Lean-Agile подходов в компанию. SAFe подходит для больших компаний со сложными проектами.
  • SAFe состоит из 4 уровней и десятков элементов, управляемых разными людьми. Фреймворк разделен на уровни для разных размеров организаций и ситуаций: Essential, Large Solution, Portfolio и Full.
  • Фреймворк помогает упорядочить работу нескольких команд над одним продуктом и быстрее выпускать продукты на рынок.
  • SAFe задействует много разных ролей, но основных несколько: Release Train Engineer, Product Manager, Scrum Master, Product Owner.
Если хотите разобраться в SAFe лучше и внедрить его в свои бизнес-процессы, обратитесь в компанию Neogenda. Просто запишитесь на бесплатную консультацию, и наши эксперты помогут интегрировать фреймворк в ваш бизнес.
]]> Малоизвестные факты о Законе Литтла: как обеспечить предсказуемость рабочего процесса http://neogenda.ru/blog/7uz0k8ebu1-maloizvestnie-fakti-o-zakone-littla-kak http://neogenda.ru/blog/7uz0k8ebu1-maloizvestnie-fakti-o-zakone-littla-kak?amp=true Tue, 18 Feb 2025 10:11:00 +0300 Устойчивая предсказуемость достигается за счёт создания стабильной системы поставки. Закон Литтла подтверждает это явление. Давайте...

Малоизвестные факты о Законе Литтла: как обеспечить предсказуемость рабочего процесса

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

Что такое уравнение закона Литтла?

Представьте, что вы владеете популярным трейлером по продаже еды. Вы известны своими органическими грибами шиитаке, выращенными в естественных условиях и буррито. Ваши свежеприготовленные начос с острой сальсой верде – хит сезона, и ваши клиенты любят вас за это.
Допустим, каждый час к вам приходят 20 человек. Они задерживаются на полчаса, чтобы поесть и поболтать. Сколько клиентов в любой момент времени находится у вашего трейлера?
Закон Литтла гласит:
  • λ — частота прихода клиентов. В нашем примере λ = 20 клиентов в час.
  • W — среднее время пребывания клиента, W = 0,5 часа.
  • L — среднее количество клиентов у трейлера в данный момент.
А вот и уравнение закона Литтла L = λ * W
Основываясь на этой формуле, мы можем рассчитать, что среднее количество клиентов, которыми вы работаете одновременно, составляет L = 20 * 0,5 = 10 клиентов.
Итак, почему это важно?

Цель закона в области управления проектами

Давайте рассмотрим, как руководители корпораций применяют закон Литтла на практике и используют его для повышения прогнозируемости своих рабочих процессов.
Закон Литтла можно использовать для расчета производительности вашего бизнеса. С этой целью формулу можно выразить немного по-другому:
  • λ — пропускная способность количество выполненных задач за единицу времени), вместо количества приходящих клиентов.
  • W — время цикла (время прохождения задачи через процесс) вместо времени, которое люди проводят в заведении.
  • L — это незавершенная работа (количество активных задач в системе) или количество товаров, находящихся в вашей системе в любой момент времени, а не объем заказов.
Таким образом, формула становится L = λ * W
WIP = Пропускная способность * Время цикла
Три ключевых факта о законе Литтла:
  1. Нельзя применять его для прогнозирования выполнения обязательств.
  2. Он описывает только средние значения.
  3. Он анализирует прошлые данные.
Рассмотрим их подробнее.

Закон Литтла не помогает в прогнозировании

Некоторые считают, что закон Литтла полезен для предсказания будущего. Но так ли это?
Допустим, у вас:
  • Средний WIP = 6 задач
  • Пропускная способность = 2 задачи в день
  • Среднее время цикла = 3 дня

Что произойдёт, если увеличить WIP?

Можно ли сказать, что, если поднять WIP до 12 задач, а время цикла оставить неизменным (3 дня), то пропускная способность вырастет до 4 задач в день?
Нет — закон Литтла такого прогноза не дает. Все, что вам скажет закон Литтла, это то, что увеличение среднего значения WIP приведет к изменению одного (или обоих) из двух ключевых показателей — среднего времени цикла и средней пропускной способности.
Чтобы уравнение закона Литтла имело силу, все лежащие в его основе допущения должны применяться к исследуемому нами периоду времени. Чуть позже рассмотрим этот момент подробнее.

Закон Литтла — это уравнение средних величин

Поскольку все переменные в нём представляют средние значения, закон Литтла нельзя использовать для вероятностных прогнозов.
Пример:
  • Если шанс успешного завершения проекта всего 20%, согласитесь ли вы на такую дату сдачи?
  • Средние значения дают общую картину, но без анализа распределения данных предсказать вероятность успеха невозможно.
Поскольку каждый компонент в зависимости является средним значением, закон Литтла представляет собой соотношение средних значений. Этот расчет даст среднее значение. Таким образом, мы не можем делать никаких вероятностных прогнозов, используя этот подход.
Делать прогнозы, основанные на среднем значении, рискованно. Прогнозы, основанные на средних значениях, будут иметь смысл только в том случае, если вы что-то знаете о форме базового распределения ваших данных. Без этого знания нет никакого способа определить: ваша цель имеет ровно 50%, гораздо больше 50% или значительно меньше 50% шансов на успех.
Согласовали бы вы дату сдачи проекта, вероятность которой составляет 20%? Мы, конечно, не рекомендуем этого делать.

Закон Литтла анализирует прошлые данные

Этот закон помогает изучать прошлые процессы и оценивать стабильность системы. Он разработан для использования исторических данных в анализе предсказуемости рабочего процесса.
На накопительной диаграмме можно оценить:
  • Среднюю скорость выполнения задач
  • Среднюю пропускную способность
  • Средний WIP
  • Среднее время цикла
В стабильной системе средняя скорость выполнения примерно равна средней пропускной способности. Это означает, что задачи поступают и завершаются с одинаковой скоростью. Если процесс стабилен и предсказуем, закон Литтла будет давать точные оценки.

Как проверить стабильность?

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

Главный инсайт о законе Литтла

Само уравнение — не главное. Его ценность в том, что оно помогает понять взаимосвязь трёх ключевых показателей рабочего процесса.
Одна из самых распространённых проблем — постоянное увеличение WIP. А закон Литтла чётко показывает: если растёт WIP, увеличивается и время цикла.
Как можно оставаться предсказуемым, если время цикла постоянно растёт? Никак.
Используйте закон Литтла, чтобы анализировать свои процессы и делать их более стабильными и управляемыми.
Если хотите лучше разобраться в законе Литтла и применять его для улучшения своих бизнес-процессов, обратитесь в компанию Neogenda. Начнем с бесплатной консультации?
]]> Долгосрочные и краткосрочные цели для бизнеса: как ставить и достигать http://neogenda.ru/blog/id78fvk8g1-dolgosrochnie-i-kratkosrochnie-tseli-dly http://neogenda.ru/blog/id78fvk8g1-dolgosrochnie-i-kratkosrochnie-tseli-dly?amp=true Mon, 17 Feb 2025 07:02:00 +0300 Андрей Сидоренко Представьте компанию, которая плывет по течению и плохо понимает куда движется. Она тратит ресурсы, пробует...

Долгосрочные и краткосрочные цели для бизнеса: как ставить и достигать

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

Что такое бизнес-цели

Бизнес-цели — ориентиры, которые помогают компании развиваться, определять стратегию и достигать конкретных результатов. Они бывают краткосрочными, среднесрочными, долгосрочными, количественными и качественными, ориентированными на процесс либо результат.
Цели и задачи: в чем разница? Бизнес-цели — это конечные результаты, которые хочет достичь фирма, а задачи — определенные шаги для их достижения. Чтобы правильно выстроить процессы и избежать хаоса в управлении, важно понимать эту разницу.

Зачем компаниям нужны бизнес-цели

Без четких ориентиров компания рискует потерять фокус, тратить ресурсы неэффективно и не достигать желаемых результатов. Вот почему цели нужны каждой компании:
  1. Управление проектами и командой. Ясные цели делают процессы более управляемыми. Они помогают выстраивать гибкое управление проектами, распределять приоритеты и ресурсы. Если компания ставит долгосрочную цель по увеличению доли рынка, это повлияет на задачи отдела маркетинга и продаж.
  2. Оценка результатов и эффективности. Бизнес-цели связаны с ключевыми результатами, которые помогают измерять успех. Использование OKR и KPI позволяет отслеживать прогресс и корректировать стратегию, если что-то идет не так.
  3. Совместная работа и мотивация сотрудников. Если команда понимает бизнес-цели, ей легче координировать совместную деятельность, принимать решения и видеть смысл во всем происходящем. Это особенно актуально для крупных фирм, где управление портфелем проектов требует четкого видения.
Получается, что цели — это не просто формальность, а основа стратегического роста, эффективного управления и успешного развития бизнеса.

Какие выделяют виды бизнес-целей

Чтобы эффективно планировать, важно понимать, какие существуют виды целей и как их классифицировать. Бизнес-цели можно разделить по времени, направленности и уровню детализации.
Рассмотрим каждую категорию подробнее.

По времени

Краткосрочные цели. Это задачи, которые компания планирует реализовать в ближайшее время: в течение нескольких недель, месяцев или максимум года. Они помогают оперативно реагировать на изменения рынка и двигаться к более глобальным ориентирам.
Пример. Розничная сеть планирует запустить программу лояльности и увеличить средний чек на 15% в течение квартала.
Среднесрочные цели. Охватывают период от года до трех лет. Они соединяют краткосрочное и долгосрочное планирование для бизнеса, поэтому позволяют идти к крупным целям поэтапно.
Пример. Производственная компания ставит цель автоматизировать 50% процессов в течение двух лет, чтобы повысить эффективность работы.
Долгосрочные цели. Направлены на стратегическое развитие компании с горизонтом от трех до десяти лет. Они определяют глобальное направление бизнеса, а еще помогают формировать миссию и ценности компании.
Долгосрочные цели пример. Технологический стартап ставит цель выйти на международный рынок и занять 10% ниши за пять лет.
Важно, чтобы долгосрочные и краткосрочные цели для бизнеса не противоречили друг другу, а работали в связке. Если компания стремится увеличить прибыль на 50% за пять лет (долгосрочная цель), то логично разбить этот процесс на этапы: расширение ассортимента, внедрение новых каналов продаж, повышение узнаваемости бренда (краткосрочные и среднесрочные цели).

По направленности

Количественные и качественные цели. Количественные измеряются в цифрах: доход, количество клиентов, процент роста. Качественные связаны с улучшением процессов, репутации или культуры внутри компании.
Пример. Количественная цель — увеличить число подписчиков в соцсетях на 20% за полгода. Качественная — повысить уровень клиентского сервиса, чтобы улучшить отзывы.
Цели, ориентированные на результат. Они фокусируются на итоге, который компания хочет достичь. При этом четко формулируются и позволяют оценить успех.
Пример. Выйти на лидирующую позицию в рейтинге SEO-выдачи по ключевым запросам в течение года.
Цели, ориентированные на процесс. Они направлены на совершенствование самого процесса работы. Могут включать автоматизацию, обучение сотрудников, интеграцию новых технологий.
Пример. Внедрить CRM, чтобы оптимизировать взаимодействие с целевой аудиторией.

По уровню детализации

Цели конкретного сотрудника. Личные бизнес-цели сотрудников должны координироваться с целями компании.
Пример. Менеджер по продажам ставит цель увеличить конверсию сделок на 15% в течение квартала.
Цели отдела. Каждое подразделение компании работает над тем, чтобы достигать общие цели через свои локальные задачи.
Пример. Отдел маркетинга ставит цель увеличить число лидов на 30% за год.
Цели компании. Это глобальные ориентиры, к которым движется весь бизнес.
Пример. Компания ставит цель увеличить долю рынка до 25% в течение пяти лет.
Таким образом, чтобы структурировать работу, выбрать правильные приоритеты и добиться стабильного роста, нужно различать бизнес-цели.

Как ставить бизнес-цели

Просто ставить цели недостаточно. Нужно правильно их формулировать, чтобы они были понятны и достижимы. Существуют методы, которые помогают ставить цели и структурировать шаги, чтобы к ним идти:
SMART акцентирует внимание на пяти главных характеристиках, которым должна соответствовать каждая цель:
  • Specific (конкретная) — четко определенная и понятная для всех участников процесса.
  • Measurable (измеримая) — с количественными или качественными показателями, благодаря которым можно измерить прогресс.
  • Achievable (достижимая) — реальная и достижимая с учетом ресурсов и времени, которые есть.
  • Relevant (актуальная) — релевантная миссии и стратегии компании.
  • Time-bound (ограниченная во времени) — с четкими установленными сроками.
Пример. Увеличить количество новых клиентов на 15% за следующий квартал с помощью рекламной кампании в соцсетях.
Метод помогает избежать неопределенных формулировок и сделать достижение целей более управляемым.

Метод OKR

Другой эффективный метод — OKR (Objectives and Key Results). Он фокусируется на более высокоуровневых целях и результатах, которые нужно достичь. Этот метод часто используется в крупных компаниях, чтобы выстроить четкую стратегию и взаимосвязь между разными подразделениями.
Objective (цель) — глобальная цель, которую организация ставит перед собой.
Key Results (ключевые результаты) — измеримые показатели, позволяющие понять, насколько фирма близка к достижению цели.
Пример OKR. Цель: повысить узнаваемость бренда. Ключевые результаты: сделать количество подписчиков в соцсетях больше на 30%; достигнуть 25% упоминаний в отраслевых медиа.
Благодаря методу можно сфокусироваться на главных результатах и достигать конкретных показателей, которые помогают реализовать стратегическую цель.

Сеанс мозгового штурма

Перед тем как формулировать бизнес-цели, полезно провести с командой сеанс мозгового штурма. Этот метод помогает генерировать идеи и находить возможности для развития, которые могут стать основой для новых целей.
Чтобы провести мозговой штурм:
  • Соберите команду из разных отделов — так можно получить разнообразные идеи и точки зрения.
  • Определите ключевые сферы бизнеса, которые требуют улучшений или изменений.
  • Запишите все предложенные идеи и оцените их по приоритетности.
  • Выберите наиболее перспективные идеи и начните разрабатывать конкретные цели и задачи.
Пример. В ходе мозгового штурма команда компании выясняет, что основная проблема — низкий уровень повторных покупок. В результате получается сформулировать такую цель: «Улучшить клиентскую программу лояльности, чтобы увеличить повторные покупки на 20% в течение полугода».

Как управлять бизнес-целями

Важно не просто определить, какие цели нужны компании, но и грамотно их реализовывать, отслеживать прогресс и, если нужно, корректировать курс. Вот на какие моменты следует обращать внимание, чтобы компания двигалась в нужном направлении:
1. Совместная работа и контроль за исполнением. Чтобы успешно управлять целями, внутри команды должно быть тесное взаимодействие. Каждому сотруднику или подразделению следует четко понимать свою роль в достижении общей цели. Регулярные встречи, отчетность и системы управления проектами помогают не только отслеживать процесс, но и вовремя выявлять возможные проблемы.
2. Гибкое управление проектами. В условиях изменчивого рынка и бизнес-среды необходимо уметь адаптировать цели и задачи в процессе работы. Если разбивать крупные цели на более мелкие и управляемые задачи, можно легче вносить изменения и корректировать план. Это особенно важно для стартапов и быстрорастущих компаний, которые часто сталкиваются с непредсказуемостью.
3. Методы оценки эффективности. Для того, чтобы понимать, насколько вы близки к достижению целей, необходимо регулярно оценивать эффективность. KPI (ключевые показатели эффективности) или OKR (цели и ключевые результаты) позволяют отслеживать, насколько точно удается выполнять цели. Кроме того, проведение back-обзора после выполнения задачи позволяет выявить слабые места и улучшить процесс в будущем.
4. Управление изменениями. Цели не должны быть жестко зафиксированы, особенно в условиях, когда рынок быстро меняется. Постоянно оценивайте внешние и внутренние факторы, пересматривайте стратегии и корректируйте цели, если необходимо. Это позволит компании адаптироваться и держать фокус на главных задачах.

Какие ошибки бывают в постановке бизнес-целей и как их избежать

В процессе разработки целей легко допустить ошибки, которые могут повлиять на результат:
Ошибка Что означает Как избежать
Формулировать цели без четкости и измеримости Если цель слишком общая, например «повысить продажи», непонятно, что именно нужно сделать, чтобы ее достигнуть Формулируйте цели так, чтобы их можно было измерить. Используйте метод SMART для определения конкретных и измеримых результатов
Игнорировать временные рамки Если нет четких сроков выполнения целей, процесс затягивается, а это может не соответствовать реальным потребностям бизнеса Определите реалистичные сроки для каждой цели. Разбейте долгосрочные цели на краткосрочные этапы, чтобы отслеживать прогресс и корректировать план
Отклоняться от стратегии компании Если цели не согласованы с общей стратегией компании, то даже их достижение может не привести к успеху Убедитесь, что цели поддерживают стратегию компании и согласованы с приоритетами бизнеса. Привязывайте цели к ключевым направлениям
Недооценивать важность гибкости в долгосрочных целях Бизнес-среда меняется, и жесткие долгосрочные цели могут стать неактуальными Ставьте долгосрочные цели с учетом возможных корректировок в будущем. Адаптируйте цели, если внешние факторы меняются
Ожидать нереалистичных результатов и недооценивать ресурсы Завышенные ожидания могут демотивировать сотрудников и не соответствовать возможностям компании, а это увеличивает риск неудачи Оценивайте свои ресурсы и возможности на этапе постановки целей. Убедитесь, что у вас достаточно ресурсов, чтобы их реализовать
Не контролировать и не оценивать процесс выполнения целей Если не следить за тем, как выполняются цели, можно не заметить проблемы и не отреагировать на них вовремя Используйте KPI или OKR, чтобы контролировать выполнение целей. Регулярно отслеживайте процесс и при необходимости корректируйте план

Что в итоге

Чтобы компания развивалась, важно правильно формулировать краткосрочные и долгосрочные цели, грамотно их структурировать и регулярно отслеживать результаты. Это требует не только теоретических знаний, но и практических навыков, которые помогут избежать распространенных ошибок.
А если хотите эффективно ставить цели, управлять ими и командой, консалтинговая компания Neogenda предложит решения именно для вашего бизнеса. Мы уже успешно работали с Tinkoff, Яндекс, Авито, Сбер и другими. Запишитесь на бесплатную консультацию — наши специалисты помогут выбрать лучшие практики для достижения ваших целей.
]]> Как Business Model Canvas помогает создать успешную стратегию и развить бизнес http://neogenda.ru/blog/x8h6tghtc1-kak-business-model-canvas-pomogaet-sozda http://neogenda.ru/blog/x8h6tghtc1-kak-business-model-canvas-pomogaet-sozda?amp=true Wed, 19 Feb 2025 07:14:00 +0300 Артур Нек Каждый успешный бизнес начинается с идеи. Но чтобы эта идея стала прибыльной и устойчивой, важно...

Как Business Model Canvas помогает создать успешную стратегию и развить бизнес

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

Что такое Business Model Canvas

Business Model Canvas, или бизнес-модель Остервальдера, — это визуальный инструмент, благодаря которому можно четко структурировать основные аспекты бизнеса. Каркас модели — девять блоков. Они охватывают все основные части: от целевых клиентов и ценностного предложения до каналов сбыта и структуры издержек.
Это позволяет понять, как все компоненты бизнеса связаны друг с другом, и оценить их эффективность, выявить возможности для оптимизации и роста.
А. Остервальдер и Ив Пинье
Модель Остервальдера предложили Александр Остервальдер и Ив Пинье — авторы книги о бизнес-моделях, которая стала популярна в 2010 году. Так, компании разной величины используют Business Model Canvas, чтобы строить стратегии, оптимизировать процессы и находить новые решения.

Как выглядит структура Business Model Canvas

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

1. Потребительские сегменты (Customer Segments)

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

2. Ценностное предложение (Value Proposition)

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

3. Каналы сбыта и взаимодействия (Channels)

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

4. Отношения с клиентами (Customer Relationships)

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

5. Потоки доходов (Revenue Streams)

Блок показывает, как в бизнес приходят деньги от клиентов: прямые продажи, подписки или доходы от лицензирования. Выбор правильной модели монетизации зависит от типа ценностного предложения и потребительских сегментов.

6. Ключевые ресурсы (Key Resources)

Блок описывает основные возможности, которые бизнес использует для создания и предложения ценности. Это могут быть ресурсы как материальные (заводы, офисы), так и нематериальные (бренд, интеллектуальная собственность). Все это нужно для реализации всех основных видов деятельности.

7. Ключевые виды деятельности (Key Activities)

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

8. Ключевые партнеры (Key Partners)

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

9. Структура издержек (Cost Structure)

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

Какие у Business Model Canvas могут быть преимущества и недостатки

При работе с моделью Остервальдера важно учитывать ее преимущества и недостатки.

Преимущества

Простота в использовании. Модель понятна и позволяет быстро создать стратегию бизнеса. Даже без глубоких знаний в управлении.
Пример. Стартап по доставке еды использует Business Model Canvas, чтобы сразу определить ключевые аспекты бизнеса:
  • Потребительские сегменты — офисные сотрудники, молодежь, семьи.
  • Ценностное предложение — доставка до 30 минут, широкий выбор блюд, удобный заказ через приложение.
  • Каналы сбыта — мобильное приложение, веб-сайт, соцсети, партнерские сервисы.
Подход помогает быстро увидеть сильные и слабые стороны бизнеса, разработать план стратегии и адаптироваться к рынку.
Понимание взаимосвязи элементов бизнеса. Модель помогает наглядно увидеть и осознать, как ресурсы, партнеры и процессы взаимодействуют друг с другом и влияют на бизнес.
Пример. Интернет-платформа для онлайн-курсов использует бизнес-модель Остервальдера, чтобы увидеть как связаны ключевые элементы:
  • Ключевые ресурсы — программное обеспечение, образовательный контент, эксперты.
  • Ключевые виды деятельности — разработка курсов, маркетинг, поддержка пользователей.
  • Партнерства — сотрудничество с учебными заведениями для создания актуальных материалов.
Это помогает понять, как ресурсы и процессы влияют друг на друга: как качественный контент повышает спрос, а эффективный маркетинг привлекает новых пользователей.

Недостатки

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

Можно ли выбрать бизнес-модель из существующих шаблонов

Некоторые предприниматели задаются вопросом: можно ли выбрать готовую модель из существующих шаблонов? Ответ — да, можно, но важно понимать, что шаблоны служат лишь отправной точкой, а не окончательным решением. Они помогают упростить планирование и предлагают структурированный подход к созданию бизнес-модели.
Выбор подходящего шаблона зависит от специфики вашего бизнеса, отрасли и масштабов. Например, шаблон Остервальдера идеально подходит для стартапов и небольших компаний, которые только начинают развиваться и нуждаются в быстром, наглядном анализе ключевых аспектов бизнеса. В то время как крупные компании со сложной структурой могут выбрать более детализированные шаблоны бизнес-моделей, например, Lean Canvas, или сочетать их с другими инструментами для глубокого анализа. Важно помнить, что шаблон должен отражать реальные потребности и цели вашей компании, а не быть просто обобщенным решением.
Хотя обычно шаблоны предлагают стандартные категории, такие как потребительские сегменты, ценностное предложение и каналы сбыта, вы всегда можете адаптировать их под особенности вашего бизнеса. Это позволяет не только максимально точно отразить реальные процессы и стратегии, но и создать рабочую модель, которая будет поддерживать развитие бизнеса на всех этапах.

Как оценивать бизнес-модель

Чтобы оценить эффективность бизнес-модели, нужно проанализировать ключевые метрики. Эти показатели помогают понять, насколько хорошо работает бизнес и как можно оптимизировать его компоненты:
1. Экономическая эффективность. Оценка структуры издержек — важный аспект. Необходимо определить, насколько эффективно расходуются ресурсы на создание и доставку ценности. Высокие затраты на каналы сбыта, производство или маркетинг могут негативно повлиять на прибыльность модели. Чтобы улучшить финансовые показатели, важно найти баланс между затратами и доходами.
2. Рентабельность и монетизация. Потоки доходов показывают, как бизнес зарабатывает деньги. Оценка рентабельности позволяет определить, насколько прибыльны выбранные модели монетизации — будь то прямые продажи, подписки или реклама. Важно учитывать, что разные потребительские сегменты могут требовать различных подходов к монетизации.
3. Адаптивность и устойчивость. Анализ устойчивости бизнес-модели позволяет оценить ее способность адаптироваться к изменениям на рынке и потребительским предпочтениям. Оценка гибкости каналов сбыта, ценностного предложения и отношений с клиентами поможет выявить слабые места и улучшить устойчивость модели в долгосрочной перспективе.
Таким образом, эффективная оценка бизнес-модели требует комплексного анализа этих метрик, чтобы найти точки роста и прибыльности.

Как заполнять Business Model Canvas: пример

Если для примера взять гипотетический стартап, который занимается доставкой еды через мобильное приложение, модель Остервальдера могла бы выглядеть так:

1. Потребительские сегменты (Customer Segments)

Целевая аудитория стартапа — это люди, которые хотят быстро и удобно заказать еду через мобильное приложение. Сегменты могут включать:
  • молодежь и студентов, которые предпочитают заказывать еду на дом или в офис;
  • занятых профессионалов, которым нужно быстро перекусить во время работы;
  • семьи, которым удобно заказать еду не выходя из дома.

2. Ценностное предложение (Value Proposition)

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

3. Каналы сбыта (Channels)

Каналы, через которые компания взаимодействует с клиентами:
  • мобильное приложение — основной канал для заказов;
  • веб-сайт — для пользователей, которые предпочитают делать заказы с компьютера;
  • социальные сети — для продвижения и взаимодействия с клиентами.

4. Отношения с клиентами (Customer Relationships)

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

5. Потоки доходов (Revenue Streams)

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

6. Ключевые ресурсы (Key Resources)

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

7. Ключевые виды деятельности (Key Activities)

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

8. Ключевые партнеры (Key Partners)

  • Рестораны и кафе: поставляют еду для доставки.
  • Фрилансеры-курьеры и аутсорсинговые службы доставки: помогают с доставкой.
  • Маркетинговые агентства: продвигают бренд и привлекают пользователей.

9. Структура издержек (Cost Structure)

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

Что в итоге

Business Model Canvas — это инструмент, который помогает структурировать ключевые элементы компании и принимать обоснованные решения. Использование модели позволяет эффективно адаптировать бизнес под изменения рынка и улучшать взаимодействие с клиентами.
Для существующих компаний модель помогает пересмотреть стратегию и оптимизировать процессы, а для стартапов — быстро проверить концепцию.
Если вы хотите внедрить современные методы стратегического управления бизнес-процессами и вывести вашу компанию на новый уровень, обратитесь к экспертам Neogenda. Наш подход включает обучение сотрудников, реорганизацию процессов и внедрение инновационных решений. Его уже успели оценить Сбер, Яндекс, Точка и X5 Group.
Начните с бесплатной консультации от практиков Neogenda и откройте новые возможности для вашего бизнеса.
]]> Язык UML: как диаграммы помогают оптимизировать бизнес-процессы и создавать успешные продукты http://neogenda.ru/blog/lzxeun9591-yazik-uml-kak-diagrammi-pomogayut-optimi http://neogenda.ru/blog/lzxeun9591-yazik-uml-kak-diagrammi-pomogayut-optimi?amp=true Fri, 21 Feb 2025 07:18:00 +0300 Существует ли универсальный подход, который помогает визуализировать, анализировать и улучшать процессы? Диаграммы UML позволяют видеть...

Язык UML: как диаграммы помогают оптимизировать бизнес-процессы и создавать успешные продукты

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

Что представляет собой язык UML

Язык UML (Unified Modeling Language) — это стандартный язык моделирования. Его применяют, чтобы проектировать и документировать сложные системы. UML помогает наглядно продемонстрировать процессы и упрощает взаимодействие в команде.
Модели, созданные с помощью языка, дают возможность структурировать систему, определить ключевые элементы и их взаимодействие. Этот универсальный инструмент применяют как в разработке ПО, так и в оптимизации бизнес-процессов.
Чтобы создать модель UML, используют диаграммы UML — каждая отображает определенные стороны системы. Такая визуализация помогает описывать структуру и последовательность процессов. Это особенно полезно при работе над сложными проектами.
UML: пример — разные специалисты используют разные диаграммы

Где применяется UML и как он помогает бизнесу

С UML работают, чтобы создавать визуальные модели, которые описывают ключевые факторы разработки продуктов и оптимизации бизнеса.
Варианты использования UML включают:
  • Моделирование бизнес-процессов — создание диаграмм, которые наглядно показывают потоки работ, связи подразделений и этапы процесса.
  • Анализ сценариев использования — построение диаграмм, которые иллюстрируют взаимодействие пользователей с системой, чтобы выявить их потребности и ожидаемые результаты.
  • Разработка программного обеспечения — язык применяют, чтобы проектировать структуру и поведение систем, от архитектуры до алгоритмов.

Что стоит учитывать: преимущества и недостатки UML

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

Преимущества

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

Недостатки

  • Достаточно сложен — для начинающих изучение UML может быть сложным, ведь на освоение множества диаграмм нужно время.
  • Избыточен для простых задач — в небольших проектах или простых бизнес-процессах UML может показаться чрезмерным и проще использовать более простые методы моделирования.
  • Запутан при больших объемах данных — при моделировании сложных систем диаграммы могут становиться перегруженными, поэтому воспринимать и использовать информацию становится трудно.
Тем не менее, несмотря на некоторые ограничения, UML помогает создавать модели систем и анализировать бизнес-процессы в сложных проектах.

Что такое UML-диаграммы и зачем они нужны

UML-диаграммы используют, чтобы создавать графические модели, которые помогают понять, как работает система и как различные ее компоненты взаимодействуют друг с другом. Благодаря визуализации процессов с помощью UML можно улучшить коммуникацию внутри команды и сделать разработку более прозрачной, доступной и понятной.
Разные виды диаграмм, независимо от типа, строятся на базе нескольких основных концепций, таких как объекты и классы. Эти элементы определяют как будет выглядеть структура системы:
→ Объект — это конкретный экземпляр класса, который содержит данные и выполняет определенные функции. Каждый объект — часть более широкой системы, и все вместе они образуют ее структуру. Могут взаимодействовать друг с другом, а также изменять свои состояния в зависимости от условий системы.
→ Класс — это шаблон или модель для объектов. Описывает атрибуты и методы, общие для всех объектов этого типа. Например, если класс — это «Автомобиль», то объектами этого класса станут конкретные автомобили с уникальными характеристиками (цвет, модель, год выпуска), но у них будут общие атрибуты и методы, такие как скорость или тип топлива.
Для отображения взаимодействий между этими объектами и классами UML использует различные виды связей. Они бывают разными:
→ Ассоциация — это связь двух классов, которая указывает на то, что объекты этих классов могут взаимодействовать друг с другом. Например, объект «Клиент» может быть связан с объектом «Заказ».
→ Зависимость — более слабая связь, которая обозначает, что один элемент системы зависит от другого. Например, класс «Программа» может зависеть от класса «База данных», но они не имеют прямой ассоциации.
→ Агрегация и композиция — более сильные типы связей. Они описывают отношения, при которых один объект (целое) состоит из других объектов (частей). В агрегации части могут существовать независимо от целого, в композиции — не могут.
Эти виды связей помогают точнее и детальнее моделировать поведение системы, поскольку показывают, как различные компоненты системы взаимодействуют друг с другом.

Какие виды UML-диаграмм существуют

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

Структурные диаграммы

Они используются для описания статической части системы, ее структуры, взаимосвязей компонентов и их атрибутов. Они помогают моделировать, как компоненты системы взаимодействуют между собой и как организована сама система. Рассмотрим основные виды:
Диаграмма классов — это структурная диаграмма, которую можно назвать одной из самых популярных и широко используемых. Она отображает классы системы, их атрибуты и методы, отношения между ними. Этот инструмент чаще всего используют, чтобы представлять объектно-ориентированные системы.
Пример. Для системы «Банк» можно представить такие классы, как «Клиент», «Счет», «Транзакция, — у каждого будут атрибуты и методы. Класс «Счет» может содержать атрибуты «номер счета», «баланс» и метод «пополнение счета».
Диаграмма объектов — частный случай диаграммы классов. Отображает конкретные экземпляры классов на определенный момент времени. Эти диаграммы используют, чтобы представлять конкретные объекты, их связи и состояние в системе.
Пример. Для той же банковской системы можно показать конкретный объект «Счет №12345» с конкретным значением атрибута «баланс».
UML-диаграммы: пример. Диаграмма объектов
Диаграмма компонентов нужна для представления физической структуры системы с ее компонентами и их взаимодействием. Эти компоненты могут быть программными модулями, библиотеками или другими элементами системы.
Пример. В диаграмме компонентов для веб-приложения можно показать компоненты: «Интерфейс пользователя», «База данных» и «Сервер приложений», а также их зависимости друг от друга.
Диаграмма пакетов позволяет организовать и сгруппировать элементы системы в пакеты, чтобы упростить представление больших систем. Это полезно, когда нужно увидеть, какие компоненты системы к чему относятся.
Пример. Для системы интернет-магазина можно включать такие пакеты, как «Пользовательский интерфейс», «Управление товарами», «Оплата». Это помогает разделить систему на логически связанные части.
Диаграмма профилей предназначена для описания расширений UML, которые можно использовать для конкретных доменов или областей применения. Эта диаграмма позволяет модифицировать существующие элементы UML — добавлять новые стереотипы и ограничения.
Пример. Для разработки веб-приложений можно создать диаграмму профилей, которая добавляет специализированные элементы: «Пользователь», «Сессия», «Запрос».
Диаграмма развертывания показывает физическое развертывание компонентов на ресурсах. Она отображает, как программные компоненты распределены по серверам и прочим устройствам.
Пример. Для облачной системы можно показывать серверы, на которых размещаются различные части приложения, такие как «Web-сервер», «База данных», «Сервер API».
Диаграмма кооперации, она же диаграмма взаимодействия, или диаграмма связей, описывает взаимодействия между объектами для выполнения конкретной задачи. Она ориентирована на коммуникацию объектов между собой, их действия и сообщения.
Пример. Для банковского приложения можно показать, как объект «Клиент» отправляет запрос на «Счет», а «Счет» инициирует транзакцию с банком.

Диаграммы поведения

Они отображают динамические аспекты системы. Показывают, как объекты и компоненты взаимодействуют с течением времени, как они меняют свое состояние или выполняют различные действия.
Рассмотрим основные виды:
Диаграмма прецедентов, или Use Case Diagram, используется для представления функциональных требований системы с точки зрения ее пользователей. Она описывает взаимодействие между пользователями и системой — показывает, какие задачи (прецеденты) система должна выполнять для пользователей.
Пример. Для системы онлайн-магазина можно показать, как «Покупатель» и «Администратор» взаимодействуют с системой, чтобы осуществить «Просмотр товаров», «Оформление заказа», «Добавление товара».
Диаграмма состояний показывает, как объект системы меняет свое состояние в ответ на события или действия. Она полезна для моделирования сложных объектов, которые перетекают из одного состояния в другое.
Пример. Для объекта «Заказ» в онлайн-магазине можно показывать такие состояния, как «Новый заказ», «Оплачен», «Отправлен», «Доставлен».
Диаграмма деятельности, или диаграмма активности, отображает поток управления в процессе. Ее используют для моделирования сложных бизнес-процессов, чтобы увидеть, как различные действия и решения переходят одно в другое.
Пример. Для оформления заказа можно показывать последовательность этапов: выбор товара, наполнение корзины, подтверждение заказа и завершение оплаты.
Диаграммы взаимодействия описывают взаимодействия между объектами или компонентами системы:
  • Диаграмма последовательности демонстрирует, как объекты взаимодействуют между собой в определенной последовательности. При этом видны время и порядок сообщений. Пример. Для транзакции в банке можно показать последовательности сообщений от клиента к серверу и затем к базе данных для выполнения перевода.
  • Диаграмма коммуникации иллюстрирует взаимодействия между объектами через передачи сообщений, но без акцента на временной последовательности. Пример. Визуализация может отображать, как клиент взаимодействует с веб-сервисом, отправляя запросы и получая ответы.
  • Диаграмма синхронизации используется для иллюстрирования многозадачных либо параллельных процессов — показывает, как синхронизируются различные потоки в системе. Пример. Для системы управления очередями диаграмма синхронизации может отображать, как запросы от пользователей обрабатываются параллельно и синхронизируются на сервере.
  • Диаграмма обзора взаимодействия, или диаграмма общего взаимодействия, показывает общую картину взаимодействия объектов системы в контексте выполнения определенной операции. Пример. Подобная визуализация может показывать, как различные системы — платежный шлюз, база данных, интерфейс пользователя — работают вместе в процессе оформления покупки.

Как построить UML-диаграмму: пошаговая инструкция

Чтобы разработать UML-диаграмму, необходимо выполнить несколько ключевых шагов, которые помогут точно визуализировать систему или бизнес-процесс.

1. Изучите основы синтаксиса UML

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

2. Ознакомьтесь с типами UML-диаграмм

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

3. Выберите инструмент для построения диаграммы

После того как определитесь с типом диаграммы, переходите к выбору инструмента для ее построения. Для создания UML-диаграмм можно использовать как стандартные графические редакторы, так и специальные онлайн-сервисы, такие как diagrams.net, Lucidchart. Эти инструменты позволяют удобно строить диаграммы, перетаскивать элементы, соединять их соответствующими связями.

4. Постройте диаграмму

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

5. Проверьте диаграмму

После того как построили диаграмму, важно ее проверить. Убедитесь, что все элементы и связи отображают правильную модель и что диаграмма действительно понятна для других пользователей. При этом не забывайте обновлять диаграмму по мере изменений в системе или бизнес-процессах, чтобы она оставалась актуальной.
Внедрение UML-диаграмм в бизнес-процессы и создание продуктов помогает наглядно моделировать сложные системы, чтобы упростить коммуникацию внутри команды и между подразделениями. Благодаря этому подходу можно повысить эффективность, снизить риски и оптимизировать работу.
Если вы хотите внедрить эти методы, улучшить управленческие практики и преумножить производительность вашей команды, поможет консалтинговая компания Neogenda. Мы реализовали более 100 успешных проектов для Tinkoff, Яндекс, Авито, Сбер и других лидеров рынка. Уже обучили более 5000 сотрудников. Запишитесь на бесплатную консультацию в Zoom, и наши эксперты предложат индивидуальные решения для вашего бизнеса.
]]> KPI для бизнеса: как оценить и улучшить результаты компании с помощью ключевых показателей http://neogenda.ru/blog/87emfdpmf1-kpi-dlya-biznesa-kak-otsenit-i-uluchshit http://neogenda.ru/blog/87emfdpmf1-kpi-dlya-biznesa-kak-otsenit-i-uluchshit?amp=true Sat, 22 Feb 2025 08:13:00 +0300 Бизнес часто сталкивается с проблемой — не получается точно оценить эффективность работы. Без четких метрик...

KPI для бизнеса: как оценить и улучшить результаты компании с помощью ключевых показателей

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

Для чего применяют KPI

KPI — это, простыми словами, инструмент для оценки эффективности работы компании, сотрудников и бизнес-процессов. Использовать KPI нужно, чтобы измерять текущие результаты, принимать взвешенные решения и достигать поставленных целей. Рассмотрим основные векторы, для которых применяют ключевые показатели:
  • Оценка производительности и результативности. С помощью KPI можно определить, насколько эффективно работают сотрудники и отделы. К примеру, в маркетинге и продажах показатели помогают отслеживать количество лидов, конверсию или доход от конкретных кампаний. Это позволяет вовремя понять, какие процессы нужно доработать.
  • Определение сильных и слабых сторон бизнеса. KPI показывают, что работает хорошо, а что не приносит ожидаемых результатов. Например, если компания использует показатели результативности для отдела продаж, можно легко понять, на каком этапе бизнес теряет клиентов или какие методы продаж пора корректировать.
  • Поддержка стратегического и оперативного планирования. Следует отслеживать результаты и выстраивать долгосрочную стратегию. KPI помогают установить критерии результативности и критерии эффективности. А это позволяет сфокусироваться на самых важных процессах и повысить их эффективность.
  • Мотивация сотрудников. Кипиай для сотрудников имеют большое значение в вопросах мотивации и системы премирования. Если четко определены цели, а система KPI прозрачна, специалисты понимают, чего от них ждут и как их усилия отражаются на успехе всей компании. Это повышает вовлеченность и продуктивность. К тому же важно учитывать, как на мотивацию влияет оклад KPI. Ведь оплата труда, которая зависит от достижения определенных показателей, может стать дополнительным стимулом для команды.
  • Оценка бизнес-процессов. KPI помогают понимать, какие процессы нужно автоматизировать или оптимизировать. Например, в логистике показатели способны повлиять на снижение времени доставки или расходов на транспорт, а в HR-сфере — улучшить процесс найма.

Когда KPI не нужны

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

Какие бывают виды KPI

Не существует универсального списка KPI. Их выбирают в зависимости от отрасли и особенностей бизнеса. Однако, можно выделить несколько ключевых категорий:
  • Финансовые помогают отслеживать финансовую эффективность компании. Пример KPI: чистая прибыль, рентабельность продаж.
  • Нефинансовые — оценка нематериальных аспектов бизнеса. Пример: удовлетворенность клиентов.
  • Качественные и количественные показатели. Первые оцениваются на основе субъективных критериев. Пример: компетентность сотрудников. Вторые измеряются числовыми значениями. Пример: количество продаж.
  • Индивидуальные KPI оценивают работу отдельного сотрудника. Пример: продуктивность менеджера по продажам.
  • Командные — показатели, оценивающие достижения команды. Пример: объем продаж отдела.
  • Запаздывающие измеряются после завершения процесса. Пример: чистая прибыль за квартал.
  • Опережающие KPI прогнозируют будущие результаты. Пример: предполагаемое количество лидов.
  • Оперативные — показатели для отслеживания краткосрочных процессов. Пример: время обработки заказов.
  • Стратегические KPI помогают оценить долгосрочные цели. Пример: доля на рынке.
  • Показатели результативности оценивают выполнение целей. Пример: количество завершенных проектов в срок.
  • Показатели эффективности позволяют понять, как используются ресурсы. Пример: рентабельность инвестиций (ROI).
  • Абсолютные — показатели, выраженные в числовых значениях. Пример: объем продаж.
  • Относительные — показатели, измеряемые в сравнении с другими величинами. Пример: доля рынка.
  • Функциональные — оценка работы конкретной функции. Пример: скорость обработки заявок в службе поддержки.
  • Проектные KPI — показатели, связанные с успешностью проектов. Пример: процент выполнения задач в проекте.
Выбор подходящих KPI зависит от целей компании и специфики ее работы, поэтому важно подбирать их индивидуально для каждой ситуации.

Как происходит внедрение KPI в компанию

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

Постановка целей и определение ключевых показателей

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

Разработка матрицы и карты KPI

Карта KPI — это инструмент, который позволяет визуализировать взаимосвязи между стратегическими целями компании и ключевыми показателями результативности (KPI). Она помогает понять, как каждый показатель влияет на достижение глобальных целей.
Матрица KPI дополняет карту. Она систематизирует и структурирует все показатели. Это таблица, в которой для каждого отдела или сотрудника указаны цели, соответствующие показатели результативности и способ их измерения.
Эти инструменты помогают наглядно увидеть, какие метрики влияют на достижение целей компании, делают процесс прозрачным и помогают рассчитывать KPI. Еще они позволяют отслеживать изменения в динамике показателей и корректировать стратегии, если это необходимо.

Разработка системы мотивации

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

Обучение персонала

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

Как рассчитать KPI

Правильный расчет KPI помогает контролировать результаты работы компании, отдела или сотрудников. Чтобы показатели выполняли свою задачу, важно учитывать их основные принципы:
  • Измеримость. Показатели должны быть четко определены и легко измеримы.
  • Доступность данных. Чтобы вычислить KPI, необходимо, чтобы все данные были доступны и актуальны.
  • Согласованность с целями. Показатели должны прямо соответствовать задачам компании. Без этого не получится отслеживать прогресс и видеть, как обстоят дела с достижением целей.
Эти принципы — основа для расчета KPI. Без понятных, доступных и измеримых данных невозможно точно отслеживать эффективность бизнеса.
Пример 1: KPI для отдела продаж.
Конверсия лидов означает процент лидов, которые превращаются в клиентов.
Формула: Конверсия = (Количество сделок / Количество лидов) х 100
За месяц было 1000 лидов и 250 заключенных сделок, значит, конверсия составит 25%.
Пример 2: KPI для маркетинга.
Стоимость привлечения клиента (CAC) измеряет, сколько компания тратит на привлечение одного клиента.
Формула: САС = Маркетинговые расходы / Количество новых клиентов
Допустим, компания потратила 500 000 рублей на маркетинг и привлекла 250 клиентов. Получается, стоимость привлечения одного клиента составит 2000 рублей.
Пример 3: KPI для системы мотивации сотрудников.
В этом случае можно использовать показатель производительности. Допустим, сотрудник должен выполнить 150 задач, а выполнил 120, его производительность = 120 / 150 х 100 = 80%
Этот показатель становится важной частью системы мотивации, потому что напрямую влияет на вознаграждения и премии. Чем лучше сотрудник выполняет свои KPI, тем больше бонусов он может получить.

Какие можно выделить плюсы и минусы KPI

Как и любой инструмент, KPI имеют свои преимущества и недостатки. Рассмотрим их подробнее.

Преимущества KPI

Четкая оценка эффективности
KPI позволяют объективно измерять успехи компании, отдела или сотрудника. Если использовать ключевые показатели эффективности, можно четко понять, насколько получилось достигнуть поставленных целей и какие процессы нужно улучшать. Например, в маркетинге с помощью KPI можно оценить эффективность рекламных кампаний или конверсии лидов.
Обоснованные решения
KPI предоставляют данные, на основе которых руководитель отдела или компании может принимать важные решения. Например, если KPI для сотрудников показывают низкую производительность, это может стать сигналом для изменения стратегии или пересмотра рабочего процесса.
Управление мотивацией сотрудников
KPI помогают создать прозрачную систему мотивации. Когда сотрудникам ясно, каких показателей результативности они должны достичь, растут вовлеченность и продуктивность. Например, если часть зарплаты зависит от выполнения определенных KPI, сотрудники будут стараться достигать этих целей.
Оптимизация бизнес-процессов
Ключевые метрики помогают выявить слабые места фирмы. Например, система KPI может показать, какие участки производственного процесса нужно оптимизировать или автоматизировать, чтобы повысить общую эффективность компании.
Мониторинг долгосрочной стратегии
С помощью стратегических KPI можно отслеживать прогресс в реализации долгосрочных целей, таких как рост рыночной доли или повышение клиентской лояльности.

Недостатки KPI

Фокусировка на узких аспектах
Сотрудники и менеджеры часто могут фокусироваться только на тех показателях, которые легко измеряются, при этом игнорировать более сложные, но не менее важные аспекты работы. Например, если главным показателем будет количество выполненных задач, это может привести к снижению качества работы — сотрудник может сосредоточиться на скорости выполнения, а не на качестве.
Отвлечение на краткосрочные цели
Оперативные KPI, ориентированные на достижение краткосрочных целей, могут отвлекать от более важных долгосрочных задач. Например, если бизнес слишком сосредоточен на немедленных финансовых результатах, это может мешать реализации стратегии.
Зависимость от количественных данных
KPI часто фокусируются на числовых показателях, таких как выручка, конверсия или количество проданных единиц. Однако важно учитывать, что качественные аспекты, такие как удовлетворенность клиентов или корпоративная культура, тоже имеют значение, но их сложнее измерить.
Сложность внедрения и адаптации
Внедрение системы KPI в компанию может быть сложным и затратным процессом. На это нужны время и усилия. Не всегда легко правильно выбрать индикаторы, которые точно отражают эффективность работы. К тому же иногда сотрудники против внедрения KPI, особенно если не понимают, как показатели связаны с их задачами и мотивацией.
Необходимость корректировки целей и показателей
Цели бизнеса могут меняться со временем, и в этом случае нужно пересматривать и корректировать матрицу KPI. Если показатели неправильно настроены, можно сделать неправильные выводы о том, как работает компания или отдел.

Какие основные ошибки выделяют при работе с KPI и как их избежать

Если использовать KPI неправильно, можно столкнуться с серьезными проблемами. Вот пять распространенных ошибок при работе с бизнес-метриками и рекомендации, как их избежать.
Ошибка Что значит Как избежать
1. Неопределенность целей Когда цели KPI неясны, трудно понять, какие нужны результаты. Из-за этого данные будут интерпретироваться неверно Четко формулируйте цели KPI, чтобы они соответствовали методу SMART и были конкретными, измеримыми, достижимыми, актуальными и ограниченными во времени
2. Слишком много KPI Чрезмерное количество показателей затрудняет анализ. Фокусироваться на ключевых аспектах бизнеса становится сложнее Ограничьте количество KPI до самых важных. Выберите те, которые напрямую влияют на эффективность работы
3. Игнорирование качественных показателей Если оценивать только числовые показатели, можно упустить важные моменты, например удовлетворенность клиентов Включайте в матрицу KPI как качественные, так и количественные показатели, чтобы учесть все важные факторы
4. Неадаптированные KPI для разных ролей Если использовать одинаковые KPI для разных сотрудников и отделов, можно получить нечестную оценку работы Разрабатывайте индивидуальные показатели для разных ролей, чтобы учесть конкретные задачи и ответственность каждого
5. Отсутствие регулярного мониторинга Без постоянного отслеживания и анализа результатов невозможно вовремя корректировать действия и достигать целей Внедрите систему проверки и анализа результатов KPI, чтобы вовремя менять стратегию
KPI — это мощный инструмент для оценки и оптимизации работы компании, сотрудников и процессов. Правильное внедрение показателей эффективности помогает повышать производительность и достигать целей.
Если хотите грамотно внедрить систему KPI и улучшить результаты бизнеса, команда Neogenda готова помочь. Мы работали с крупными компаниями, такими как Tinkoff, Яндекс, Авито и Сбер, обучили более 5000 сотрудников. Чтобы разобраться в актуальных практиках управления и достичь новых высот, оставьте заявку на бесплатную консультацию. Эксперты Neogenda помогут построить верный маршрут.
]]> Организационная структура компании: ключ к эффективному управлению http://neogenda.ru/blog/6s5g25rzb1-organizatsionnaya-struktura-kompanii-kly http://neogenda.ru/blog/6s5g25rzb1-organizatsionnaya-struktura-kompanii-kly?amp=true Sun, 23 Feb 2025 08:22:00 +0300 Артур Нек Успех компании во многом зависит от ее внутреннего устройства. Потому что организационная структура предприятия —...

Организационная структура компании: ключ к эффективному управлению

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

Что такое организационная структура предприятия

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

Зачем бизнесу нужна организационная структура

Ясная схема организационной структуры важна для любого бизнеса. Это не зависит от его масштаба. Оргструктура помогает компании:
  • Быстрее принимать решения — понятная иерархия позволяет быстро реагировать на изменения.
  • Оптимизировать работу отделов — можно избежать дублирования функций и хаоса в процессах.
  • Наладить прозрачное взаимодействие — сотрудники понимают, как организована работа и куда обращаться с вопросами.
  • Снизить риски ошибок — четкое распределение обязанностей исключает неопределенность в действиях.
  • Расти и масштабироваться — с хорошо продуманной структурой проще расширить компанию и внедрять новые проекты.
Организационная структура — это не только инструмент управления, но и залог стабильности и развития бизнеса.

Какие основные элементы организационной структуры можно выделить

Организационная структура состоит из нескольких ключевых элементов, которые позволяют стабильно работать и эффективно управлять компанией. Каждый элемент играет свою роль для внутренних процессов и взаимодействий:
1. Иерархическая структура управления — это распределение полномочий и подчинения между сотрудниками и подразделениями. Каждый знает, кому он подчиняется и от кого получает задания.
Пример. В торговой компании с филиалами в разных регионах сотрудники магазинов подчиняются менеджеру филиала, а он — региональному руководителю. Это позволяет быстро принимать решения и контролировать выполнение задач.
2. Структурные подразделения и отделы — это разделение компании на функциональные части, каждая из которых выполняет определенные задачи. Четко выстроенная структура отдела определяет роли, обязанности и взаимодействие сотрудников.
Пример. В компании есть следующие отделы: производственный, который отвечает за изготовление продукции; отдел продаж, который ищет клиентов и заключает сделки; бухгалтерия, которая ведет финансовую отчетность. У каждого отдела определенные роли и обязанности.
3. Коммуникационные каналы — это способы обмена информацией между различными уровнями и подразделениями компании. Они обеспечивают бесперебойное движение данных. Благодаря этому команда работает слаженно, а задачи решаются быстро.
Пример. IT-компания для управления проектами использует CRM-систему. Она позволяет командам координировать действия в реальном времени, оставлять комментарии, ставить задачи и отслеживать их выполнение.
4. Процессы и обязанности — четкое определение задач и процессов, которые каждый сотрудник или подразделение должны выполнять. Это помогает избежать путаницы и дублирования работы, обеспечить высокую степень ответственности на всех уровнях.
Пример. В логистической компании есть прописанные процессы для обработки заказов: менеджер принимает заявку от клиента; отдел доставки организует перевозку товара; складской персонал отвечает за погрузку и выгрузку. Каждое звено понимает, за какой этап работы отвечает.

Какие бывают типы организационных структур

Каждая управленческая структура имеет свои особенности и области применения. Рассмотрим основные виды, их преимущества и недостатки:

Линейная структура

Представляет собой простую иерархию, в которой каждый сотрудник подчиняется только одному руководителю. Решения принимаются сверху вниз, и роль каждого человека четко определена.
Пример. Линейную структуру часто используют в малых организациях, где процессы не нужно как-то сложно координировать. Это могут быть небольшие производственные предприятия.
Плюсы:
  • ростота и понятность;
  • быстрое принятие решений;
  • четкое распределение ответственности.
Минусы:
  • ограниченная гибкость;
  • неэффективность при расширении компании.

Линейно-штабная структура

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

Функциональная структура

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

Дивизионная структура управления

Делит компанию на самостоятельные подразделения (дивизионы), каждым из которых управляет свой руководитель. Продукты, регионы или целевые аудитории — тоже свои.
Пример. Структура используется в крупных компаниях, которые работают на разных рынках или с различными группами продукции. Это могут быть многонациональные корпорации, такие как Procter & Gamble или General Electric.
Плюсы:
  • гибкость в управлении;
  • адаптация к изменениям на рынке;
  • ответственность и независимость дивизионов.
Минусы:
  • потенциальное дублирование функций и ресурсов между дивизионами;
  • проблемы с контролем.

Матричная структура управления

Представляет собой комбинацию функциональной и проектной структуры. В этой системе сотрудники могут подчиняться как своему функциональному руководителю, так и руководителю проекта. Это позволяет работать над несколькими задачами одновременно.
Пример. Используется в больших организациях с проектной деятельностью — в IT-компаниях или крупных строительных фирмах, где важно, чтобы специалисты с разными компетенциями работали над одним проектом.
Плюсы:
  • повышенная гибкость и адаптивность к проектным задачам;
  • лучшая координация между функциями и проектами.
Минусы:
  • риски конфликтов из-за двойного подчинения;
  • долгое принятие решений.

Горизонтальная структура

Характеризуется минимальной иерархией. Сотрудники в таких организациях часто имеют больше свободы и ответственности, поэтому решения принимают совместно.
Пример. Обычно применяется в небольших фирмах, где важна инициатива, например в технологических стартапах или креативных агентствах.
Плюсы:
  • быстрое принятие решений;
  • высокая степень свободы для сотрудников;
  • мало бюрократии; простая коммуникация.
Минусы:
  • неэффективность при росте компании;
  • проблемы с распределением обязанностей и ответственности.

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

Каждая структурная схема подходит для определенных задач. Это может зависеть от размера компании, ее сферы и целей. Выбор подходящей структуры — это важное стратегическое решение. Оно напрямую влияет на эффективность работы, коммуникации и развитие бизнеса. Рассмотрим ключевые факторы, которые помогут выбрать подходящий тип:
1. Определите размер и стадию развития компании
Малый и средний бизнес, как правило, использует более простые формы структуры, такие как линейная или горизонтальная, где минимальное количество уровней управления. В крупных организациях, в которых нужна более сложная координация и разделение обязанностей, часто применяют функциональную, дивизионную либо матричную структуры.
2. Учитывайте отрасль и характер бизнеса
Структура предприятия должна соответствовать специфике ее деятельности. Например, компании, которые производят товары массового потребления, могут выбрать функциональную структуру. В этом случае каждый отдел будет фокусироваться на своей ключевой задаче (продажи, маркетинг, производство). Компаниям, которые работают с разными продуктами или в нескольких регионах, лучше подойдет дивизионная структура — она удобна для автономности.
3. Оцените потребности в гибкости и инновациях
Если ваш бизнес работает в условиях высокой неопределенности и изменения происходят быстро, например, в сфере технологий или стартапах, горизонтальная или матричная структуры могут стать отличным выбором. Они позволяют минимизировать бюрократию и быстрее принимать решения. В таких структурах у сотрудников часто большая степень свободы и ответственности.
4. Подумайте о коммуникации и координации
Важно учитывать, как будет происходить коммуникация внутри компании. Если у вас несколько функциональных отделов, но нужно, чтобы каждый работал над общими задачами, подойдет матричная структура. Она формирует горизонтальные связи между отделами и позволяет эффективнее работать над проектами. А если в приоритете четкая вертикаль власти и меньшее количество взаимодействий между отделами, оптимальной будет линейная структура.
5. Рассмотрите сложность управления и принятия решений
В крупных компаниях, у которых множество продуктов и рынков, важно учитывать, как лучше принимать решения и координировать их между подразделениями. Линейно-штабная или функциональная структуры подойдут для более стабильных компаний с четко определенными задачами. При этом дивизионная и матричная лучше работают в тех компаниях, которым нужны гибкость и более сложные связи между подразделениями.
6. Рассмотрите корпоративную культуру
В компаниях с более формальной корпоративной культурой, где важен строгий контроль и четкие инструкции, лучше всего будет работать линейная или линейно-штабная структура. В фирмах с инновационной и гибкой культурой, где важна свобода действий и креативность сотрудников, оптимальными будут горизонтальная или матричная структура.
Еще при выборе подходящего типа оргструктуры важно учитывать общую корпоративную структуру компании. То есть, как ваша организация в целом ориентируется на управление, контроль и коммуникации между высшим руководством, подразделениями и сотрудниками. Корпоративная структура, в свою очередь, должна поддерживать выбранную оргструктуру, цели и стратегию компании, но в то же время быть гибкой.

Какие ошибки при выборе организационной структуры чаще всего бывают и как их избежать

Выбор организационной структуры — не просто формальность. Это ключевой шаг, который определяет будущее компании. Неправильно выбранная структура может стать серьезным препятствием для роста и развития. Рассмотрим типичные ошибки и способы их предотвращения:
Ошибка К чему ведет Как избежать
Отсутствие анализа бизнес-процессов Структурная схема, которая не учитывает особенности компании, может негативно повлиять на скорость работы и снизить прибыль Прежде чем выбирать структуру, проведите детальный анализ процессов, определите узкие места, приоритеты и долгосрочные цели компании
Слишком сложная структура Перегруженная структура — это путь к бюрократии, долгим решениям и конфликтам между отделами Выбирайте структуру, которая подходит уровню компании. Убедитесь, что уровней управления мало, но они эффективны
Недостаток коммуникационных каналов Сотрудники не понимают, куда обращаться с вопросами, а это приводит к хаосу, и работа становится неэффективной Внедрите инструменты, которые помогут упростить взаимодействие, например CRM-системы
Игнорирование изменений Невозможность адаптироваться к росту компании или изменениям на рынке, делает бизнес неконкурентоспособным Регулярно оценивайте эффективность структуры и вносите изменения по мере роста или трансформации компании
Дублирование функций Одни и те же обязанности приводят к конфликтам и избыточным затратам Проведите аудит функций отделов, чтобы исключить дублирующие роли. Четко распределите обязанности между подразделениями
Недостаток гибкости Жесткая структура тормозит развитие и мешает адаптироваться к изменениям Для компании в быстро меняющихся отраслях выберите более гибкие подходы, например матричную или горизонтальную структуру
Правильная организационная структура — основа успешного бизнеса. Она помогает наладить взаимодействие между сотрудниками, настроить коммуникацию и повысить продуктивность на всех уровнях.
Если вы хотите внедрить современные методы управления и улучшить организационные процессы в вашем бизнесе, обратитесь в Neogenda. Наши решения уже помогли таким компаниям как Сбер, Яндекс, X5 Group и Тинькофф. Запишитесь на бесплатную консультацию, чтобы найти структуру для своего успеха.
]]> Как использовать аналитику из Канбан-метода для улучшения Scrum-событий http://neogenda.ru/blog/3u0uzmubo1-kak-ispolzovat-analitiku-iz-kanban-metod http://neogenda.ru/blog/3u0uzmubo1-kak-ispolzovat-analitiku-iz-kanban-metod?amp=true Mon, 24 Feb 2025 08:31:00 +0300 Артур Нек Все больше Scrum-команд осознают преимущества использования Канбан-систем для управления рабочими процессами. Заимствование практик из разных...

Как использовать аналитику из Канбан-метода для улучшения Scrum-событий

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

Планирование спринта: определение объема работы

Цель планирования спринта — договориться о том, что и как будет сделано.
Первый шаг к принятию объективного решения о том, какой объем работы ваша команда может выполнить во время спринта, — это изучить свои возможности. Самый эффективный подход, который можно использовать, — это открыть свои предыдущие спринты и посмотреть, сколько задач вы выполнили за один спринт за последние 3–6 месяцев.
Гистограмма пропускной способности показывает количество задач, выполненных за определенный период. Она группирует данные за каждые две недели и фиксирует количество завершенных задач.
Пример анализа:
  • 5 задач удалось выполнить только в одном спринте;
  • 10 задач — в двух спринтах;
  • 12 задач — в одном;
  • 14 задач — в двух и т. д.
Теперь можно прогнозировать:
  • 98% вероятность, что команда выполнит не менее 5 задач;
  • 85% вероятность, что выполнит 10 задач;
  • 70% вероятность, что справится с 12 задачами;
  • 50% вероятность, что закончит 14 задач.
Если команда однажды завершила 24 задачи, это не значит, что такой результат стабилен. Вероятность повторения — менее 30%. Планируя слишком большой объем задач, есть риск переноса их на следующий спринт.
Используйте этот анализ, чтобы установить реалистичные цели. Если команда берет на себя заведомо невыполнимый объем работы, она ставит под сомнение собственные гарантии.

Ежедневные совещания (стендапы): согласование плана работы

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

Ретроспектива спринта: определение точек роста

Ретроспектива помогает выявить проблемные зоны и определить, как улучшить работу команды.
Здесь очень помогает анализ Диаграммы распределения времени цикла. Она визуализирует все ваши выполненные задачи в виде точек, разбросанных по графику:
  • горизонтальная ось — временная шкала,
  • вертикальная ось — время выполнения задач.
Анализируйте задачи в верхней части диаграммы (те, которые выполнялись дольше всего):
  • Задачи со сроком выполнения более 14 дней требуют особого внимания, так как они могли переноситься из спринта в спринт.
  • Красные точки (задачи, попавшие в блокировку) — определите, что именно их задерживало.
Еще одним важным аспектом является анализ блокировок, возникших во время спринта, и повышение понимания об их влиянии на производительность.
Красные точки немного большего размера представляют задачи, которые были затронуты блокировкой в любой момент их жизненного цикла.
Выявление и устранение основных причин появления блокировок — один из наиболее эффективных способов обеспечения эволюционных изменений. Вы можете использовать блокировки Диаграммы распределения времени цикла, для кластеризации блокеров и определения приоритетов тех, которые больше всего влияют на длительность рабочего процесса.
Независимо от того, насколько последовательно и внимательно осуществляется планирование, всегда остается некоторая степень неопределенности. Когда в середине спринта возникает необходимость выполнить незапланированные задачи, это может стать неприятным сюрпризом. Анализ объема непредвиденной работы и оценка ее влияния на цель вашего спринта открывают возможности для улучшения.
Еще один важный анализ — Диаграмма распределения пропускной способности. Это отличный инструмент, который можно использовать, когда нужно выявить большой объем незапланированных задач, с которыми приходится иметь дело вашей команде. Она отображает все ваши выполненные задачи, разделенные по категориям, тем самым показывая процентную долю ускорения, которого вы достигли.
Если выполнение незапланированных задач во время спринтов становится регулярным явлением, подумайте о резервировании ресурсов заранее, чтобы эффективно управлять выполнением непредвиденных задач и быть уверенным, что это не скажется отрицательно на всем рабочем процессе.

Канбан и Scrum отлично дополняют друг друга

Реальность такова, что не следует выбирать какой-то один инструмент: выясните, какие методы лучше всего подходят для вашей команды, и внедрите их.
Под гибкостью мы подразумеваем совместное использование Канбан и Scrum для более эффективного планирования, отслеживания и управления рабочим процессом, что позволит быстрее выполнять поставленные задачи без потери качества конечного продукта.
]]> Финализация целей http://neogenda.ru/blog/9ghf7kut11-finalizatsiya-tselei http://neogenda.ru/blog/9ghf7kut11-finalizatsiya-tselei?amp=true Wed, 05 Mar 2025 08:44:00 +0300 Андрей Сидоренко Вы уверены в своих целях? Готовы ли пустить их в работу?

Финализация целей

Вы уверены в своих целях? Готовы ли пустить их в работу?
Ранее мы связали цели OKR с ключевой результирующей метрикой (полярной звездой), показали их влияние на финансовую модель и убедились, что это не рутинная работа.
Но прежде чем перейти к ключевым результатам, давайте зафиналим наши цели. Убедимся, что они действительно лучшие из возможных.

Простая проверка: поделитесь целью

Один из самых действенных способов улучшить цель — обсудить её с кем-то. Лично мне нравится делиться целями с командой. Это может вызвать волнение или даже страх, ведь ты вложил столько сил в их разработку!
Но самое важное — это обратная связь. И чем круче получать её, тем интереснее комментировать чужие цели в ответ.

Ключевые вопросы для проверки целей

Вот чек-лист, который я использую, когда впервые оцениваю цели проекта:
  • Цель важна для бизнеса? Она основана на реальном бизнес-результате?
  • Приоритетна ли она для команды и компании?
  • Достаточно ли амбициозна? Подталкивает ли к тому, что раньше казалось невозможным?
  • Вдохновляет ли? Её легко запомнить?
  • Реально ли достичь её в ближайший квартал?
Теперь разберём пять вопросов, которые помогут уточнить цель и получить на неё обратную связь.

1. В цели заложен рост, прорыв или исследование?

OKR описывают изменения. Если цель — сохранить статус-кво, так и формулируйте: «Удержать X». Если цель — прорыв, сделайте её вдохновляющей: «Завоевать новый регион». Если речь об исследовании, обозначьте гипотезу: «Найти эффективные каналы продвижения».

2. Можно ли сделать цель конкретнее?

Расплывчатые цели — слабые. Чем точнее формулировка, тем больше ясности в команде.
Пример:
  • ❌ «Порадовать наших клиентов»
  • ✅ «Войти в ТОП-100 продавцов Wildberries»
Однако важно не перегружать цель деталями. Она должна задавать направление, а не диктовать пошаговый план.

3. Ориентирована ли цель на достижения?

Язык важен! Цель должна вдохновлять на действия, а не быть пассивной. Задайте себе вопрос: вдохновляет ли цель на следующее правильное действие? Что начнут обсуждать люди?

4. Можно ли сформулировать её короче?

Чем проще и лаконичнее цель, тем легче её запомнить. Избегайте модных терминов, непонятных команде. Чем короче формулировка, тем выше отклик.

5. Можно ли сделать её более запоминающейся?

Свяжите цель с культурой компании: используйте внутренний жаргон, фирменные метафоры. Это сделает её естественной для команды и повысит вовлечённость.
Готово? Осталась пара шагов!
Теперь у вас есть 1–2 цели, в которых вы уверены. Вскоре мы опубликуем примеры различных целей в нашем блоге.
Если у вас есть сомнения, пишите свои цели в комментариях к видео — разберём, дадим обратную связь и подскажем, как улучшить формулировки!
]]> Agile-трансформация: что это и зачем нужно компаниям http://neogenda.ru/blog/daeykmnnt1-agile-transformatsiya-chto-eto-i-zachem http://neogenda.ru/blog/daeykmnnt1-agile-transformatsiya-chto-eto-i-zachem?amp=true Sun, 16 Mar 2025 08:46:00 +0300 Артур Нек Agile-трансформация — это процесс перехода компании от традиционных методов управления к гибким подходам в работе....

Agile-трансформация: что это и зачем нужно компаниям

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

В чем отличие agile-трансформации от простого внедрения agile

Внедрить agile и провести agile-трансформацию — немного разные понятия.
Многие компании начинают внедрять отдельные элементы — Scrum-доски, ежедневные стендапы, Канбан-системы — но это лишь инструменты, которые сами по себе не дадут нужного эффекта без изменения подхода к работе.
Иногда компании внедряют гибкий подход только в часть команд. А в остальных сохраняют жесткую иерархию, где все решения принимаются топ-менеджментом без учета обратной связи от команд.
В обоих ситуациях преимущества agile будут минимальными, а сотрудники быстро разочаруются в очередной корпоративной инициативе. Все потому, что никто не поймет преимуществ agile. У сотрудников просто появится больше работы и ответственности, но подход к работе не поменяется.
Цель agile-трансформации — создать компанию, которая сможет быстро адаптироваться к изменениям рынка и потребностям клиентов и поэтому будет быстрее выпускать продукты на рынок, повышая удовлетворенность клиентов. А главное — где agile работает во всех командах и на всех уровнях.

Признаки, что компании нужна agile-трансформация

Продукты долго не выходят на рынок. Если от идеи до запуска проходят месяцы или даже годы, компания рискует создавать устаревшие продукты еще до выхода. Гибкий подход позволяет быстро тестировать гипотезы и запускать новые продукты, чтобы не терять потенциальную прибыль.
Компания долго реагирует на изменения рынка. Если компания не может оперативно реагировать на действия конкурентов, изменения в законодательстве или новые потребности пользователей, теряет на этом клиентов и время. А значит — и деньги. Agile-подход позволяет быстро перераспределять ресурсы и менять приоритеты в зависимости от текущей ситуации.
Текучка специалистов. Жесткая иерархия, микроменеджмент и размытая ответственность приводят к тому, что лучшие сотрудники уходят к конкурентам. Люди хотят работать в среде, где ценят их мнение, дают возможность принимать решения и видеть результаты своей работы. Agile-трансформация помогает перестроить корпоративную культуру и создать благоприятную обстановку для сотрудников.
Проблемы с коммуникацией внутри компании. Если в компании маркетинг, продажи, разработка и другие отделы работают изолированно друг от друга, появляется недопонимание, конфликты и работа ради работы. Agile-подход предполагает формирование кросс-функциональных команд, где специалисты разных профилей работают вместе над общей целью.
Нет понимания, ради чего работает компания. Если не получается ответить на вопрос, какую ценность создала команда за последний месяц, либо, если команда оценивает работу только по количеству выполненных задач, это признак проблем с метриками. Agile-трансформация помогает определить понятные ценности для пользователя и бизнеса.
Кому нужна agile-трансформация

Преимущества agile-трансформации для бизнеса

Ускоряет вывод продукта на рынок. Компания McKinsey провела исследования и выяснила, что agile-команды задерживают выпуск продуктов на 30% реже по сравнению с традиционными методами. Это значит, что команды сокращают цикл разработки и изначально создают нужный и работающий продукт.
Повышает качество продуктов. В agile-подходе команды работают короткими итерациями и получают регулярную обратную связь от пользователей. Это позволяет выявлять и исправлять проблемы на ранних этапах, а не в конце длительного цикла разработки. В результате конечный продукт лучше соответствует потребностям пользователей.
Растет вовлеченность сотрудников. В agile-подходе команды сами определяют, как достичь поставленных целей. Это повышает их мотивацию и заинтересованность в результате. Это доказали McKinsey в еще одном исследовании. Они проанализировали 22 компании и выявили, что agile-трансформация повысила вовлеченность сотрудников на 20-30%.
Снижаются расходы и улучшается unit-экономика проектов. Agile позволяет быстро проверять идеи на небольших сегментах пользователей и масштабировать те решения, которые приносят прибыль.
Повышается прозрачность процессов. Регулярные встречи и визуализация рабочих процессов через Kanban-доски делают работу команд видимой для всех. Руководители получают актуальную информацию о статусе проектов, проблемах и рисках. Повышается доверие между всеми участниками процесса, снижается количество конфликтов и недопониманий.

Как понять, что компания готова к agile-трансформации

Перед началом agile-трансформации нужно понять, насколько компания готова к изменениям. Это поможет определить, с чего начать и выбрать наиболее подходящую стратегию трансформации. Оценивать компанию можно разными способами.
По модели Киневина. Это инструмент, который помогает понять, в какой среде работает компания и как ей лучше управлять. Модель выделяет четыре типа ситуаций:
  • Простая ситуация — когда все понятно и предсказуемо. Когда известно, как решать задачи.
  • Сложная ситуация — когда нужно подумать и разобраться, прежде чем действовать.
  • Запутанная ситуация — когда нельзя предсказать, что произойдет, и приходится пробовать разные решения.
  • Хаотичная ситуация — когда все очень нестабильно и нужно быстро действовать.
Agile-подходы лучше всего работают, когда ситуация сложная или запутанная.
Например, компания, которая делает мобильные приложения, постоянно узнает про новые технологии и меняющиеся желания пользователей. Ей нужно быстро подстраиваться под изменения. Agile поможет такой компании работать маленькими шагами и быстро адаптироваться.
А вот завод, где производят лекарства по строгим правилам и процессам, может не получить большой пользы от полного перехода на agile. Для него лучше взять только некоторые полезные практики.
Небольшое пояснение к схеме: известные неизвестные — это факторы, о существовании которых мы знаем, но не знаем их точных значений или влияния. Неизвестные неизвестные — это факторы, о существовании которых мы даже не подозреваем.
По Agile suitability model. Эта модель помогает оценить, готова ли компания к agile, по разным показателям:
  • Культура компании. Ценят ли в компании совместную работу и новые идеи.
  • Как устроено управление. Много ли начальников, кто принимает решения.
  • Размер команд. Для agile лучше команды по 5-9 человек.
  • Общение с клиентами. Можно ли быстро узнать их мнение и собрать обратную связь.
  • Типы проектов и нужна ли для них гибкость.
  • Технические инструменты и отлаженность процессов работы.
Компания получает оценки от 1 до 5 по каждому пункту. Если средняя оценка меньше 3, значит, есть серьезные препятствия для перехода на agile. Сначала лучше исправить проблемы, а уже потом менять подход к работе.
Например, рекламное агентство с хорошей командной работой и слишком большим числом согласований, может сначала упростить процесс принятия решений. А уже потом внедрять agile-методы.
Вот примерная таблица, которая поможет провести оценку:
Категория Описание
Культура компании 1 – Сотрудники избегают изменений, боятся рисковать, информация не распространяется.
2 – Сотрудники неохотно принимают изменения, мало делятся информацией.
3 – Нейтральное отношение к изменениям, информация распространяется не всегда.
4 – Сотрудники открыты к изменениям, делятся знаниями, готовы экспериментировать.
5 – Активно поддерживают изменения, открыто обсуждают ошибки, постоянно учатся.
Структура управления 1 – Жесткая иерархия, все решения принимает руководство.
2 – Многоуровневая структура, долгие согласования.
3 – Средняя иерархия, некоторые решения принимаются на уровне команд.
4 – Небольшая иерархия, команды могут работать автономно.
5 – Плоская структура, команды самоорганизуются и принимают большинство решений.
Размер и распределение команд 1 – Очень большие команды (более 20 человек), работающие в разных часовых поясах.
2 – Большие команды (15-20 человек) с разной географией.
3 – Средние команды (11-15 человек), работающие в одном или близких офисах.
4 – Команды оптимального размера (5-9 человек), работающие в разных местах.
5 – Команды оптимального размера (5-9 человек), работающие в одном месте.
Взаимодействие с клиентами 1 – Очень редкое общение с клиентами, через посредников.
2 – Ограниченное общение, в основном через формальные каналы.
3 – Периодическое взаимодействие, есть возможность получать обратную связь.
4 – Регулярное взаимодействие, клиент доступен для команды.
5 – Постоянное взаимодействие, представитель клиента работает вместе с командой.
Тип и критичность проектов 1 – Высококритичные проекты с жесткими требованиями и регуляциями.
2 – Формализованные проекты с мало меняющимися требованиями.
3 – Смешанные проекты, некоторые требования могут меняться.
4 – Проекты с изменяющимися требованиями, допускающие гибкость.
5 – Инновационные проекты, требующие постоянной адаптации.
Технические практики 1 – Отсутствие автоматизации, ручное тестирование, редкие релизы.
2 – Минимальная автоматизация, долгий цикл выпуска продукта.
3 – Частичная автоматизация, средний цикл выпуска.
4 – Хорошая автоматизация тестирования, быстрые релизы.
5 – Полная автоматизация, непрерывная интеграция и доставка.
Зрелость процессов 1 – Хаотичные или отсутствующие процессы.
2 – Базовые процессы без систематического применения.
3 – Определенные процессы, соблюдаемые командами.
4 – Отлаженные процессы с измерением эффективности.
5 – Оптимизированные процессы, постоянно улучшаемые.
Также понять, готова компания к трансформации или нет, можно по простому анализу:
  1. Опросите сотрудников, насколько они готовы к изменениям в компании.
  2. Проведите интервью с руководителями разных уровней и оцените, готовы ли они внедрять изменения и меняться вместе с командами.
  3. Проанализируйте несколько недавних проектов: как быстро вносились изменения, насколько эффективно работали команды, какие проблемы возникали.
  4. Оцените текущие процессы принятия решений: кто и как быстро принимает решения, насколько они понятны для команд.
Если после анализа вы поймете, что сотрудники боятся перемен, руководители не готовы делегировать, проекты затягиваются из-за бюрократии, а решения принимаются медленно, стоит задуматься об agile-трансформации.

Как провести agile-трансформацию в компании

Внедрение гибких методологий — поэтапный процесс. Рассказываем о каждом.

Подготовительный этап: сформировать стратегию трансформации

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

Организовать стратсессию для руководителей и ключевых стейкхолдеров

Любая серьезная трансформация начинается сверху. Если руководство не поддержит изменения, они просто не приживутся. Поэтому нужно провести стратегическую сессию, на которой:
  • Объяснить топ-менеджменту компании, как именно agile-подход поможет достичь бизнес-целей.
  • Предположить основные проблемы, которые могут возникнуть, и обсудить их.
  • Определить роли в процессе трансформации (кто будет спонсором, кто — мотиватором команд).

Создать дорожную карту трансформации с конкретными этапами

Дорожная карта — это визуализация вашего пути к agile-организации. Она должна включать:
  • Последовательность этапов трансформации (что за чем следует).
  • Временные рамки для каждого этапа.
  • Ключевые вехи, по которым можно отслеживать прогресс.
  • Зоны ответственности команд и отдельных сотрудников.
Хорошая дорожная карта не должна быть слишком детализированной. Но должна давать четкое понимание будущих действий и основных этапов.
Читайте также: Что такое роадмап проекта, как его сделать и в чем его отличие от продуктового роадмапа
Обучить сотрудников Agile и сформировать несколько agile-команд
Этот шаг нужен для тех компаний, где еще не используется Agile. Не стоит внедрять гибкие методологии сразу во всех сферах. Лучше делать это поэтапно и начинать с нескольких команд. Для этого сотрудников нужно сначала обучить. Провести базовые тренинги по agile-мышлению, воркшопы по Scrum и Kanban для команд, которые будут использовать эти фреймворки. Также стоит обучить будущих скрам-мастеров, product owner и agile-коучей.
Затем можно постепенно трансформировать работу. Для этого:
  • Выберите 2-3 команды, которые готовы к изменениям. Создайте подходящие условия: пространство для работы, инструменты для управления проектами, отсутствие микроменеджмента.
  • Определите подходящие проекты — они не должны быть критичными для бизнеса, чтобы не навредить компании в случае сложностей.
  • Когда внедрите agile в отдельных командах, через время анализируйте результаты. Собирайте обратную связь и корректируйте процессы. Когда увидите первые успехи — увеличенную скорость разработки, улучшение качества продукта или повышение удовлетворенности клиентов, постепенно масштабируйте agile-подход на другие команды.

Внедрите инструменты для отслеживания процессов

Один из ключевых принципов agile — прозрачность. Чтобы ее добиться, нужно использовать инструменты для управления проектами:
  • Физические или онлайн kanban-доски для визуализации рабочего процесса.
  • Инструменты для планирования спринтов и отслеживания прогресса: Jira, Asana и др.
  • Сервисы для проведения встреч, ретроспектив и сбора обратной связи.
  • Дашборды для отслеживания ключевых метрик.
Главное — не перегрузить команды инструментами, чтобы не создать лишнюю бюрократию и не нагрузить сотрудников лишней работой.
Инструменты для управления проектами

Определите метрики успеха и способы отслеживания

Чтобы понимать, насколько успешна ваша трансформация, нужно определить конкретные метрики и регулярно их отслеживать:
  • Бизнес-метрики. Например, time-to-market, возврат инвестиций, удовлетворенность клиентов.
  • Метрики процесса. Например, скорость работы команд, предсказуемость поставок, частота релизов.
  • Метрики культуры. Например, вовлеченность сотрудников, текучесть кадров, количество инициатив от сотрудников.
  • Технические метрики. Например, количество багов, скорость внедрения изменений, стабильность системы.
Читайте также: 5 самых важных Agile-метрик и 11 второстепенных

Проблемы, которые мешают Agile-трансформации

Сопротивление изменениям со стороны сотрудников и менеджмента. Сотрудники могут бояться потерять стабильность, понятную роль или статус в компании. А менеджеры — потерять контроль над сотрудниками и авторитет.
Как это проявляется:
  • Саботаж новых процессов («У нас и так все работает, зачем что-то менять?»).
  • Формальное соблюдение процессов без понимания их сути.
  • Работа старыми методами.
Как преодолеть:
Активно вовлекайте сотрудников в процесс трансформации с самого начала. Давайте людям выражать свое мнение.
  • Хвалите сотрудников и поощряйте тех, кто поддерживает изменения.
  • Трансформируйте роль менеджеров из контролирующей в поддерживающую.
Сложности из-за совмещения старых и новых процессов. В большинстве компаний невозможно в один день полностью переключиться на agile. В итоге какое-то время компания работает в переходном периоде, когда старые и новые процессы сосуществуют.
Основные трудности:
  • Команды должны соблюдать требования и старых, и новых процессов.
  • Конфликт приоритетов между agile и традиционными командами.
  • Непонимание, какому процессу следовать в конкретной ситуации.
  • Перегрузка сотрудников из-за параллельного использования разных систем.
Как преодолеть:
  • Создайте четкую карту переходного периода с указанием, какие процессы остаются, а какие меняются.
  • Определите правила взаимодействия между agile и традиционными командами.
  • Временно увеличьте ресурсы для команд, которые находятся в переходном периоде.
  • Постепенно убирайте устаревшие отчеты и процессы.
Недостаток знаний и опыта в области agile-методологий. Иногда компании внедряют agile, хотя не понимают всех нюансов методологии. В итоге практики применяются поверхностно, без понимания самой сути.
Как преодолеть:
  • Инвестируйте в обучение сотрудников всех уровней, не только команд разработки. Поощряйте получение сертификатов (PSM, PSPO, SAFe) ключевыми сотрудниками.
  • Пригласите опытных agile-коучей для поддержки команд на ранних этапах.
  • Регулярно проводите ретроспективы не только процесса разработки, но и самого внедрения agile.
Разочарование руководства из-за медленных результатов. Руководители часто ожидают быстрых улучшений после начала agile-трансформации. Но бывает, что сначала продуктивность может даже снизиться, пока команды адаптируются к новым методам работы.
Типичные ситуации:
  • Сомнения в целесообразности продолжения трансформации.
  • Возврат к старым методам при первых трудностях.
  • Сокращение бюджета на трансформацию до того, как появятся реальные результаты.
Как преодолеть:
  • Заранее установите реалистичные ожидания о сроках появления первых результатов.
  • Фокусируйтесь на измеримых метриках, которые показывают прогресс. Хоть и небольшой.
  • Разделите трансформацию на небольшие этапы с ясными критериями успеха.
  • Регулярно демонстрируйте связь между agile-практиками и бизнес-целями компании.
Проведение agile-трансформации
Сложность масштабирования agile-подхода на всю организацию. Часто компании успешно внедряют agile в отдельных командах, но с переносом на всю организацию не справляются.
Основные проблемы:
  • Непонимание как адаптировать agile для нетехнических отделов.
  • Сложности координации работы множества agile-команд.
  • Конфликты между agile-командами и традиционными структурами вроде финансов и HR.
  • Потеря гибкости из-за масштабирования.
Как преодолеть:
  • Масштабируйте с помощью специальных фреймворков с учетом специфики вашей организации. Например, с помощью фреймворков SAFe, LeSS или Nexus.
  • Используйте инкрементальный подход: масштабируйте постепенно, начинайте с связанных команд.
  • Регулярно пересматривайте и упрощайте процессы, чтобы предотвратить бюрократию.

Что в итоге

  • Agile-трансформация — переход компании от традиционных методов управления к гибким подходам. Agile-методики внедряются во всю компанию и меняют принципы управления, планирования, структуры и культуры.
  • Цель agile-трансформации — сделать так, чтобы компания могла быстро адаптироваться к изменениям рынка и потребностям клиентов.
  • Признаки, что компании нужна agile-трансформация: медленное внедрение продуктов, долгая реакция на изменения рынка, текучка специалистов, проблемы с коммуникацией, нет понимания ценности работы.
  • Agile-трансформация ускоряет вывод продукта на рынок, повышает качество продуктов, увеличивает вовлеченность сотрудников, снижает расходы и улучшает unit-экономику проектов, повышает прозрачность процессов.
  • Перед началом agile-трансформации нужно оценить готовность компании к изменениям с помощью различных инструментов и опросов.
  • Внедрение гибких методологий проходит в несколько этапов: подготовительный этап, формирование стратегии трансформации, обучение сотрудников, внедрение инструментов для отслеживания процессов, определение метрик успеха и способов отслеживания.
  • Основные проблемы при agile-трансформации: сопротивление изменениям со стороны сотрудников и менеджмента, сложности совмещения старых и новых процессов, недостаток знаний и опыта в области agile методологий, разочарование руководства из-за медленных результатов, сложность масштабирования agile-подхода на всю организацию.
Если хотите провести agile-трансформацию и вывести компанию на новый уровень, обратитесь за помощью в Neogenda. Просто запишитесь на бесплатную консультацию, и наши эксперты помогут интегрировать модель в ваш бизнес.
]]> Продуктовый подход: что это такое и как его применять http://neogenda.ru/blog/tmzcx69fz1-produktovii-podhod-chto-eto-takoe-i-kak http://neogenda.ru/blog/tmzcx69fz1-produktovii-podhod-chto-eto-takoe-i-kak?amp=true Mon, 17 Mar 2025 09:57:00 +0300 Дмитрий Кустов Когда компания выпускает новый продукт на рынок, у нее есть 2 пути. Первый — использовать...

Продуктовый подход: что это такое и как его применять

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

Что такое продуктовый подход

Продуктовый подход — это способ организации работы, при котором основной фокус направлен на создание ценного продукта для клиента. В таком подходе команда старается решить проблемы пользователей и улучшить их опыт взаимодействия с продуктом.
То есть, команда ориентируется на результаты, а не на выполнение задач. А еще продуктовый подход подразумевает, что команда отвечает за продукт на всех этапах его «жизни» — от идеи до улучшений и поддержки после запуска.
Продуктовый подход состоит из 3 основных элементов:
Фокус на потребностях пользователей. Команда понимает, что разработка качественного продукта — ее главная задача. Не процесс, не услуга, а именно готовый продукт, который решает проблемы клиентов.
Итерации и улучшение. Главная цель подхода — решить задачу клиента. Поэтому подход предполагает регулярные итерации и улучшения. Например, анализ обратной связи от пользователей, тестирование гипотез и адаптация продукта под нужды клиентов.
Работа кросс-функциональных команд. В продуктовой команде есть не только разработчики, но и дизайнеры, маркетологи, аналитики и другие специалисты. Все работают вместе, чтобы создавать и улучшать продукт.

Чем продуктовый подход отличается от других моделей управления

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

Почему стоит использовать продуктовый подход в бизнесе

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

Кто управляет продуктовой командой

Продуктовыми командами управляет Product Owner (PO) — человек, который смотрит на продукт с точки зрения потребностей бизнеса и клиентов. Он отвечает за стратегию и развитие продукта.
Определяет, какие функции и улучшения должны быть реализованы в первую очередь.
PO взаимодействует с командой, заказчиками и другими заинтересованными сторонами, чтобы создать лучший продукт.
У PO есть несколько обязанностей:
  • Собирать и анализировать требования от клиентов и пользователей. И понимать, как должны выглядеть финальные результаты.
  • Вести бэклог: на основе продуктового анализа потребностей пользователей и бизнеса формирует список задач и функций, которые должны быть реализованы в следующем спринте (если используется Scrum).
  • Приоритизировать задачи, которые необходимо выполнить для достижения целей продукта. Корректировать планы в зависимости от информации и потребности клиентов.
  • Общаться командой разработки и следить за всем циклом разработки. Уточнять требования и давать обратную связь по промежуточным результатам.
Обязанности product Owner

Кто входит в продуктовую команду

В продуктовом подходе команды должны быть кросс-функциональными. То есть, состоять из специалистов разных ролей.
Желательно, чтобы решения принимала небольшая группа работников. Иначе каждый этап разработки будет задерживаться из-за долгих правок и согласований.
Product Owner — отвечает за продукт в целом. Фокусируется на продукте, его развитии и ценности для пользователя. Он определяет, какие фичи будут востребованы и какие изменения необходимы. PO работает с командой разработки, но не управляет сроками и ресурсами проекта.
Product Manager — отвечает за реализацию проекта, следит за соблюдением сроков, бюджета и распределением ресурсов. PM отвечает за выполнение задач в рамках проекта, но не всегда вовлечен в принятие решений по функциональности продукта.
Разработчики — создают продукт. Это могут быть программисты, инженеры и другие технические специалисты, которые реализуют функциональность, описанную в требованиях.
Дизайнеры, копирайтеры — создают интерфейс и опыт пользователя (UX/UI). Делают продукт удобным, красивым и понятным для пользователей.
Маркетологи — занимаются продвижением продукта. Исследуют рынок, разрабатывают стратегии маркетинга и работают над привлечением пользователей.
Тестировщики — проверяют продукт на ошибки и баги. Тестируют функциональность, пользовательский интерфейс и взаимодействие с другими системами. Помогают избежать проблем на этапе релиза и обеспечивают стабильную работу продукта.
Аналитики — собирают и анализируют данные о продукте и пользователях. Помогают выявить потребности клиентов. Отслеживают ключевые метрики, чтобы команда могла принимать обоснованные решения и улучшать продукт.
Agile Coach — помогает команде следовать agile-практикам, внедрять Scrum или Kanban. Обучает команду гибким методологиям и помогает оптимизировать процесс разработки, улучшить коммуникацию и эффективность работы.

Как построить эффективную команду

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

Создать среду для эффективного взаимодействия

Команде должно быть легко обмениваться идеями и своевременно реагировать на изменения. В этом помогут методы управления проектами Kanban и Scrum.
Kanban поможет визуализировать рабочие процессы, отслеживать задачи и их статус. Задачи на доске могут быть разделены на несколько колонок: «Запланировано», «В процессе», «Готово».
Также канбан поможет контролировать выполнение задач и следить за всем процессом работы. Это даст всем участникам команды возможность видеть:
  • На каком этапе находится каждая задача.
  • Какие задачи заблокированы и почему.
  • Сколько времени осталось до завершения работы.
Scrum поможет работать отдельными спринтами, обычно длительностью в 2 недели. Команда будет планировать задачи на ближайший спринт, расставлять приоритеты и делать все, чтобы в конце спринта завершить работу по этим задачам.

Приоритизировать задачи

Для приоритизации используют бэклог, где собираются все задачи, фичи и улучшения. Product Owner на основе потребностей пользователей и бизнеса решает, какие задачи нужно выполнять в первую очередь. Задачи разделяют по приоритетам вроде этих:
  • Высокий приоритет — фичи, которые напрямую влияют на пользовательский опыт или решают критические проблемы.
  • Средний приоритет — улучшения, которые важны, но не срочные. Например, незначительные улучшения интерфейса.
  • Низкий приоритет — задачи, которые можно отложить на более позднее время.

Мотивировать команду

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

Как внедрить продуктовый подход в компанию

Шаг 1. Проанализировать текущие процессы

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

Шаг 2. Подготовить и сформировать команду

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

Шаг 3. Разработать бэклог продукта и внедрить инструменты управления

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

Шаг 4. Договориться о встречах

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

Шаг 5. Адаптироваться и улучшать процесс работы

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

Сложности при внедрении продуктового подхода

Неправильный выбор команд. Здесь можно выделить сразу 2 проблемы:
  • Использовать много команд и ждать результат от всех одновременно. Очень сложно сделать так, чтобы несколько команд работали синхронно.
  • Распределять одну небольшую задачу между разными командами. В этом случае большая вероятность, что информация между командами будет передаваться с ошибками и конечный результат не будет отвечать ожиданиям.
Сопротивление изменениям. Люди привыкают работать определенным образом и боятся переходить на новый формат. Иногда сотрудники вовсе не понимают, зачем менять привычную структуру работы. Например, если им не объясняют, как это улучшит результаты.
Недостаток коммуникации между участниками процесса. Когда коммуникация нарушена, работа может замедляться. Никто не знает, что и зачем нужно делать. Из-за этого сроки будут сдвигаться, а качество продукта — страдать.

Как измерять успех продуктового подхода

В этом пригодятся разные метрики. Глобально их можно обобщить в 3 группы.
Удовлетворенность клиентов — одна из самых важных метрик. Если продукт нравится пользователям, они остаются лояльными, чаще возвращаются и рекомендуют его другим. Оценить удовлетворенность можно через анкеты, опросы, NPS (Net Promoter Score) или отзывы на различных платформах. Важно не только собирать отзывы, но и активно с ними работать: фиксировать, сортировать по важности и учитывать при планировании дальнейших шагов.
Кроме обратной связи от пользователей, важна также обратная связь от команды. Это помогает выявить проблемы в рабочих процессах. А также помогает улучшить взаимодействие между различными ролями в продуктовой команде.
Рост прибыли. При правильном внедрении продуктового подхода компания должна зарабатывать больше. Поэтому стоит отслеживать, как новый подход влияет на объем продаж, жизненную ценность клиента (Customer Lifetime Value) или стоимость привлечения клиента (Customer Acquisition Cost).
Качество продукта. Эти метрики измеряются через количество багов, откликов пользователей и запросов на улучшение. Здесь же стоит учитывать время до выпуска новых функций или улучшений, чтобы оценить, насколько быстро команда реагирует на потребности пользователей.
Можно использовать и другие метрики. Выбор зависит от продукта и рынка, в котором он существует.

Что в итоге

  • Продуктовый подход — это способ организации работы, при котором основной фокус направлен на создание ценного продукта для клиента.
  • Продуктовый подход подразумевает ответственность команды за продукт на всех этапах его жизни. В основе продуктового подхода лежит идея постоянного улучшения продукта и удовлетворения потребностей целевой аудитории.
  • Условно можно выделить 3 принципа продуктового подхода: фокус на продукте, ориентация на потребности клиента, постоянное улучшение.
  • Продуктовый подход отличается от других моделей управления тем, что ориентирован на создание качественного продукта, а не на выполнение задач или оптимизацию рабочих процессов.
  • Внедрение продуктового подхода помогает бороться с конкурентами, улучшать клиентский опыт, делать бизнес гибким и мотивировать команду.
  • Продуктовый подход — это метод работы, который подразумевает изменения в стратегии. При этом важно исправлять текущие проблемы и работать над улучшением долгосрочной стратегии.
  • Чтобы корректно адаптировать стратегию, анализируйте данные, выделяйте ключевые проблемы и принимайте решения на основе фактов, а не догадок. Постоянно сравнивайте новые результаты с исходными метками, чтобы увидеть, какие изменения действительно дали положительный эффект.
Если хотите разобраться в продуктовом подходе и внедрить его в компанию, обратитесь за помощью в Neogenda. Просто запишитесь на бесплатную консультацию, и наши эксперты помогут интегрировать модель в ваш бизнес.
]]> Кто такой Agile-коуч и зачем его нанимать http://neogenda.ru/blog/vtxk1led41-kto-takoi-agile-kouch-i-zachem-ego-nanim http://neogenda.ru/blog/vtxk1led41-kto-takoi-agile-kouch-i-zachem-ego-nanim?amp=true Tue, 18 Mar 2025 06:36:00 +0300 Артур Нек Agile-коуч — специалист, который помогает компаниям внедрять и развивать гибкие методы управления проектами вроде Scrum...

Кто такой Agile-коуч и зачем его нанимать

Agile-коуч — специалист, который помогает компаниям внедрять и развивать гибкие методы управления проектами вроде Scrum и Kanban. Его задача сделать так, чтобы все процессы в компании соответствовали принципам Agile:
  • итеративности;
  • адаптивности;
  • клиентоориентированности;
  • сотрудничеству внутри компании и с клиентами;
  • самоорганизации;
  • прозрачности;
  • постоянному улучшению.
В статье рассказываем, как выиграет компания от работы с Agile-коучем и как нанять хорошего специалиста.
Кто такой Agile-coach

Чем занимается Agile-коуч

Задача Agile-коуча отличается от задач Scrum-мастера или Product Owner. Scrum-мастер фокусируется на правильном выполнении Scrum-процессов в команде, помогает команде следовать принципам Scrum. Product Owner сосредоточен на управлении продуктом, его задачах и приоритетах.
Agile-коуч работает на более высоком уровне: он обучает или поддерживает конкретную команду и помогает всему бизнесу внедрять гибкие методологии. В основном коуч работает с процессами и командами.
Agile-коуч обучает команды гибким подходам. Например, Scrum, Канбан или Lean методам.
Scrum — это метод работы, который делит проект на маленькие этапы. Каждый этап называется спринтом. В конце спринта команда должна предоставить конкретный результат. Agile-коуч помогает команде правильно организовать спринты, расставить приоритеты и организовать работу. Он следит, чтобы все участники команды понимали свою роль и задачи.
Kanban — метод, который помогает управлять задачами на разных стадиях выполнения. Задачи отображаются на доске, где команда видит стадии каждой из них. Agile-коуч обучает команду правильно использовать Kanban-доски для визуализации работы и обучает управлять потоком задач.
Lean-методы помогают минимизировать потери и оптимизировать работу. Agile-коуч помогает команде анализировать, где происходят задержки или излишние затраты времени, и ищет пути их устранения.
Scrum, Kanban и Lean подходы. Источник
Agile-коуч адаптирует методологии под компанию и ее цели. Если компания занимается разработкой ПО и ей важна скорость выхода новых функций, коуч настроит Scrum так, чтобы команда могла работать над продуктом с максимальной отдачей.
Если компания хочет сократить затраты и повысить эффективность, коуч может предложить подходы из Lean для минимизации потерь и оптимизации ресурсов.
Проводит тренинги, воркшопы и мастермайнды. Коуч может организовать тренинг по Scrum или Канбан для команды и объяснить, как делегировать задачи и управлять продуктовым бэклогом. Либо, как работать с доской задач.
Решает проблемы внутри команды. В процессе работы по Agile команда может перегрузить себя задачами или плохо распределить роли. Из-за этого работа будет останавливаться. Коуч поможет реорганизовать роли, изменить подход к оценке задач или наладить более эффективное взаимодействие между участниками. При этом коуч не будет решать проблемы за команду. Он будет помогать находить решения, чтобы в будущем сотрудники справлялись с трудностями самостоятельно.
Выступает ментором. Коуч не только обучает методикам, но и помогает их применять. Например, на начальном этапе коуч может помогать в составлении расписания спринтов, распределении задач и определении приоритетов.

Типы Agile-коучей

Коучей можно разделить на 3 типа:
  • фасилитатор;
  • agile-coach;
  • корпоративный коуч.

Фасилитатор

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

Agile-coach

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

Корпоративный коуч

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

Преимущества Agile-коучинга

✅ Делает процессы прозрачными. Коуч обучает команды работать по четким и понятным правилам. Это позволяет видеть, что и как происходит на каждом этапе работы. Например, с помощью Scrum все задачи и их статусы становятся видимыми для всех участников. В результате каждый знает, за что отвечает и на какой стадии находится проект.
✅ Улучшает коммуникацию. Коуч помогает наладить регулярные встречи, на которых обсуждаются текущие задачи и проблемы. Он проводит командные ретроспективы, где все участники проекта могут делиться мнениями и предложениями по улучшению работы.
✅ Снижает риски неправильного выполнения задач. Все потому, что команда работает небольшими итерациями, быстро тестирует изменения и исправляет ошибки.

Как работает Agile-коуч на разных уровнях

На уровне топ-менеджмента Agile-коуч помогает руководителям компании понять, как внедрить Agile в стратегические процессы. Коуч работает с директором и другими членами руководства, помогает выстроить корпоративную культуру.
Он обучает топ-менеджеров принципам Agile, чтобы те могли принимать быстрые решения и управлять изменениями. Например, коуч помогает пересматривать подходы к планированию и адаптации стратегии.
На уровне среднего менеджмента и владельцев продукта коуч помогает улучшить взаимодействие между командами и помогает ставить понятные цели. Он обучает менеджеров Scrum или Kanban. Помогает владельцам продукта формулировать четкие требования и расставлять приоритеты.
Коуч обучает работать с бэклогом, проводить встречи для обсуждения текущих задач и эффективно управлять проектами. Также коуч помогает наладить взаимодействие между различными отделами, чтобы ускорить принятие решений и повысить скорость работы.
На уровне отдельных команд Agile-коуч работает непосредственно с разработчиками, тестировщиками и другими специалистами. Он помогает настроить процессы так, чтобы команда могла эффективно работать с Scrum, Kanban, Lean и др.
Коуч обучает команду самоорганизации, чтобы каждый участник мог брать на себя ответственность за выполнение задач и предлагать улучшения в процессе работы. Он также помогает команде правильно проводить ежедневные стендапы, ретроспективы и планировать спринты.
Работа Agile-коуча

Качества хорошего Agile-коуча

Наличие сертификатов и знание разных подходов к обучению. Желательно, чтобы у коуча были сертификаты международного уровня. Например, ICAgile, Certified ScrumMaster или Agile Certified Practitioner.
Также большую роль играют подходы, используемые к обучению. Важно, чтобы коуч мог подобрать методику, которая подходит именно для вашей команды и бизнеса, будь то Scrum, Kanban или Lean.
Умение разрабатывать итеративные процессы. Один из ключевых элементов Agile — итеративный процесс, где работа разбивается на этапы. Коуч помогает команде понять, как планировать и выполнять работу маленькими частями. А также, как правильно визуализировать задачи.
Способность организовывать встречи. Хороший коуч помогает организовать встречи после завершения каждого этапа работы. На них команда обсуждает, что получилось хорошо, а что можно улучшить.
Помощь в постановке целей. Agile-коуч помогает команде ставить конкретные, достижимые и измеримые цели.
Понимание бизнеса и экономики. Agile-коуч не должен ограничиваться только процессами. Он должен понимать бизнес и помогать делать его более конкурентоспособным. Например, помогать оптимизировать процессы, улучшать взаимодействие с клиентами или повышать качество продуктов.
Наличие навыков взаимодействия с людьми. Хорошие специалисты должны обладать педагогическими, коммуникативными, лидерскими качествами для эффективного обучения и руководства. Быть проактивными.
Все потому, что они должны уметь объяснять сложные вещи простым языком. Выстраивать доверительное общение и направлять команду к результату. А иногда — решать нестандартные ситуации.

Как понять, что Agile-коуч помог компании

Результат любых действий можно оценить с помощью метрик. Они показывают, как хорошо команда адаптировалась к Agile, какие процессы требуют улучшения и как это влияет на бизнес.
Можно использовать разные метрики.
Для оценки работы команды — скорость выполнения задач (Velocity). Измеряется как среднее количество задач или сторипоинтов, завершенных за спринт. Velocity показывает, как быстро выполняется работа и помогает прогнозировать сроки. Если команда начинает выполнять больше задач за спринт, это обычно указывает на рост производительности.
Для оценки успешности работы — процент спринтов, завершенных успешно. Дополнительно можно учитывать количество реализованных улучшений. Эта метрика оценивает, сколько предложений из ретроспектив было внедрено в работу. В результате можно оценить, насколько активно команда работает над улучшением процессов и как Agile-коуч помогает внедрять изменения.
Для оценки производительности — время выполнения задачи (Cycle Time). Измеряется как среднее время от старта задачи до ее завершения. Чем короче Cycle Time, тем быстрее компания сможет реагировать на запросы клиентов.
Анализ эффективности работы Agile-коучей
Дополнительно можно оценивать время от идеи до реализации (Lead Time). Метрика измеряет период с момента создания задачи до ее релиза. Показатель говорит о том, как быстро команда может доставить ценность клиенту.
Чтобы понять, насколько команда заинтересована в коуче, можно:
  • Считать индекс удовлетворенности команды с помощью регулярных опросов. После тренингов и изменений в процессах индекс должен расти.
  • Отслеживать количество участников на стендапах и ежедневных встречах. Если на стендапы приходит большая часть команды и они активно участвуют, это говорит о высоком уровне вовлеченности и командной работы.
Конечно, можно использовать и другие метрики. Все зависит от того, что вы хотите проанализировать и как построена работа в компании.

Что в итоге

  • Agile-коуч — специалист, который помогает внедрять и развивать гибкие методы управления проектами (Scrum, Kanban).
  • Коуч обучает команды гибким подходам (Scrum, Канбан, Lean) и адаптирует методологии под компанию и ее цели. А также проводит тренинги, воркшопы и мастермайнды, решает проблемы внутри команды и выступает ментором.
  • Agile-коучи делятся на 3 типа: фасилитатор, agile-coach, корпоративный коуч.
  • Преимущества Agile-коуча: делает процессы прозрачными, улучшает коммуникацию, снижает риски неправильного выполнения задач.
  • Хороший Agile-коуч должен иметь сертификаты, знать разные подходы к обучению, уметь разрабатывать итеративные процессы, работать с досками задач, организовывать встречи, помогать в постановке целей, понимать бизнес и экономику, иметь навыки взаимодействия с людьми, быть проактивным и выстраивать доверительное общение.
  • Результат работы Agile-коуча можно оценить с помощью метрик вроде скорости выполнения задач (Velocity), процента спринтов, завершенных успешно, время выполнения задачи (Cycle Time), время от идеи до реализации (Lead Time), индекса удовлетворенности команды и количества участников на встречах.
Гибкие методологии — отличный способ вывести компанию на новый уровень. И вот, почему:
Но все эти утверждения верны только в том случае, если Agile грамотно внедрен в компанию и команда понимает, как работать с гибкими методологиями.
Если хотите нанять Agile-коуча и вывести компанию на новый уровень, обратитесь за помощью в Neogenda. Просто запишитесь на бесплатную консультацию, и наши эксперты помогут интегрировать модель в ваш бизнес.
]]> Управление изменениями: как трансформировать процессы компании и достигать успеха http://neogenda.ru/blog/9i6ibhhtm1-upravlenie-izmeneniyami-kak-transformiro http://neogenda.ru/blog/9i6ibhhtm1-upravlenie-izmeneniyami-kak-transformiro?amp=true Thu, 20 Mar 2025 06:40:00 +0300 Андрей Сидоренко Представьте фирму, которая годами работает по проверенной схеме: одни и те же бизнес-процессы, привычные методы...

Управление изменениями: как трансформировать процессы компании и достигать успеха

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

Что означает управление изменениями

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

Чем отличается управление изменениями от управления проектами

Бывает, что управление изменениями путают с управлением проектами, но между ними все же есть различия.
Критерий Управление проектами Управление изменениями
Основной фокус Выполнение конкретных задач Адаптация сотрудников и процессов
Цель Достичь запланированного результата Успешно внедрить изменения
Методы Планирование, контроль сроков и бюджета Коммуникации, работа с сопротивлением
Участники Руководители проектов, исполнители Все сотрудники компании
Проще говоря, управление изменениями в проекте направлено на людей и процессы, а управление изменениями в организации — это более глобальные преобразования, которые влияют на всю структуру фирмы.

Почему важно управлять изменениями в компании

Есть много примеров, когда организации либо успешно адаптировались к изменениям, либо терпели неудачу, потому что не смогли перестроиться. Так, компания Kodak проигнорировала цифровую революцию и ушла с рынка. А Netflix, например, вовремя изменил свою бизнес-модель и перешел от проката DVD к стриминговому сервису. В результате стал мировым лидером. Разница между этими компаниями в том, что одна управляла изменениями, а другая — нет.
Любая трансформация фирмы затрагивает бизнес-процессы, сотрудников, клиентов. Если изменения внедряются хаотично, работа начинает сбоить, снижается эффективность и растет сопротивление персонала.
Пример. Допустим, компания решила автоматизировать отдел продаж и внедрить новую CRM-систему. Без подготовки сотрудникам будет трудно, а это приведет к снижению продаж, ошибкам в данных и отказу от новой технологии. Но если внедрение пройдет по стратегии управления изменениями, с обучением персонала и поэтапным переходом, продуктивность отдела не только не пострадает, но и возрастет.
Управление изменениями — это не разовое действие, а стратегический процесс. Компании, которые системно подходят к трансформациям, остаются конкурентоспособными и эффективно адаптируются к новым условиям. Для этого важно:
  • Понимать необходимость изменений — анализировать, какие процессы нужно модернизировать и почему.
  • Выбрать подходящую стратегию — использовать проверенные методики, такие как модель управления изменениями ADKAR или модель Коттера.
  • Работать с персоналом — объяснять сотрудникам ценность перемен, чтобы снижать сопротивление.
  • Контролировать процесс — оценивать результаты и при необходимости корректировать стратегию.

Кто управляет изменениями в бизнесе

В организации процессом перемен занимается не один человек, а команда, в том числе топ-менеджеры, линейные руководители, профильные эксперты. Однако в крупных корпорациях за внедрение трансформаций отвечает менеджер по управлению изменениями. Его задача — не просто запустить процесс, а добиться того, чтобы сотрудники приняли и поддержали нововведения.
Как правило, такой специалист:
  • Оценивает готовность компании — анализирует текущие бизнес-процессы, выявляет возможные риски и точки сопротивления.
  • Разрабатывает стратегии изменений — выбирает подходящую модель управления изменениями.
  • Общается с руководством и сотрудниками — разъясняет цели, преимущества и влияние нововведений.
  • Обучает персонал — проводит тренинги и поддерживает сотрудников во время переходного периода.
  • Контролирует процесс — оценивает эффективность и, если нужно, корректирует стратегию.
В небольших организациях эти функции могут выполнять руководители подразделений или HR-отдел.

Как взаимодействуют отделы при управлении изменениями

Успешно внедрить трансформации не получится без слаженной работы всех подразделений. Особенно важную роль играют:
  • Руководство компании — задает стратегическое направление и определяет приоритеты.
  • HR-отдел — помогает работать с корпоративной культурой, обучением и мотивацией сотрудников.
  • IT-департамент — отвечает за техническую часть, особенно при внедрении цифровых решений.
  • Отдел продаж — адаптируется к новым процессам работы с клиентами, использованию CRM-систем и другим изменениям.
Пример. Если компания внедряет новую CRM, продавцы должны перестроить свою работу, а IT-отдел — обеспечить техническую поддержку. В этом случае специалист по управлению изменениями координирует процесс, помогает сотрудникам освоить систему и следит, чтобы эффективность не снизилась.
Получается, что управление изменениями — как стратегия, так и командная работа, где каждый отдел играет свою роль.

Как понять, будут ли изменения успешными

Даже самые перспективные инициативы могут оказаться безрезультатными, если компания не готова их внедрять. Чтобы трансформация принесла ожидаемые результаты, она должна соответствовать нескольким ключевым критериям:
  • Четкая цель — компания должна понимать, какие проблемы решает изменение, какой эффект ожидается. Например, интеграция новой CRM-системы в отделе продаж должна повысить эффективность работы, а не просто заменить привычные инструменты.
  • Поддержка руководства — без участия топ-менеджмента изменения редко приживаются. Если лидеры организации активно вовлечены в процесс, сотрудники воспринимают трансформацию как важную часть стратегии, а не временную инициативу.
  • Готовность работников — управление организационными изменениями должно учитывать уровень подготовки сотрудников. Если персонал не обучен новым процессам либо не понимает их ценность, изменения столкнутся с сопротивлением.
  • Продуманная стратегия — использование проверенных методик помогает структурировать работу и минимизировать риски.
  • Гибкость внедрения — любые изменения требуют корректировок в ходе внедрения. Если компания готова адаптировать стратегию, основываясь на обратной связи и аналитике, вероятность успеха возрастает.

Как оценить, готова ли компания к изменениям

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

Какие модели управления изменениями обычно применяют

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

Модель Курта Левина

Одна из простых и фундаментальных концепций управления изменениями, которую предложил психолог Курт Левин, состоит из трех шагов:
Модель Курта Левина
  1. Размораживание. Осознание того, что изменения необходимы. Это этап, на котором руководство должно объяснить сотрудникам, почему текущая ситуация требует трансформации, и подготовить их к переменам.
  2. Изменение. Внедрение новых процессов, инструментов или структур. Здесь важно обучать персонал, оказывать поддержку и устранять возникающие барьеры.
  3. Замораживание. Закрепление новых методов работы как стандартных. На этом этапе важно следить за тем, чтобы сотрудники действительно приняли изменения и не вернулись к старым привычкам.
Эта модель особенно полезна для компаний, которые проходят через четкие, структурированные трансформации, например при переходе на новую систему управления бизнес-процессами.

Модель управления изменениями ADKAR

ADKAR разработал Джефф Хиатт, и это одна из самых популярных методологий. Она фокусируется на том, как отдельные работники воспринимают изменения, и включает пять основных этапов:
Модель ADKAR
  • Awareness (осознание). Сотрудники должны понимать, почему происходят изменения.
  • Desire (желание). Важно мотивировать персонал и снизить сопротивление.
  • Knowledge (знание). Обучение новым навыкам и процессам.
  • Ability (способность). Практическое применение новых знаний в работе.
  • Reinforcement (подкрепление). Поддержка и контроль, чтобы новые процессы стали нормой.
Модель ADKAR особенно эффективна, когда изменения требуют активного вовлечения сотрудников, например, при цифровой трансформации или реорганизации отдела продаж.

Модель Коттера

Джон Коттер, профессор Гарвардской школы бизнеса, предложил восьмишаговую модель, которая помогает компаниям вводить изменения более плавно:
Модель Коттера
  1. Создать ощущение срочности.
  2. Сформировать мощную коалицию сторонников.
  3. Разработать стратегическое видение изменений.
  4. Донести его до сотрудников.
  5. Устранить препятствия.
  6. Достигать краткосрочных побед.
  7. Развивать успех, а также внедрять новые инициативы.
  8. Закрепить изменения в корпоративной культуре.
Эта модель подходит для крупных компаний, которым нужно масштабное изменение стратегии или организационной структуры.

Другие модели управления изменениями

Есть и другие методологии, которые используют в зависимости от специфики бизнеса:
  • Модель 7S (McKinsey) — анализирует организационные изменения через семь взаимосвязанных звеньев: стратегия, структура, системы, стиль управления, навыки, ценности, сотрудники.
  • Кривая изменений Кюблер-Росс — показывает, как люди психологически реагируют на перемены, а это полезно для управления сопротивлением.
  • Lean Change Management — адаптивный подход, который сочетает принципы гибкого управления проектами и классических моделей изменений.
Выбор методологии зависит от типа изменений, корпоративной культуры, специфики бизнеса. Так, для глобальных структурных изменений подойдет модель Коттера. Если важно учитывать реакцию сотрудников, лучше использовать модель ADKAR. А для внедрения новых технологий удобна модель К. Левина.

Как внедрять изменения по шагам

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

1. Оценить необходимость изменений

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

2. Разработать стратегию

Когда стало понятно, что без изменений не обойтись, разрабатывают стратегию их внедрения. В этот этап входит:
  • Выбор подходящей модели — например, модель управления изменениями ADKAR подойдет, если важно учитывать реакцию сотрудников, а модель Коттера — если изменения затрагивают всю организацию.
  • Определение ключевых этапов — формирование плана с четкими сроками, задачами и ответственными лицами.
  • Подготовка ресурсов — анализ финансовых, кадровых и технических возможностей компании.
На этом же этапе важно определить, какие методы управления бизнес-процессами помогут минимизировать сбои и плавно внедрить изменения.

3. Наладить коммуникацию с командой

Чаще всего неудачи в управлении организационными изменениями случаются из-за недостатка информации. Если сотрудники не понимают, зачем нужны изменения, они могут саботировать процесс или пассивно сопротивляться.
Эффективная коммуникация — это:
  • Объяснение причин и выгоды — сотрудники должны видеть ценность изменений для себя и компании.
  • Диалог и обратная связь — руководителям важно не только доносить информацию, но и слушать мнения команды.
  • Обучение и поддержка — при внедрении новых инструментов, например автоматизации бизнес-процессов, нужно проводить тренинги.

4. Контролировать и корректировать

Даже при идеальном планировании процесс изменений редко проходит гладко. Поэтому важно регулярно оценивать как продвигается внедрение и при необходимости вносить корректировки.
На этом этапе используют:
  • Ключевые показатели эффективности (KPI) — отслеживание прогресса изменений по заранее определенным метрикам.
  • Опросы сотрудников — анализ восприятия новых процессов и выявление проблем.
  • Гибкость стратегии — возможность адаптировать подход, если первоначальный план не дает ожидаемых результатов.

Какие ошибки в управлении изменениями могут быть и как их избежать

Даже лучшие модели управления изменениями не дадут результатов, если их применять неправильно. Компании часто допускают ошибки, которые могут замедлить процесс или обнулить его:
Ошибка Последствия Как избежать
Неправильный выбор модели управления изменениями Если модель не подходит ситуации, процесс замедляется или встречает сопротивление Перед выбором модели оцените масштаб изменений. Для небольших трансформаций подойдет ADKAR, для глобальных — модель Коттера
Игнорирование влияния на сотрудников Сопротивление сотрудников, снижение мотивации, скрытый саботаж Заранее оценивайте реакцию команды, используйте методы управления, которые учитывают человеческий фактор. Вовлекайте персонал через обучение и коммуникацию
Недостаточное внимание к управлению бизнес-процессами Дисбаланс в работе отделов, снижение эффективности, хаос в организации. Например, изменения в отделе продаж без анализа существующих процессов могут привести к тому, что компания начнет терять клиентов Проведите аудит бизнес-процессов перед внедрением изменений
Плохая коммуникация Недопонимание целей изменений, слухи, сопротивление на всех уровнях Разработайте стратегию коммуникации: регулярные встречи, чаты, письма от руководства. Донесите, зачем нужны изменения и какие от них выгоды
Отсутствие контроля и корректировки Если компания запустила процесс изменений, без мониторинга они могут не закрепиться, и сотрудники вернутся к старым привычкам Внедряйте KPI, регулярно проверяйте и корректируйте стратегию, если это нужно

Как мотивировать сотрудников на изменения

Даже самые полезные организационные изменения могут встретить сопротивление, если сотрудники не понимают их сути или боятся последствий. Чтобы избежать этого, важно не только грамотно управлять процессом, но и мотивировать персонал. Люди должны чувствовать, что перемены принесут им пользу, а их мнение учитывается.
Вот несколько эффективных способов, которые помогут вовлечь команду в процесс изменений:
Метод Как работает Как применять
Открытая и честная коммуникация Сотрудникам важно понимать, какие изменения происходят, зачем они нужны и как повлияют на их работу Используйте корпоративные рассылки, собрания, чаты. Руководители могут лично объяснять важность изменений
Привлечение сотрудников к процессу Люди охотнее поддерживают то, в чем участвуют. Если у них есть возможность влиять на процесс, они станут его союзниками, а не противниками Создайте рабочие группы, спрашивайте мнение сотрудников, дайте им ощущение контроля
Обучение и поддержка Если сотрудники не понимают, как работать в новых условиях, они будут сопротивляться. Обучение снижает тревожность и повышает уверенность Организуйте тренинги, создавайте видеоинструкции, привлекайте наставников
Показывайте быстрые победы Долгосрочные изменения могут казаться бесконечными. Маленькие победы мотивируют и показывают, что процесс движется в правильном направлении Отмечайте успехи: улучшение показателей, удобство новых процессов, положительные отзывы клиентов
Материальная и нематериальная мотивация Люди лучше реагируют на изменения, если видят в них личную выгоду Используйте бонусы, признание, повышение по карьерной лестнице. Иногда достаточно просто похвалить за адаптацию
Поддержка лидеров мнений Если авторитетные сотрудники поддерживают изменения, остальным будет легче принять их Найдите амбассадоров среди сотрудников и вовлеките их в продвижение изменений
Управление изменениями — это не только выбор правильной стратегии, но и работа с людьми. Сотрудники должны понимать, зачем нужны перемены, чувствовать поддержку и видеть реальную выгоду для себя. Если правильно выстроить процесс мотивации, изменения пройдут легче, а сопротивление снизится.

Что в итоге

Эффективное управление изменениями позволяет компаниям адаптироваться к новым условиям, улучшать бизнес-процессы и достигать стратегических целей. Однако, чтобы новые процессы действительно работали, важно не только правильно их спланировать, но и поддерживать команду, выбрать подходящую модель управления изменениями и наладить четкую коммуникацию.
Если хотите, чтобы ваш бизнес уверенно проходил через трансформации, и использовал лучшие управленческие практики, в этом помогут специалисты Neogenda. Мы реализовали более 100 успешных проектов для таких компаний, как Tinkoff, Яндекс, Авито, Сбер и Skyeng. Обучили свыше 5 000 сотрудников. Запишитесь на бесплатную консультацию в Zoom — подберем оптимальные решения именно для вашего бизнеса.
]]> Лидерство и эмоциональный интеллект: как soft skills помогают управлять командой http://neogenda.ru/blog/yp9in3dxo1-liderstvo-i-emotsionalnii-intellekt-kak http://neogenda.ru/blog/yp9in3dxo1-liderstvo-i-emotsionalnii-intellekt-kak?amp=true Fri, 21 Mar 2025 06:59:00 +0300 Артур Нек Сегодня успешные лидеры — не просто эксперты в своем деле. Это те, кто владеет социальными...

Лидерство и эмоциональный интеллект: как soft skills помогают управлять командой

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

Что значит эмоциональный интеллект и почему он важен

Термин «эмоциональный интеллект» (EQ) описывает умение человека осознавать, понимать, управлять своими эмоциями, кроме того, правильно взаимодействовать с эмоциями окружающих. Речь не о врожденном таланте, это навык, который можно прокачать.
Эмоциональный интеллект включает четыре ингредиента:
4 составляющих эмоционального интеллекта
  1. Самоосознание — возможность считывать собственные эмоции и то, как они влияют на поведение.
  2. Саморегуляция — навык управлять чувствами, контролировать стресс, импульсивные реакции.
  3. Социальная осознанность — эмпатия, понимание эмоций окружающих.
  4. Навыки управления отношениями — грамотная коммуникация, умение давать обратную связь, решать конфликты, вдохновлять коллег.
Благодаря высокому уровню эмоционального интеллекта можно выстраивать продуктивные взаимоотношения, сохранять самообладание в нестабильных ситуациях, поддерживать благоприятную атмосферу в коллективе.
Руководители с развитым EQ легче адаптируются к изменениям, способны справляться со стрессом, понимать эмоциональное состояние сотрудников. Это особенно важно в кризисные моменты, когда команда нуждается в уверенности и стабильности.

Какие преимущества дает эмоциональный интеллект бизнесу

Совершенствование эмоционального интеллекта в сфере управления персоналом — не просто тренд, а значимый фактор успеха компании. Благодаря лидерам с развитым EQ бизнес может:
  • Повышать продуктивность. Команды, в которых царит доверие и открытая коммуникация, работают эффективнее. Сотрудники не боятся высказывать идеи, обсуждать проблемы и предлагать решения.
  • Снижать текучесть кадров. Когда лидер умеет управлять эмоциями, давать честную обратную связь и поддерживать баланс нагрузки, у сотрудников меньше желания менять работу.
  • Укреплять корпоративную культуру. Руководитель, который демонстрирует эмпатию, уважение и справедливость, задает тон всей организации. В результате формируется среда, где важны не только результаты, но и взаимоотношения.
  • Принимать дальновидные решения. Лидер с высоким уровнем EQ не поддается эмоциям, анализирует ситуацию со всех сторон и принимает решения, учитывая как логику, так и эмоциональное состояние команды.
Пример. В компании Google особое внимание уделяют эмоциональному интеллекту руководителей. В рамках проекта Oxygen, проведенного в 2008 году, исследователи выяснили, что наиболее успешные менеджеры обладают высокой эмпатией, умеют слушать, давать конструктивную обратную связь и поддерживать команду. Данные показали, что под руководством таких лидеров сотрудники демонстрируют высокий уровень вовлеченности, работают продуктивнее и реже сталкиваются с выгоранием. Эти выводы стали основой для развития программ обучения управленцев в компании.

Почему клиентоориентированные компании инвестируют в EQ

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

Как эмоциональный интеллект связан с бизнес-моделью компании

EQ лидера влияет не только на атмосферу в коллективе, но и на стратегическое развитие бизнеса. Интересно, что его ключевые компоненты можно сопоставить с элементами Business Model Canvas (BMC) — популярного инструмента для проектирования бизнес-модели. Это показывает, что управление эмоциями так же структурировано и важно, как управление ресурсами, клиентами и ценностями компании.
<table cellspacing="30">
    <tr>
        <td><b>Компонент EQ</b></td>
        <td><b>Аналог в BMC</b></td>
        <td><b>Как влияет на компанию</b></td>
        <td><b>Пример</b></td>
    </tr>
    <tr>
        <td>Самоосознание (понимание своих эмоций, сильных и слабых сторон)</td>
        <td>Ключевые ресурсы (что определяет ценность бизнеса)</td>
        <td>Осознанный лидер принимает свои сильные и слабые стороны. Это помогает ему эффективно распределять ресурсы и роли</td>
        <td>Руководитель осознает, что его сильная сторона — стратегическое мышление, но слабая — оперативное. Тогда он нанимает операционного директора</td>
    </tr>
    <tr>
        <td>Саморегуляция (контроль над эмоциями, стрессоустойчивость)</td>
        <td>Ключевые виды деятельности (процессы, создающие ценность)</td>
        <td>Лидер, который умеет управлять своими эмоциями, принимает решения на основе анализа, а не импульсов. Это влияет на стабильность компании</td>
        <td>Во время кризиса СЕО не поддается панике, а анализирует ситуацию и разрабатывает антикризисный план</td>
    </tr>
    <tr>
        <td>Социальная осознанность (эмпатия, понимание, эмоции других)</td>
        <td>Отношения с клиентами (как бизнес взаимодействует с ЦА)</td>
        <td>Чуткий руководитель понимает потребности сотрудников и клиентов, что улучшает внутренние и внешние отношения компании</td>
        <td>Менеджер замечает, что команда перегружена, и перераспределяет задачи, чтобы предотвратить выгорание</td>
    </tr>
    <tr>
        <td>Навыки управления отношениями (коммуникация, мотивация)</td>
        <td>Каналы взаимодействия (способы донесения ценности до клиентов)</td>
        <td>Лидер, умеющий выстраивать отношения, создает культуру доверия и эффективной коммуникации</td>
        <td>Директор проводит регулярные встречи one-to-one, чтобы повышать мотивацию команды</td>
    </tr>
    <tr>
        <td>EQ как фактор успеха бизнеса</td>
        <td>Ценностное предложение (ключевая ценность компании)</td>
        <td>Эмоциональный интеллект лидера помогает формировать культуру, в которой сотрудники мотивированы и вовлечены. Это становится конкурентным преимуществом</td>
        <td>Компания с сильной корпоративной культурой привлекает талантливых специалистов</td>
    </tr>
</table>
Этот подход позволяет по-новому взглянуть на роль EQ в лидерстве. Как и в BMC, каждый элемент влияет на общую эффективность: без осознания себя трудно правильно распределять ресурсы, без эмпатии — выстраивать команду, а без саморегуляции — стабильно вести бизнес.

Как эмоциональный интеллект и soft skills помогают управлять командой

Грамотное руководство невозможно без способности понимать эмоции людей, управлять ими, выстраивать продуктивные отношения в коллективе. Эмоциональный интеллект руководителя в сочетании с гибкими навыками позволяет не только добиваться высоких результатов, но и создавать здоровую рабочую среду, в которой сотрудники чувствуют себя мотивированными и ценными. Вот какие основные soft skills можно выделить:
  • Эмпатия — способность понимать эмоции сотрудников и учитывать их в управлении.
  • Коммуникативные навыки — умение четко доносить информацию, слушать и давать конструктивную обратную связь.
  • Стрессоустойчивость — навык сохранять спокойствие в сложных ситуациях и не передавать стресс команде.
  • Гибкость мышления — умение адаптироваться к изменениям и предлагать нестандартные решения.
  • Навыки мотивации — способность вдохновлять команду, поддерживать вовлеченность сотрудников.
Пример. Илон Маск, несмотря на свой гениальный ум и стратегическое видение, иногда сталкивается с критикой из-за жесткого стиля управления. Его не всегда высокая эмоциональная устойчивость и резкость в общении приводили к стрессу у сотрудников, особенно в Tesla и Х (Twitter). Однако его способность мотивировать людей на амбициозные цели доказывает, что сочетание харизмы, уверенности и эмпатии — ключ к успешному лидерству.
Эмоциональный интеллект и soft skills не просто делают лидера более эффективным. Они формируют среду, в которой команда работает с максимальной продуктивностью.

Как EQ влияет на принятие решений

Лидер с развитым эмоциональным интеллектом в управлении персоналом принимает более взвешенные решения, так как умеет учитывать не только факты, но и эмоциональный фон команды.
Поэтому высокий EQ помогает:
  • контролировать эмоции, не действовать импульсивно;
  • учитывать реакцию сотрудников и снижать сопротивление изменениям;
  • выбирать оптимальное время для внедрения нововведений.

Почему эмпатия и обратная связь делают лидера эффективнее

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

Как эмоциональный интеллект влияет на корпоративную культуру

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

Эмоциональный интеллект руководителя: как развивать и применять

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

Практика самоанализа

  • Регулярно оценивайте свои эмоции: что вы чувствуете в разных ситуациях?
  • Ведите дневник эмоций — фиксируйте, какие чувства возникли и как они повлияли на поведение.
  • Анализируйте, как ваши эмоции влияют на принятие решений и взаимоотношения в команде.

Тренировка саморегуляции

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

Развитие эмпатии

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

Совершенствование навыков общения

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

Как научиться давать конструктивную обратную связь

Обратная связь — полезный инструмент, который может либо мотивировать сотрудников, либо подорвать их уверенность. Руководитель с высоким EQ умеет преподносить критику так, чтобы она помогала развитию, а не вызывала негатив.
Вот основные принципы эффективной обратной связи:
  • Конкретность — говорите не обобщенно («Ты плохо работаешь»), а указывайте конкретные моменты («Твой отчет был неполным, не хватало анализа данных»).
  • Баланс позитива и корректировки — отмечайте сильные стороны сотрудника перед тем, как говорить о недочетах.
  • Предложение решений — критика без рекомендаций неэффективна. Лучше сказать: «Попробуй добавить больше деталей в отчет, это поможет нам лучше понять ситуацию».
  • Вовлеченность — чтобы сотрудник мог сам увидеть точки роста, задавайте вопросы: «Как ты сам оцениваешь свою работу?»
Пример. В Google менеджеров обучают давать «развивающую обратную связь», в которой сочетаются похвала, четкая корректировка и рекомендации по улучшению. Это повышает вовлеченность сотрудников и снижает уровень стресса при получении замечаний.
Развитие эмоционального интеллекта требует осознанности и практики, но в результате руководитель получает мощный инструмент для успешного управления командой и создания продуктивной рабочей среды.

Как поддерживать мотивацию и вовлеченность сотрудников

Чем выше вовлеченность команды, тем лучше результаты работы и ниже текучесть кадров. Эмоциональный интеллект руководителя помогает создать среду, в которой сотрудники чувствуют себя ценными и вдохновленными.
Вот ключевые методы повышения мотивации:
  • Признание достижений. Даже простая похвала может повысить уверенность сотрудника в себе.
  • Индивидуальный подход. Кто-то мотивируется новыми вызовами, а кому-то важна стабильность.
  • Создание атмосферы доверия. Если сотрудник не боится высказывать идеи и получать честную обратную связь, его вовлеченность растет.
  • Вовлечение в принятие решений. Когда сотрудники чувствуют, что их мнение важно, они работают с большей отдачей.
Пример. Netflix придерживается принципа «контекст, а не контроль». Руководители делятся с сотрудниками стратегической информацией, но не навязывают жесткие инструкции. Такой подход повышает вовлеченность, так как люди чувствуют ответственность за результат.

Как управлять командой в кризисных ситуациях

Кризисы неизбежны, но руководители с высоким EQ могут снизить тревожность сотрудников и направить их энергию на поиск решений, а не на панику. Рассмотрим основные принципы управления во время кризиса:
  • Спокойствие и уверенность лидера. Сотрудники перенимают эмоциональное состояние руководителя.
  • Открытая коммуникация. Важно честно объяснять ситуацию, даже если новости не самые приятные.
  • Фокус на решениях. Вместо поиска виноватых — обсуждение выхода из кризиса.
  • Поддержка сотрудников. Люди ценят внимание к их эмоциональному состоянию и получают дополнительную мотивацию.
Пример. В 2020 году, во время пандемии COVID-19, генеральный директор компании Airbnb, Брайан Чески, продемонстрировал высокий уровень эмоционального интеллекта. Столкнувшись с резким снижением спроса на туристические услуги, компания была вынуждена сократить около 25% своих сотрудников. Чески лично объявил об этом решении, выразив глубокое сожаление и подчеркнув, что увольнения не связаны с недостатками сотрудников, а стали следствием глобального кризиса. Он подробно объяснил причины и шаги, предпринятые для поддержки увольняемых, включая предоставление выходных пособий и помощи в трудоустройстве. Такая прозрачность и забота о сотрудниках помогли сохранить доверие к руководству и минимизировать стресс в коллективе.

Как управлять эмоциями сотрудников

Эмоциональный климат в коллективе влияет на продуктивность так же, как профессиональные навыки. Руководитель с развитым эмоциональным интеллектом в менеджменте может вовремя выявлять напряженность и предотвращать конфликты. Чтобы управлять эмоциями в коллективе, используют:
  • Активное слушание. Задавайте вопросы: «Что вас беспокоит?», «Как мы можем решить проблему?»
  • Позитивную сторону корпоративной культуры. Традиции компании и командные мероприятия укрепляют эмоциональные связи.
  • Обратную связь с фокусом на рост. Даже в сложных ситуациях важно мотивировать сотрудников.
  • Личный пример. Если руководитель контролирует эмоции, команда учится этому.
Пример. Илон Маск в кризисный период для Tesla проводил ночи на заводе вместе с рабочими, демонстрируя преданность общему делу. Это повысило моральный дух сотрудников и помогло компании преодолеть трудности.

Как недостаток EQ приводит к конфликтам в команде

Руководители с низким уровнем эмоционального интеллекта часто не осознают влияние своих эмоций на окружающих. Это может приводить к напряженности, снижению доверия и открытому противостоянию в коллективе.
Рассмотрим основные причины конфликтов из-за низкого EQ:
  • Импульсивные решения. Руководитель не анализирует эмоции команды перед внедрением изменений.
  • Неспособность распознавать настроение сотрудников. Например, игнорирование выгорания приводит к росту недовольства.
  • Плохая коммуникация. Недостаток эмпатии мешает понять, что тревожит коллектив.
Пример. В компании «Д» внедрили новую систему учета рабочего времени без предварительного обсуждения. Это вызвало негативную реакцию сотрудников, которые увидели в этом недоверие со стороны руководства. Если бы лидер проанализировал эмоции команды заранее и объяснил цели нововведения, конфликта можно было бы избежать.

Почему жесткий стиль управления не всегда эффективен

Авторитарный стиль управления может дать быстрые результаты, но в долгосрочной перспективе он снижает мотивацию, усиливает текучесть кадров и ухудшает корпоративную культуру. Вот основные проблемы жесткого управления:
  • Страх ошибки. Сотрудники боятся высказывать идеи, что снижает инновационность.
  • Недостаток доверия. Команда чувствует себя исполнителями, а не частью бизнеса.
  • Высокий уровень стресса. Давление и микроменеджмент приводят к выгоранию.
Читайте также: «Стили управления командой: все о кнутах и пряниках»

Какие ошибки в обратной связи демотивируют сотрудников

Обратная связь должна помогать развитию, а не вызывать у сотрудников чувство вины или страха. Некоторые руководители допускают такие ошибки:
  • Критикуют без конкретики. «Ты работаешь плохо» — такая фраза не дает понимания, что нужно исправить.
  • Игнорируют положительные аспекты. Только замечания без признания достижений демотивируют.
  • Публично обсуждают ошибки. Замечания при коллегах могут вызывать стресс и раздражение.
Пример. Менеджер компании «Ф» постоянно критиковал сотрудников на общих собраниях. В итоге команда перестала проявлять инициативу, опасаясь новых замечаний. Индивидуальная обратная связь помогла бы избежать такого эффекта.
Как применять полученные знания в управлении
Развитие эмоционального интеллекта — не разовое действие, а постоянный процесс, который требует осознанности. Руководители, которые хотят эффективно управлять командой, должны применять EQ на практике:
Используйте эмоциональный интеллект в принятии решений
Лидер с развитым EQ не принимает решения на эмоциях, а анализирует ситуацию с разных сторон. Перед тем как вводить изменения или давать критику, важно учитывать настроение команды, возможные реакции и долгосрочные последствия.
Совет. Перед важным решением спросите себя: «Как это отразится на эмоциях сотрудников?» Если решение может вызвать стресс, подготовьте стратегию его внедрения с минимальными рисками.

Практикуйте осознанное лидерство

Эмоциональный интеллект в управлении персоналом помогает не только контролировать эмоции, но и осознавать, как ваш стиль общения влияет на коллектив. Уверенность, спокойствие и эмпатия руководителя создают комфортную рабочую атмосферу.
Пример. Генеральный директор Microsoft Сатья Наделла изменил корпоративную культуру компании, сделав акцент на эмпатии и обучении. Это позволило повысить вовлеченность сотрудников и вывести компанию на новый уровень.

Развивайте культуру обратной связи

Регулярная и конструктивная обратная связь помогает сотрудникам понимать свои сильные стороны и зоны роста. Важно делать это не только в сложные моменты, но и для поддержки мотивации.
Как внедрить:

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

Создавайте психологически безопасную среду

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

Будьте примером для команды

Руководитель задает тон для всей организации. Если он сам управляет эмоциями, проявляет эмпатию и остается профессионалом даже в сложных ситуациях, команда перенимает этот стиль поведения.
Пример. В 2014 году гендиректор Starbucks Говард Шульц столкнулся с падением прибыли компании и необходимостью преобразований. Вместо жестких мер он сделал ставку на вовлеченность сотрудников: инициировал программу бесплатного образования для работников, усилил внутреннюю коммуникацию и уделил внимание их благополучию. Это повысило лояльность команды, улучшило сервис и в итоге помогло Starbucks восстановить позиции на рынке.

Что в итоге

Развитие эмоционального интеллекта — не просто модный тренд, а ключевой инструмент эффективного лидерства. Руководители, которые осознанно работают над своим EQ, создают здоровую рабочую атмосферу, мотивируют команду и принимают взвешенные управленческие решения. Внедрение этих принципов помогает не только улучшить взаимоотношения в коллективе, но и повысить продуктивность бизнеса в целом.
Если вы хотите вывести управление в вашей компании на новый уровень, специалисты Neogenda помогут в этом. Мы работаем с крупнейшими компаниями, такими как Tinkoff, Яндекс, Авито, Сбер и Билайн, и уже обучили более 5 000 сотрудников. Наши эксперты подберут для вас индивидуальные решения, основанные на реальном управленческом опыте и современных практиках.
Запишитесь на бесплатную консультацию в Zoom, чтобы найти способы сделать вашу команду еще эффективнее.
]]> Почему организационные изменения проваливаются и как этого избежать http://neogenda.ru/blog/o69hjxp6v1-pochemu-organizatsionnie-izmeneniya-prov http://neogenda.ru/blog/o69hjxp6v1-pochemu-organizatsionnie-izmeneniya-prov?amp=true Sat, 22 Mar 2025 07:09:00 +0300 Алексей Пименов Изменения — это сложный процесс, который легко провалить. Существует два основных способа сделать это: перегрузка...

Почему организационные изменения проваливаются и как этого избежать

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

1. Перегрузка изменений

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

2. Ложное плато

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

Баланс между перегрузкой и ложным плато

Менеджер изменений должен находить баланс: не перегружать систему и не останавливаться на полпути. Для этого используются:
  • Хардовые инструменты: визуализация, метрики, принятие решений на основе данных.
  • Софтовые инструменты: убеждение, работа с сопротивлением, создание доверия.
Но есть еще одна важная составляющая — обход эмоционального сопротивления.

Как обойти эмоциональное сопротивление

Любые организационные изменения — это атака на идентичность людей. Человек привык к своей роли, понимал свое место в системе, а теперь ему говорят: «Ты был таким, а теперь будешь другим».
Это затрагивает не только привычки, но и самоощущение, вызывая страх и неуверенность. Возникает сопротивление. Как его снизить?

1. Принцип дзюдо: сначала поддаться, затем направить

Вместо того чтобы сразу ломать сопротивление, присоединитесь к эмоции человека. Признайте его сомнения: «Да, часто такое не работает», «Я тоже так думал». Это снижает барьер, и после этого можно плавно перевести обсуждение в логику: «Но давай разберемся, как это можно улучшить».
Пример: Компания хочет перевести сотрудников на удаленную работу. Люди боятся изоляции и снижения эффективности. Вместо приказа руководство сначала обсуждает плюсы и минусы с коллективом, выявляет основные страхи, а затем предлагает постепенный переход с промежуточными этапами адаптации.

2. Перебить эмоцию более сильной эмоцией

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

3. Смена альфа-лидера

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

4. Создание точки пунктуации

Пункт номер 4 требует особого внимания. Чтобы понять его суть, полезно обратиться к биологической модели эволюционного развития — концепции «прерывистого равновесия» (punctuated equilibrium).

Прерывистое равновесие в природе

В биологии прерывистое равновесие описывает, как экосистемы могут находиться в двух состояниях:
  • Период пунктуации: Это момент, когда происходит нечто кардинальное – падение метеорита, таяние ледников, экологическая катастрофа. Такие события резко меняют условия жизни, и виды начинают эволюционировать очень быстро. Один из ярких примеров – Кембрийский взрыв, когда накопление кислорода позволило перейти от жизни беспозвоночных к позвоночным.
  • Состояние равновесия: Это длительный период стабильности, когда изменения происходят очень медленно. Примером могут служить изолированные экосистемы, где виды эволюционируют минимально. Так, на Галапагосских островах сохранилась уникальная голубоногая олуш, демонстрирующая, как стабильные условия позволяют сохраняться определенным характеристикам на протяжении долгого времени.

Пунктуация в жизни и бизнесе

Аналогичным образом, в жизни человека и в бизнесе существуют периоды, когда изменения происходят легче или, наоборот, практически отсутствуют:

Периоды пунктуации

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

Состояние равновесия (зона комфорта)

В периоды стабильности, когда ничего критически не угрожает, отсутствует стимул для перемен. Здесь можно провести интересную аналогию: представьте, что вы сидите на муравейнике – муравьи кусают, но боли недостаточно, чтобы заставить вас встать и изменить ситуацию. Так и в комфортной зоне люди зачастую не видят необходимости меняться, потому что им привычно и безопасно.
Создание точки пунктуации: пример из политики
Для иллюстрации принципа создания точки пунктуации рассмотрим исторический кейс с Маргарет Тэтчер.
История Фолклендских островов
Маргарет Тэтчер, премьер-министр Великобритании, в начале своего первого срока сталкивалась с низкими рейтингами и скептицизмом общества. Однако судьба страны, а вместе с ней и политический курс, изменилась благодаря кризису на Фолклендских островах:
5. Эмоциональное вовлечение
В мире организационных изменений важны не только стратегические и аналитические решения, но и способность задействовать эмоциональную составляющую коллектива.
Эмоциональное вовлечение: бальзам на душу
Эмоциональное вовлечение – это инструмент, который помогает создать атмосферу доверия и участия. Он основан на идеях storytelling и визуализации процессов, а также на принципах кайзен-культуры. Вот как это работает:
  • Storytelling и визуализация: Рассказывая истории успеха, показывая примеры и демонстрируя визуальные материалы, вы помогаете людям увидеть конечную цель и понять, зачем нужны изменения. Это позволяет им лично прикоснуться к новому видению, почувствовать себя участниками процесса.
  • Интерактивные методы: Применение тактильных инструментов, таких как стикеры, бумажки и голосование точками на фасилитационных сессиях, позволяет сотрудникам активно включаться в процесс принятия решений. Такой подход превращает изменения в игру, где каждый имеет возможность внести свой вклад, а коллектив чувствует, что его мнение действительно важно.
  • Эмпатия и участие: Вовлечение людей – это не только о сборе идей, но и о проявлении эмпатии. Когда сотрудники видят, что их мнение учитывается, они охотнее поддерживают изменения. Это помогает создать устойчивый эмоциональный фундамент для дальнейших трансформаций.

6. Коучинг идентичности

Последний, но не менее важный инструмент – это коучинг идентичности или смена идентичности. Он представляет собой работу профессиональных коучей, способных изменить внутреннее восприятие сотрудника и его отношение к работе. В отличие от гибких методов, которые можно масштабировать для работы с большими группами, коучинг идентичности работает по принципу «рапиры»: вы целенаправленно воздействуете на критическую точку, где должно произойти значимое изменение.
Целенаправленное воздействие: Профессиональный коуч, используя инструменты вроде пирамиды Дилтса, меняет майндсет сотрудника без предварительного запроса на перемены. Это сложный процесс, требующий глубокого понимания психологии человека, но результаты могут быть поразительными.
Сложность масштабирования: Основная трудность коучинга идентичности заключается в его масштабировании. Если требуется изменить мышление сотен людей, понадобится целая армия высококвалифицированных коучей. Поэтому зачастую этот инструмент используется выборочно – руководитель передаёт наиболее ценного сотрудника в руки эксперта, как бы выделяя драгоценный камень для тонкой обработки.
Подводя итог, можно сказать, что успешное проведение организационных изменений требует продуманного и поэтапного подхода.
Представленные нами шесть инструментов — обход эмоционального сопротивления, эмоциональное вовлечение, смена альфа-лидера, коучинг смены идентичности, перебитие эмоций более сильной эмоцией и, наконец, создание точки пунктуации — образуют план, показывающий как сложность применения, так и степень риска каждого метода.
Эти инструменты позволяют вывести сотрудников из состояния привычного равновесия, создать пространство для рефлексии и выработки нового решения, а затем стабилизировать новую реальность. При этом:
  • Обход эмоционального сопротивления помогает мягко перевести эмоциональное состояние людей в логическую плоскость.
  • Эмоциональное вовлечение через истории, визуальные материалы и интерактивные методы позволяет сделать процесс изменений персональным и понятным.
  • Смена альфа-лидера даёт шанс обновить культурные коды коллектива, заменив старые подходы новым, более прогрессивным взглядом.
  • Коучинг смены идентичности (хоть и высокоэффективный) остаётся сложным для масштабирования инструментом, требующим участия опытных специалистов.
  • Перебитие эмоций более сильной эмоцией применяется в тех случаях, когда сопротивление достигает критической массы, но требует крайней осторожности.
  • Создание точки пунктуации – самый радикальный и, пожалуй, кровавый метод, который применяется только в исключительных случаях, когда изменение системы неизбежно, и требуется создать кризис для запуска эволюционных преобразований.
]]> Как строить стратегию компании: разбор ошибок и эффективных подходов http://neogenda.ru/blog/nrs8ea8yd1-kak-stroit-strategiyu-kompanii-razbor-os http://neogenda.ru/blog/nrs8ea8yd1-kak-stroit-strategiyu-kompanii-razbor-os?amp=true Sat, 22 Mar 2025 07:20:00 +0300 Артур Нек Меня зовут Артур Нек, и я консультант по Objective & Key Result (OKR) — простому...

Как строить стратегию компании: разбор ошибок и эффективных подходов

Меня зовут Артур Нек, и я консультант по Objective & Key Result (OKR) — простому и легковесному фреймворку, который позволяет эффективно планировать работу компании. Этот подход широко применяется такими гигантами, как Google и Intel, а в последние годы активно распространяется и в России. Многие компании используют его для постановки целей, определения ключевых результатов и оценки их достижения.
Но перед тем как говорить о целеполагании, важно разобраться в стратегии компании. Ведь часто бизнес сталкивается с вопросом: «А есть ли у нас вообще стратегия?» Именно этот момент и стал отправной точкой моего доклада.

Почему важна стратегия?

Институт стратегирования — это не новая концепция; его активное развитие началось с 1960-х годов.
Если вы хотите глубже разобраться в построении стратегий, рекомендую изучить ключевые школы стратегического мышления. Один из фундаментальных трудов в этой области — «Стратегическое сафари» Генри Минцберга, где представлен полный спектр стратегических подходов.
Несмотря на разнообразие стратегических школ, все они сходятся в одном: стратегия — это эффективное использование имеющихся ресурсов (человеческих, финансовых и других), их грамотное структурирование и направление для достижения выгодного положения на рынке и улучшения ключевых показателей. По сути, стратегия — это определение долгосрочных целей.
Понятие «долгосрочный период» может варьироваться, но обычно речь идет о 3–5 годах. Чем меньше у вас ресурсов, тем более продуманная стратегия требуется. В условиях ограниченных возможностей важно минимизировать риски и избегать размытия фокуса.

Проблемы со стратегией: распространенные ошибки

1. «Вечные стратегии» — забытые документы

Один из самых распространенных сценариев: стратегия вроде бы есть, но она устарела. Встречаются компании, где стратегические документы хранятся в архиве и написаны 10–20 лет назад. В таких случаях руководство может сказать: «Да, у нас есть стратегия!» — но по факту она неактуальна и не помогает в принятии решений.
Рынок постоянно меняется, и стратегия должна быть гибкой, учитывающей современные вызовы. Если ваш стратегический документ — это просто «хотелка» в духе «стать вторым Яндексом или Facebook», без четкого плана действий, то он не принесет пользы.

2. «Шизофреническая стратегия» — раздвоение реальности

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

3. «Вода» — пустые и сложные формулировки

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

4. «Неспособность найти проблему» — игнорирование ключевых препятствий

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

Признаки хорошей стратегии

Начинается всегда с 3 этапов: постановка диагноза → сформированная политика решения проблемы → согласованные направления и ресурсы.
  • Анализ текущей ситуации — глубокая оценка рынка, внутренних процессов, ресурсов и возможностей компании. Включает анализ конкурентов, потребностей клиентов и возможных угроз.
  • Четкие приоритеты — стратегия должна четко обозначать ключевые направления развития и проблемы, которые необходимо решить в первую очередь.
  • Простота и понятность — стратегия не должна быть перегружена сложными терминами, она должна быть понятна всем сотрудникам, от руководства до исполнителей.
  • Связь с операционным уровнем — стратегия должна быть заземлена на конкретные задачи, инициативы и измеримые показатели, которые можно отслеживать в динамике.
  • Гибкость — способность адаптироваться к изменяющимся условиям рынка. Хорошая стратегия предусматривает возможность корректировки на основе новых данных и изменений во внешней среде.
  • Фокус на конкурентные преимущества — стратегия должна учитывать уникальные сильные стороны компании и способы их эффективного использования.
  • Понятные механизмы реализации — в стратегии должны быть четко прописаны инструменты, методы и подходы, с помощью которых цели будут достигнуты.
  • Прозрачность и вовлеченность команды — стратегия должна быть донесена до всех сотрудников компании, чтобы каждый понимал свою роль в ее реализации.

Как строить стратегию компании в кризисное время: ключевые подходы

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

Инерционная стратегия: ловушка сокращений

Одной из распространенных реакций на кризис является инерционная стратегия, которая, к сожалению, часто ведет к замкнутому кругу проблем. Представьте ситуацию: в компании падает спрос, снижается покупательская способность клиентов, уменьшается объем продаж, и, как следствие, выручка. Первое, что приходит в голову управленцам — срочно взять ситуацию под контроль и сократить затраты. Самое очевидное решение — урезать фонд оплаты труда (ФОТ).
Сценарий выглядит так: руководители сократят 30% сотрудников, еще 20% переводят на сдельную оплату. Вроде бы план по экономии выполнен, но неожиданно падает качество работы, снижается уровень сервиса, растет текучка кадров.
В результате выручка проседает еще сильнее, а возможности для роста становятся все более ограниченными. Так компания загоняет себя в петлю, которая лишь усиливает кризис.

Почему массовые сокращения — рискованное решение?

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

Четыре базовые антикризисные стратегии

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

Как определить правильный фокус?

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

Горизонт планирования: как часто пересматривать стратегию?

В современных условиях долгосрочное стратегическое планирование отошло на второй план. Сейчас наиболее эффективный горизонт планирования — от полугода до года. Многие компании пересматривают стратегию раз в квартал, что позволяет быстро адаптироваться к изменениям и корректировать курс.
Такой подход дает несколько преимуществ:
  • Позволяет быстро реагировать на новые рыночные условия.
  • Обеспечивает регулярный анализ финансовых результатов и ключевых показателей.
  • Дает гибкость в стратегическом управлении.
]]> Паспорт продукта: зачем он нужен и как его собрать? http://neogenda.ru/blog/3m2r7zaak1-pasport-produkta-zachem-on-nuzhen-i-kak http://neogenda.ru/blog/3m2r7zaak1-pasport-produkta-zachem-on-nuzhen-i-kak?amp=true Mon, 24 Mar 2025 07:23:00 +0300 Дмитрий Кустов Сегодня поговорим о концепции паспорта продукта: зачем он нужен, как возникла эта идея, какие проблемы...

Паспорт продукта: зачем он нужен и как его собрать?

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

Как появилась идея паспорта продукта?

Концепция возникла на основе опыта одной из компаний. Проблема заключалась в том, что управление продуктом сопровождалось множеством разрозненных документов, хранящихся в разных местах: Miro, Excel, Google Диск, внутренние инструменты. Информация о продукте была разбросана по разным вкладкам у менеджеров, что усложнило доступ и системный анализ.
Возникла необходимость собрать все данные в одном документе, который позволял бы быстро получить целостное представление о продукте:
  • Как развивается продукт?
  • Почему развивается именно в этом направлении?
  • Как изменяются ключевые метрики?
  • Какие показатели анализируются?
Благодаря такому документу компания не зависела от конкретного владельца продукта. Даже если он покидал команду, у бизнеса оставалась четкая и структурированная информация о продукте.

Что включает в себя паспорт продукта?

Наполнение паспорта продукта зависит от специфики компании. Каждая команда формирует его по-своему, ориентируясь на ключевые задачи, требования топ-менеджмента и стратегические приоритеты.
Пример паспорта продукта организации:
  • Ключевые артефакты
  • Бизнес показатели
  • Продуктовые показатели
  • Основные ссылки
  • Команда
  • Логи
Ключевые артефакты:
  • VISION
  • Финансовая модель
  • Объем рынка
  • Анализ конкурентов
  • Позиционирование
  • Стратегия
  • Roadmap
Все данные хранились в Confluence, но можно использовать любой удобный инструмент — Google Docs, Notion или другую систему. Главное, чтобы информация была централизованной и легко доступной.

Как это работало на практике

Верхний блок паспорта содержал ключевые артефакты, где отмечались даты последнего обновления. Например, объем рынка мы пересчитывали несколько раз, и самая актуальная версия документа всегда находилась вверху.
Далее шли бизнес показатели, которые заполнялись владельцем продукта в начале каждого месяца. Мы отслеживали:
  • выручку от новых и старых пользователей,
  • общую выручку,
  • расходы,
  • gross profit.
В зависимости от специфики вашего продукта метрики могут быть другими — важно, чтобы они помогали понимать текущее состояние бизнеса.
Следующим блоком были продуктовые метрики, аналогично обновляемые раз в месяц. Каждая компания определяет их самостоятельно, исходя из специфики продукта.
Затем размещались ссылки на важные документы и инструменты — Miro, Jira, файлы по Discovery и Delivery процессам, ссылки на Figma. Это упрощало доступ к информации для всех участников команды.
Далее представлен список ключевых участников команды. Основные роли включали:
  • Владелец продукта
  • Delivery Manager
  • Team Lead разработчиков.
  • Team Lead саппорта
  • Продуктовый дизайнер
  • Продуктовый маркетинг-менеджер
Завершающим разделом являются логи по продукту, которые содержат описание ключевых артефактов и их изменений. В логах сохраняются все предыдущие версии важных документов.
Например, если обновляется анализ рынка, старый документ переносится в лог, а новая версия фиксируется в заголовке.
Кроме того, в логах хранятся документы, связанные с исследованиями рынков, конкурентов и клиентов. Регулярно проводились встречи Product Roadmap Preview, и все презентации загружались в этот раздел. Также проходили встречи Product Discovery Review, о которых будет представлено отдельное видео с подробным описанием оформления. Все артефакты хранились в логах, что позволяло отслеживать даты, ключевые выводы и решения, принятые на каждом этапе.

Зачем собирать паспорт продукта?

Заполнение и актуализация паспорта продукта требуют внимания со стороны менеджера или владельца продукта. Однако выгоды от этого процесса значительны:
  1. Получаете целостную картину о продукте компании без подключения памяти менеджера или владельца продукта.
  2. Структурирует и систематизирует работу менеджера или владельца продукта.
  3. Освобождает менеджеров и владельцев продуктов от бесед с заинтересованными лицами, когда им хочется обновить картину понимания продукта.
  4. Снижает когнитивную нагрузку на менеджеров и владельцев продуктов по содержанию целостной картине продукта.
  5. В случае замены менеджера или владельца продукта, новому продакту будет легче разобраться с продуктом.
]]> Четыре основные метрики Канбан-системы http://neogenda.ru/blog/nlmtd2khx1-chetire-osnovnie-metriki-kanban-sistemi http://neogenda.ru/blog/nlmtd2khx1-chetire-osnovnie-metriki-kanban-sistemi?amp=true Tue, 25 Mar 2025 07:25:00 +0300 Канбан – это мощный инструмент для управления рабочими процессами. Чтобы эффективно использовать эту методологию, необходимо...

Четыре основные метрики Канбан-системы

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

Время производства (Lead Time)

Время производства – время от момента попадания задачи в систему до момента ее завершения. Если ваша Канбан-доска начинается с момента принятия обязательства, то вы можете измерять время от попадания задачи в систему до ее выполнения. Чем короче это время, тем быстрее заказчики получают результаты.

Пропускная способность (Throughput)

Пропускная способность – это количество завершенных задач за единицу времени. Аналогия с автомобильной скоростью помогает лучше понять эту метрику: скорость измеряется в километрах в час, а пропускная способность – в задачах за неделю, месяц или другую единицу времени.
Часто путают время производства и пропускную способность. Например, когда менеджер говорит: «Я хочу, чтобы работа выполнялась быстрее», он может иметь в виду как ускорение выполнения каждой задачи, так и увеличение количества задач в единицу времени. Эти показатели требуют разных управленческих решений.

Эффективность потока (Flow Efficiency)

Эффективность потока показывает, сколько времени из всего производственного цикла задача находилась в активной работе, а сколько – в ожидании. Рабочий процесс можно представить как череду активной работы и простоев. Например, разработчик выполнил задачу (T1), но прежде, чем ее подхватит следующий специалист, проходит время ожидания (T2). В итоге значительная часть времени может уходить впустую.
Для расчета эффективности потока аналитики отслеживают, в каких колонках Канбан-доски задача находилась в статусе «в работе», а в каких – «в ожидании». Вычтя время в буферных колонках, можно рассчитать эффективность. Однако стоит помнить, если метрика показывает, например, 47%, это не обязательно отражает реальную картину. Время в колонке «в работе» не означает, что задача активно выполнялась без перерывов.
По отрасли средняя эффективность потока варьируется от 1% до 15%, и это нормально. Всегда нужно выбирать гранулярность. Главное – понимать, где можно уменьшить ожидания и сделать процесс более непрерывным.
Однако использовать эту метрику для KPI не рекомендуется, поскольку чем хуже вы ее считаете, тем лучше выглядят показатели. Важно помнить, время касания это не одно и тоже с суммарными трудозатратами.

Количество незавершенной работы (Work in Progress, WIP)

Количество незавершенной работы – это число задач, находящихся в работе в данный момент. Этот показатель напрямую влияет на время производства. Чем больше задач одновременно в работе, тем выше вероятность их задержки. Для управления этим параметром в Канбане применяют WIP-лимиты, ограничивающие число активных задач.
Как влиять на метрики?
  • Хотите увеличить пропускную способность? Увеличивайте число специалистов или автоматизируйте процессы.
  • Хотите сократить время производства? Ограничивайте количество задач в работе с помощью WIP-лимитов.
  • Хотите повысить эффективность потока? Минимизируйте время ожидания между этапами.
Важно оценивать эффективность потока для понимания работы системы. Но помните, не сравнивайте свою эффективность с чужой, только с собственной, и не связывайте эффективность с внешними метриками, такими как ОКR или KPI.

Как предсказывать сроки выполнения задач?

Когда заказчик спрашивает: «Когда будет готова задача?», важно уточнить, с какой вероятностью он хочет получить прогноз. Предсказать на 100% невозможно, но статистика поможет дать разумный ответ.
В Канбане для этого строят диаграмму распределения времени выполнения задач. Она показывает, за сколько времени в прошлом выполнялись задачи, и помогает прогнозировать сроки. Если менеджер настаивает на 100% предсказуемости, стоит показать ему максимальный срок, например, год. Чаще всего он осознает, что разумнее ориентироваться на более вероятные сроки (4-6 месяцев)
]]> Как мотивировать сотрудников http://neogenda.ru/blog/0cm8gfjnl1-kak-motivirovat-sotrudnikov http://neogenda.ru/blog/0cm8gfjnl1-kak-motivirovat-sotrudnikov?amp=true Mon, 07 Apr 2025 07:27:00 +0300 Артур Нек Представьте ситуацию: вы собрали команду профессионалов, экспертов в своей области, но они работают без энтузиазма....

Как мотивировать сотрудников

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

Почему финансовая мотивация работает недолго

Финансовая мотивация, будь то повышение зарплаты или дополнительные бонусы, имеет короткий срок действия.
Уже через 2-3 недели после повышения сотрудники возвращаются к привычной рутине. Деньги перестают быть стимулом, и вовлеченность снова падает.
Но почему так происходит?
Дело в том, что финансовая мотивация — это внешний фактор. Она не затрагивает внутренние потребности человека, которые действительно влияют на его вовлеченность и желание работать.
Рассмотрим основные типы внутренней мотивации, которые важно учитывать.

Четыре типа внутренней мотивации

1. Мотивация выживания

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

2. Мотивация вознаграждения

Этот тип мотивации популярен в торговых компаниях.
Сотрудники стремятся к премиям, повышению зарплаты или социального статуса. Вначале такая система кажется эффективной: люди стараются, достигают целей. Однако через месяц-два они привыкают к новому уровню дохода и начинают воспринимать его как должное.
Пример: Если сотрудник привык получать 13 тысяч рублей вместо 10, он перестает видеть в этом стимул. Инициатива падает, и вовлеченность снова снижается.

3. Мотивация принадлежности

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

4. Мотивация смысла

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

Как мотивировать сотрудников: практические шаги

Теперь, когда мы разобрали типы мотивации, давайте поговорим о том, как создать условия для вовлеченности в вашей компании.
1. Делегирование решений
Не превращайтесь в «решалу», к которому сотрудники приходят с любым вопросом. Пусть они сами предлагают решения проблем. Это развивает их самостоятельность и вовлеченность.
2. Автономность принятия решений
Дайте сотрудникам свободу действий в их зоне ответственности. Например, пусть сами выбирают подрядчиков или методы достижения целей. Это повышает их вовлеченность на 70%.
3. Формулировка долгосрочных целей
Четко обозначьте, какой результат вы ожидаете от сотрудника и как его работа влияет на общие цели компании. Это помогает сплотить команду и дает сотрудникам понимание их роли.
4. Доверительная атмосфера
Создайте среду, где ошибки — это часть процесса, а не повод для наказания. Поощряйте профессиональное развитие и образовательные активности.

Как понять, что мотивирует сотрудника?

На этапе собеседования задайте кандидату вопросы, которые помогут понять его мотивацию:
  • Если мы повысим тебе зарплату в два раза, что ты будешь с ней делать?
  • Если мы сократим твою зарплату на 30%, как ты отреагируешь?
Ответы на эти вопросы покажут, что для человека важнее: деньги, стабильность или смысл. Также обратите внимание на то, какие вопросы задает кандидат. Если он интересуется продуктом, миссией компании, это говорит о его вовлеченности. Если же его волнует только график и зарплата, это сигнал о мотивации выживания.

Заключение

Настоящая мотивация сотрудников строится не на деньгах, а на вовлеченности, автономности и доверии. Комбинация этих факторов позволяет создать команду, которая не только эффективно работает, но и чувствует себя частью чего-то большего.
]]> Как управлять удаленными командами http://neogenda.ru/blog/ihgfj43zd1-kak-upravlyat-udalennimi-komandami http://neogenda.ru/blog/ihgfj43zd1-kak-upravlyat-udalennimi-komandami?amp=true Tue, 08 Apr 2025 07:30:00 +0300 Артур Нек Удаленку все чаще практикуют в разных компаниях. Где-то переходят на гибридный формат — 3–4 дня...

Как управлять удаленными командами

Удаленку все чаще практикуют в разных компаниях. Где-то переходят на гибридный формат — 3–4 дня в офисе, 1–2 дня дома. А где-то сотрудникам разрешают работать из дома постоянно. Рассказываем, с какими проблемами сталкиваются работодатели при переходе на удаленку и как переводить команды на работу из дома.

Проблемы при работе с удаленными командами

Сложности коммуникации и синхронизации работы. Когда команда работает из разных мест и часовых поясов, выстроить нормальную коммуникацию очень сложно. Проявляется это в нескольких проблемах:
  • сообщения в мессенджерах теряются и остаются без ответа;
  • недопонимания сотрудников из-за отсутствия невербальных сигналов;
  • часть информации искажается и воспринимается неверно;
  • сложно определить, кто и какой задачей занимается прямо сейчас.
Проблемы с мотивацией и вовлеченностью. Удаленные сотрудники часто чувствуют себя оторванными от общей миссии компании и слабо вовлечены в жизнь компании. Иногда из-за этого у них снижается мотивация работать и возникает выгорание.
Сложности с контролем сотрудников без микроменеджмента. Иногда начальникам кажется, что люди из дома практически не работают, занимаются своими делами и решают важные задачи в последний момент. Это часто приводит к микроменеджменту, который демотивирует команду.
Размытие границ между рабочим и личным временем. Когда офис и дом — одно и то же место, границы между работой и личной жизнью стираются. По данным Buffer, 22% удаленных сотрудников своей главной проблемой называют невозможность отключиться от работы. В результате это приводит к переработкам, выгоранию, ухудшению качества жизни и низкой продуктивности.
Срыв сроков. Бывает и такое: руководитель доверяет сотрудникам и не следит за каждым их действием, а те забивают на важные задачи, не успевают по срокам и подводят компанию.

Как перевести на удаленку тех, кто был в офисе

Начнем с самого интересного — как отправить работать из дома тех, кто до этого всегда был в офисе.

Проанализировать текущие процессы и адаптировать их к удаленному формату

Что нужно проанализировать.
1. Рабочие процессы: какие из них нужно решать только в офисе, а какие можно выполнять удаленно.
2. Документооборот: какие документы существуют только в бумажном виде и что нужно оцифровать.
3. Коммуникационные каналы: как информация передается между сотрудниками и отделами, где могут возникнуть проблемы при удаленной работе.
4. Инструменты и программное обеспечение: что из имеющегося пригодно для удаленки, а какое ПО нужно докупить.
Например, если в отделе продаж все данные о клиентах хранятся в Excel-таблицах, нужно заранее перейти на облачную CRM-систему и настроить доступы сотрудникам.

Создать инструкции по решению задач

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

Создать руководства по работе

В руководство должны входить:
1. Технические аспекты: как настроить домашнее рабочее место, какое оборудование необходимо, как подключаться к корпоративным системам.
2. Организационные моменты: как вести учет рабочего времени, какие каналы использовать для разных типов сообщений, как участвовать в виртуальных встречах.
3. Безопасность: правила работы с конфиденциальной информацией, настройки VPN, требования к паролям и 2FA.
Такое руководство стоит делать интерактивным — с видеоинструкциями, скриншотами и примерами.
Если в будущем планируется проводить онбординг новичков, дополнительно можно разработать организационную карту — документ, отражающий структуру компании, ключевых людей и их зоны ответственности. Она помогает понять, к кому обращаться по разным вопросам.
Пример организационной карты в компании по web-разработке
А также сделать базу знаний с информацией о продуктах, процессах, инструментах и терминологии компании.

Установить правила коммуникации и рабочего времени

В офисе вопросы решаются проще: подошел к коллеге → спросил → вернулся к работе. На удаленке надо ввести четкие правила.
Например, определить часы доступности — время, когда все должны быть на связи для оперативного решения вопросов. А также установить регламент ответов на сообщения: на email можно отвечать в течение дня, а на сообщения в рабочем чате — в течение часа. Договориться о статусах доступности: «в работе», «на встрече», «обед», «не беспокоить».
Также нужно ввести главное правило — все должно быть задокументировано. Даже если это промежуточное решение. Все цели и задачи тоже нужно отражать в письменном виде. Для каждой команды и каждого сотрудника.
Когда все будет готово, останется выбрать сервисы для управления проектами и взаимодействия сотрудников.

Какие инструменты использовать для управления командой на удаленке

В работе пригодятся инструменты для разных задач:
  • для коммуникации;
  • для мониторинга задач;
  • для управления персоналом;
  • для совместной работы с документами;
  • для трекинга рабочего времени.

Для коммуникации

Для созвонов по видео подойдут Zoom, Яндекс.Телемост, VK Звонки, корпоративные сервисы, Сбер Jazz и др.
А для общения стоит использовать корпоративные мессенджеры вроде Пачка, Slack, Discord. Можно использовать и обычные мессенджеры: Telegram, WhatsApp и др.
Но все же лучше использовать корпоративные мессенджеры, потому что в WhatsApp и Telegram системные администраторы не смогут контролировать состав участников. Если кто-то из сотрудников уволится, его могут забыть удалить из чата и он продолжит видеть конфиденциальную информацию.
Кроме того, корпоративные мессенджеры помогут разделять личные и рабочие сообщения сотрудников. Все потому, что после работы сотрудник, скорее всего, все равно будет пользоваться тем же Telegram, будет получать сообщения и невольно читать их. А когда сообщения будут разделены, случайно прочитать их будет сложнее.

Для мониторинга задач

Подойдут любые системы управления проектами: WEEK, Kaiten, Bitrix и др CRM.
Эти сервисы помогут ставить задачи и следить за их выполнением, применять методологии agile/scrum. Анализировать скорость работы команды и планировать будущие задачи, давать комментарии и в целом работать над улучшением процессов.

Для совместной работы с документами

Подойдут любые файлообменники вроде Google Drive и Яндекс Диск, а также любые сервисы для совместной работы: Google Документы, Google Презентации, базы данных в Notion и т. д.
Работать в таких сервисах обязательно, иначе документы будут вечно теряться. Да и сортировать их в том же Telegram или Пачке будет не очень удобно. А в Google Drive все сотрудники смогут отыскать нужный файл – открыть его в документах и внести изменения при необходимости.

Для управления персоналом

Пригодятся системы вроде Контур.Персонал, Битрикс24, СберПульс.
Системы для управления персоналом используют HR-менеджеры для упрощения рутинных процессов. Такие сервисы называют HRM-системами (система управления человеческим капиталом).
HRM-системы помогают проводить обучение сотрудников, облегчают поиск и наем новых работников, следят за расписанием и отпусками и даже помогают разобраться в документации.

Для контроля рабочего времени

Подойдут любые трекеры: Toggl, Harvest, Kickidler, Everhour.
Такие сервисы помогут понять, сколько времени уходит на решение задачи, что занимает больше всего времени и т. д. Главное — чтобы сотрудник не забывал вовремя включать и выключать таймер.
Некоторые руководители воспринимают системы учета рабочего времени исключительно как инструмент контроля. Кто-то даже запрашивает доступ к интернет-логам пользователей, экранам и веб-камере человека. Но мы считаем, что трекеры стоит использовать только для оптимизации рабочей нагрузки и предотвращения выгорания.
Поэтому сотрудникам стоит объяснять, что вести учет рабочего времени нужно не для отчетности перед руководителем, а для совместного анализа эффективности. Такой подход дает ценную информацию:
  • какие задачи занимают непропорционально много времени и нуждаются в оптимизации;
  • кто из команды перегружен;
  • какие процессы содержат скрытые трудозатраты, невидимые при планировании;
  • как сотрудники распределяют время между разными типами задач.
Эта информация позволяет точнее планировать спринты и проекты. Предотвращает выгорание и помогает понять, где нужны дополнительные ресурсы или автоматизация.
Сервисы для удаленной работы

Как следить за работой удаленных сотрудников и не переходить в тотальный контроль

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

Как правильно выстроить общение с удаленными командами

Для максимальной эффективности нужно использовать три типа обратной связи:
1. Позитивная обратная связь — отмечать успехи и достижения. Многие руководители считают, что хорошая работа — это норма, которую не нужно подчеркивать. Но на удаленке нет невербальной коммуникации, нельзя пожать руку человеку и т. д. Поэтому конкретная похвала за конкретные достижения повышает мотивацию и уверенность сотрудников.
2. Негативная (корректирующая) обратная связь — указывать на ошибки и области для улучшения. Здесь важно говорить конкретно, фокусироваться на действиях, а не на личности, и предлагать решения. В удаленном формате лучше давать такую обратную связь в видеоформате, чтобы видеть реакцию сотрудника и сразу прояснять недопонимание.
3. Смысловая обратная связь — связывать работу сотрудника с большими целями компании и показывать ее значение. В такой обратной связи важно объяснять, как конкретные действия человека влияют на общий успех, какую ценность они создают для клиентов и компании, чтобы поддерживать уровень мотивации.
В общении на удаленке важна регулярность. Это помогает не терять информацию и решать задачи вовремя. Общаться можно двумя способами: текстом в мессенджерах или на видеовстречах и созвонах.
В случае с видеовстречами и созвонами можно использовать такую структуру:
  • Ежедневные стендапы (15–20 минут). Короткие встречи, где каждый рассказывает о том, что сделал вчера, что планирует сегодня и с какими проблемами столкнулся. Цель — синхронизировать сотрудников и выявить потенциальные проблемы.
  • Еженедельные командные встречи (30–60 минут). Более глубокое обсуждение задач, планирование на неделю вперед, решение накопившихся вопросов.
  • Ежемесячные ревью результатов (1–2 часа). Анализ достижений за месяц, корректировка целей, закрытие задач. Пересмотр долгосрочных целей, расстановка приоритетов на будущее.
А чтобы созвоны всегда проходили с пользой, заранее объясняйте цель встречи и ожидаемые результаты. Говорите, какую информацию каждый специалист должен к ней подготовить. Это поможет минимизировать риск, что беседа пойдет не по плану.
Назначайте модератора, который будет следить за временем и вовлекать всех участников. Планерки изматывают сотрудников и снижают продуктивность, в идеале встреча должна длиться до 2 часов.
Разрешайте сотрудникам шутить и флудить. В удаленных командах нужно поддерживать неформальное общение, чтобы коллеги лучше узнавали друг друга и дружили.
Ведите заметки во время встречи в общем документе, где все будут видеть ключевые мысли и решения. А в конце встречи делайте саммари со списком следующих шагов, ответственных и сроков.
А чтобы повышать командный дух и развивать чувство привязанности, предложите сотрудникам приходить на стендап за 2–5 минут до начала и общаться в это время на любые темы. Обсуждать семью, детей, домашних животных, хобби и все что угодно.
Важно. Одна из частых ошибок при организации удаленной работы — попытка компенсировать отсутствие офиса бесконечными видеоконференциями. Но вместо мотивации это, наоборот, забирает у сотрудников много времени и снижает продуктивность.
Поэтому коммуникацию лучше разделять. Сложные вопросы, мозговые штурмы и принятие решение выносить на видеовстречи. А для передачи информации, обновлений статуса задач и не срочных вопросов использовать мессенджеры. Если команда работает в разных часовых поясах и собрать всех вместе никак не получается — использовать мессенджеры.

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

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

Как давать критику на удаленке

Давать критику дистанционно сложнее, чем лично. Сообщение в мессенджере может казаться более резким и грубым, а без невербальных сигналов сложно правильно интерпретировать тон и намерения.
Поэтому удаленных сотрудников нужно критиковать правильно:
  • Выбирать подходящий канал для общения. Для серьезной критики использовать видеосвязь. Это позволяет видеть реакцию собеседника и общаться в живом формате.
  • Начинать с контекста и цели беседы. Например: «Я хочу обсудить последнюю презентацию, потому что мне важно, чтобы проект был успешным. И я знаю, что вы можете сделать эту работу еще лучше».
  • Задавать вопросы и слушать. Давать сотруднику возможность объяснить свою точку зрения. Спрашивать, как в следующий раз избежать подобной проблемы.
  • Заканчивать на позитивной ноте с конкретным планом действий.

Как управлять конфликтами в удаленной команде

Конфликты в удаленных командах обычно делятся на несколько категорий.
  • Коммуникационные конфликты. Возникают из-за недостатка информации или неверного понимания сообщений. Например, когда краткое сообщение «Это нужно переделать» в чате воспринимается как резкая критика.
  • Процессные конфликты. Связаны с разногласиями в методах работы. Один сотрудник предпочитает детальное планирование, другой — гибкий подход.
  • Ценностные конфликты. Появляются из-за разницы в приоритетах. Например, для дизайнера важно качество и эстетика, а для продакт-менеджера — быстрый выпуск MVP.
Читайте также: «Как управлять конфликтами в команде»
А по влиянию на работу команды конфликты делятся на критичные и простые. Из-за критичных конфликтов останавливается работа над проектом, атмосфера в команде становится токсичной. В самом конфликте участвует много людей и это влияет на достижение бизнес-целей. Для их решения приходится подключать руководителя.
Простые конфликты обычно происходят в небольших группах по 2–3 человека. Они не сильно влияют на результат, обычно возникают из-за недопонимания и решаются без руководителя.
Каким бы ни был конфликт, его нужно решить: оценить риски и свести к минимуму угрозы для проекта. Возможно, перераспределить какие-то функции конфликтующих сотрудников. Когда проекту ничего не будет угрожать, можно решать проблему.
Для критичных конфликтов эффективен директивный подход. Руководитель должен быстро вмешаться, принять решение и провести индивидуальные встречи с каждой из сторон для прояснения ситуации. При этом важно после разрешения острой фазы организовать общую встречу, чтобы восстановить рабочие отношения.
В простых конфликтах руководителю лучше быть модератором. Организовать встречу, установить правила диалога и помочь сторонам найти компромисс самостоятельно.
Лучшее решение конфликта — его отсутствие. Чтобы снизить риск конфликтов в командах, можно использовать типирование.
Типирование — разделение сотрудников на группы по психотипам.
Одна из наиболее практичных типологий — DISC, которая делит людей на четыре основных типа:
  • доминирующий (D) — ориентированный на результат, прямолинейный;
  • влияющий (I) — общительный, оптимистичный, ориентированный на людей;
  • постоянный (S) — терпеливый, надежный, командный игрок;
  • добросовестный (C) — аналитичный, точный, ориентированный на качество.
Зная тип личности каждого сотрудника, вы можете:
  • Адаптировать стиль коммуникации (например, для “D” — кратко и по делу, для “I” — эмоционально и с общей картиной).
  • Правильно ставить задачи (для “C” важны детали и инструкции, для “D” — конечный результат и свобода действий).
  • Формировать сбалансированные команды для проектов.
  • Предвидеть потенциальные конфликты (например, между ориентированным на скорость “D” и перфекционистом “C”).
Помимо DISC можно использовать другие модели типирования личности. Например, типология Майерс-Бриггс (MBTI) предлагает 16 типов личности. Модель основана на том, как люди воспринимают мир и принимают решения. В отличие от DISC, эта модель лучше учитывает когнитивные особенности психики.
Также есть модель Большой Пятерки (Big Five), которая оценивает людей по шкалам экстраверсии, нейротизма, открытости опыту, сознательности и доброжелательности. Эта модель помогает определять паттерны поведения в долгосрочной перспективе и определять подходящие роли для человека.

Чек-лист: как правильно организовать удаленную работу сотрудников

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

Использовать результат-ориентированный подход

При управлении удаленными сотрудниками нужно фокусироваться на результатах, а не на процессе их достижения. В офисе руководитель видит, что сотрудник сидит за компьютером, но это не гарантирует продуктивность. На удаленке такая видимость отсутствует вовсе.
В результат-ориентированном подходе можно выделить 3 принципа:
1. Четкое определение ожидаемого результата. Сотрудник должен точно понимать, что от него требуется и как будет оцениваться его работа.
2. Понятные сроки. Без четких дедлайнов работа может растягиваться бесконечно.
3. Свобода выбора методов достижения цели. Если сотрудник хорошо делает работу и укладывается в сроки, не так важно, в каком порядке и в какое время он выполняет задачи.
Например, вместо требования «работать с 9 до 18» лучше сформулировать задачу: «к пятнице подготовить отчет по проекту Х с анализом трех ключевых метрик».
Как распределять время на удаленке

Создавать доверительные отношения между руководителем и командой

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

Использовать понятную систему целей и KPI

В распределенной команде важно, чтобы все понимали общие цели и свой вклад в их достижение.
Вот пример эффективной системы целей для удаленной команды:
1. Стратегические цели компании понятны всем сотрудникам. Каждый понимает, как его работа связана с общей миссией.
2. Командные цели на квартал/спринт. Цели поставлены по OKR (цели и ключевые результаты) или по SMART (конкретные, измеримые, достижимые, релевантные и ограниченные по времени).
3. Индивидуальные KPI, привязанные к командным целям. При этом важно не перегружать систему большим количеством метрик — 3–5 ключевых показателей обычно достаточно.
Например, для маркетолога это может быть количество квалифицированных лидов, для разработчика — количество закрытых задач с учетом их сложности, для поддержки — время ответа и удовлетворенность клиентов.

Поддерживать регулярную коммуникацию

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

Соблюдать баланс между контролем и автономией

Сильный контроль за удаленными командами убивает инициативу к работе. А слишком слабый контроль может привести к хаосу. Поэтому нужно искать баланс:
  • Определить зоны полной автономии, где сотрудник принимает решения самостоятельно (например, выбор технического решения для задачи).
  • Установить точки обязательной синхронизации (например, демонстрация прототипа клиенту).
  • Создать прозрачную систему отчетности, которая помогает всей команде быть в курсе прогресса.
  • Проводить регулярные встречи, где каждый может сигнализировать о проблемах и рисках.
Если хотите перевести команду на удаленку и не знаете, с чего начать, обратитесь за помощью в Neogenda. Просто запишитесь на бесплатную консультацию, и наши эксперты помогут составить план перехода для вашей компании.
]]> 12 ошибок фасилитатора: как зафакапить стратегическую сессию http://neogenda.ru/blog/eryp8b1s81-12-oshibok-fasilitatora-kak-zafakapit-st http://neogenda.ru/blog/eryp8b1s81-12-oshibok-fasilitatora-kak-zafakapit-st?amp=true Mon, 14 Apr 2025 13:10:00 +0300 Фасилитация – это искусство управления групповой динамикой, поиска решений и построения эффективных стратегий. Однако даже...

12 ошибок фасилитатора: как зафакапить стратегическую сессию

Фасилитация – это искусство управления групповой динамикой, поиска решений и построения эффективных стратегий. Однако даже опытные фасилитаторы могут допускать ошибки, которые сводят на нет все усилия. Сегодня я расскажем о 12 ошибках, которые гарантированно испортят любую сессию.

1. Отсутствие четкой цели и ожидаемого результата

Что это? Когда у заказчика уже есть готовое решение, но он собирает сессию, чтобы «группа сама к нему пришла».
Если решение уже принято, но фасилитация проводится для формального обсуждения, знайте: группа всегда придёт к своему выводу, который может отличаться от ожиданий заказчика. Итог — потеря доверия со стороны участников.
Что делать? Если решение уже есть, лучше обсуждать его напрямую, а не создавать искусственные ситуации поиска альтернатив.

2. Соглашаться на «фоссипуляцию»

Что это? Когда у заказчика уже есть готовое решение, но он собирает сессию, чтобы «группа сама к нему пришла».
Если заказчик уже принял решение, но хочет провести сессию для формального обсуждения, знайте: группа всегда придёт к своему выводу, и он может отличаться от ожиданий заказчика. Итог – потеря доверия со стороны участников.
Что делать? Если решение уже есть, лучше обсуждать его напрямую, а не создавать искусственные ситуации поиска альтернатив.

3. Отказ от сценария сессии

Заходить в сессию «в потоке» — это провал. Без структуры и плана фасилитатор проведет восемь часов в импровизации, а заказчик столкнется с несоответствием ожиданий и реальности.
Что делать? Разрабатывать сценарий в нескольких вариациях, согласовывать его с заказчиком и адаптировать при необходимости.

4. Копирование чужих сценариев

Каждая команда и каждый запрос уникальны. Использование стандартных сценариев без адаптации приводит к потере контекста и снижению эффективности встречи.
Что делать? Создавать сценарий под конкретный запрос и команду. Даже похожие запросы требуют индивидуального подхода.

5. Согласование сценария не с заказчиком

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

6. Игнорирование перерывов

Сессия без запланированных перерывов приводит к усталости, снижению вовлеченности и самовольным паузам участников.
Что делать? Закладывать полноценные перерывы (не менее 15 минут) и планировать работу так, чтобы оставался запас времени.

7. Отсутствие брифинга для участников

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

8. Отсутствие ключевых участников

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

9. Слепое следование сценарию

Жизнь всегда вносит коррективы, и если группа уходит в важное обсуждение, игнорировать это — значит потерять доверие участников.
Что делать? Гибко адаптировать сценарий, но не терять контроль над процессом.

10. Разрешать «наблюдателей» без роли

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

11. Игнорирование конфликтов

Конфликты на сессии неизбежны. Их игнорирование подрывает доверие к фасилитатору и снижает эффективность работы.
Что делать? Обозначать конфликт и предлагать группе способы его решения.

12. Нечеткие формулировки вопросов

Размытые вопросы вроде «Что нужно сделать, чтобы достичь цели?» дают столь же размытые ответы.
Что делать? Формулировать вопросы максимально конкретно, например: «Какие шаги нам нужно предпринять в следующем квартале, чтобы оптимизировать операционную деятельность на 20%?».

Бонус: 13-я ошибка — не разбирать ошибки после сессии

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

Вместо итога

Фасилитация — это живая история. Чем больше осознанности и гибкости, тем эффективнее проходит работа. Используйте эти советы, и ваши сессии будут продуктивными и результативными!
Если вы хотите вывести управление в вашей компании на новый уровень, специалисты Neogenda помогут в этом. Мы работаем с крупнейшими компаниями, такими как Tinkoff, Яндекс, Авито, Сбер и Билайн, и уже обучили более 5 000 сотрудников. Наши эксперты подберут для вас индивидуальные решения, основанные на реальном управленческом опыте и современных практиках.
Запишитесь на бесплатную консультацию в Zoom, чтобы найти способы сделать вашу команду ещё эффективнее.
]]> Что такое стратегическое планирование: этапы, виды и цели в менеджменте http://neogenda.ru/blog/08pbk1f0f1-chto-takoe-strategicheskoe-planirovanie http://neogenda.ru/blog/08pbk1f0f1-chto-takoe-strategicheskoe-planirovanie?amp=true Tue, 15 Apr 2025 13:12:00 +0300 Андрей Сидоренко Чтобы руководитель понимал, куда движется компания, и мог подготовиться к переменам, нужно спланировать стратегию развития....

Что такое стратегическое планирование: этапы, виды и цели в менеджменте

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

Что такое стратегическое планирование и зачем оно нужно

Стратегическое планирование — подход к управлению компанией, при котором менеджмент определяет долгосрочные цели и пути их достижения. Главная задача такого планирования — понять, куда движется бизнес и какие шаги нужно предпринять, чтобы занять сильную позицию на рынке.
В бизнесе существует три уровня планирования, и каждый из уровней важен по своему:
  • Операционное планирование — планирование на короткие промежутки времени: день, неделя, месяц. Здесь решаются вопросы по типу «какие задачи нужно выполнить в этом месяце».
  • Тактическое планирование привязано к производственному циклу компании. Например для розничного бизнеса это может быть сезон, для производства — квартал или полугодие. В общем, здесь планируют в среднесрочной перспективе.
  • Стратегическое планирование используют для горизонта в 3–10 лет. Стратегия определяет, куда движется компания, какое место на рынке хочет занять и какие ресурсы для этого потребуются.
Все три уровня взаимосвязаны между собой и дополняют друг друга: ежедневные дела соответствуют тактическим решениям, а те помогают достичь стратегических целей.

Зачем использовать стратегическое планирование

Стратегия определяет, сможет ли компания адаптироваться к изменениям на рынке, быть конкурентоспособной и стабильно расти. Вот еще несколько преимуществ планирования:
  1. Все в компании понимают, куда движется бизнес. Все решения последовательны и согласованы между собой.
  2. Проще определить, куда в первую очередь направить ресурсы — людей, деньги, время и т. д.
  3. Планирование заставляет регулярно анализировать рынок и компанию. Это помогает заранее увидеть новые возможности или угрозы.
  4. Команды и отделы работают по единому плану и понимают, зачем решают конкретную задачу в конкретный момент.

Когда нужно создавать стратегический план

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

Чем стратегический план отличается от других инструментов планирования

Стратегический план путают с разными документами: бизнес-планом, миссией компании и программой проекта.
Стратегический план и бизнес-план — разные документы. Главное отличие — в горизонте планирования. Стратегический план охватывает долгосрочную перспективу (обычно от 3 до 10 лет), а бизнес-план рассчитан на 1–3 года.
Второе важное различие — глубина детализации. Стратегический план обозначает общие направления, по которым компания будет двигаться. Бизнес-план подробно описывает конкретные показатели, цифры, KPI, финансовые расчеты, календарные графики, бюджет и шаги по выполнению краткосрочных задач.
Кроме того, бизнес-план часто создается для внешних стейкхолдеров — инвесторов, банков, партнеров, а стратегический план — это внутренний документ, предназначенный в первую очередь для руководства компании.
Стратегический план также тесно связан с миссией и концепцией организации. Миссия компании — это своего рода философская основа бизнеса. Миссия отвечает на вопрос: «зачем существует компания?» Концепция — это видение будущего организации, ее идеальный образ.
Стратегический план показывает, как именно организация будет реализовывать миссию и как будет выглядеть в будущем. Планирование переводит абстрактные идеи в конкретные цели, задачи и действия. Проще говоря, миссия и концепция определяет, к чему стремится компания, а стратегическое планирование — как этого достичь.
Стратегическое планирование и программа проекта — тоже разные документы. Программа проекта обычно охватывает конкретный проект с ограниченным сроком и ресурсами, а стратегический план охватывает всю компанию целиком.

Как провести стратегическое планирование

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

Проанализировать компанию

Для стратегического планирования пригодится разная информация.
Внутренняя отчетность — финансовые показатели, операционные метрики, данные о клиентах и продажах.
Исследование рынка — опросы клиентов, анализ конкурентов, изучение трендов. Можно проводить собственными силами или заказывать у агентств.
Экспертные интервью — беседы с ключевыми клиентами, партнерами, экспертами, которые помогут лучше понять рынок.
Стратегические сессии — групповые обсуждения с командой для брейншторминга.
Бенчмаркинг — сравнение показателей компании с конкурентами в отрасли.
При планировании первым делом нужно провести внутренний аудит и понять, в каком положении находится компания. Для этого нужно изучить:
  • Финансовые показатели: рентабельность, денежные потоки, структуру расходов, динамику выручки.
  • Эффективность компании: сравнить производительность с конкурентами, найти слабые места в процессах и лишние процессы, оценить используемые технологии.
  • Человеческие ресурсы: оценить компетенцию команды, текучесть кадров, вовлеченность сотрудников.
Затем нужно проанализировать рынок и конкурентов. Анализировать нужно разные сферы:
  • Размер и динамика рынка: растет он или сокращается, какие сегменты развиваются быстрее, каковы прогнозы на ближайшие годы.
  • Конкуренты: кто основные конкуренты, их сильные и слабые стороны, стратегии, рыночные доли.
  • Клиенты: какие у них предпочтения, болевые точки, потребности, сегменты покупателей.
  • Внешние факторы: изменения в законодательстве, экономическая ситуация, социальные тенденции.
Чтобы анализировать информацию было проще, обычно используют несколько инструментов: SWOT-анализ, PEST, метод 5 сил Портера, матрица BCG.
SWOT-анализ помогает взглянуть на компанию с 4 сторон: сильные и слабые стороны, возможности и угрозы. Примеры возможных вопросов собрали в таблице:
Что анализируем Какие вопросы задаем
Сильные стороны Что компания делает лучше других
Какие уникальные продукты или технологии есть у компании
Слабые стороны Какие продукты или услуги компании показывают низкие результаты
Насколько эффективно используются маркетинговые каналы
В чем бизнес уступает конкурентам
Возможности Какие технологии могут стать преимуществом для компании
Какие сегменты рынка компания еще не охватила
Как можно расширить географию продаж
С кем можно заключить партнерство
Угрозы Какие действия конкурентов могут негативно повлиять на бизнес
Как рыночные изменения могут повлиять на компанию
Какие политические или законодательные изменения могут негативно отразиться на бизнесе
Ответы на эти вопросы помогут понять, на чем стоит сосредоточиться и как минимизировать риски. Подробнее о SWOT-анализе читайте в статье «Что такое SWOT-анализ и как его провести».
PEST-анализ — инструмент для анализа макросреды, который учитывает политические (P), экономические (E), социальные (S) и технологические (T) факторы. Анализ помогает выявить глобальные тренды, которые могут повлиять на бизнес.
5 сил Портера — модель для анализа конкурентной среды. Чтобы использовать этот инструмент, нужно проанализировать пять ключевых факторов:
  • конкуренция внутри отрасли;
  • сила поставщиков;
  • сила покупателей;
  • угроза появления новых игроков;
  • угроза появления товаров-заменителей.
Например, если в вашей отрасли высокая конкуренция, нужно усилить маркетинг и улучшить продукт, чтобы оставаться на плаву.
Матрица BCG. Помогает понять, какие продукты нужны компании, а какие — нет. Матрица BCG делит продукты на четыре группы:
  • звезды;
  • дойные коровы;
  • вопросительные знаки;
  • собаки.
Чтобы работать с этим инструментом, нужно оценить каждый продукт по двум критериям: его доля на рынке и темпы роста.
Например, «звезды» — это товары с высокой долей на рынке. Их нужно поддерживать и развивать. «Дойные коровы» приносят стабильную прибыль, но рынок для них уже не растет. Их задача — поддерживать текущий уровень дохода.
«Вопросительные знаки» — продукты с потенциалом, но им не хватает рыночной доли. Нужно решить, стоит ли инвестировать в их развитие. А «собаки» — это продукты, которые почти не приносят прибыли. Их стоит либо закрыть, либо значительно переработать.
Например при разработке стратегии развития сети кофеен SWOT-анализ может выявить угрозу со стороны новых форматов доставки кофе. А 5 сил Портера — показать, что основная конкуренция происходит не между кофейнями, а между всеми заведениями и сервисами в районе, которые предлагают напитки и перекусы в течение дня.

Определить или пересмотреть миссию компании

Миссия отвечает на вопрос «зачем мы существуем?», а видение описывает, куда вы хотите прийти в долгосрочной перспективе. Хорошая миссия:
  • отражает суть бизнеса;
  • вдохновляет сотрудников;
  • понятна клиентам;
  • не привязана к конкретным продуктам (они могут меняться).
Например миссия компании Starbucks звучит так: «воодушевлять и стимулировать – один человек, одна чашка, одна община». Миссия отражает основную цель компании — не просто продавать кофе, а создавать атмосферу, в которой люди могут наслаждаться общением и отдыхом.

Сформулировать и записать бизнес-стратегию

В бизнес-стратегию обычно включают несколько элементов:
  • Стратегическое видение и миссия — куда компания стремится в долгосрочной перспективе.
  • Стратегические цели — конкретные, измеримые результаты, которых компания хочет достичь.
  • Стратегические направления — основные пути достижения целей (например, выход на новые рынки, развитие новых продуктов, оптимизация процессов).
  • Конкурентное преимущество — что именно делает компанию уникальной и ценной для клиентов.
  • Ключевые инициативы — конкретные проекты и программы, которые будут реализованы для воплощения стратегии.
Итоговый документ должен получиться достаточно конкретным, кратким – чтобы его можно было легко понять и запомнить, и понятным для всех.
Например стратегический документ производственной компании может включать страницу с ключевыми показателями и целями на 3 года, 3–5 страниц с описанием стратегических направлений и конкурентных преимуществ и приложение с детальными планами по отдельным инициативам.

Поставить стратегические цели

Стратегические цели — это конкретные результаты, которые компания планирует достичь в течение следующих лет и реализовать свое видение.
Стратегические цели лучше ставить по методике SMART. Это значит, что цель должна быть:
  • Конкретной (Specific). Например, «Увеличить долю рынка в сегменте премиум-класса с 8% до 15%».
  • Измеримой (Measurable). Цель должна быть такой, чтобы компания могла отслеживать прогресс с помощью конкретных метрик.
  • Достижимой (Achievable). Цель должна быть амбициозной, но реалистичной.
  • Релевантной (Relevant). Цель должна поддерживать миссию и видение компании.
  • Ограниченная по времени (Time-bound). Цель должна иметь четкие сроки достижения.

Разработать стратегию для достижения целей

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

Создать тактические планы и операционные задачи

Готовую стратегию нужно превратить в конкретные планы действий. Тактические планы — это среднесрочные планы (обычно на 1–2 года), а операционные задачи — это ежедневная деятельность.
На этом этапе нужно распределить ответственность. Определить, какие проекты или программы нужно запустить, чтобы достичь стратегических целей.
Затем установить промежуточные цели, KPI и распределить ресурсы. Определить, сколько людей, времени и денег нужно выделить на каждую инициативу.
Например, если по стратегии нужно выйти в соседние регионы, тактический план может содержать такие пункты: «Открыть точку в городе N к маю 2025 года», «Нанять команду из 5 человек к сентябрю 2025 года».
После этого можно внедрять стратегию в компанию и реализовывать ее.

Корректировать стратегию по ходу

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

Кто должен участвовать в стратегическом планировании

В разработке стратегии должны участвовать люди, ответственные за разные направления бизнеса. Обычно это топ-менеджмент, руководители подразделений и ключевые сотрудники, которые знают реальную ситуацию в компании и на рынке.
Например при разработке стратегии IT-стартапа обычно участвуют CEO, CTO, руководители продуктового, маркетингового и финансового направлений, а также 1–2 ключевых разработчика и продакт-менеджера.

Типичные ошибки в стратегическом планировании

Ошибки при планировании снижают эффективность работы и мешают достигать поставленных целей. Рассмотрим ошибки подробнее и обсудим конкретные методы, которые помогут избежать этих проблем:

Слишком абстрактные формулировки

Одна из самых распространенных проблем — размытые формулировки, которые каждый может трактовать по-своему.
Вот примеры слишком абстрактных целей:
  • «Стать лидером рынка».
  • «Повысить качество обслуживания».
  • «Увеличить эффективность процессов».
  • «Развить инновационную культуру».
Такие формулировки не дают понимания, что конкретно нужно делать и как измерить успех. Чтобы избежать этой ошибки, нужно ставить цели по SMART и добавлять в цель конкретные показатели.
Например «Увеличить долю рынка в сегменте В2В с 15% до 25% за 3 года».

Отсутствует связь между стратегией и операционной деятельностью

Бывает, что стратегия живет своей жизнью в красивой презентации, а сотрудники продолжают работать по-старому. И не понимают, как их действия связаны с долгосрочными целями организации.
Чтобы избежать такой ошибки, разработайте «каскад целей» — процесс, при котором стратегические цели компании трансформируются в цели подразделений, команд и отдельных сотрудников.
Также разработайте систему KPI и включите в нее показатели, связанные с реализацией стратегии. Например, если стратегия предполагает улучшение клиентского опыта, у сотрудников службы поддержки должны быть KPI, связанные с удовлетворенностью клиентов.

Жесткий подход к планированию

Жесткий подход к стратегическому планированию не дает адаптироваться к изменениям рынка, технологий или предпочтений клиентов. Признаки жесткого подхода:
  • пересмотр стратегии раз в несколько лет;
  • изменения в планах воспринимаются как неудача;
  • для корректировки стратегии нужно заполнять сотни бумажек и согласовывать с разными отделами.
Чтобы сделать стратегическое планирование более гибким, регулярно пересматривайте стратегию (например, ежеквартально или два раза в год), чтобы реагировать на изменения на рынке. А также внедрите принципы agile-подхода — работайте короткими циклами, быстро тестируйте гипотезы и адаптируйтесь.
Еще один вариант — используйте сценарное планирование. Для этого разработайте несколько версий стратегии для разных сценариев развития рынка.

Разрыв между стратегией и потребностями рынка

Иногда компании разрабатывают стратегию, исходя из внутренних соображений или амбиций руководства. И не учитывают предпочтений клиентов или действий конкурентов.
Чтобы стратегия всегда была связана с рынком, нужно соблюдать несколько правил:
  • Начинать разработку стратегии с анализа потребностей клиентов и трендов рынка.
  • Регулярно собирать обратную связь от клиентов и отталкиваться от нее при планировании.
  • Оперативно реагировать на изменения в поведении конкурентов или потребителей.
Если вы хотите провести стратегическое планирование и улучшить организационные процессы в вашем бизнесе, обратитесь в Neogenda. Наши решения уже помогли таким компаниям как Сбер, Яндекс, X5 Group и Тинькофф. Запишитесь на бесплатную консультацию, чтобы найти структуру для своего успеха.
]]> Самоорганизация vs Самоуправление: Разбираемся в терминах http://neogenda.ru/blog/edndtf98f1-samoorganizatsiya-vs-samoupravlenie-razb http://neogenda.ru/blog/edndtf98f1-samoorganizatsiya-vs-samoupravlenie-razb?amp=true Wed, 16 Apr 2025 13:45:00 +0300 Артур Нек Сегодня мы поговорим о том, чем отличаются такие понятия, как самоорганизация, самоуправление и бирюзовые организации....

Самоорганизация vs Самоуправление: Разбираемся в терминах

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

Что такое самоорганизация и самоуправление?

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

Вовлечение персонала в самоорганизацию

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

Бизнес-преимущества самоорганизации

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

Есть ли бирюзовые компании в России?

Полностью бирюзовых организаций, в классическом понимании Лалу, нет. Однако в России есть компании с высоким уровнем самоуправления, например, Oil Energy. Их основатель осознал, что рост компании невозможен при классической модели управления, и внедрил элементы самоуправления, такие как холакратия и социократия.

Как внедрять самоорганизацию?

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

Разница между самоорганизацией и анархией

Самоорганизация — это не хаос, а структурированный процесс с четкими договоренностями. Анархия — это отсутствие управления. В самоорганизации же управление распределено.

Как доверять людям, если они совершают ошибки?

Чтобы доверие появилось, нужно:
  • Делегировать полномочия постепенно.
  • Начать с небольшой группы проверенных сотрудников.
  • Развивать культуру обратной связи и обучения.

Как решать конфликты в самоорганизованных командах?

Конфликты часто возникают из-за:
  • Разных трактовок понятий — решается уточнением формулировок.
  • Разного опыта — решается обменом знаниями или экспериментами.
  • Разных целей — решается привязкой к общей эволюционной цели компании.

Куда девать начальников?

Лидеры остаются, но их роль меняется. Они становятся наставниками, помогая сотрудникам принимать решения и развиваться.

Управление и бирюзовые компании: миф или реальность?

В последнее время модными стали концепции спиральной динамики и уровней организаций по Фредерику Лалу. Однако важно понимать, что сам создатель спиральной динамики Клэр Грейвс предостерегал от использования этой теории для организаций — она была разработана исключительно для анализа людей. Вместо того чтобы «красить» компанию в бирюзовые тона, лучше решать конкретные проблемы. Если ваша организация эффективна и работает по принципам бирюзового управления, окружающие сами это заметят, без необходимости вводить модные термины.

Холократия, социократия или клиентократия? Что работает лучше?

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

Экскурсии на предприятия: инсайты или маркетинг?

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

Бирюзовое управление: заслуга системы или удачи?

Скептики считают, что успех таких компаний, как «ВкусВилл», — это не результат системы, а просто удачная ниша. Однако многие пытались повторить их путь, но не смогли. Главное отличие — в подходе к управлению. Например, «ВкусВилл» прошел несколько ключевых этапов эволюции:
  • Рост до 12 человек — работает интуитивное управление.
  • До 150 человек — необходимо внедрение новых корпоративных процессов.
  • Свыше 150 человек — важна радикальная трансформация, отказ от жестких иерархий.
  • От 1700 человек и выше — бирюзовые практики (Лалу) плюс собственные решения.
  • Более 20 000 сотрудников — разработка уникальной системы управления (в случае «ВкусВилла» — клиентократия).

Как контролировать качество при масштабировании?

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

Ценности компании: как сделать так, чтобы они работали?

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

Будущее самоуправляемых организаций

Можно ли ожидать появления новых уровней управления, превосходящих бирюзовый? Скорее всего, да. Сегодня главная задача — внедрить существующие принципы в массовую практику. А дальше компании будут эволюционировать, создавая еще более адаптивные модели управления.
]]> Зачем нужен сервис-деск: инструмент техподдержки и повышения качества сервиса http://neogenda.ru/blog/yns4jyftf1-zachem-nuzhen-servis-desk-instrument-teh http://neogenda.ru/blog/yns4jyftf1-zachem-nuzhen-servis-desk-instrument-teh?amp=true Thu, 17 Apr 2025 13:59:00 +0300 В бизнесе скорость и качество обслуживания играют решающую роль. Если поддержка отвечает медленно, компания теряет...

Зачем нужен сервис-деск: инструмент техподдержки и повышения качества сервиса

В бизнесе скорость и качество обслуживания играют решающую роль. Если поддержка отвечает медленно, компания теряет заказы и доверие, а конкуренты получают новых клиентов. Сервис-деск (service desk) помогает автоматизировать работу с обращениями. А еще — ускорять и контролировать процессы.
Service desk системы повышают эффективность работы сотрудников, улучшают общение и связь с клиентами и позволяют выявлять слабые места в обслуживании. В статье расскажем, какие задачи решает такое ПО, с помощью каких функций, как помогает бизнесу и на что обратить внимание при выборе системы.

Что такое service desk и зачем это нужно

Service desk — централизованная система для управления запросами пользователей и клиентов, которую используют для:
  • приема обращений через разные каналы связи (телефон, email, телеграм-бот);
  • автоматизации обработки заявок;
  • организации базы знаний, где сотрудники и клиенты могут находить ответы на частые вопросы;
  • контроля соблюдения сроков по SLA;
  • мониторинга эффективности работы сотрудников.
Часто service desk, который могут называть support desk, путают с CRM и help desk, но между ними есть принципиальные различия:
  • CRM (система управления взаимоотношениями с клиентами) — в первую очередь предназначена для работы отдела продаж, хранения персональных данных покупателей, анализа их активности и взаимодействий. Помогает общаться с клиентами, отслеживать сделки и автоматизировать маркетинг.
  • Help desk — это упрощенный вариант сервис-деска, который в основном фокусируется на приеме и обработке заявок. В нем обычно нет расширенных функций аналитики, базы знаний или автоматического распределения задач.
  • В IT service desk объединяет в себе функции help desk, но при этом обладает более широкими возможностями для управления ИТ-инфраструктурой, процессами поддержки и внутренних сервисов компании.
С помощью сервис-деска компании могут использовать инструмент, который собирает все обращения от пользователей в единую программу заявок, автоматически распределяет их между специалистами, отслеживает выполнение и информирует клиентов о статусе их заявки.

Какие основные задачи выполняет сервис-деск

Service desk — комплексное решение, которое помогает бизнесу оптимизировать работу с клиентами, а также сотрудниками. Его ключевые задачи:

Автоматизация процессов

Сервис-деск позволяет сократить ручной труд и устранить хаос в обработке обращений.
Пример работы:

1. Клиенты и сотрудники могут оставлять заявку через удобный канал связи.
2. Система учета заявок фиксирует запрос, автоматически назначает исполнителя и определяет приоритет.
3. Сотрудник службы поддержки пользователей получает уведомление и начинает обработку.
4. Если проблема стандартная, может помочь база знаний.
5. После решения проблемы система фиксирует результат, и это помогает находить слабые места и улучшать процессы.

Быстрая реакция на запросы

Скорость обработки обращений напрямую влияет на удовлетворенность аудитории. Если запросы игнорируют, долго рассматривают или оставляют без ответа, бизнес рискует потерять доверие людей.
Сервис-деск помогает:
  • оперативно распределять заявки между специалистами;
  • отслеживать, на каком этапе находится обращение;
  • автоматически уведомлять клиента о статусе его заявки;
  • использовать SLA (соглашения об уровне сервиса) для контроля времени реакции и решения проблемы клиента.
Благодаря этим механизмам работа службы поддержки пользователей позволяет давать быстрый ответ и избегать задержек.

Улучшение качества обслуживания

Правильная поддержка клиентов — это не только скорость, но и удобство. Service desk делает взаимодействие с аудиторией прозрачным и понятным:
  • клиент видит заявку в системе и понимает, кто ее обрабатывает и на каком она этапе;
  • база знаний помогает решать типовые вопросы без участия операторов;
  • система аналитики позволяет оценивать, как работает служба поддержки клиентов, находить слабые места и улучшать процессы.
Благодаря этим возможностям компании могут решать проблемы клиентов быстрее и эффективнее, чтобы повышать их лояльность.

Какие функции предлагает сервис-деск

Разберем ключевые функции, которые делают работу службы поддержки более эффективной:

Программа заявок

Одна из базовых функций сервис-деска — централизованная программа заявок, которая фиксирует все обращения клиентов и упрощает их обработку. При этом система учета заявок регистрирует запрос, присваивает ему номер, отмечает время обращения и детали проблемы. Если обращение требует сложного решения, клиент может прикрепить вложения (скриншоты, файлы). К тому же он видит заявку и ее статус в личном кабинете.
Пример заявки в модуль Service desk от Kaiten

База знаний и система управления знаниями

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

Автоматическое распределение заявок

Когда в поддержку поступает много обращений, важно правильно их распределять. В service desk это происходит автоматически по заданным алгоритмам.
Заявки назначаются:
  • по загруженности сотрудников — чтобы не было перекосов;
  • по компетенциям, например, технические вопросы — инженерам, финансовые — бухгалтерии;
  • по приоритету — критичные запросы сразу отправляются в работу.
Это значительно ускоряет обработку заявок и делает поддержку клиентов эффективнее.

Контроль сроков по SLA и уведомления

SLA (Service Level Agreement) — соглашение об уровне сервиса, которое определяет, за какое время должны обработать заявку. Чтобы его соблюдать, сервис-деск:
  • автоматически назначает приоритет заявке;
  • отслеживает сроки и отправляет напоминания;
  • уведомляет ответственных сотрудников, если время на исходе.
Благодаря этому компания поддерживает высокий уровень сервиса и соблюдает обязательства перед клиентами.

Каналы связи: email, чат-боты, телеграм-бот

Клиенты ожидают, что смогут связаться с поддержкой любым удобным способом. Service desk позволяет объединить все каналы в единую систему:
  • email — классический способ подачи заявки;
  • чат-боты — отвечают на частые вопросы и помогают автоматически создавать заявки;
  • телеграм-бот — удобный инструмент для оперативного общения;
  • портал самообслуживания — клиент может оставить заявку и сразу найти ответ в базе знаний.
Чем больше каналов поддерживает система, тем проще клиенту общаться с поддержкой и получить быстрый ответ.

Как сервис-деск помогает отделу продаж

Грамотная работа с клиентскими запросами — это еще и возможность для роста продаж. Service desk помогает менеджерам лучше понимать потребности клиентов и выстраивать более персонализированное взаимодействие.
Вот какие возможности открывает сервис-деск для отдела продаж:
  • Передача информации о клиентах — менеджеры видят историю запросов, и это помогает учитывать потребности клиента.
  • Выявление частых проблем — если клиенты регулярно спрашивают об одной и той же функции или услуге, это сигнал о том, что ее нужно лучше объяснять в маркетинговых материалах.
  • Автоматизация работы — заявки с запросами на консультации или коммерческие предложения могут автоматически отправляться в отдел продаж.

Как находить слабые места в работе службы поддержки

Чтобы улучшать клиентский сервис, нужно понимать, какие проблемы существуют в работе поддержки. Вот что можно анализировать с помощью сервис-деска:
  • Скорость обработки заявок — если заявки обрабатываются дольше, чем указано в SLA, это сигнал о том, что не хватает ресурсов или есть проблемы в процессе.
  • Часто повторяющиеся обращения — если клиенты задают одни и те же вопросы, возможно, нужно доработать продукт или улучшить базу знаний.
  • Загруженность сотрудников — аналитика показывает, какие сотрудники перегружены, а какие обрабатывают меньше запросов.
  • Популярность каналов связи — можно определить, откуда поступает больше всего заявок (email, чат-боты, телефон) и перераспределить ресурсы.
Чтобы с помощью этих данных улучшать работу поддержки:
  • оптимизируйте процессы, если заявки «зависают» или требуют слишком много времени на обработку;
  • расширьте базу знаний, чтобы клиенты могли находить ответы без обращения в поддержку;
  • увеличьте штат или перераспределите нагрузку, если сервис-деск показывает, что сотрудники не справляются с потоком заявок.

Как выбрать сервис-деск

Чтобы подобрать решение, которое будет наилучшим образом отвечать потребностям вашего бизнеса, стоит учитывать ряд параметров.
1. Варианты поставки
Сначала нужно определиться с типом поставки:
  • Облачные решения позволяют работать через интернет без необходимости устанавливать систему на локальных серверах. Эти решения обычно проще в настройке и эксплуатации, так как обслуживаются сторонним поставщиком. Облачные сервисы подходят компаниям, которым важна мобильность и экономия на инфраструктуре.
  • Локальные решения требуют установки системы на собственные серверы компании. Этот вариант подходит для бизнеса, который хочет полностью контролировать инфраструктуру и данные.
2. Гибкая настройка и простота подключения
Удобная система должна легко адаптироваться под конкретные потребности. Что можно настраивать:
  • приоритеты и категории заявок;
  • автоматические сценарии обработки;
  • интеграции с другими сервисами (CRM, ERP, телефония);
  • каналы связи;
  • отчетность и аналитику;
  • интерфейс портала самообслуживания.
Интеграция с телефонией в системе Okdesk
Важно, чтобы система была проста в подключении — без сложной установки и длительного обучения сотрудников. Чем быстрее ее можно внедрить, тем раньше компания начнет получать пользу.
Чем больше возможностей для настройки, тем легче будет адаптировать систему под ваши требования.
3. Стоимость решения
У разных решений могут быть разные модели ценообразования:
  • Подписка на облачные сервисы — чаще всего компании платят за количество пользователей или за объем заявок, что позволяет гибко управлять затратами.
  • Разовые расходы на локальные решения — такие системы требуют значительных первоначальных затрат на покупку лицензий, серверное оборудование и техническую поддержку.
  • Важно заранее оценить, какой бюджет вы готовы выделить на внедрение и обслуживание системы, а еще учитывать возможные скрытые расходы на обучение сотрудников и техническую поддержку.
4. Масштабируемость
Если бизнес растет, то система должна быть способна адаптироваться к увеличению объема заявок и пользователей. Важно выбрать решение, которое можно масштабировать без значительных усилий, поэтому желательно, чтобы можно было:
  • добавлять новых пользователей;
  • увеличивать объемы данных и запросов;
  • просто настраивать новые рабочие процессы и автоматизации по мере роста компании.
5. Безопасность персональных данных
Безопасность данных — значимый критерий, особенно для компаний, которые работают с персональными данными клиентов. Обратите внимание на следующие моменты:
  • Шифрование данных — наличие шифрования для защиты данных при их передаче и хранении.
  • Соответствие стандартам безопасности — система должна соответствовать стандартам защиты информации, например российским законам о защите данных.
  • Контроль доступа — возможность настройки прав доступа для сотрудников, чтобы ограничить доступ к чувствительным данным.
6. Уровень поддержки и обучение
Когда систему настроили и используют, важно, чтобы были доступны:
  • Техническая поддержка — наличие круглосуточной поддержки, возможность быстрого реагирования на инциденты и решение возникающих проблем.
  • Обучение и документация — обучающие материалы, вебинары и материалы для пользователей, чтобы ускорить освоение системы и ее эффективное использование.
7. Отзывы
Перед окончательным выбором системы полезно почитать отзывы других пользователей. Это поможет сориентироваться, насколько она соответствует заявленным возможностям и какие подводные камни могут возникнуть в процессе работы.
Ищите информацию на форумах, в социальных сетях и на сайтах с отзывами, чтобы узнать мнение других людей о надежности, удобстве и функциональности системы.

Примеры популярных систем service desk

Существует множество сервис-деск решений, каждое из которых имеет свои особенности и подходит для различных типов бизнеса. Вот несколько из них:
Jira Service Management — мощная система от Atlassian, которая активно использовалась для IT-поддержки и управления заявками. Но в 2022 году Jira ушла с российского рынка, и доступ к системе для пользователей из РФ ограничен. Несмотря на это, она остается популярной в других странах, особенно среди тех, кто уже использует продукты Atlassian.
Zendesk — одна из самых популярных платформ для поддержки клиентов, которая предоставляет все необходимые функции для работы с заявками через различные каналы (email, чат, соцсети и др.). Zendesk предлагает гибкие решения для бизнеса и продолжает активно работать в России и на международном рынке.
Freshdesk — облачная система, которая ориентирована на малые и средние предприятия. Предлагает удобные инструменты для автоматизации процессов и аналитики. Freshdesk остается доступной в России, ее активно используют компании, чтобы улучшать качество обслуживания.
Usedesk — российская система, популярная среди отечественных пользователей. Предлагает гибкие настройки, удобный интерфейс, возможности для внедрения других бизнес-инструментов. Это локальное решение подходит для организаций, которым важно работать в рамках российского законодательства.
Okdesk — российская система для технической поддержки. Ее активно используют малые и средние предприятия. Предлагает удобный интерфейс и возможности для автоматизации, а также хорошую поддержку на русском языке.

Что в итоге

Сервис-деск — эффективный инструмент, который помогает усовершенствовать работу службы поддержки, быстрее обрабатывать заявки и повысить качество обслуживания клиентов. Выбор подходящей системы может значительно упростить процессы в фирме, сделать их гораздо прозрачнее и продуктивнее.
Если хотите внедрить сервис-деск и управленческие практики в ваш бизнес, чтобы поднять уровень производительности команды, поможет Neogenda. Мы уже сотрудничали с такими крупными компаниями, как Tinkoff, Яндекс, Авито, Сбер, обучили более пяти тысяч сотрудников. Оставьте заявку на бесплатную консультацию через Zoom — наши эксперты подберут решение, которое поможет вашему бизнесу расти и развиваться.
]]> Инженерные практики и их влияние на бизнес http://neogenda.ru/blog/ogblz23ub1-inzhenernie-praktiki-i-ih-vliyanie-na-bi http://neogenda.ru/blog/ogblz23ub1-inzhenernie-praktiki-i-ih-vliyanie-na-bi?amp=true Fri, 18 Apr 2025 14:36:00 +0300 В современном мире разработки программного обеспечения существует миф о противостоянии между техническим совершенством решений и...

Инженерные практики и их влияние на бизнес

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

Качество как способ достижения бизнес-ценности

Часто приходится слышать вопрос: «Что важнее – качество или скорость?». В реальности эти два фактора взаимосвязаны. Экстремальное программирование (XP) пропагандирует принципы, согласно которым простота и отказ от избыточной сложности позволяют быстрее получать обратную связь, оперативно вносить изменения и поддерживать высокое качество продукта. Инженерные практики помогают создать систему, которая легко адаптируется к изменениям, минимизируя технический долг и повышая скорость доставки нового функционала.

Что инженерные практики дают бизнесу?

Инженерные практики обеспечивают:
  • Гибкость и адаптивность – быстрый отклик на изменения рынка и потребностей пользователей.
  • Минимизацию затрат на поддержку – качественный код проще тестировать, изменять и расширять.
  • Снижение числа багов – автоматизированные тесты, рефакторинг и парное программирование уменьшают вероятность критических ошибок.
  • Устойчивость к изменениям состава команды – благодаря принципам коллективного владения кодом и автоматизированного тестирования.

Zero Bug Policy: Как справиться с багами?

Одна из ключевых инженерных практик – Zero Bug Policy, подход, при котором накопленные ошибки в бэклоге не хранятся годами, а либо устраняются немедленно, либо закрываются как неактуальные. Самое сложное в этом процессе – убедить команду отказаться от накопленного списка багов, но статистика показывает: если ошибка остается нерешенной более трёх месяцев, скорее всего, она так и останется нерешенной. Подход Zero Bug Policy позволяет сосредоточиться на текущих проблемах и поддерживать высокое качество продукта.

Как внедрять инженерные практики?

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

Парное программирование и его преимущества

Парное программирование часто вызывает сопротивление как у инженеров, так и у менеджеров. Однако исследования показывают, что:
  • Несмотря на снижение объема написанного кода (примерно на 30%), его качество значительно выше.
  • В коде меньше багов, а архитектурные решения принимаются осознаннее.
  • Новые сотрудники быстрее встраиваются в команду.
Менеджмент часто опасается, что парное программирование снижает производительность, но в долгосрочной перспективе оно снижает затраты на исправление багов и технический долг, что приносит бизнесу реальную выгоду.
На какие процессные метрики влияют различные инженерные практики? Мы уже немного говорили про пропускную способность, а что насчет времени производства?
Возьмем, например, парное программирование в комбинации с Test-Driven Development (TDD). Это означает, что ты большую задачу разбиваешь на серию очень небольших шагов, каждый из которых завершается за 10-15 минут. Причем сразу же получаешь код-ревью, то есть твой код достигает production-ready качества. Конечно, задача еще не выполнена за 10 минут, но первый шаг сделан, первая строчка работающего кода написана. Причем не просто кода, а кода, покрытого тестами. И эта часть уже может быть интегрирована, разработчики могут давать фидбек, рефакторить. Таким образом, lead time для этого фрагмента кода сокращается до минимума.
Представь, что ты идешь к цели по ступенькам. Они маленькие, но каждая приближает тебя к конечному результату. Такой подход повышает вероятность успеха, в отличие от стратегии «одной большой ставки», когда ты надеешься попасть в цель с первого раза, но в случае ошибки придется все переделывать. Это увеличивает lead time в разы.
Также стоит учитывать, что одна и та же функциональность, реализуемая на разных этапах жизни продукта, может иметь разный lead time из-за накопления технического долга. Если ты применяешь парное программирование и Test-Driven Development, ты выравниваешь этот показатель. Постоянный рефакторинг и упрощение кода позволяют поддерживать его в состоянии, в котором его всегда легко понять и изменить. Это делает lead time предсказуемым, что само по себе уже является большим преимуществом.
Кроме того, работая в паре, ты сокращаешь WIP-лимит, что также способствует уменьшению lead time. Автоматизация тоже играет роль: вместо двух недель регресса тесты прогоняются за три дня. А если добавить современные практики, такие как continuous delivery, lead time сокращается до минимума – код пушится, тут же попадает в pipeline, проходит тесты и уходит в продакшн.
Сoding mother..cker
Есть такой подход – «coding mother..cker», его сторонники говорят: «Не важно, что мы делаем, главное – кодить». Является ли это разумным подходом? Возможно, в каких-то контекстах, например, на хакатоне. Если цель – быстро накидать работающий прототип, почему бы и нет? Но в долгосрочной перспективе такой метод неустойчив. Даже в условиях хакатона полезно работать в паре или в мобе – больше идей, выше качество.

Универсальные специалисты

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

Make it work, make it pretty, make it fast

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

Как стать скрам-мастером, которого не ненавидят разработчики?

Если скрам-мастер приносит пользу – его не ненавидят. Главное – не просто цитировать Scrum Guide, а понимать, какие проблемы есть у команды и как их решать. Хороший скрам-мастер помогает, а не заставляет следовать догмам. Он должен слушать команду, учитывать, что уже пробовали, и предлагать идеи, которые действительно могут помочь.

Пропаганда инженерных практик без их знания

Можно ли продвигать инженерные практики, не зная их на практике? Теоретически да, но сложно. Однако базовое понимание терминов и принципов уже дает возможность разговаривать с разработчиками на их языке. Например, один из эффективных подходов – обучение инженеров и менеджеров основам инженерных практик через простые аналогии (например, объяснение работы Git через написание книги).

Инженерная практика, без которой нельзя обойтись в современной разработке

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

30% времени на технический долг

Техническим долгом нужно управлять так же, как бизнес-требованиями. Если проблема критична и без ее решения система не выдержит рост нагрузки, ее нужно решать. Фиксированное выделение 30% времени на технологический долг – это попытка искусственно упростить процесс. Гораздо важнее уметь обосновывать необходимость таких работ бизнесу.
Один из подходов – выделение отдельной команды, сфокусированной на поддержке продукта. Они занимаются исправлением багов, мелкими бизнес-доработками и устранением технологического долга, управляя этим процессом через Канбан-лейны.

100% покрытие тестами при TDD – миф или реальность?

Реальность. Но не в том смысле, что 100% строк кода покрыты тестами, а в том, что вся логика, где есть условия, циклы и исключения, оказывается под тестами. Это достигается не количественным подходом, а строгим процессом написания тестов перед кодом.
]]> Как точнее прогнозировать сроки проекта. Метод Монте-Карло http://neogenda.ru/blog/h5kznng4z1-kak-tochnee-prognozirovat-sroki-proekta http://neogenda.ru/blog/h5kznng4z1-kak-tochnee-prognozirovat-sroki-proekta?amp=true Mon, 21 Apr 2025 17:03:00 +0300 Прогнозирование сроков завершения проектов — сложная задача, особенно в условиях высокой неопределенности. В этой статье...

Как точнее прогнозировать сроки проекта. Метод Монте-Карло

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

Исходные условия

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

Визуализация и анализ

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

Метод Монте-Карло

Обычные оценки не давали нужной точности, поэтому мы решили использовать метод Монте-Карло. Суть метода заключается в моделировании большого количества возможных сценариев и определении на их основе вероятностного распределения сроков завершения проекта.
Первые результаты разрушили иллюзии:
Используя исторические данные о пропускной способности команд, мы запустили симуляции и получили пугающий результат: средний прогноз выполнения проекта составлял два года, а некоторые команды могли растянуть работу на 3–4 года. Это кардинально отличалось от изначального «дедлайна» в конце года.

Принятые управленческие решения

Результаты прогнозирования позволили нам предпринять несколько важных шагов:
  1. Пересмотр ожиданий — донесли до всех участников, что завершить проект в изначальные сроки невозможно.
  2. Фокусировка на главном — убрали все второстепенные задачи, не относящиеся к проекту.
  3. Перепланирование ресурсов — перераспределили людей между командами, усиливая те, где были наиболее узкие места.
  4. Минимизация срочных задач — ограничили количество срочных (экспедит) задач до одной в момент времени.
  5. Аутсорсинг — передали часть задач подрядчикам, чтобы разгрузить основные команды.

Финальные мысли и гайд по проекту

Проект занял два с половиной года. Целый год ничего не происходило, но потом процесс пошел, и в итоге мы все завершили. Я обещал гайд — давайте его получим.
  • Договоренности. Самое важное в начале — договориться со всеми. За эти два с половиной года бизнес ни разу не пришёл к разработке с претензией, что рефакторинг не приносит ценности. Если удастся договориться на старте, половина проблем уйдет.
  • Декомпозиция. Создавайте элементы, которыми можно управлять на уровне продукта и прогнозируемой модели. Если этим можно управлять, значит, это можно использовать для моделирования методом Монте-Карло.
  • Визуализация. Постоянно отслеживайте прогресс, чтобы вовремя выявлять проблемы.
  • Статистика. Необходимо использовать исторические данные и статистику для повышения точности прогнозов.
  • Инструменты. Выбирайте удобные инструменты для моделирования и отслеживания задач.
  • Коммиты перед стейкхолдерами. Их стоит делать, когда уже есть хоть какая-то управляемость. Если у вас нет заведённых задач, а уже идут разговоры «сделаем к концу года», то это не лучший подход. Лучше дать коммит чуть позже, но более обоснованный.
  • Принятие решений. Управление — это не просто прогнозирование и следование плану. Нужно адаптироваться, менять подходы, следить за ситуацией и принимать гибкие решения.
  • Прогноз — это процесс. Это не разовая задача, а постоянная работа.
Если вы хотите вывести управление в вашей компании на новый уровень, специалисты Neogenda помогут в этом. Мы работаем с крупнейшими компаниями, такими как Tinkoff, Яндекс, Авито, Сбер и Билайн, и уже обучили более 5 000 сотрудников. Наши эксперты подберут для вас индивидуальные решения, основанные на реальном управленческом опыте и современных практиках.
Запишитесь на бесплатную консультацию в Zoom, чтобы найти способы сделать вашу команду ещё эффективнее.
]]> Как мотивировать сотрудников без повышения заработной платы http://neogenda.ru/blog/o83xmd2l61-kak-motivirovat-sotrudnikov-bez-povishen http://neogenda.ru/blog/o83xmd2l61-kak-motivirovat-sotrudnikov-bez-povishen?amp=true Tue, 22 Apr 2025 17:06:00 +0300 Артур Нек

Как мотивировать сотрудников без повышения заработной платы

Многие считают, что лучшая мотивация — это деньги. И опросы это подтверждают: Институт общественного мнения совместно с Mediacom провели исследование и узнали, что сотрудникам наиболее интересны повышение заработной платы (42%) и премирование (35%)*.
Но если денег на повышение зарплат и большие премии нет, сотрудников можно мотивировать и без денег. В этой статье мы рассмотрим 10 проверенных способов, как мотивировать сотрудников нематериально и создавать сильную команду.

Почему материальная мотивация работает не всегда

При попытке мотивировать сотрудников, первая мысль, которая приходит в голову большинству руководителей — повысить зарплату. Кажется, что деньги решают все проблемы с мотивацией.
Исследования показывают, что финансовая мотивация действительно работает. Вот только ее эффект длится всего 2–3 недели. Сотрудник получает повышение, радуется, работает с удвоенной энергией… А потом возвращается к привычному ритму. Новая зарплата становится новой нормой, уровень вовлеченности человека падает к исходному уровню.
Это происходит из-за «порога удовлетворенности». Когда базовые материальные потребности человека удовлетворены, деньги перестают быть главным мотиватором. Потому что теряется смысл зарабатывать больше. Как только сотрудник начинает получать достаточно для комфортной жизни, каждый дополнительный рубль приносит все меньше и меньше радости и мотивации.
Поэтому, чтобы замотивировать сотрудника в долгосрочной перспективе, нужно работать с более глубокими потребностями человека — признанием, самореализацией, принадлежностью к чему-то значимому.

Что на самом деле движет сотрудниками

Можно выделить несколько основных типов внутренней мотивации:
  1. Мотивация достижения — стремление достигать поставленных целей и получать признание за результаты. Такие сотрудники любят измеримые KPI и признание успехов.
  2. Мотивация отношений — потребность в хороших отношениях с коллегами и ощущении принадлежности к команде. Для таких людей важна атмосфера и совместная работа.
  3. Мотивация роста — стремление к личному и профессиональному развитию. Эти сотрудники ценят обучение и новые вызовы.
  4. Мотивация безопасности — потребность в стабильности и предсказуемости. Такие люди ценят четкие правила и долгосрочные гарантии.
  5. Мотивация смысла — потребность видеть более высокую цель компании и свою роль в ее достижении. Эти сотрудники хотят понимать, как их работа влияет на мир.

Способ №1: Признавать достижения и давать обратную связь

Каждый человек хочет знать, что его усилия не проходят незамеченными. Когда сотрудник видит, что руководитель замечает и ценит его достижения, это создает мощный стимул работать дальше.
По исследованиям Gallup, организации, которые признают достижения сотрудников, имеют на 31% меньшую текучесть кадров и на 14% более высокую производительность.
Существует два основных способа признания заслуг сотрудников — публичный и личный.
Для публичного признания можно:
  • похвалить сотрудника на общих собраниях;
  • упомянуть достижения в командных чатах;
  • наградить человека на корпоративных мероприятиях;
Личное признание может проявляться через:
  • индивидуальную беседу с руководителем;
  • персональное письмо или сообщение с благодарностью;
  • небольшие персональные подарки.
Чтобы похвала действительно работала как мотиватор, нужно соблюдать несколько простых правил.
Хвалите за конкретные действия и результаты, а не за общие качества. Не «ты молодец», а «благодаря твоему анализу удалось сократить расходы на 15%».
Связывайте индивидуальные достижения с общими целями компании. Например: «Твоя оптимизация процесса помогла нам выполнить квартальный план раньше срока».
Не злоупотребляйте. Если хвалить за каждую мелочь, признание обесценивается.

Способ №2: Делегировать полномочия

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

Как найти баланс между контролем и свободой для сотрудников

Здесь проблема в том, что, с одной стороны, руководитель хочет дать сотрудникам свободу. С другой — несет ответственность за результат перед компанией.
Чтобы найти золотую середину, стоит соблюдать несколько принципов:
  • Четко определять границы. Например: «Ты можешь выбрать любое решение, но бюджет не должен превышать X, а дедлайн — Y».
  • Устанавливать контрольные точки. Нужно договариваться о регулярных чекпоинтах, где сотрудник будет отчитываться о прогрессе.
  • Фокусироваться на результатах, а не на процессе. Нужно определить четкие KPI и дать свободу в выборе способов их достижения.
  • Разрешить ошибаться. Чтобы сотрудники учились и не боялись брать на себя ответственность.

Способ №3: Поощрять обучение и развитие

По данным LinkedIn, 94% сотрудников остались бы в компании дольше, если бы она инвестировала в их обучение.
Оплачивая обучение, компания показывает, что ценит сотрудника и рассчитывает на долгосрочное сотрудничество. А сотрудник видит рост его навыков и компетенций. Это создает чувство принадлежности, которое мотивирует работать с большей отдачей.
При этом использовать можно разные форматы обучения и развития. Например проводить тренинги, курсы и наставничество. Ротировать должности для получения разностороннего опыта, проводить хакатоны и др.

Как связать карьерный рост с обучением

Обучение мотивирует сильнее, когда сотрудники видят прямую связь между приобретаемыми навыками и перспективами роста. Вот как можно установить эту связь:
  1. Создать систему карьерных треков. Сотрудник должен понимать, какие навыки ему нужны для перехода на следующий уровень.
  2. Разработать индивидуальные планы развития, где четко прописано, какие программы обучения помогут достичь карьерных целей.
  3. Связать наличие компетенций с возможностью получить новые проекты или зоны ответственности.
Часто руководители боятся вкладываться в обучение. Они думают, что обученные сотрудники уйдут к конкурентам. Но статистика показывает обратное: сотрудники, получающие возможности для обучения и развития, склонны оставаться в компании и показывать высокую вовлеченность.

Способ №4: Объяснить смысл работы и выстроить связь с целями компании

Иногда руководители считают, что цель компании очевидна для всех. Но на практике многие сотрудники плохо понимают куда движется организация и почему это важно. Донести миссию до каждого работника можно разными способами:
  1. Регулярно рассказывайте о стратегии компании, ее долгосрочных и краткосрочных целях на общих собраниях.
  2. Используйте инфографики, дашборды и другие наглядные материалы, которые показывают продвижение к целям.
  3. Рассказывайте конкретные истории о том, как ваш продукт или услуга изменили жизнь клиентов к лучшему.
  4. Привлекайте сотрудников к обсуждению будущего компании.
Но чтобы замотивировать сотрудника, недостаточно просто объявить грандиозную миссию компании. Нужно показать, как повседневная работа каждого человека приближает организацию к этой цели:
  • Использовать каскадирование целей. Разбивайте глобальные цели компании на цели для отдельных команд, а затем на индивидуальные задачи.
  • Ставить цели по OKR (Objectives and Key Results). Внедрите систему, где четко видно, как работа каждого сотрудника влияет на ключевые результаты компании.
  • Обсуждать вклад команд. На встречах с руководителем обсуждайте не только текущие задачи, но и то, как они способствуют достижению целей.
  • Настраивать внутреннюю коммуникацию. Рассказывайте истории о том, как работа разных отделов помогает компании в целом. Например как улучшение какой-то внутренней системы разработчиками помогло отделу продаж заключить важную сделку.
Еще в 2018 году ученые в статье «Нейробиология мышления роста и внутренней мотивации» доказали, что сотрудники, которые понимают смысл своей работы и связь с общими целями, демонстрируют более высокую мотивацию и вовлеченность.

Способ №5: Создать удобные условия труда

В этот способ входит несколько принципов: возможность гибкого графика, создание комфортных рабочих мест, соблюдение work-life баланса.
Гибкий график повышает мотивацию по нескольким причинам:
  • Повышает чувство ответственности и вовлеченности, потому что позволяет сотруднику самостоятельно определять время и место работы. Кроме того, кто-то продуктивнее работает утром, кто-то — вечером. Гибкий график позволяет каждому выбрать оптимальное для себя время, что напрямую влияет на эффективность.
  • Экономит время и снижает уровень стресса. На дорогу до офиса люди тратят от 1 до 3 часов в день, стоят в пробках, нервничают в общественном транспорте и т. д. Удаленная работа помогает сэкономить время и не портить людям настроение перед началом рабочего дня.
  • Позволяет работать в комфортной обстановке. Для многих дом — это место, где они чувствуют себя наиболее комфортно и безопасно. Это способствует творческому мышлению и продуктивности.
По исследованиям Buffer, 98% сотрудников хотели бы иметь возможность работать удаленно хотя бы часть времени, а 97% рекомендовали бы другим такой формат работы.
Важно: при переходе на гибкий формат руководителям придется научиться доверять своим сотрудникам, оценивать их по результатам, а не по времени проведенному на рабочем месте.
Комфортное рабочее место — это удобный стул и стол, хорошее освещение, и зонирование пространства. Грамотная эргономика позволяет сотрудникам трудится эффективнее, быстрее решать задачи и меньше уставать. Когда можно работать в комфорте — мотивация что-то делать растет.
Work-life баланс тоже влияет на мотивацию по двум причинам:
  1. Понимание, что человек может уделять достаточно времени близким и любимым занятиям, снижает тревожность и улучшает психологическое состояние.
  2. Постоянные переработки ведут к эмоциональному истощению и профессиональному выгоранию. Здоровый баланс позволяет поддерживать энтузиазм и интерес к работе.

Способ №6: Внедрить геймификацию и соревновательный элемент

Геймификация — использование игровых принципов и механик в неигровых контекстах. В бизнесе это означает превращение рабочих процессов в игру с правилами, достижениями и наградами.
Чтобы геймификация работала как инструмент повышения мотивации сотрудников, нужно соблюдать несколько принципов:
  • Сотрудники должны иметь возможность выбирать, участвовать им или нет. Принуждение к игре убивает ее суть.
  • Игровые механики должны быть простыми и прозрачными. Каждый участник должен понимать, что нужно делать, чтобы получить награду.
  • В игре должны быть четкие метрики успеха, которые можно отслеживать и сравнивать.
  • Сотрудники должны видеть свой прогресс и получать мгновенную реакцию на свои действия.
  • Задачи не должны быть ни слишком легкими, ни слишком сложными. Иначе решать их станет скучно.
  • Игровые элементы должны направлять сотрудников к достижению реальных рабочих целей, а не отвлекать от них.
Например, если вы хотите повысить качество клиентского сервиса, можно создать игру, где сотрудники получают баллы за положительные отзывы клиентов, скорость решения проблем или креативные решения.
Для геймификации можно использовать разные форматы. Например, создать доску и отмечать достижения сотрудников в разных областях. Проводить хакатоны с физическими призами. Либо ввести накопительные системы баллов, которые можно обменивать на реальные привилегии: дополнительный выходной, обучение, билеты на мероприятия.

Как создать здоровую конкуренцию внутри команды

Чтобы не создать в компании токсичную среду из-за соревнований, придерживайтесь простых правил.
Соревнуйтесь с проблемами, а не друг с другом. Лучше, когда команда вместе преодолевает сложности, чем когда сотрудники борются друг против друга.
Используйте командные соревнования. Разделите коллектив на команды и создайте дружеское соперничество между ними.
Регулярно меняйте команды. Это предотвращает образование постоянных победителей и проигравших.
Отмечайте разные типы достижений. Не только скорость или количество, но и качество, инновационность, помощь коллегам.

Способ №7: Развить корпоративную культуру

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

Как сформировать правильную культуру

Создание корпоративной культуры — огромная тема для отдельного материала. Поэтому здесь пройдемся кратко:
  1. Четко определите ценности компании. Это должны быть конкретные принципы, которые проявляются в повседневных действиях. Например «мы экспериментируем и не боимся ошибаться».
  2. Создавайте традиции, которые укрепляют желаемую культуру. Например, если для компании важна инновационность, проводите регулярные хакатоны или выделяйте время на персональные проекты.
  3. Регулярно спрашивайте сотрудников как они воспринимают атмосферу в компании и что можно улучшить.

Способ №8: Оценить перспективы роста

А точнее — поговорить о карьере и составить индивидуальный план развития.
Разговор о карьере можно организовать примерно так:
  1. Начните с понимания амбиций. Простой вопрос «Где ты видишь себя через 2-3 года?» может открыть много полезной информации о мотивации сотрудника.
  2. Будьте честными насчет возможностей. Если в небольшой компании ограничены варианты вертикального роста, говорите об этом прямо, но предлагайте альтернативы. Например расширение зоны ответственности.
  3. Связывайте карьерные перспективы с целями компании. Например что по мере масштабирования компании понадобятся тимлиды и сотрудник может заранее обучиться специальности.
Индивидуальный план развития (ИПР) — это конкретная дорожная карта для профессионального и карьерного роста сотрудника. В плане обычно отражают карьерную цель — кем сотрудник хочет стать в среднесрочной перспективе (1–2 года). Необходимые навыки, знания и опыт, которые нужно получить для достижения цели. А также конкретные действия по развитию, метрики успеха и ресурсы, которые компания готова предоставить.
Например для разработчика, который хочет стать тимлидом, ИПР может включать технические курсы, постепенное делегирование задач по координации команды, участие в ретроспективах с другими тимлидами и регулярную обратную связь от текущего руководителя.
Разговоры о карьере и ИПР дают понимание о перспективах для сотрудников и конкретных шагах по развитию.

Ротация и горизонтальное перемещение вместо вертикального роста

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

Способ №9: Придумать персонализированные бонусы

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

Способ №10: Создать инновационную среду

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

Что в итоге

Внедрить систему нематериальной мотивации в компании можно несколькими способами:
  • Проведите индивидуальные беседы и просто спросите что для сотрудника важно в работе.
  • Используйте тесты и опросники по определению типов мотивации.
  • Наблюдайте за реакцией сотрудников на разные методы поощрения — смотрите, что вызывает наибольший энтузиазм.
  • Проводите регулярные опросы удовлетворенности и силе мотивирующих факторах.
  • Обратите внимание на спонтанные высказывания сотрудников о том, что им нравится или не нравится в работе.
  • Помните. Система мотивации, которая не учитывает индивидуальные особенности сотрудников, вряд ли поможет. Нельзя мотивировать интроверта публичной похвалой, а человека, ценящего стабильность — рискованными проектами с неопределенным исходом.
Если не знаете, как мотивировать сотрудников и хотите создать сильную команду, обратитесь за помощью в Neogenda. Просто запишитесь на бесплатную консультацию, и наши эксперты помогут разработать решение для вашего бизнеса.
* — Исследование Института общественного мнения
]]> Как успешно выйти на международный рынок: опыт Дмитрия Хаскеля http://neogenda.ru/blog/vme4ggbgu1-kak-uspeshno-viiti-na-mezhdunarodnii-rin http://neogenda.ru/blog/vme4ggbgu1-kak-uspeshno-viiti-na-mezhdunarodnii-rin?amp=true Wed, 23 Apr 2025 17:11:00 +0300 Артур Нек Ведение бизнеса за пределами своей страны кажется сложным и даже пугающим процессом...

Как успешно выйти на международный рынок: опыт Дмитрия Хаскеля

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

От локального бизнеса к международной компании

Изначально Дмитрий работал на российском рынке, но однажды его пригласили управлять компанией, занимающейся производством поверхностно-активных веществ. Перед командой стояла задача расширения за пределы России, и был проведен анализ возможных каналов выхода на международный рынок. Рассматривались три основные стратегии:
  • Выставки — эффективный, но дорогостоящий метод, требующий значительных вложений в стенды, поездки и проживание.
  • Открытие представительств — требует серьезной подготовки и оценки потенциала рынка.
  • Маркетплейсы — более доступный и гибкий вариант.
Компания выбрала маркетплейсы, а основным инструментом продвижения стала платформа Alibaba. Следуя четким инструкциям, Дмитрий и его команда быстро вывели продукцию в топ, привлекли внимание самой Alibaba и в итоге стали ее сервисным партнером. Это стало отправной точкой для масштабирования бизнеса.

Основные ошибки при выходе на международные рынки

Дмитрий делится статистикой: из 30 российских компаний, открывших представительства в Дубае, успешно закрепились только две. Остальные продолжили работать с российскими клиентами. Это говорит о том, что выход на международный рынок требует не только желания, но и грамотной стратегии.
Ключевые ошибки:
  • Неподготовленность команды. Экспорт требует фокусировки и профессионалов, разбирающихся в специфике рынка.
  • Отсутствие партнеров на месте. В каждой стране важно иметь локального партнера, который понимает законодательство и специфику ведения бизнеса.
  • Выбор неподходящего рынка. Часто компании ориентируются на «красивые» страны, такие как США или Китай, игнорируя более перспективные рынки.

Как выбрать страну для экспорта?

Важно опираться на аналитику, а не на тренды. Например, Китай может быть переполнен конкурентами, тогда как менее очевидные рынки, такие как Казахстан или Узбекистан, могут стать отличным стартом.
Способы анализа рынка:
  • Использование сервисов, таких как Jungle Scout, для изучения конкурентов и спроса на Amazon.
  • Проведение обзвона конкурентов, чтобы выяснить рыночную ситуацию и спрос.
  • Тестирование товаров через маркетплейсы — размещение предложений и оценка отклика потенциальных клиентов.

Где искать партнеров?

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

Альтернативные модели работы

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

Переломные моменты и принятие сложных решений

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

Если бы я мог дать совет себе 15-20 лет назад…

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

О партнерстве в бизнесе

Мой партнер Борис Нейман — человек, с которым мы нашли идеальную модель сотрудничества. У каждого из нас были свои бизнесы, но мы приняли решение объединиться и работать по принципу 50/50. Это помогло избежать недопонимания: когда ты вкладываешься в общий бизнес, не возникает ощущения, что кто-то делает больше. Мы четко разделили роли: собственники принимают стратегические решения, а операционный менеджмент отвечает за ежедневную работу. Такой подход позволяет фокусироваться на развитии, а не на внутренней конкуренции.

Выращивание управленцев внутри компании

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

Как я принимаю решения о новых проектах

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

Выход на международный рынок: ключевые моменты

  1. Выбирать рынки, где действительно есть спрос.
  2. Привлекать местных специалистов или людей, которые хорошо знают регион.
  3. Лично посещать страну, чтобы понять культуру ведения бизнеса.
  4. Быстро реагировать на запросы — это ключевой фактор успеха в международной торговле.

Итог

Бизнес — это постоянное движение и адаптация. Важно не бояться перемен, искать новые возможности и учиться на каждом этапе. Надеюсь, мой опыт поможет тем, кто стоит перед важными решениями или только начинает свой путь в предпринимательстве.
Если вы хотите вывести управление в вашей компании на новый уровень, специалисты Neogenda помогут в этом. Мы работаем с крупнейшими компаниями, такими как Tinkoff, Яндекс, Авито, Сбер и Билайн, и уже обучили более 5 000 сотрудников. Наши эксперты подберут для вас индивидуальные решения, основанные на реальном управленческом опыте и современных практиках.
Запишитесь на бесплатную консультацию в Zoom, чтобы найти способы сделать вашу команду еще эффективнее.
]]> Канбан доска: как правильно настроить рабочий процесс http://neogenda.ru/blog/f77uptvbh1-kanban-doska-kak-pravilno-nastroit-raboc http://neogenda.ru/blog/f77uptvbh1-kanban-doska-kak-pravilno-nastroit-raboc?amp=true Thu, 24 Apr 2025 17:14:00 +0300 Артур Нек Метод Канбан возник в 1950-х годах благодаря компании Toyota. Тайити Оно, менеджер компании, столкнулся с...

Канбан доска: как правильно настроить рабочий процесс

Метод Канбан возник в 1950-х годах благодаря компании Toyota. Тайити Оно, менеджер компании, столкнулся с серьезной проблемой: как организовать эффективное производство в условиях ограниченных ресурсов послевоенной Японии?
Решением стала система, где производство деталей начиналось только по сигналу от следующего этапа работы.
На практике это работало примерно так:
  • Каждый цех или участок производства имел две корзины для деталей: одну — с деталями, над которыми сейчас работают, и пустую, которую отправляли «назад» с заказом на новые детали.
  • К каждой корзине прикреплялась физическая карточка, на которой указывалось точное количество и тип необходимых деталей.
  • Рабочий на каждом участке брал детали только тогда, когда они требовались для текущей работы. Когда запас деталей уменьшался до определенного уровня, он отправлял пустую корзину с карточкой-канбаном на предыдущий участок.
  • Получив корзину с карточкой, рабочие предыдущего участка понимали, что пора производить новую партию деталей именно того типа и в том количестве, которое указано на карточке.
Это полностью меняло логику производства. Вместо традиционной системы «делаем детали и отправляем их вперед независимо от потребности», Toyota внедрила принцип «производим только то, что запросили следующие участки и ровно в том количестве, которое необходимо».
Такая система помогла Toyota сократить склады запасных частей, уменьшить перепроизводство и сделать всю цепочку производства более гибкой и эффективной. А в результате — стать одной из крупнейших компании в мире.
В статье разбираемся, что такое Канбан-метод, как он устроен и как его внедрить в свою компанию.

Что такое Канбан-метод

Канбан — это инструмент визуализации рабочих процессов, который позволяет наглядно представить все задачи и их текущий статус.
После Toyota канбан-метод перекочевал и в другие сферы: IT, разработка, менеджмент. На смену корзинам пришли физические и виртуальные доски, разделенные на колонки, где каждая колонка представляет определенный этап рабочего процесса. А карточки внутри колонок — конкретные задачи.
Главная идея канбана проста: сделать наглядным весь поток задач. Определить, где возникают заторы и оптимизировать рабочий процесс.

Ключевые принципы Канбана

Канбан — целая философия организации работы. Метод основан на нескольких ключевых принципах:
1. Визуализация рабочих процессов. Все задачи должны быть отражены на доске. Так команда лучше понимает, что происходит, где возникают проблемы и как распределяется нагрузка. Визуализация помогает быстрее выявлять узкие места и устранять их.
2. Ограничение незавершенной работы (WIP-лимиты). В команде должен быть лимит на количество задач, находящихся в работе одновременно. Это помогает фокусироваться на конкретных задачах и не распыляться.
3. Управление потоком. Команда должна отслеживать, как задачи перемещаются по доске и устранять препятствия. Это позволяет добиться равномерного темпа работы и избежать ситуаций, когда задачи подолгу застревают на одном этапе.
4. Повышение прозрачности. Правила работы с доской должны быть ясными и понятными для всех участников процесса. Каждый член команды должен знать, по каким критериям задача переходит на следующий этап.
5. Непрерывное улучшение. Команда должна регулярно анализировать свою работу и вносить улучшения в процесс. Это позволит постепенно устранять проблемы и делать работу более эффективной.
Еще один важный принцип Канбана — работа «вытягивается»: новая задача берется в работу только тогда, когда есть ресурсы на ее выполнение. То есть, команда сама берет задачи из бэклога в соответствии со своей реальной загруженностью.
Например, если в колонке «Разработка» установлен лимит в 3 задачи, то четвертую задачу можно взять только после того, как одна из трех текущих будет завершена и перемещена в следующую колонку.
Этот принцип помогает:
  • не перегружать команду;
  • понимать реальную пропускную способность системы;
  • сокращать время выполнения задач;
  • повышать предсказуемость сроков.
В традиционном подходе менеджеры распределяют задачи между сотрудниками и часто не учитывают реальную загрузку исполнителей.

Чем Kanban отличается от Scrum

В Scrum команда берет на себя определенное количество задач на спринт и работает над ними до дедлайна. В канбане фокус смещается на поток работы и ограничение количества задач в процессе выполнения. Новые задачи могут добавляться в бэклог в любой момент, если это не нарушает установленные правила.
Ключевые отличия от Scrum:
В Канбане нет фиксированных итераций (спринтов). Работа движется непрерывным потоком.
Scrum предполагает фиксированные роли (Scrum Master, Product Owner, команда разработки), тогда как для Канбана не нужно вводить новые роли.
В Канбане изменения можно вносить в любой момент, а в Scrum — обычно в начале нового спринта.

Из чего состоит базовая Канбан-доска

В самом простом виде канбан доска состоит из трех основных колонок:
  • Бэклог — задачи, которые нужно выполнить. Отсюда задачи попадают в работу.
  • В работе — задачи, над которыми команда работает прямо сейчас.
  • Готово — выполненные задачи, которые прошли проверку и переданы клиенту.
Но в реальности на доске больше колонок и зависимостей. Поэтому в целом можно выделить несколько основных колонок:
  • Бэклог — список задач и область, где происходит приоритизация. Здесь решается, какие задачи будут взяты в работу следующими.
  • Колонки анализа/проектирования — здесь команда изучает требования, оценивает сложность и продумывает решение. На этом этапе канбан карточка может дополняться деталями.
  • Колонки разработки — непосредственное создание продукта.
  • Колонки проверки/тестирования — здесь проверяют продукт на соответствие требованиям, наличие дефектов и т. д.
  • Колонки выпуска/релиза — финальные шаги перед отправкой результата клиенту.
Также в канбан-доске можно условно выделить 2 точки:
  • Точка принятия обязательств — момент, когда команда официально берет задачу в работу и обязуется ее выполнить. На канбан-доске это обычно граница между колонкой «Бэклог» и первой колонкой активной работы.
  • Точка поставки продукта — момент, когда работа считается полностью завершенной и переданной клиенту.
Важный момент: часто между основными этапами добавляют буферные колонки вроде «Ожидает тестирования» или «Готово к проверке». Это делается для того, чтобы показать завершенность задачи на одном этапе и ее готовность перейти на следующий.

Как можно улучшить канбан-систему

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

Горизонтальные дорожки (swimlanes) для разных типов работ

Канбан-доску можно разделить по горизонтали — на так называемые дорожки или swimlanes. Дорожки позволяют группировать карточки канбан по определенным признакам:
  • По типам работ. Например, отдельные дорожки для разработки новых функций и исправления ошибок. Это помогает не забывать о важных, но не срочных задачах.
  • По проектам или продуктам. Если команда работает над несколькими проектами одновременно, дорожки помогут визуально разделить их на доске.
  • По классам обслуживания. Можно создать полосу для срочных задач и обычные полосы для стандартных работ.
По командам или исполнителям.
Например, канбан-доска для проекта по разработке ПО может состоять из таких дорожек:
  • срочные исправления (верхняя дорожка с высшим приоритетом);
  • новые функции (основной поток разработки);
  • улучшения UX/UI (доработки интерфейса);
  • технический долг (архитектурные улучшения, рефакторинг).
Дорожки позволяют визуально контролировать баланс разных типов работ. Например, если в дорожке «Технический долг» задачи постоянно застревают, это сигнал, что команда накапливает технические проблемы, которые потом могут замедлить разработку.
Источник: Канбан метод базовая практика, А. Пименов

Дополнительные визуальные элементы

Визуальные элементы можно использовать, чтобы сделать информацию более наглядной и доступной.
Цветовая кодировка. Разные цвета канбан-карточек могут означать:
  • тип работы (зеленый — новая функция, красный — баг);
  • приоритет (красный — высокий, желтый — средний, зеленый — низкий);
  • продукт или проект;
  • команду или отдел.
Метки и флаги. Небольшие маркеры, которые добавляют дополнительную информацию:
  • блокеры (задача застряла из-за внешних факторов);
  • зависимости от других задач;
  • крайние сроки;
  • статус проверки.
Индикаторы времени. Маркеры, показывающие, сколько времени задача находится в текущем статусе:
  • счетчики дней;
  • цветовые индикаторы (зеленый → желтый → красный. По мере старения задачи).

Что такое WIP-лимиты и как их определить

WIP-лимиты (Work In Progress — работа в процессе) — это ограничение количества задач, которые могут одновременно находиться в работе на определенном этапе.

Как рассчитать оптимальные WIP-лимиты

Не существует универсальной формулы для расчета идеальных WIP-лимитов. Но определить примерные значения можно с помощью формулы Литтла.
Формула выглядит так:
L = λ x W
Буквы означают:
  • L — количество задач в работе;
  • λ — пропускная способность (Throughput);
  • W — время цикла (Lead Time).
Пропускная способность (Throughput) — количество задач, которые команда завершает за определенный период времени (день, неделю, месяц). Это метрика скорости работы команды. Например, если за неделю команда завершила 10 задач, то пропускная способность составляет 10 задач в неделю.
Время цикла (Lead Time) — это время, которое проходит от момента, когда канбан-карточка попадает на доску (точка принятия обязательств), до момента, когда задача полностью завершена (точка поставки продукта).
Допустим, среднее время выполнения одной задачи составляет 2 недели (время цикла W = 2 недели). А пропускная способность равна 10.
Тогда по формуле Литтла оптимальным количеством задач в работе будет: 10 задач/неделю × 2 недели = 20 задач.
Кроме формулы Литтла можно использовать другие методы:
  • Эмпирический подход. Начните с существующей ситуации. Посмотрите, сколько задач обычно находится в работе на каждом этапе, и установите лимит немного ниже этого значения (на 10–20%). Постепенно снижайте или повышайте лимит и наблюдайте за производительностью команды.
  • Подход от узкого места. Определите самый медленный этап в вашем процессе (узкое место) и установите лимит, равный его пропускной способности.
И помните. Нет правильного или неправильного WIP-лимита. Есть только тот, который работает лучше в конкретной ситуации.

Как WIP-лимиты улучшают поток работы

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

Как адаптировать лимиты под разные этапы и типы задач

WIP-лимиты не должны быть одинаковыми для всех этапов и типов работ. Вот несколько принципов их адаптации:
  1. Учитывайте специфику этапа. На этапах с высокой неопределенностью (например, исследование) лучше использовать более низкие лимиты, чем на предсказуемых этапах (вроде тестирования по чек-листу).
  2. Адаптируйте лимит под размер команды. Очевидно, что команда из 5 человек может параллельно работать над большим количеством задач, чем команда из 2 человек.
  3. Учитывайте типы задач. Для разных типов задач могут потребоваться разные лимиты. Например, для срочных исправлений ошибок можно выделить отдельный поток с собственными лимитами.
  4. Используйте буферные колонки. Они помогают сгладить разницу в скорости работы разных этапов.
  5. Регулярно пересматривайте лимиты. Анализируйте как работает система и корректируйте лимиты по мере необходимости.

Как внедрить Канбан-систему в компанию

Внедрение Канбан можно разделить на несколько последовательных этапов:
  • согласование с руководством;
  • аудит текущих процессов;
  • проектирование доски;
  • установка WIP-лимитов;
  • внедрение доски в работу;
  • измерение и улучшение.
На этапе согласования нужно объяснить руководству и ключевым сотрудникам преимущества канбан и как он решит конкретные проблемы.
На этапе аудита нужно пройтись по нескольким пунктам:
  1. Собрать всю команду и провести сессию для создания ценности. Это поможет выявить, как на самом деле движутся задачи от идеи до реализации.
  2. Задать вопросы: «Как появляются задачи?», «Какие этапы они проходят?», «Где чаще всего возникают задержки?», «Кто за что отвечает?».
  3. Зафиксировать не идеальный, а реальный процесс со всеми его недостатками. Часто выясняется, что официальный процесс и то, как работа выполняется на практике — это разные вещи.
  4. Измерить ключевые показатели: сколько времени задача проводит на каждом этапе, как часто возвращается на доработку, сколько задач обычно находится в работе одновременно.
  5. Выявить проблемные участки: где образуются заторы, где задачи застревают, где качество страдает из-за спешки.
После аудита можно приступать к проектированию первой версии канбан-доски. Главный принцип здесь — простота. Не пытайтесь создать идеальную доску с первого раза. Начните с минимальной работоспособной версии и постепенно улучшайте ее. Вот шаги для создания базовой канбан доски:
  1. Определите основные стадии рабочего процесса. Для начала достаточно 3: «Бэклог», «В работе», «Готово» и 1–2 промежуточных стадии, специфичных для вашего процесса.
  2. Решите, какую информацию будут содержать канбан-карточки. Обычно это название задачи, ответственный, дедлайн, приоритет и краткое описание.
  3. Выберите формат доски — физическая (стена с стикерами) или цифровая. У каждого варианта есть свои преимущества. Физическая доска более наглядна, цифровая удобна для распределенных команд.
  4. Создайте шаблоны карточек, которые будут содержать всю необходимую информацию в шаблонизированном виде.
  5. Установите начальные WIP-лимиты.
После создания доски ее нужно внедрить в жизнь команды. Вот несколько шагов, которые помогут это сделать:
  1. Проведите обучающую сессию для всей команды. Объясните принципы канбан, как работает доска, что означают WIP-лимиты и какие правила нужно соблюдать.
  2. Перенесите все текущие задачи на доску. Это покажет чем занята команда, поможет выявить перегруженные участки.
  3. Введите ежедневные стендап-митинги (15–20 минут), где каждый член команды рассказывает о своих задачах, проблемах и плане действий.
  4. Назначьте ответственного за актуализацию доски.
  5. Начните собирать метрики: время цикла (сколько времени задача проводит на доске от начала до конца), пропускная способность (сколько задач команда завершает за период), распределение задач по колонкам.
  6. Проводите регулярные ретроспективы (раз в 2–4 недели) и обсуждайте работу канбан-системы и возможные улучшения.

Типичные ошибки при работе с канбан-досками

Ошибка №1: Отдельная доска для каждого проекта

Часто команды создают разные канбан доски для каждого проекта. Сначала это кажется логичным: разные проекты — разные доски. Но что происходит, когда люди работают над несколькими проектами одновременно?
У каждого сотрудника появляется несколько приоритетов №1, несколько приоритетов №2 и так далее. Такой подход не дает реально оценить загруженность команды и ее пропускную способность.
Решение: создавать доски не для проектов, а для команд. Одна команда — одна доска, на которой отражаются все задачи этой команды, независимо от проекта.

Ошибка №2: Колонки по отделам, а не по активностям

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

Ошибка №3: Выделенная колонка для заблокированных задач

Многие команды создают специальную колонку «Заблокировано» и помещают туда все задачи, работа над которыми приостановлена из-за каких-то препятствий. На первый взгляд это логично — ведь мы освобождаем место в колонках с WIP-лимитами.
Но такой подход имеет серьезные недостатки:
  1. Создает впечатление, что блокировка — это нормальная часть рабочего процесса.
  2. Заблокированные задачи как бы исчезают из поля зрения, теряется чувство ответственности за их завершение.
  3. Становится сложно отслеживать, сколько времени на самом деле уходит на выполнение задачи с учетом периодов блокировки.
Решение: оставляйте заблокированные задачи в тех колонках, где они застряли, но помечайте их специальными маркерами. Так они не пропадут из поля зрения.

Ошибка №4: Удаление карточек с незавершенными задачами

Иногда в процессе работы выясняется, что задача больше не актуальна или ее нельзя выполнить. Часто такие карточки удаляют с доски. Это ошибка по двум причинам:
Это мешает оценивать WIP-лимиты и применять формулу Литтла, т. к. не все задачи, вошедшие в систему, пройдут через нее и будут участвовать в расчетах.
Это мешает анализировать причины, почему задача не была завершена, как это произошло и что можно улучшить, чтобы этого избежать в будущем.
Решение: вместо удаления добавляйте метку «Отменено» к карточке и перемещайте ее в колонку «Готово».

Ошибка №5: Перемещение карточек назад по доске

Иногда команды перемещают карточку назад в предыдущую колонку, если задача не соответствует критериям качества на одном из этапов. Это приводит к проблемам:
  • Анализировать выполнение работы и прогнозировать сроки становится сложнее.
  • Скрываются реальные проблемы, из-за которых рабочий процесс нарушается.
  • Увеличивается общее время выполнения задачи из-за постоянных возвратов.
Решение: оставляйте задачу в текущей колонке и работайте над устранением недостатков. Если нужно, создавайте подзадачи или используйте специальные маркеры для задач, требующих доработки.
Важно. Настоящее завершение задачи — это не просто перемещение канбан карточки в последнюю колонку. Это момент, когда результат работы действительно используется и приносит ценность.
Многие команды ошибочно считают, что задача завершена, когда разработка окончена. На самом деле, задача по-настоящему завершена в момент, когда она:
  • прошла тестирование;
  • развернута в продакшн-среде;
  • пользователи действительно используют продукт;
  • продукт работает корректно.

Как понять, что Канбан приносит пользу

Сначала нужно собрать данные для анализа:
  • Когда задача появилась на доске.
  • Когда она перешла из одной колонки в другую.
  • Когда задача была завершена.
На основании этих данных можно узнать:
  • среднее время цикла;
  • изменение времени цикла;
  • пропускную способность.
Среднее время цикла вычисляется как разница между временем завершения задачи (пункт 3) и временем ее появления на доске (пункт 1). Эта метрика помогает прогнозировать время выполнения будущих проектов. Например, если среднее время цикла составляет 10 дней с отклонением ±2 дня, то с высокой вероятностью новая подобная задача будет выполнена за 8–12 дней.
Об изменении времени цикла можно судить по времени цикла для задач за разные периоды. По данным о появлении и завершении задач (пункты 1 и 3), можно определить, становится ли система быстрее или медленнее. Если среднее время выполнения задач растет, значит, в системе появились проблемы, которые нужно решать.
Пропускная способность измеряется количеством завершенных задач (пункт 3) за определенный период времени. Стабильность этого показателя говорит о предсказуемости работы команды. Если количество завершенных задач за период примерно одинаково, значит, команда работает в постоянном ритме.
Дополнительно можно анализировать эффективность потока (Flow Efficiency). Метрика показывает, какой процент времени цикла задача действительно находилась в активной работе, а не просто ожидала.
Формула для расчета эффективности потока:
(Время активной работы/Общее время цикла) × 100%
Чем выше значение эффективности, тем лучше.
С точки зрения долгосрочного эффекта Канбан поможет проанализировать изменения в компании с помощью кумулятивной диаграммы потока (Cumulative Flow Diagram, CFD).
CFD выглядит как график с накоплением, где:
  • Ось X — это время.
  • Ось Y — количество канбан карточек.
  • Разные цвета показывают разные стадии рабочего процесса.
Источник: Канбан метод базовая практика, А. Пименов
Для примера рассмотрим тренды по оранжевой и черной линиям на диаграмме (колонки «План» и «Готово»).
Источник: Канбан метод базовая практика, А. Пименов
По графику видно, что тренды со временем расходятся. Это может говорить о том, что количество рабочих элементов в системе растет. А значит — будет расти среднее время производства.
Угол отклонения трендов от горизонтальной оси показывает скорость поступления рабочих элементов в колонку «План» и убыль выполненных рабочих элементов в колонку «Готово». По графику видно, что скорость поступления работы превышает скорость ее завершения.
В целом при анализе CFD вы можете обнаружить:
  • Расширяющиеся полосы — признак того, что задачи застревают в определенных статусах.
  • Параллельные верхнюю и нижнюю линии — признак стабильной системы, где поступление и завершение задач сбалансированы.
  • Растущее расстояние между верхней и нижней линиями — накопление незавершенной работы.

Как использовать метрики для оптимизации рабочего процесса

Выявлять узкие места. Если задачи застревают в определенной колонке (видно по расширению соответствующей полосы на CFD), возможно, в этой стадии не хватает ресурсов или есть другие препятствия.
Настраивать WIP-лимиты. Если время цикла слишком большое, возможно, команда берет в работу слишком много задач одновременно. Ограниченное количество задач в работе может значительно сократить время выполнения.
Распределять процессы. Если одни колонки постоянно переполнены, а другие пустуют, процесс несбалансирован. Перераспределение ресурсов поможет грамотно распределить ресурсы и сделать выполнение задач более предсказуемым.

Что в итоге

  • Канбан-метод — инструмент визуализации рабочих процессов для повышения эффективности работы.
  • Метод основан на ключевых принципах: визуализация, ограничение незавершенной работы, управление потоком, повышение прозрачности, непрерывное улучшение.
  • Канбан-доска состоит из трех основных колонок: «Бэклог», «В работе», «Готово». Продвинутые элементы канбан-системы включают горизонтальные дорожки (swimlanes) и дополнительные визуальные элементы.
  • WIP-лимиты (Work In Progress — работа в процессе) помогают оптимизировать поток работы и повысить предсказуемость.
  • Внедрение канбан-системы в компанию проходит через несколько этапов: согласование, аудит, проектирование, установка WIP-лимитов, внедрение, измерение и улучшение.Типичные ошибки при работе с канбан-досками: создание отдельных досок для каждого проекта, использование колонок по отделам, выделение колонки для заблокированных задач, удаление карточек с незавершенными задачами, перемещение карточек назад по доске.
Канбан — это не просто доска со стикерами, а мощный инструмент управления потоком работ, который помогает команде работать более эффективно. Он не задает жестких правил, а дает гибкий фреймворк, который можно адаптировать под нужды вашей команды и постоянно улучшать.
Если хотите внедрить Канбан в компанию и вывести компанию на новый уровень, обратитесь за помощью в Neogenda. Просто запишитесь на бесплатную консультацию, и наши эксперты помогут интегрировать систему в ваш бизнес.
]]> Как выбрать между аутсорсингом и аутстаффингом: взгляд эксперта http://neogenda.ru/blog/s6xxxng8r1-kak-vibrat-mezhdu-autsorsingom-i-autstaf http://neogenda.ru/blog/s6xxxng8r1-kak-vibrat-mezhdu-autsorsingom-i-autstaf?amp=true Fri, 25 Apr 2025 11:20:00 +0300 Сегодня у нас горячая тема для обсуждения — аутсорс, аутстаф, штатные сотрудники и вообще, как...

Как выбрать между аутсорсингом и аутстаффингом: взгляд эксперта

Сегодня у нас горячая тема для обсуждения — аутсорс, аутстаф, штатные сотрудники и вообще, как выбрать оптимальную модель работы для вашего бизнеса. Я пригласил профессионала в этой области — Егора Репьева, Business Development Manager в компании Evron. Компания Evron работает с крупнейшими мировыми заказчиками, такими как Volkswagen и Pirelli, и имеет многолетний опыт в сфере IT-разработки. В этом подкасте мы разберемся, в чем же разница между аутсорсом и аутставом, какие плюсы и минусы у каждой модели, и для каких задач каждая из них подходит.

Что такое аутсорс и аутстаф?

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

Зачем компании привлекают аутстаф?

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

Как избежать ловушек при использовании аутстафа?

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

Аутстаф vs. штатные сотрудники: гибкость и риски

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

Как выбрать оптимальную модель для своего бизнеса?

Итак, выбор между аутсорсингом, аутстаффингом и наймом штатных сотрудников зависит от множества факторов: задач, сроков, бюджета и зрелости компании. Аутсорсинг подходит для задач, которые можно делегировать внешним исполнителям, а аутстаф — для тех случаев, когда необходимо быстро влить дополнительные ресурсы в свою команду. Но важно помнить, что ни одна из этих моделей не является универсальной. В некоторых случаях целесообразно комбинировать их, находя баланс между скоростью, качеством и контролем над процессом.
В конечном итоге, ключевым фактором в выборе модели является понимание того, что именно нужно вашему бизнесу в данный момент — и какие ресурсы у вас есть для реализации этих целей.
Процесс найма и взаимодействие с аутстаффингом: Готовность к рискам и выстраивание правильной коммуникации
Когда компания решает нанимать сотрудника через аутстаффинг, процесс часто начинается с того, что компания говорит:
«Этот кандидат не наш, мы его не наняли, но если он вам подойдет, мы его возьмем».
Это открытая схема, где нет никаких скрытых рисков. Особенно в сферах, как бигтехи и финтехи, где постоянный перерасход ресурсов является нормой. Предложения кандидатов могут поступать от разных компаний, что является нормальной практикой на рынке. Однако, когда ситуация выглядит как нечто «гротескное», например, когда предлагают одно и то же с наименьшими изменениями и пытаются убедить, что это «наш сотрудник», такой подход стоит сразу исключить. Важно понимать, что коммуникация на входе компании говорит о том, как она будет работать и внутри. Если процесс найма организован слабо, то скорее всего, и внутри компании дела обстоят так же. Низкое качество предоставляемой информации, отсутствие структурированности, а также адаптация под вас людей, которые будут учиться «на ходу» — все это риски, которые могут оказаться дорогостоящими.
Собеседования — это не только момент отбора кандидата, но и показатель того, как компания соблюдает дисциплину. Например, если кандидаты опаздывают на собеседование, не подключаются вовремя к видео-звонку или сидят в небрежной одежде, это может стать индикатором того, что отношение компании к работе и к процессам тоже несерьезное. Это также касается кандидатов, которые проходят собеседование с камерой, а не без, что дает представление о готовности кандидата к работе и его подходу.

Процесс онбординга и погружения в проект

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

Гарантии и риски: что делать, если процесс не работает?

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

Мифы о выгодах аутстафа и их финансовой стороне

Аутстаффинг часто воспринимается как возможность снять с себя нагрузку, связанную с социальными выплатами, налоговыми вопросами и другими организационными моментами. Однако, в действительности, аутстаффинг может быть даже более выгодным, чем найм сотрудников, особенно в краткосрочной перспективе. Это позволяет компании избежать дополнительных затрат на социальное обеспечение, выплату бонусов, ДМС и прочих благ, а также упростить процесс увольнения сотрудников. В случае с аутстафферами компании, как правило, не платят за больничные и отпуска, что может существенно снизить издержки.
Тем не менее, существуют мифы, что аутстафферы — это те люди, которых можно выжимать по полной, заставлять работать сверхурочно и платить им меньше, чем in-house сотрудникам.
Это не так, а выгорание может быть проблемой как для сотрудников инхаус, так и для аутстафферов. Важно понимать, что грамотное управление аутстафом и использование аккаунт-менеджмента помогает избежать таких проблем.
В случае с аутстаффером заказчик получает не только квалифицированного сотрудника, но и доступ к коллективной экспертизе компании, которая предоставляет его. В процессе работы аутстаффер может обращаться за помощью, советами и решениями к коллегам внутри своей компании, что помогает ему не выгореть и решить возникающие проблемы.
]]> Кто такой трекер и зачем он нужен? http://neogenda.ru/blog/5dupa4kfm1-kto-takoi-treker-i-zachem-on-nuzhen http://neogenda.ru/blog/5dupa4kfm1-kto-takoi-treker-i-zachem-on-nuzhen?amp=true Sat, 26 Apr 2025 11:23:00 +0300 Артур Нек Источник: Kanban Podcast Ведущий: Алекс Цыбульник — Kanban-coach...

Кто такой трекер и зачем он нужен?

Источник: Kanban Podcast
Ведущий: Алекс Цыбульник — Kanban-coach
Гость: Дмитрий Козлов — трекер в компании ProductVision

О себе и профессиональном пути

  • Начал заниматься продуктами в 2013 году, перейдя из тех. подразделения Альфа-Банка в бизнес.
  • Первое задание — проведение Альфа-Кэмпа (2014), первого финтех-акселератора в России.
  • С 2015 года активно работает с командами и в роли трекера.
  • Прошел путь от разработчика (Oracle, MySQL, разные языки программирования) до бизнес-партнера и продукт-менеджера в Яндексе.
  • Сейчас фокус — только трекерство, обучение команд, сопровождение трансформаций.

Кто такой трекер в современной организации?

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

История появления трекеров

1. Родина трекеров — Силиконовая долина, где инвесторы искали способ «держать руку на пульсе» стартапов.
2. В России профессия появилась благодаря ФРИИ и Жене Калинину, который адаптировал методологию.
3. Отличие российской модели:
  • В США трекер — контролёр.
  • В России — партнёр команды, помогает бежать быстрее без формальной власти.
Эволюция:
  • Началось со стартапов, потом перешло в корпорации (Альфа, Сбер, 500 Startups, КРОК и др.).
  • Появился корпоративный трекер — тот же подход, но с учетом ограничений крупной компании.

Зачем организации трекер?

Главная ценность — диагностика узких мест.
1. Помогает понять, где в команде/процессе проблема:
  • Коммуникации
  • Целеполагание
  • Метрики
  • Приоритеты
2. Вторая ценность — изменение мышления команды:
  • Вместо «нам сказали сделать» → «мы влияем на такие-то метрики, потому что провели эксперименты».
  • Команда начинает мыслить через гипотезы, экономику, результат.
  • Видно по риторике, когда команда прошла работу с трекером (примеры — МТС, трансформация через Сергея Паращенко).

Инструментарий трекера

Главный инструмент — вопросительная коммуникация. Правильно поставленные вопросы помогают продвинуть команду вперёд: увидеть альтернативы, прояснить мотивацию, расставить приоритеты. Второй важный инструмент — экспертиза и насмотренность. Особенно важна она на старте, когда нужно «разбудить» команду, показать, как бывает по-другому.
Трекер не учит, но может делиться кейсами и аналогиями:
«Вот в таком-то проекте пробовали вот так — сработало/не сработало. А у вас как?». Это позволяет расширить мышление и подстегнуть к самостоятельному поиску решений.
Важно: если у команды нет запроса на изменения, трекер бессилен.

Где трекер в Kanban-процессе?

Апстрим (upstream) — генерация и отбор идей, гипотез, опционов.
Даунстрим (downstream) — реализация, доставка ценности.
Трекер работает на стадии апстрима:
1. Помогает понять, что из поступающего потока брать, а что — нет.
2. Не контролирует выполнение задач (даунстрим) — это про план-факт.
3. Помогает оценить обоснованность гипотез, идей, задач:
  • Влияет ли на метрики?
  • Есть ли ценность для бизнеса?
  • Действительно ли прибыль будет такой, как заявлено?

Практические кейсы и ответственность трекера

1. Примеры значимого эффекта работы трекера

  • Пилот гипотезы для детской карты: за 5 недель был проведен CustDev, создан MVP, запущен пилот и получены первые средства «налом на руки». Эта проверка легла в стратегию продукта, хотя полный запуск затянулся из‑за маркетинга.
  • Поддержка стартапа при переезде в Силиконовую долину: трекер взаимодействовал с российской командой, чей продукт затем успешно стартовал в США под новым брендом.
  • Оптимизация штата: при аудитах продукции и процессов трекер выявлял в компании «слепые зоны», где сотрудники выполняли формальные задачи без явной ценности. После совместного анализа часть позиций была сокращена, что привело к экономии ресурсов и повышению общей эффективности.

2. Как отличить настоящего трекера от шарлатана

  • Фокус на вопросах, а не на догмах. Настоящий трекер задаёт именно те вопросы, которые подталкивают к конкретным решениям и гипотезам. Шарлатан зацикливается на «методологии ради методологии» или разбрасывается избитыми вопросами без результата.
  • Гибкость и эмпатия. Профессионал умеет подстраиваться под команду и её ограничения: поддерживает интроверта в Customer Development, помогает найти подходящий формат эксперимента, если традиционные методы не работают.
  • Отсутствие волшебных кнопок. Трекер не обещает «кнопку успеха», а показывает реальные ограничения процесса и помогает команде самим выстроить путь к результату.

3. Место трекера в Kanban‑потоке

  • Upstream. Основная зона ответственности — этап отбора идей, гипотез и опций перед переходом к обязательствам («commitment point»). Трекер помогает понять, какие задачи действительно стоят того, чтобы их взять в работу, и каким метрикам они должны соответствовать.
  • Downstream. На этапе исполнения и поставки («delivery») трекер не вмешивается — это зона план‑факт контроля и оперативного управления.

4. Ответственность трекера

  • Перед инвесторами или владельцами бизнеса: предоставить объективную картину и диагностику — где команды не двигаются вперёд и почему. Если команда не достигает цели, трекер предлагает варианты решения или рекомендует приостановить проект во избежание «сжигания денег».
  • Перед командой: способствовать фокусировке на ценных целях и метриках, учить аргументированной защите гипотез и экспериментов. Если команда не готова к изменениям, трекер информирует заказчика и помогает найти мотивацию или определить причину стагнации.
]]> Fit for Purpose Framework: как понять, чего хочет клиент http://neogenda.ru/blog/v29vc3ral1-fit-for-purpose-framework-kak-ponyat-che http://neogenda.ru/blog/v29vc3ral1-fit-for-purpose-framework-kak-ponyat-che?amp=true Sun, 27 Apr 2025 11:25:00 +0300 Артур Нек Источник: Kanban Podcast В этом выпуске подкаста Kanban Talks мы обсуждаем один из самых интересных...

Fit for Purpose Framework: как понять, чего хочет клиент

В этом выпуске подкаста Kanban Talks мы обсуждаем один из самых интересных и при этом недооцененных инструментов стратегического маркетинга — Fit for Purpose Framework (F4P). Говорим, почему клиент выбирает именно ваш продукт, как понять его настоящие мотивы, и что можно сделать с этими знаниями в маркетинге и управлении продуктом.
В гостях — Алексей Пименов, Kanban-тренер компании «Neogenda», который делится опытом практического применения F4P и объясняет саму логику подхода.

Что такое F4P и зачем он нужен

Fit for Purpose Framework (F4P) — это инструмент стратегического маркетинга, который помогает понять, почему клиенты выбирают именно ваш продукт или сервис. Его основная задача — выявить соответствие между ожиданиями клиента и тем, что вы предлагаете. Иными словами, насколько вы «подходите по назначению».
Большинство традиционных инструментов маркетинга концентрируются на сегментации: демографии, географии, потребительских привычках. F4P предлагает другой подход — он фокусируется на поводе выбора и на перспективе клиента, а не только на продукте. Это позволяет по-новому взглянуть на продуктовую стратегию и выделить те метрики, которые реально важны для пользователя.

Основные компоненты F4P

F4P делит пользовательские метрики на четыре типа:
  1. Fitness Criteria (Критерии соответствия). Это то, насколько продукт соответствует ожиданиям клиента. Например, скорость доставки, простота интерфейса или надежность сервиса. Самый главный блок — именно здесь определяется, удовлетворен ли клиент.
  2. Health Indicators (Индикаторы здоровья). Они отражают общее состояние бизнеса, но не всегда напрямую влияют на выбор клиента. Например, маржинальность или производительность системы.
  3. Improvement Drivers (Факторы улучшения). Метрики, за которыми следят, чтобы понимать, как и куда расти. Часто сюда относят OKR — цели развития и трансформации, которые пока не влияют напрямую на принятие решений клиентов.
  4. Vanity Metrics (Показушные метрики). То, что выглядит красиво на презентациях, но не приносит реальной пользы: лайки, клики, трафик без конверсии и т.п.
F4P-фреймворк помогает отфильтровать важные метрики от второстепенных и сосредоточиться на том, что действительно влияет на выбор клиента.

Почему важно знать, в каком сегменте метрика?

Потому что это меняет фокус:
  • Если вы строите стратегию на Health Indicators, но теряете клиентов — вы не туда смотрите.
  • Если все KPI сосредоточены на Improvement Drivers, но не проверяются по Fitness Criteria — вы «улучшаете» не то, что важно клиенту.
  • Если вы живёте по Vanity Metrics — вы просто рисуете красивые дашборды без смысла.
«Самое страшное — когда ни у одного менеджера в компании KPI не стоит на критерии соответствия. Это значит, что никто не отвечает за соответствие клиента. А это же вообще дичь».

Применение на практике

Первый и самый простой шаг — использование F4P-карточек (Fit for Purpose Cards). Это шаблонные опросники, которые можно использовать для сбора обратной связи. В них клиенты указывают, что именно они ценят в продукте и как оценивают его соответствие ожиданиям.
Многие начинают именно с карточек, потому что это быстрый способ получить информацию из первых рук. Важно понимать, что карточки работают не только с внешними клиентами, но и с внутренними — сотрудниками.
Пример: кейс Антона Манина, где он применял F4P-карточки при работе с командой в Сбербанке. Люди, которые не находят соответствия между своими целями и работой, просто уходят — карточки позволяют выявлять эти несостыковки заранее.
Также стоит ознакомиться с официальной инфографикой фреймворка — она уже переведена на русский и довольно наглядна.

Проблемы с метриками и KPI

Частая ошибка в бизнесе — размещение KPI в зонах, которые не связаны с клиентскими критериями. Например, KPI часто настраиваются на Health Indicators или Improvement Drivers, а не на Fitness Criteria, что приводит к искажению фокуса: менеджеры улучшают то, что не важно клиенту.
Такой дисбаланс может привести к тому, что бизнес оптимизирует процессы и улучшает цифры, но не становится ближе к пользователю. Правильная постановка KPI — это еще и вопрос честности по отношению к клиенту и к себе.

Как рассказать об этом коллегам

Если вы хотите объяснить фреймворк команде, можно использовать короткую формулировку:
F4P — это способ понять, почему клиент выбирает нас, а не конкурентов. Это инструмент, который позволяет уверенно ответить на вопрос: соответствуем ли мы назначению клиента?
F4P — не замена базовым знаниям в продуктовом управлении, а дополнение. Он отлично сочетается с такими практиками, как CGM, кастдев, дизайн-спринты, Lean Startup и прочими.

C чего начать использовать F4P

Если вы только начинаете:
  • Почитайте книгу. Она написана Алексеем Жегловым и Дэвидом Андерсоном. Отличный старт.
  • Изучите официальную инфографику — она переведена на русский язык и подробно объясняет фреймворк.
  • Попробуйте F4P-карточки (опросники). Самый простой и действенный способ начать. Они помогают понять: почему клиент выбрал именно вас? что для него важно? как он бы сравнивал вас с альтернативами?
«Я сам начинал именно с карточек. Это даёт много инсайтов — буквально с первых ответов».

Где изучить подробнее

Книга «Fit for Purpose» от Дэвида Андерсона и Алексея Жеглова — базовый источник, где пошагово объясняется, как работает фреймворк. Обучение тоже есть, но оно больше для тех, кто не любит читать или хочет живые кейсы с локального рынка. Примеры в книге порой могут показаться непонятными, особенно если вы не знакомы с реалиями западных рынков — просто гуглите дополнительные контексты.

А есть ли российские примеры?

Да. Есть кейс Антона Монина, применявшего F4P в Сбербанке. Он же рассказывал об использовании F4P-карточек при работе с сотрудниками — как способ понять, почему человек остается или уходит.
Такие примеры крайне нужны. Алексей предложил отличную идею: собрать примеры использования F4P на нашем рынке, чтобы комьюнити росло и росла применимость инструмента в повседневной работе.

Выгоды использования F4P

  • Лучшее понимание клиента: почему он выбрал вас, что для него важно, где вы не соответствуете.
  • Более точная сегментация: на основе поведенческих и мотивационных характеристик.
  • Улучшение продуктов: через фокус на нужных метриках.
  • Прозрачность в команде: одинаковое понимание целей у всех участников.
И в целом — это инструмент здравого смысла, который позволяет смотреть на старые данные по-новому и находить в них неочевидные решения.
]]> Масштабируемый канбан в Казахстане: как Agile-подходы спасают от корпоративного хаоса http://neogenda.ru/blog/1rakpay5c1-masshtabiruemii-kanban-v-kazahstane-kak http://neogenda.ru/blog/1rakpay5c1-masshtabiruemii-kanban-v-kazahstane-kak?amp=true Mon, 28 Apr 2025 11:53:00 +0300 Источник: Kanban Podcast Гость выпуска: Даулет Нигметов, Agile Delivery Manager и управляющий партнер Agile-школы The4School....

Масштабируемый канбан в Казахстане: как Agile-подходы спасают от корпоративного хаоса

Гость выпуска: Даулет Нигметов, Agile Delivery Manager и управляющий партнер Agile-школы The4School.
Тема: Реальный кейс масштабирования Канбан-метода в казахстанской компании, название которой, увы, под NDA. Но суть — куда важнее названия.

Кто такой Даулет?

Даулет — человек с данными в крови. Начинал карьеру как аналитик: Excel, Power BI, цифры, графики, всё строго по делу. Потом перешёл в проектный офис, где впервые столкнулся с Agile-подходами. Там и случился первый контакт со Scrum и Kanban. С тех пор Даулет не просто в теме — он прокладывает путь другим: помогал трансформировать команды и целые организации, работал как внутри компаний, так и в консалтинге, а теперь развивает Agile-экспертизу на рынке Казахстана через The4School.

Кейс: масштабирование Канбан-метода

Исходная точка:
Компания уже «варилась» в Agile — Scrum-фреймворки были внедрены, Agile-майндсет формировался. Но до полного счастья не хватало прозрачности. Особенно в сервисных функциях, где множество команд обслуживали сразу несколько внутренних заказчиков.
Главная боль:
— Где моя задача?
— Кто за это отвечает?
— Когда мы это получим?
Знакомо, правда? Не хватало общей картины. Бизнес жаловался на скорость, команды — на перегруз, а все вместе — на непрозрачность. Было понятно: нужно не просто «внедрить Канбан в команду», а выйти на уровень масштабирования процессов между несколькими функциями.

Что послужило триггером?

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

Почему не SAFe?

Логичный вопрос — если масштабы растут, может пора переходить на SAFe? Даулет объясняет, почему нет:
  • Команды были не «фичевые», а сервисные. То есть они не создавали продукты, а выполняли запросы от бизнеса. Поэтому сложно было выстроить value stream’ы под одного пользователя или направление.
  • Дорого и долго. Полноценная SAFe-трансформация требует подготовленных людей (SPC, RTE, скрам-мастера), долгой подготовки и бюджета. А бизнес хотел изменений уже вчера.
  • Не тот тип задач. SAFe хорош для продуктовой разработки. Здесь был постоянный поток задач от разных заказчиков.

Рассматривали ли другие фреймворки?

Да. В ход пошли все масштабируемые фреймворки: LeSS, Nexus и так далее. Но у каждого из них — свои ограничения. Например, LeSS хорош, если у команд есть высокая автономия, чего здесь не было: корпоративная структура, вертикальные связи, кросс-функциональные зависимости — всё как положено в большой организации.
Так родилась идея собственного масштабируемого решения на базе Канбан.

Канбан как связующее звено

Когда мы начали настраивать Канбан для команд, стало понятно: нужно не просто доску нарисовать, а выстроить рабочую систему. Тут и появился ключевой инструмент — STATIK (Systems Thinking Approach To Introducing Kanban). Именно с его помощью мы:
  • анализировали контекст каждой команды;
  • помогали сформулировать ожидания и потребности;
  • строили рабочий процесс, основанный на реальных потоках работы;
  • задавали правила, лимиты, роли, встречи, и все остальные важные аспекты.
Короче говоря, не просто «перетащи карточку», а цельная система работы.
Каждая команда получила свой канбан уровня ML2 — командного уровня зрелости (в терминах Kanban Maturity Model). У них появились внутренние каденции, расписание ретро, правила взаимодействия. Всё это — не «по принуждению», а в формате помощи и развития.

Как связать команды, если доски разные?

Вот тут началось веселое. Очевидное решение — просто «отразить» задачу между досками. То есть одна команда создала задачу, другая ее видит у себя. Это называется reflection.
Но на практике — сложно:
  • У всех разный workflow.
  • Кто-то привык работать через пять этапов, у кого-то их десять.
  • У каждой команды своя специфика, свои смыслы.
Если всё унифицировать до «To Do – In Progress – Done», то получится мёртвая доска, которая не несет ценности. Поэтому мы отказались от прямой синхронизации досок.

Вместо этого — материнская доска

Всё взаимодействие пошло через одну основную доску, которая жила в Jira Service Desk. Это и был тот самый «клей», скрепляющий всю систему. Команды продолжали работать в своих привычных пространствах, но данные с их досок агрегировались и отображались на материнской доске.
Что это дало?
  • Прозрачность на всех уровнях.
  • Возможность не дергать команды по статусу задач.
  • Контроль за всем процессом, включая ожидания, задержки, узкие места.

А как же системное внедрение?

Да, STATIK помог нам не просто «натянуть Канбан», а встроить его в реальную жизнь команд. Мы провели анализ запросов, построили карты потоков, определили источники входящей работы, ограничили WIP (Work In Progress), сформировали каденции и роли.
Причём всё это не выглядело как «доска на стене», а было полноценной управленческой системой:
  • понятной;
  • прозрачной;
  • адаптивной.
Каждая команда видела смысл в том, что делает, и как она связана с другими.

Что дальше?

Ну, во-первых, у нас появилась реальная метрика производительности, о которой расскажу в следующей части. Но уже на этом этапе бизнес увидел:
  • сколько времени реально проходит от запроса до результата;
  • где происходят задержки;
  • какие команды загружены больше других;
  • и самое главное — что вообще происходит без лишних писем и звонков.
И это уже был огромный шаг вперёд.
Если вы когда-то пытались выстроить end-to-end процесс в большой организации — знаете, насколько это может быть больно. Но с правильными подходами и немного упрямства — реально всё собрать в систему, которая не просто работает, а помогает всем участникам.

Лидерство, культура и зрелость: завершаем настройку масштабируемого Канбана

Раньше в команде всё было «по старинке»: задачи попадали к исполнителям сверху, кто-то просто «впихивал» их в работу, не особо задумываясь о потоке и приоритетах. Но после внедрения Канбана всё поменялось. Люди начали брать задачи осознанно, вытягивать их по мере готовности, а не ждать, пока кто-то спустит сверху. Это был важный знак зрелости и… да, лидерства.
Как говорил один из участников команды:
«Я не начну задачу, пока мне её реально не поставят. Не впихну сам — вытяну, когда всё будет готово».
Такой подход показал, что лидерство проявляется не в тайтле, а в поведении. Даже аналитики и разработчики стали управлять своим рабочим процессом — видеть цель, контролировать загрузку и принимать решения. Именно это и стало переломным моментом — не просто внедрение инструментов, а изменение культуры на всех уровнях.
К слову о культуре — это тоже важный элемент. Компания изначально декларировала ценности вроде Agility и клиентоцентричности, но они оставались на уровне «плакатов на стенах». После внедрения Канбана всё стало иначе. Ценности стали неотъемлемой частью принятия решений, ребята реально начали ими жить. Канбан помог встроить ценности в процессы — и это дало мощный буст для всей организации.
«Ценности — это не лозунги, это курсоры в принятии решений», — отметил Даулет.
Дальше — больше: благодаря практике визуализации, ограничению WIP, метрикам и потоку задач в JIRA, команды начали не просто видеть, где что застряло, но и улучшать процессы эволюционно. А ведь это и есть суть Канбана — двигаться от текущего состояния к лучшему без революций.

Финальный аккорд

Этот кейс — не просто история про JIRA, доски и метрики. Это история про то, как через настройку сервиса, развитие культуры и осознанное лидерство можно не только навести порядок в рабочих процессах, но и создать команду, которая реально тащит.
Хочется верить, что кейс станет полезным тем, кто только ищет свой путь в масштабировании Канбан. А если вы уже на этом пути — не останавливайтесь. Потому что как сказал Даулет:
«Самое худшее — это остановиться и сказать: у нас Канбан. Всё. Приехали».
Нет. Канбан — это путь. И он продолжается.
]]> Нематериальная мотивация сотрудников: 5 способов http://neogenda.ru/blog/ifv8gz1hk1-nematerialnaya-motivatsiya-sotrudnikov-5 http://neogenda.ru/blog/ifv8gz1hk1-nematerialnaya-motivatsiya-sotrudnikov-5?amp=true Tue, 29 Apr 2025 12:55:00 +0300 Артур Нек Почему материальная мотивация не работает и что действительно вдохновляет людей достигать большего?

Нематериальная мотивация сотрудников: 5 способов

Почему материальная мотивация не работает и что действительно вдохновляет людей достигать большего?
Многие считают, что чем больше делает сотрудник, тем больше ему нужно платить. Однако в какой-то момент люди достигают своего «порога удовлетворенности» — уровня дохода, при котором дополнительное повышение зарплаты уже не приводит к росту мотивации.
Этот эффект можно сравнить с ситуацией студента, которому не хватает денег на лапшу быстрого приготовления. Как только он заработал нужную сумму, его потребности удовлетворены. На следующем этапе он хочет ходить в рестораны — и только тогда появляется новая мотивация для роста.
Если у человека нет внутренней потребности сделать большой скачок, никакое денежное вознаграждение его не подтолкнет. При этом для компании материальная мотивация часто оказывается не столько стимулом, сколько инструментом оптимизации фонда оплаты труда.
Давайте разберем, какие способы нематериальной мотивации действительно работают.

Мотивация №1: Понимание цели

Первое, что вдохновляет людей и заставляет их расти, — это осознание цели.
  • Для чего мы делаем то, что делаем?
  • Куда движется компания?
  • Кому и как мы помогаем?
  • Какая глобальная задача стоит за повседневными задачами?
Когда человек видит смысл в своей работе, у него появляется энергия. Если вам сложно заниматься рутинными задачами, спросите себя: «Понимаю ли я, ради чего это делаю?»
Руководителям стоит объяснять команде, какие приоритеты сейчас важны, и давать возможность влиять на путь к этим целям. Тогда сотрудники начнут работать гораздо эффективнее.

Мотивация №2: Подчеркивайте мастерство человека

Дайте сотрудникам возможность проявлять и развивать свое мастерство.
  • Поручайте сложные задачи, требующие профессиональных навыков.
  • Внедряйте систему грейдов, по которой человек может расти как специалист.
  • Развивайте корпоративное обучение.
Обучение не только поддерживает и оттачивает навыки сотрудников, но и делает их более вовлеченными. Чем выше уровень их компетентности, тем сильнее их приверженность целям компании.
Не стоит бояться, что обученный сотрудник уйдет. Если у него есть возможность расти внутри компании, риск ухода минимален.
Важно обучать не только профессиональным навыкам, но и инструментам личной эффективности. Когда человек видит, что компания в него инвестирует, он становится увереннее, а качество его жизни улучшается.

Мотивация №3: Автономность принятия решения

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

Мотивация №4: Привилегии

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

Мотивация №5: Мероприятия празднования успеха компании

Важно отмечать достижения компании и сотрудников. Это может быть:
  • Корпоративное мероприятие (поездка, поход, вечеринка).
  • Публичное признание успехов.
  • Введение традиций празднования.
Главное — дать понять, почему проходит мероприятие: мы достигли значимого результата, который поможет нам расти дальше. Подобные события формируют культуру, в которой стремление к цели воспринимается как ценность.
Подчеркивайте успехи сотрудников. Это повышает их уверенность и мотивацию двигаться дальше.
Если вы хотите вывести управление в вашей компании на новый уровень, специалисты Neogenda помогут в этом. Мы работаем с крупнейшими компаниями: Tinkoff, Яндекс, Авито, Сбер, Билайн, и уже обучили более 5 000 сотрудников. Наши эксперты подберут для вас индивидуальные решения, основанные на реальном управленческом опыте и современных практиках.
Запишитесь на бесплатную консультацию в Zoom, чтобы найти способы сделать вашу команду еще эффективнее.
]]> Груминг в IT: как улучшить управление разработкой через регулярное уточнение бэклога http://neogenda.ru/blog/4ymp4pg2d1-gruming-v-it-kak-uluchshit-upravlenie-ra http://neogenda.ru/blog/4ymp4pg2d1-gruming-v-it-kak-uluchshit-upravlenie-ra?amp=true Wed, 30 Apr 2025 15:31:00 +0300 Артур Нек Груминг бэклога, или Product Backlog Refinement, стал важной частью работы команд. Владельцам продукта этот инструмент...

Груминг в IT: как улучшить управление разработкой через регулярное уточнение бэклога

Груминг бэклога, или Product Backlog Refinement, стал важной частью работы команд. Владельцам продукта этот инструмент позволяет видеть полную картину и уверенно расставлять приоритеты. А разработчикам — заранее понять, что именно предстоит создать, на каких условиях и зачем.
В статье расскажем, что такое груминг бэклога, чем отличается от других практик, кто в нем участвует и как проводить его эффективно.

Что такое груминг бэклога

Груминг бэклога — это регулярный процесс, благодаря которому обновляют, уточняют и расставляют по значимости задачи в бэклоге продукта.
Во время груминга команда может дополнять список деталями, менять элементы, объединять или удалять. Это делает бэклог гибким инструментом, а не архивом идей. В спринтах становится меньше неопределенности.
Обычно в груминге бэклога участвует:
  • владелец продукта (Product Owner) — задает направление, уточняет ценность задач, отвечает за определение приоритетов;
  • команда разработчиков — оценивает технические сложности, выясняет детали, предлагает улучшения;
  • Scrum Master — при необходимости помогает организовать процесс и поддерживать фокус на целях сессии.
По ситуации могут приглашать бизнес-аналитиков, дизайнеров, тестировщиков, если это помогает прояснить требования к задачам.

Чем груминг в Скраме отличается от планирования спринта и ретроспективы

Иногда груминг путают с планированием спринта и ретроспективой. Однако у каждого из этих процессов своя цель, фокус и условия проведения.

Для чего нужен груминг в Agile

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

Актуализация бэклога продукта

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

Приоритизация задач в бэклоге

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

Четкое описание требований

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

Оценка сложности задач

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

Подготовка к планированию спринта

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

Повышение прозрачности и вовлеченности команды

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

Адаптация к изменениям

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

Как проводить груминг бэклога: пошаговое руководство

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

1. Подготовка к сессии

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

2. Определение приоритетов задач бэклога

Важно определить приоритеты — разобраться, какие задачи наиболее важны для достижения бизнес-целей. Для этого можно использовать различные фреймворки:
  • MoSCoW — помогает разделить задачи на обязательные (Must), желательные (Should), возможные (Could) и ненужные (Won’t).
  • RICE — оценивает задачи по четырем параметрам: охват, влияние, уверенность и усилия.
  • WSJF (Weighted Shortest Job First) — помогает выбирать задачи с наибольшей ценностью и минимальными затратами.
  • Модель Кано — оценивает эмоциональное восприятие пользователей, что особенно полезно для улучшения опыта взаимодействия.

3. Уточнение требований

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

4. Определить критерии приемки и критерии готовности

Чтобы правильно выполнить задачи, важно установить:
  • критерии приемки (Acceptance Criteria) — это условия, при которых задача считается завершенной и выполненной корректно;
  • критерии готовности (Definition of Done) — четкие правила, которые определяют, когда задачу можно передавать в работу, тестировать или внедрять.

5. Оценка сложности задач

Оценить сложность задач можно с помощью Story points —разные единицы сложности задачи. Например, «Размер футболок» — задачи получают размер (S, M, L, XL). Это помогает команде быстрее оценить их трудоемкость.
Оценка сложности помогает владельцу продукта и команде лучше понять, сколько времени и ресурсов потребует каждая задача, и в результате — лучше планировать спринт.

6. Декомпозиция крупных задач

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

7. Документирование результатов

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

Какие инструменты помогут эффективно проводить груминг бэклога

Для продуктивного груминга важно не только организовать процесс, но и использовать подходящие инструменты. Выбор рабочих и удобных решений помогает команде сохранять контекст, вести прозрачное планирование и быстрее уточнять требования.
Среди популярных и доступных в России инструментов можно выделить:
  • Pyrus — это платформа для управления задачами и автоматизации бизнес-процессов, разработанная в РФ. Подходит для команд, которым важна простота интерфейса и возможность адаптировать рабочие процессы без программирования. Pyrus позволяет организовать груминг как часть общего рабочего процесса: от постановки задач до их уточнения и согласования между участниками.
  • Weeek — российский инструмент для управления задачами и проектами. Удобен для визуализации бэклога, распределения приоритетов, совместной работы и интеграции с другими сервисами. Подходит для небольших и средних команд.
  • Kaiten — платформа, вдохновленная Канбан Методом. Поддерживает гибкие настройки досок, бэклога, таймлайнов и аналитики. Отлично подходит для продуктовых команд, особенно если важна визуализация потока задач и возможность управлять крупными фичами.
Выбор зависит от масштабов команды, структуры проекта и уровня автоматизации процессов. Главное — обеспечить доступность платформы, удобство для участников и возможность совместной работы.

Что в итоге

Грамотный груминг (скрам) — что это? Ответ прост: процесс, который помогает ставить четкие и понятные задачи, улучшать взаимодействие внутри команды, повышать прозрачность работы и ускорять выполнения спринтов.
Если вы хотите внедрить подобные практики в систему управления и повысить эффективность вашего бизнеса, вам поможет консалтинговая компания Neogenda. Мы уже разработали комплексные решения для Сбер, Яндекс, Тинькофф, X5 Group и Точка — оптимизировали процессы и внедрили современные подходы в стратегический менеджмент. Начните с бесплатной консультации и получите рекомендации от практиков, чтобы повысить эффективность вашей работы.
]]> Как применять Jobs To Be Done – эффективный подход к разработке успешных продуктов http://neogenda.ru/blog/sladfxpr31-kak-primenyat-jobs-to-be-done-effektivni http://neogenda.ru/blog/sladfxpr31-kak-primenyat-jobs-to-be-done-effektivni?amp=true Mon, 05 May 2025 15:35:00 +0300 Артур Нек Иногда бывает, что компания идеально продумала продукт, потратила много денег на разработку и маркетинг, а...

Как применять Jobs To Be Done – эффективный подход к разработке успешных продуктов

Иногда бывает, что компания идеально продумала продукт, потратила много денег на разработку и маркетинг, а в итоге столкнулась с низким спросом и плохими отзывами. Главная причина — не плохой продукт, а несоответствие между тем, что создает бизнес, и тем, что действительно нужно пользователям.
Все потому, что традиционные методы исследования рынка и сегментации не отражают аудиторию полностью. Не решают конкретных «болей» клиента и не учитывают контекст использования.
Чтобы делать востребованный и удобный продукт — стоит пользоваться методом Jobs To Be Done (JTBD). Что это за метод и как его использовать — рассказываем в статье.

Что такое Jobs To Be Done

Jobs To Be Done — это методология, которая помогает понять истинные причины покупки продуктов или услуг.
Суть JTBD проста: человек покупает продукт не ради самого продукта, а чтобы выполнить определенную «работу». Эта «работа» — задача, которую потребитель пытается решить в своей жизни. Иногда эта задача очевидна, например, «мне нужно быстро перекусить», а иногда не осознается самим человеком. Например, «я хочу чувствовать себя частью определенной социальной группы».
Подход JTBD отлично иллюстрирует цитата Теодора Левитта: «Людям не нужна дрель, им нужно отверстие в стене». Это значит, что производители дрелей конкурируют не только с другими производителями дрелей, но и с любыми альтернативными способами создания отверстий. А если копнуть глубже, то и с другими способами крепления предметов. Ведь людям нужна не сама дырка в стене, а возможность что-то повесить на эту стену.
И каждая из этих «работ» имеет свой контекст, свои критерии успеха и свои альтернативные решения.

Структура модели JTBD

Модель JTBD состоит из нескольких взаимосвязанных элементов:
  • «Работа» — задача, которую пользователь хочет выполнить.
  • Контекст, в котором возникает необходимость выполнить работу.
  • Мотивация пользователя — почему он хочет выполнить работу.
  • Ожидаемый результат — что пользователь стремится достичь.
  • Ограничения и препятствия, которые мешают выполнению работы.
  • Критерии оценки успешности выполнения работы.
Каждый элемент дополняет друг друга и помогает лучше продумать продукт, который действительно решает проблему человека.
В модели JTBD «работа» существует в трех измерениях, которые влияют на выбор продукта:
  • Функциональное измерение — практическая задача, которую нужно выполнить. Например, «перевезти вещи из точки А в точку Б» или «получить информацию о погоде на завтра».
  • Социальное измерение — как продукт влияет на восприятие человека другими людьми. Например, «выглядеть профессионально на деловой встрече» или «показать друзьям, что я разбираюсь в современных технологиях».
  • Эмоциональное измерение — как человек хочет себя чувствовать при использовании продукта. Например, «чувствовать уверенность при публичном выступлении» или «испытывать спокойствие, потому что файлы надежно защищены».
Для наглядности рассмотрим модель JTBD на примере покупки кофе в кофейне. Кажется, что «работа» здесь простая — человек хочет выпить кофе. Но на самом деле товар выполняет больше «работ».
Функциональная работа:
  • Получить заряд энергии и бодрости на утро.
  • Утолить жажду напитком определенного вкуса.
Социальная работа:
  • Найти место для деловой встречи в неформальной обстановке.
  • Быть частью сообщества кофеманов.
Эмоциональная работа:
  • Порадовать себя приятным ритуалом.
  • Создать себе уютную атмосферу вне дома или офиса.
Одна и та же кофейня может выполнять разные «работы» для разных людей. Понимание этих различий помогает создать более точное позиционирование и улучшить клиентский опыт.
При этом один и тот же человек может нанимать разные продукты для одной и той же работы в зависимости от ситуации.
Например при желании попить кофе, человек может:
  • В будни, когда он спешит на работу, использовать ближайшую кофейню с удобной функцией предзаказа через приложение.
  • В выходные, когда у него есть время, посидеть в кофейне и поговорить с друзьями.
  • Во время путешествия выбрать местную кофейню, чтобы попробовать что-то новое.
Такая сегментация помогает определить, когда и почему пользователи предпочитают ваш продукт альтернативам. И как сделать ваше предложение более привлекательным в конкретных ситуациях.
Допустим, вы разрабатываете приложение для управления задачами и понимаете, что основная «работа» ваших пользователей — быстро записать идеи и задачи и ничего не забыть. Тогда ваш приоритет — создать максимально быстрый и удобный интерфейс ввода задач и не распыляться на расширенные функции для организации и категоризации этих задач.

Шаблоны Job Story и User Story

Чтобы перейти от абстрактной модели JTBD к конкретным требованиям продукта, удобно использовать два формата — Job Story и User Story. Оба помогают определить «работу», которую пользователь хочет выполнить, в каком контексте и зачем.
Job Story. Фиксирует момент возникновения потребности, мотивацию пользователя и ожидаемый от продукта результат. Формат выглядит так:
Когда я [ситуация], я хочу [мотивация], чтобы [ожидаемый результат].
  • «Когда я…» — описывает точный контекст или триггер: время, место, предшествующие событию.
  • «я хочу…» — формулирует саму мотивацию, то, какую работу пользователь намерен выполнить.
  • «чтобы…» — указывает на критерии успеха: каким должен быть итог, чтобы пользователь остался доволен.
Например, у кофейни может быть такой Job Story: «Когда я спешу на работу утром, хочу быстро оформить предзаказ через приложение и не опоздать на встречу».
User Story. Делает акцент на роли пользователя, его желаемом действии и бизнес-ценности. Формат выглядит так:
Как [роль пользователя], я хочу [действие], чтобы [цель/выгода].
  • «Как…» — указывает на персону или сегмент, для которого вы создаете решение.
  • «я хочу…» — конкретное действие или функцию, которую пользователь хочет совершить.
  • «чтобы…» — выгода или польза, которую пользователь получит от выполнения действия.
Пример для таск-менеджера: «Как проектный менеджер, я хочу мгновенно добавлять новые задачи голосом, не отвлекаться от текущей работы и фиксировать идеи на ходу».
Job Story нужно использовать для понимания реального контекста, в котором у человека появляется потребность использовать продукт.
Формат Что помогает сделать Когда использовать
Job Story Зафиксировать контекст, триггер и мотивацию пользователя
Выявить боли и ограничения
Определить критерии успешного результата
  • Когда и почему у пользователя возникает «работа»?
  • Какие боли и ограничения нужно снять?
  • Как должен выглядеть идеальный результат?
User Story Четко сформулировать, какую функцию или элемент интерфейса создаем и для кого
Показать ценность фичи и обосновать ее реализацию
Оценить трудозатраты и приоритизировать бэклог
  • Перевести их в конкретные задачи для разработки
  • Уточнить детали функции
  • Связать ее с бизнес‑выгодой

Чем JTBD отличается от других методов

JTBD vs Персоны. JTBD помогает понять поведение пользователей намного лучше, чем традиционные демографические данные.
Вот в чем дело: персоны основаны на предположении, что люди с похожими демографическими характеристиками имеют похожие потребности. Но это не всегда так. Например, 35-летний программист из Москвы и 35-летний программист из Санкт-Петербурга могут использовать одно и то же приложение для совершенно разных целей.
JTBD фокусируется не на том, кто эти люди, а на том, чего они пытаются достичь. Это позволяет выявить глубинные мотивации, которые часто скрыты за демографическими показателями. Вместо подхода «наш продукт предназначен для женщин 25–34 лет с высшим образованием и доходом выше среднего», JTBD позволяет сказать «наш продукт помогает людям, которые хотят быстро приготовить здоровый ужин после долгого рабочего дня для семьи».
Такой подход показывает, что два совершенно разных по демографическим показателям человека могут покупать один и тот же товар или услугу для выполнения одной и той же «работы». И наоборот, два очень похожих по демографии человека могут использовать один продукт для совершенно разных целей.
JTBD vs. Customer Development. Customer Development (CustDev) — методология, которая помогает проверять гипотезы о пользователях и рынке через непосредственное общение с потенциальными клиентами. CustDev отвечает на вопрос «есть ли проблема, которую мы пытаемся решить, и готовы ли люди платить за ее решение?».
JTBD углубляется в контекст: «какую именно работу человек пытается выполнить и при каких обстоятельствах?» То есть JTBD исследует мотивацию и контекст использования продукта. А кастдев помогает найти проблему.
JTBD vs. feature-based approach. При разработке продукта команды часто начинают с вопроса: «Какие функции нам нужно добавить в продукт?» В итоге функции в приложение добавляют, но необходимости в них изначально не было.
Анализ по JTBD начинается с вопроса: «Какую работу пользователь пытается выполнить?» И только после ответа на вопрос команда определяет, какие функции действительно нужны для выполнения работы.
Например, вместо «давайте добавим интеграцию с календарем в наше приложение для заметок», подход JTBD предлагает сначала понять: «пользователи хотят организовать свои задачи по времени» и только потом решать, какая функция лучше всего поможет в этом.
Сравнение Фокус альтернативного метода Фокус JTBD Главное отличие
Персоны Демографические характеристики (возраст, пол, локация и т. д.) Цели и задачи, которые пользователь пытается решить Выявление глубинных мотиваций вместо демографии
Customer Development Есть ли проблема и готовы ли платить за ее решение Контекст и мотивация выполнения конкретной «работы» JTBD погружается в обстоятельства и триггеры выбора
Feature‑based approach Какие функции добавить в продукт Какая «работа» стоит за потребностью пользователя Сначала понимание работы → потом подбор необходимых функций

Подходы к методу JTBD

В методологии Jobs To Be Done есть 2 подхода, которые по-разному интерпретируют концепцию «работы». Jobs As Progress и Jobs As Activities.

Jobs As Progress

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

Jobs As Activities

Подход концентрируется на том, как продукты помогают людям достигать прогресса в жизни — переходить из текущего состояния в желаемое, лучшее состояние.
Здесь внимание уделяется:
  • Конкретным действиям, которые человек хочет выполнить.
  • Шагам и процессам, через которые он проходит.
  • Критериям успешного выполнения задачи.
Если вернуться к примеру с образовательными курсами, то с точки зрения Jobs As Activities человек хочет «быстро найти релевантную информацию по теме» или «эффективно практиковать новые навыки».
Дополнительно можно выделить еще одну модель — четырех сил. Эта модель включает:
  • Толкающие силы — проблемы и боли, которые «выталкивают» человека из текущей ситуации и заставляют искать новое решение. Например, существующий продукт стал неудобным, дорогим или устаревшим.
  • Притягивающие силы — преимущества и возможности, которые «притягивают» человека к новому решению. Например, новый продукт обещает сэкономить время или гарантирует лучший результат.
  • Тревога от нового — опасения и риски, связанные с переходом на новое решение.
  • Сила привычки — комфорт и безопасность, связанные с привычкой использовать старый продукт.
Чтобы человек сменил продукт, сумма толкающих и притягивающих сил должна превышать сумму тревоги и привычки.
Конкретный подход стоит выбирать в зависимости от типа продукта и бизнес-задач. Вот несколько рекомендаций:
Jobs As Progress подходит для новых продуктов. Он поможет понять мотивацию и жизненные цели потенциальных пользователей.
Jobs As Activities подходит для улучшения существующих продуктов. Он дает конкретные инсайты о том, как люди используют продукт сейчас и что можно улучшить.
Модель четырех сил стоит выбирать при разработке продуктов для B2B-сегмента и работе с конкурентами — корпоративные и постоянные клиенты особенно чувствительны к рискам и не любят менять привычки.
Для всех подходов дополнительно можно применять Job mapping. Этот фреймворк помогает понять, какую «работу» выполняет пользователь, выявить проблемы места и точки роста на каждом шаге.
Основные этапы Job Mapping:
  • Старт. Триггер, запускающий «работу»: внешнее событие или внутреннее желание.
  • Подготовка. Сбор информации и ресурсов для начала работы.
  • Исполнение. Непосредственное выполнение ключевой задачи.
  • Завершение. Достижение результата работы и ее оформление.
  • Оценка результата. Субъективная и объективная оценка: насколько «работа» была успешна.
Пример Job Mapping для кофейни с предзаказом:
Этап Описание действия Возможные улучшения
Старт Открыть приложение и решить заказать кофе Разместить кнопку «Предзаказ» на главном экране
Подготовка Выбрать напиток, объём, добавить сироп или топпинг Сохранение прошлых заказов, быстрые списки «Любимые»
Исполнение (заказ) Оплатить и подтвердить время и место самовывоза Интеграция Apple/Google Pay
Завершение (получение) Забрать кофе в указанное время Отображение статуса в реальном времени, QR‑код для сканирования
Оценка результата Оценить вкус, скорость и удобство заказа Короткий опрос в 2 клика, система бонусов за отзыв

Виды конкуренции в контексте JTBD

Модель JTBD показывает, что у компаний есть 3 вида конкуренции:
  1. Прямая — привычное соперничество с продуктами, которые решают ту же проблему схожим способом. Например, для Spotify прямыми конкурентами являются Яндекс Музыка, YouTube Music и другие музыкальные стриминговые сервисы.
  2. Вторичная конкуренция — продукты, которые решают ту же проблему, но другим способом. Для Spotify это может быть радио.
  3. Непрямая конкуренция — все остальные способы выполнить ту же «работу», включая полностью другие категории продуктов. Например, для Spotify непрямыми конкурентами могут быть аудиокниги, видео с белым шумом на YouTube, подкасты или даже открытое окно.
Получается, что конкуренты — не всегда те, о ком думает компания. Люди не мыслят «мне нужен музыкальный стриминговый сервис». Они думают: «мне нужно что-то, что поможет мне сосредоточиться во время работы» или «мне нужно что-то для создания приятной атмосферы на вечеринке».
Выделять конкурентов 3 видов стоит для того, чтобы работать на опережение и заранее разрабатывать продукт, который понадобится целевой аудитории в будущем. Чтобы это продумать, нужно:
  • Определить, какие «работы» ваш продукт выполняет для пользователей.
  • Выяснить, какие альтернативные решения (включая непрямых конкурентов) они используют.
  • Понять, по каким критериям пользователи оценивают успешность выполнения «работы».
  • Создать продукт, который превосходит продукт всех конкурентов по ключевым критериям.
Например, мессенджер Telegram таким способом обошел прямых и непрямых конкурентов. Он создал среду, где можно общаться текстом и голосом, делать видеозвонки, принимать платежи и создавать каналы, а еще и создавать мини-приложения. Так мессенджер закрывает потребность использовать разные приложения для всех этих задач и отстраивается от большинства конкурентов.

Как выявлять настоящие потребности аудитории

Проводить интервью с пользователями. JTBD-интервью отличаются от обычных пользовательских интервью. Их главная особенность — фокус на конкретном опыте использования продукта и обстоятельствах принятия решения, а не на общих мнениях или предпочтениях.
JTBD-интервью можно проводить в разных сценариях:
  • Интервью о «переключении» (Switch Interview) — исследует, почему пользователь перешел с одного продукта на другой.
  • Хронологическое интервью — проводит пользователя через весь процесс принятия решения от первого осознания потребности до финального выбора и использования продукта.
  • Контекстное интервью — проводится в той среде, где пользователь обычно взаимодействует с продуктом, чтобы лучше понять контекст использования.
Во время JTBD-интервью важно правильно формулировать вопросы, иначе понять реальную потребность пользователя будет сложно. Вот несколько универсальных вопросов:
  • Что привело вас к покупке этого продукта? Опишите ситуацию, в которой вы поняли, что вам нужно именно это решение.
  • Чего вы пытались достичь, когда искали этот продукт?
  • Какие альтернативы вы рассматривали? Почему выбрали именно этот вариант?
  • Какие сомнения у вас были перед покупкой?
  • Как вы поняли, что продукт справился с вашей задачей? По каким критериям вы оценивали успех?
  • Что бы вы делали, если бы этого продукта не существовало?
Нужно задавать вопросы о конкретных ситуациях и реальном опыте, а не о гипотетических сценариях. Например, вместо «Как бы вы использовали приложение для управления финансами?» лучше спросить «Расскажите о последнем случае, когда вы пытались контролировать свои расходы. Почему вы решили это делать?»
Чтобы лучше понять мотивацию человека, можно использовать технику «5 почему». Суть в том, чтобы последовательно задавать вопрос «почему» несколько раз на каждый новый ответ и углубляться в причины.
На основе собранной информации можно построить карту пути клиента (CJM) и понять, когда пользователь испытывает трудности при выполнении «работы». Например, для финансового приложения это может быть сложность ввода расходов вручную или отсутствие понятной категоризации трат.
Подробнее о CJM читайте в статье: «Сustomer journey map: что это такое, пошаговая инструкция – как составить»

Как приоритизировать работы

Чтобы не распыляться и не тратить время и деньги впустую, задачи нужно приоритизировать. Это ускоряет путь к продукту, который действительно решает проблему пользователей. Помогает не разрабатывать лишних функций и не усложнять карту пути клиента.
Оценивать важность «работ» можно по 3 параметрам (на примере приложения для контроля расходов).
Частота. Как часто пользователи пытаются выполнить «работу»:
  • ежедневно — проверить баланс счета;
  • еженедельно — планировать бюджет на неделю;
  • ежемесячно — анализировать расходы за месяц;
  • ситуативно — принять решение о крупной покупке.
Значимость. Насколько важно для пользователя успешное выполнение «работы»:
  • Критично важно — не допустить просрочки платежа по кредиту;
  • Очень важно — контролировать траты в рамках бюджета;
  • Умеренно важно — разбивать расходы по категориям;
  • Малозначимо — сравнить свои расходы со средними по стране.
Неудовлетворенность. Насколько существующие решения не справляются с этой «работой»
  • Высокая неудовлетворенность — пользователи активно ищут альтернативы;
  • Средняя неудовлетворенность — пользователи справляются, но не очень довольны;
  • Низкая неудовлетворенность — пользователи в целом удовлетворены существующими решениями.
Самая важная работа — с высокой частотой, высокой значимостью и высокой неудовлетворенностью.

Количественные методы приоритизации JTBD через опросы

Чтобы сделать приоритизацию более объективной, можно использовать количественные методы.
Чтобы приоритизировать задачи через опросы, составьте список выявленных «работ» в формате, понятном респондентам. Для каждой «работы» задайте два вопроса:
Насколько важно для вас [выполнение этой работы]? (шкала от 1 до 10)
Насколько вы удовлетворены тем, как существующие решения помогают вам [выполнять эту работу]? (шкала от 1 до 10)
Рассчитайте индекс возможности (Opportunity Score) по формуле:
Индекс возможности = Важность + (Важность — Удовлетворенность)
Эта формула дает больший вес «работам», которые очень важны, но плохо удовлетворены существующими решениями.

Разбираем на примере: как анализировать бизнес по методу JTBD

Разберемся на примере создания мобильного приложения для сервиса грузоперевозок по Москве и МО.

Этап 1. Формируем гипотезы о «работах» пользователей

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

Этап 2. Готовим структуру интервью и подбираем респондентов

Для глубокого понимания потребностей пользователей команда провела интервью, где задавала такой вопрос:
Расскажите о последнем случае, когда вам понадобилось что-то перевезти. Как все происходило с самого начала?
Для исследования были отобраны три группы респондентов:
  • Люди, заказавшие грузоперевозку в последние 3 месяца.
  • Владельцы малого бизнеса, регулярно отправляющие товары.
  • Предприниматели, которые организуют доставку, но еще не используют специальные приложения.
Такая выборка позволила охватить разные сценарии использования и понять разнообразие потребностей.

Этап 3. Проводим исследование и выявляем ключевые «работы»

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

Этап 4. Приоритезируем «работы» и выбираем главные направления

Не все выявленные «работы» одинаково важны. Чтобы правильно распределить ресурсы, команда оценила каждую «работу» по частоте использования, значимости и неудовлетворенности от существующих решений.
Для количественной оценки команда опросила 300+ респондентов, которые оценивали каждую «работу» по 10-балльной шкале по этим параметрам.
В результате анализа приоритетными оказались две «работы»:
  • Для физических лиц: комплексная организация переезда «под ключ».
  • Для бизнеса: надежная доставка товаров клиентам в день заказа.
При этом команда учитывала не только потребности пользователей, но и бизнес-цели компании:
  • соответствие стратегии выхода на рынок;
  • потенциальное влияние на выручку;
  • техническую сложность реализации;
  • возможность создать устойчивое конкурентное преимущество.

Этап 5. Превращаем «работы» в конкретные решения

В случае команды — в функции приложения.
Для «работы» по организации переезда:
  • Пакетное предложение «Переезд под ключ» с возможностью заказать машину, грузчиков и упаковку за один раз.
  • Калькулятор стоимости на основе количества комнат и объема вещей.
  • Возможность назначить менеджера, который будет координировать весь процесс.
  • Чек-лист для подготовки к переезду, чтобы ничего не забыть.
Для «работы» по доставке товаров клиентам:
  • API для интеграции с интернет-магазинами и автоматического создания заказов.
  • Выбор временных слотов доставки в день заказа.
  • Отслеживание курьера на карте в реальном времени.
  • Автоматические уведомления о статусе доставки.
Особое внимание было уделено устранению моментов, которые вызывали наибольший стресс у пользователей:
  • Неопределенность с точным временем прибытия водителя.
  • Сложность оценки подходящего размера машины.
  • Отсутствие информации о местонахождении груза в процессе доставки.
  • Трудности с коммуникацией между заказчиком, водителем и получателем.

Этап 6. Проверяем, как все работает

После запуска продукта команда отслеживала стандартные метрики (количество установок, активных пользователей) и показатели, связанные с выполнением конкретных «работ»:
  • Насколько быстро пользователи проходят путь от возникновения потребности до ее удовлетворения.
  • Процент случаев, когда пользователи выбирают приложение вместо альтернативных решений для выполнения «работы».
  • Уровень стресса и удовлетворенности в процессе и после выполнения «работы».
  • Количество решенных проблем за одно взаимодействие с приложением.
Такой подход помогает сфокусироваться на том, что действительно важно — насколько хорошо продукт решает задачи клиентов.

Что в итоге

  • Jobs To Be Done (JTBD) — методология для разработки востребованных продуктов. Она помогает понять истинные причины покупки продуктов и услуг.
  • Метод фокусируется на выполнении «работы» потребителем, а не на самом продукте.
  • Модель JTBD состоит из «работы», контекста, мотивации, ожидаемого результата, ограничений и критериев оценки успешности.
  • JTBD отличается от других методов вроде персон и Customer Development тем, что фокусируется на глубинных мотивациях и контекстах использования продукта.
  • Есть несколько подходов использования JTBD: Jobs As Progress, Jobs As Activities и модель четырех сил.
  • Для выявления потребностей аудитории используются JTBD-интервью.
  • Приоритизировать «работу» можно качественно и количественно. Качественную приоритизацию проводят на основе частоты, значимости и неудовлетворенности пользователей. Количественную — через опросы и общение с аудиторией.
Если хотите внедрить методику Jobs To Be Done в свою компанию, обратитесь за помощью в Neogenda. Просто запишитесь на бесплатную консультацию, и наши эксперты помогут интегрировать модель в ваш бизнес.
]]> Как рассчитать объем рынка для бизнеса: методика PAM, TAM, SAM, SOM http://neogenda.ru/blog/mj0efmfoe1-kak-rasschitat-obem-rinka-dlya-biznesa-m http://neogenda.ru/blog/mj0efmfoe1-kak-rasschitat-obem-rinka-dlya-biznesa-m?amp=true Mon, 12 May 2025 16:57:00 +0300 Артур Нек Неправильная оценка объема рынка — одна из самых частых причин неудачи стартапов. По данным CB...

Как рассчитать объем рынка для бизнеса: методика PAM, TAM, SAM, SOM

Неправильная оценка объема рынка — одна из самых частых причин неудачи стартапов. По данным CB Insights, около 42% стартапов закрываются из-за неправильной оценки рынков.
Основатели рисуют в воображении огромные рынки и часто принимают рискованные решения: нанимают слишком много сотрудников, тратят большие бюджеты на маркетинг или создают слишком много функций в продукте. А потом реальность наступает и оказывается, что рынок в десять раз меньше, чем они думали.
Чтобы не рисковать и не разбрасываться деньгами, оценивать рынки можно по модели PAM TAM SAM SOM. Этот подход позволяет поэтапно сужать фокус от максимально широкого потенциального рынка до реально достижимой доли, которую компания может получить в ближайшем будущем. В статье рассказываем, как пользоваться моделью.

Зачем оценивать объем рынка

Объем рынка — это общая стоимость всех товаров или услуг, которые были проданы или могут быть проданы в определенной нише за конкретный период времени. По сути, это показатель спроса, который существует на рынке.
Объем рынка нужно оценивать по разным причинам.
Чтобы понимать потенциал бизнеса. Перед запуском нового продукта или выходом на новый рынок нужно знать, насколько большой пирог компания собирается делить. Если объем рынка ограничен, то масштабироваться и расти в доходе на таком рынке будет сложно независимо от того, насколько хорош продукт.
Чтобы строить реалистичные планы. Исходя из размера рынка можно предполагать более точные прогнозы по продажам и доходам. И не строить завышенных ожиданий от доходов в будущем.
Чтобы привлекать инвестиции. Потенциальные инвесторы хотят знать, на какой рынок нацелена компания и насколько он велик. Без этих данных вкладывать деньги они вряд ли будут.
Чтобы распределять ресурсы. Реальная оценка емкости рынка дает понимание, сколько ресурсов нужно вложить в разработку продукта, маркетинг и др. расходы.
Чтобы рассчитать объем производства. Без понимания объемов рынка есть риск, что клиентов не хватит и товар залежится на складе. Либо, наоборот, спрос будет, а товара не будет.

Что такое модель PAM TAM SAM SOM

Модель PAM TAM SAM SOM — это подход к оценке объема рынка, который помогает понять, насколько велик рынок вашего продукта и какую его часть вы реально можете занять.
Суть модели в том, что она разбивает оценку рынка на четыре взаимосвязанных уровня:
  • Сначала определяют всех потенциальных покупателей, которые теоретически могут заинтересоваться продуктом (PAM).
  • Из них – тех, кто готов и способен тратить деньги на аналогичные решения (TAM).
  • Затем сужают круг до клиентов, до которых реально можно достучаться своими каналами и ресурсами (SAM).
  • А в конце оценивают ту часть рынка, которую реально захватить в ближайшей перспективе (SOM).
Визуально эту модель можно представить в виде воронки или пирамиды, где каждый следующий уровень сужается:
Обычно модель используют стартапы для обоснования своей бизнес-модели и привлечения инвестиций.

PAM

PAM (Potential Available Market) — потенциально доступный рынок. По сути, это максимальный теоретический размер рынка, если бы не существовало никаких ограничений – ни географических, ни технологических, ни связанных с конкуренцией.
Например для разработчика мобильных приложений PAM может включать всех владельцев смартфонов в мире.

TAM

TAM (Total Addressable Market) — общий целевой рынок. Это весь рынок, который теоретически может купить продукт или услугу, если не учитывать ограничения по ресурсам или конкуренции.
TAM показывает максимум, на который можно рассчитывать в реальных условиях. Например, с учетом географии компании или количества клиентов.
TAM
  • Помогает понять, стоит ли вообще заниматься этим бизнесом. Если TAM слишком мал, компания просто не сможет вырасти до значительных размеров.
  • Показывает предельные возможности роста компании.
  • Дает долгосрочную цель — когда компания начинает приближаться к TAM, может думать о выходе на новые рынки или о расширении продуктовой линейки.
Например для сервиса доставки еды TAM может включать всех людей в конкретной стране, которые заказывают еду на дом.

SAM

SAM (Serviceable Available Market) — достижимый объем рынка. Это часть TAM, которую можно реально обслуживать с учетом бизнес-модели, географического охвата и технологических возможностей.
Переход от TAM к SAM — это процесс сужения рынка с учетом:
  • Географических ограничений. Большинство компаний работает на ограниченном рынке, особенно на начальных этапах. Это может быть один город, регион или несколько крупных городов.
  • Демографических факторов. Продукт может быть предназначен для определенной возрастной группы, уровня дохода или образования.
  • Технологических ограничений. Для работы с некоторыми продуктами нужна определенная инфраструктура. Для мобильных приложений нужны смартфоны, для сложных B2B-систем — соответствующая IT-инфраструктура.
  • Каналов дистрибуции. Компания может работать через определенные каналы продаж — например, только через партнеров или только онлайн.
  • Операционных возможностей. Производственные мощности, количество сотрудников, логистические возможности — все это ограничивает размер рынка, который компания реально может обслуживать.
Для того же сервиса доставки еды SAM может быть ограничен крупными городами, где компания планирует работать

SOM

SOM (Serviceable Obtainable Market) — реально достижимый объем рынка. Это наиболее реалистичная оценка доли рынка, которую бизнес может получить с учетом конкуренции, ресурсов и других ограничений. SOM показывает, какую часть от SAM можно завоевать.
На реально достижимый объем рынка влияют несколько ключевых факторов:
  • Конкурентная среда. Чем сильнее конкуренты, тем сложнее будет отвоевать у них долю рынка.
  • Ресурсы компании. Финансовые возможности, размер команды, производственные мощности напрямую влияют на то, сколько клиентов компания может привлечь и обслужить.
  • Маркетинговые возможности. Способность компании донести информацию о своем продукте до целевой аудитории.
  • Зрелость продукта. Новые продукты обычно продаются не сразу, им нужно время, чтобы завоевать доверие рынка. Особенно в B2B-сегменте, где цикл продаж и интеграций может быть долгим.
  • Лояльность клиентов к текущим решениям. Переход на новый продукт часто связан с издержками для клиентов, поэтому даже при наличии лучшего предложения смена поставщика происходит не мгновенно.
Для нашего примера с доставкой еды это может быть 5–10% рынка в выбранных городах.

Как оценить объем рынка

Есть два основных подхода: сверху вниз (top-down) и снизу вверх (bottom-up).

Метод сверху вниз (top-down)

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

Метод снизу вверх (bottom-up)

Метод «снизу вверх» работает в обратном направлении — от конкретного к общему. Процесс оценки выглядит так:
  • Определение целевой аудитории. Компания определяет ЦА и потенциального клиента — составляет портрет целевой аудитории с демографическими, географическими, социальными характеристиками.
  • Оценка размера целевой аудитории. Определяет, сколько потенциальных клиентов соответствует вашему портрету. Например, сколько в России компаний малого бизнеса, которые могут использовать конкретный сервис для автоматизации.
  • Расчет потенциальной выручки от одного клиента. Компания оценивает средний чек или пожизненную ценность клиента (LTV).
  • Расчет объема рынка. Исходя из количества потенциальных клиентов и среднего дохода с каждого, компания рассчитывает объем рынка по формуле «число клиентов * средний доход с клиента».
У каждого метода есть свои плюсы и минусы:
Метод «Сверху вниз» Метод «Снизу вверх»
Относительная простота и скорость оценки Более точная и реалистичная оценка для конкретного бизнеса
Доступность данных (не требует собственных исследований) Лучшее понимание своей целевой аудитории
Удобство для презентации инвесторам (авторитетные источники) Возможность выявить нишевые возможности, не видимые в общей статистике
Общая картина рынка даже на ранних этапах Больше практических данных для планирования маркетинга и продаж
Устаревшие или неточные данные Требует больше времени и ресурсов на исследования
Сложности с учетом специфики отдельных ниш Сложнее реализовать без клиентов или данных
Риск завышенной оценки из-за широкого определения рынка Риск упустить потенциальные сегменты, о которых вы еще не знаете
Меньшая детализация и слабая привязка к реальным клиентам Может быть менее убедительным для инвесторов без отраслевых данных
И применять их можно в разных ситуациях:
Метод «Сверху вниз» Метод «Снизу вверх»
Ранняя стадия проекта, мало собственных данных Есть данные о продажах/тестировании с пользователями
Работа в устоявшейся отрасли с обилием исследований Работа в новой или узкой нише с ограниченными данными
Необходима быстрая, примерная оценка Нужна детальная оценка для операционного планирования
Подготовка презентации для инвесторов, акцент на большую картину Необходимость понять влияние конкретных сегментов на бизнес
Продукт ориентирован на широкий рынок Продукт рассчитан на узкую нишу с уникальными характеристиками
Сложности с учетом специфики отдельных ниш Сложнее реализовать без клиентов или данных
Риск завышенной оценки из-за широкого определения рынка Риск упустить потенциальные сегменты, о которых вы еще не знаете
Меньшая детализация и слабая привязка к реальным клиентам Может быть менее убедительным для инвесторов без отраслевых данных
Нельзя точно сказать, какой метод оценки лучше. Оптимально — комбинировать оба метода. По подходу «сверху вниз» получать общее представление о размере рынка и трендах. А с помощью метода «снизу вверх» проверять эти данные и корректировать их с учетом специфики бизнеса.

Как провести анализ рынка TAM SAM SOM

Шаг 1: Предположить PAM

Сначала нужно понять максимально широкие границы рынка, на котором вы собираетесь работать.
Определить PAM можно разными подходами:
  • Отраслевой. Определите общую отрасль, в которой работает ваш продукт, и найдите данные об ее объеме. Например, если разрабатываете решение для электронной коммерции, начать можно с оценки всего рынка онлайн-продаж.
  • Проблемный. Подумайте, какую проблему решает ваш продукт. Затем оцените, сколько денег тратится на решение этой проблемы в целом. Например, для сервиса по автоматизации бухгалтерии — общие затраты бизнеса на бухгалтерский учет.
  • Подход от клиента. Определите, сколько всего потенциальных пользователей могло бы воспользоваться продуктами, подобными вашему, и сколько они в среднем готовы потратить.
  • Технологический. Если продукт основан на определенной технологии, оцените весь рынок продуктов, использующих эту технологию.

Шаг 2: Определить ЦА и собрать данные

Для определения ЦА ответьте на вопросы:
  • Кто будет использовать ваш продукт или услугу?
  • Какие проблемы решает ваш продукт?
  • Каковы демографические, географические, социальные характеристики ваших клиентов?
  • Какова их платежеспособность?
На основе этих данных нужно создать портрет клиента.
Затем нужно собрать данные, которые помогут оценить рынок. Брать данные можно в разных источниках:
  1. Google Trends поможет понять популярность запросов, связанных с вашим продуктом, и их динамику со временем.
  2. Государственная статистика (Росстат, ФНС, отраслевые министерства) даст представление о размере отрасли, количестве потенциальных клиентов, среднем уровне дохода и других важных показателях.
  3. Маркетинговые исследования от специализированных агентств дадут уже готовую аналитику по вашей отрасли с прогнозами роста рынка.
  4. Публикации в СМИ часто содержат аналитику, интервью с экспертами и данные о трендах рынка.
  5. Годовые отчеты публичных компаний — еще один источник информации о размере рынка, доходах и т. д.
  6. Опросы потребителей помогут улучшить портрет клиента. Понять, сколько люди готовы платить и что на самом деле они хотят получить.

Шаг 3: Выбрать метод расчета и провести оценку TAM

На этом этапе нужно выбрать подход к оценке TAM — сверху вниз или снизу вверх (или комбинацию обоих) — и провести расчеты.
При использовании метода сверху вниз:
  • Найдите данные об общем объеме рынка в вашей отрасли.
  • Определите, какую долю в этом объеме занимает сегмент вашего продукта.
  • Учтите географические ограничения.
При использовании метода снизу вверх:
  • Оцените общее количество потенциальных клиентов.
  • Определите среднюю цену вашего продукта или средний доход с клиента.
  • Умножьте количество клиентов на среднюю цену.
При расчете TAM учитываются только те группы клиентов, которые действительно могут использовать ваш продукт в его нынешнем виде. Например, если продукт доступен только на русском языке, TAM нужно рассчитывать только для русскоязычных пользователей. Даже если в перспективе планируется перевод на другие языки.

Шаг 4: Сузить до SAM с учетом специфики продукта/услуги

Для оценки SAM учитывайте:
  • Географические ограничения: регионы, в которых вы можете работать.
  • Технологические ограничения: требования к клиентам, которые должны быть выполнены.
  • Особенности вашего продукта: специализация на определенных сегментах.
  • Ценовую политику: если продукт дороже среднего, это сужает аудиторию.
Часто SAM рассчитывается как процент от TAM с учетом указанных факторов. Например, если компания по учету рабочего времени планирует работать только с предприятиями в городах-миллионниках (где сосредоточено примерно 40% малого бизнеса) и только с компаниями с численностью от 10 сотрудников (это около 30% от всех МСП), то SAM составит: TAM * 40% * 30%

Шаг 5: Определить реально достижимый объем рынка (SOM)

Для определения SOM:
  1. Проанализируйте конкурентную среду: количество конкурентов, их доли рынка, сильные и слабые стороны.
  2. Оцените свои ресурсы: бюджет на маркетинг, размер команды продаж, производственные мощности.
  3. Учтите скорость адаптации нового продукта на рынке, особенно для инновационных решений.
  4. Рассмотрите барьеры входа и затраты на привлечение клиентов.
  5. SOM обычно выражается как процент от SAM, который вы планируете захватить в течение определенного периода (например, за 1–3 года).
Конкретных цифр нет, они могут сильно варьироваться в зависимости от отрасли и конкурентной ситуации. Если компания ожидает, что получит 5% рынка, то SOM составит: SAM * 5%.

Шаг 6: Проанализировать результаты

Проверить реалистичность. Сравните полученные цифры с данными аналогичных компаний и отрасли в целом. Если SOM кажется слишком большим или маленьким, возможно, вы упустили какие-то факторы.
Проанализировать чувствительность. Определите, как изменятся ваши оценки, если, например, размер аудитории или средний чек увеличатся или уменьшатся на 10–20%.
Обновлять оценки. По мере развития бизнеса, получения новых данных о продажах и изменений на рынке, пересчитывайте PAM, TAM, SAM и SOM.
Как делать расчеты по модели PAM TAM SAM SOM
Чтобы закрепить знания, давайте проведем анализ по модели на примере российской IT-компании «АвтоДок», которая разрабатывает облачную систему для автоматизации документооборота в медицинских учреждениях. Работать будем по методу сверху вниз.
Важно! Мы построим пример на примерных статистических данных, потому что на сбор сведений, анализ аудитории и рынка уйдет большое количество времени. Наша цель — показать механику расчета, а не реальный исследовательский процесс.

Оцениваем PAM

Чтобы определить PAM, в «АвтоДок» оценили общую сумму, которую все медицинские учреждения России теоретически могли бы потратить на автоматизацию документооборота и управление данными.
Для расчетов в компании взяли цифры статистики за 2013–2024 гг..: в стране работает около 5300 больниц, 20 000 поликлиник и других амбулаторных учреждений.
А после анализа рынков, отчетов и исследований, в компании собрали эти цифры:
  • Среднегодовые затраты на IT составляют примерно 1,2–1,5% от их бюджета.
  • Средний годовой бюджет больницы — около 150 млн рублей, а поликлиники — около 60 млн рублей.
  • Доля расходов на системы документооборота и управления данными в IT-бюджете медучреждений составляет примерно 15–20%.
В результате компания рассчитала, сколько всего денег медучреждения могут потратить на их продукт:
  • Больницы: 5,300 * 150 млн * 1,3% * 17% ≈ 1,75 млрд рублей в год
  • Поликлиники: 20,000 * 60 млн * 1,3% * 17% ≈ 2,65 млрд рублей в год
Получается, PAM для «АвтоДок» составляет примерно 4,4 млрд рублей в год. Это максимально широкая оценка, которая не учитывает множество факторов: не все учреждения готовы к цифровизации, часть рынка уже занята конкурентами, существуют ограничения по внедрению новых систем и так далее.

Оцениваем TAM

Система изначально разработана для учреждений, которые
  • Работают в системе ОМС.
  • Имеют минимальный уровень IT-инфраструктуры.
  • Переходят на электронный документооборот.
Из отчетов Минздрава в «АвтоДок» выяснили, что решение подходит примерно для 80% больниц (из 5300) и 70% поликлиник (из 20 000).
Кроме того, «АвтоДок» фокусируется только на автоматизации документооборота, связанного с пациентами. И не включает административные, финансовые и кадровые документы. По оценкам, пациентский документооборот составляет около 60% от всего документооборота медучреждений.
Получаются такие расчеты:
  • Больницы: 1,75 млрд рублей * 80% * 60% ≈ 840 млн рублей в год
  • Поликлиники: 2,65 млрд рублей * 70% * 60% ≈ 1,11 млрд рублей в год
TAM для «АвтоДок» составляет примерно 1,95 млрд рублей в год (840 млн + 1,11 млрд). Это максимальная сумма, которую «АвтоДок» заработает, даже если будет единственной подобной компанией на рынке.

Оцениваем SAM

Географическое присутствие. На текущий момент компания имеет офисы и техническую поддержку только в Москве, Санкт-Петербурге и четырех городах-миллионниках (Екатеринбург, Новосибирск, Казань, Ростов-на-Дону). В этих регионах сосредоточено около 40% от общего числа медучреждений, входящих в TAM.
Технические требования. Для системы «АвтоДок» нужна инфраструктура, которая есть примерно у 70% медучреждений.
Операционные возможности. Команда внедрения и поддержки может обслуживать до 50 новых клиентов в месяц (это около 85% от всех возможных).
Расчеты нужно делать по формуле ниже:
TAM * географические возможности * технические требования * операционные возможности
Получаются такие цифры:
  • TAM в регионах присутствия: 1,95 млрд * 40% = 780 млн рублей.
  • Учреждения с подходящей инфраструктурой: 780 млн * 70% = 546 млн рублей.
  • Ограничения по операционным возможностям: 546 млн * 85% = 464,1 млн рублей
То есть достижимый объем целевого рынка для «АвтоДок» составляет примерно 464 млн рублей в год.

Оцениваем SOM

Для расчета SOM «АвтоДок» учитывает следующие факторы:
  1. Конкуренты. На рынке работают три крупных конкурента, которые занимают суммарно около 60% рынка, и несколько мелких игроков с долей около 15%. То есть потенциально свободными остаются примерно 25% рынка.
  2. Ресурсы компании. «АвтоДок» пока не привлекла внешних инвестиций и развивается на собственные средства. Поэтому маркетинговый бюджет и возможности по расширению команды продаж ограничены.
  3. Продуктовые преимущества. У «АвтоДок» есть сильное УТП — упрощенная интеграция с медицинским оборудованием и удобный интерфейс.
  4. Скорость принятия решений. В государственном медицинском секторе цикл продаж достаточно длительный — от первого контакта до заключения договора проходит в среднем 5–7 месяцев.
С учетом этих факторов и ограниченных ресурсов компания планирует фокусироваться только на свободной части рынка. И не переманивать клиентов у конкурентов в первый год.
По расчетам компании из-за отсутствия внешних инвестиций и небольшого маркетингового бюджета получается, что за первый год после запуска продаж «АвтоДок» сможет занять примерно 15% от свободного рынка.
Получаются такие расчеты:
  • Объем свободного рынка — те самые 25%: 464 млн * 25% = 116 млн рублей
  • Реальный достижимый объем — 15% от суммы свободного рынка: 116 млн * 15% = 17,4 млн рублей
Это значит, что реально достижимый объем рынка для «АвтоДок» в первый год работы составляет около 17,4 млн рублей.
Это и есть целевой показатель доходности, к которому компания должна стремиться в первый год работы.

Что в итоге

  • Неправильная оценка объема рынка — причина, из-за которой закрываются 42% стартапов.
  • Модель оценки рынка Пам Там Сам Сом — подход, который помогает понять, насколько велик рынок продукта и какую его часть реально можно занять.
  • PAM (Potential Available Market) — максимальный теоретический размер рынка.
  • TAM (Total Addressable Market) — общий целевой рынок, показывает предельные возможности роста компании.
  • SAM (Serviceable Available Market) — достижимый объем рынка, учитывает географические, демографические и технологические ограничения.
  • SOM (Serviceable Obtainable Market) — реально достижимый объем рынка с учетом конкуренции, ресурсов и других ограничений.
  • Оценивать объем рынка можно 2 способами: сверху вниз (top-down) и снизу вверх (bottom-up).
Если хотите разобраться с методикой PAM, TAM, SAM, SOM и вести грамотные расчеты для бизнеса, обратитесь за помощью в Neogenda. Просто запишитесь на бесплатную консультацию, и наши эксперты помогут интегрировать модель в ваш бизнес.
]]> Теория ограничений: в двух словах от Виктора Вальчука http://neogenda.ru/blog/fz218n5mh1-teoriya-ogranichenii-v-dvuh-slovah-ot-vi http://neogenda.ru/blog/fz218n5mh1-teoriya-ogranichenii-v-dvuh-slovah-ot-vi?amp=true Tue, 13 May 2025 17:17:00 +0300 Артур Нек Ведущие: Алексей Цыбульник (Kanban-coach), Виктор Вальчук (директор ARB-консалтинг, эксперт по Теории ограничений).

Теория ограничений: в двух словах от Виктора Вальчука

Ведущие: Алексей Цыбульник (Kanban-coach), Виктор Вальчук (директор ARB-консалтинг, эксперт по Теории ограничений).

Кратко о спикере

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

Что такое Теория ограничений (ТО)?

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

Четыре основных принципа ТО

  • Внутренняя простота: любая система имеет одно или несколько “узких мест”.
  • Прорывное решение: ограничение разрешимо так, чтобы убрать саму причину проблемы.
  • Люди хорошие: поиск решения не сводится к обвинению сотрудников.
  • Улучшение в любой ситуации: найдя корень проблемы и прорывное решение, результат всегда растёт.

Почему не обвинять людей

  • Система сильнее: по Демингу, 98 % проблем—внутренние, только 2 % связаны с поведением людей.
  • Ошибка атрибуции: мы склонны обвинять других, объясняя чужие ошибки их личными качествами.

Инструмент «Грозовая туча» (диаграмма разрешения конфликта)

Что это: визуальный инструмент, помогающий сформулировать и разрешить внутренний конфликт в системе.
Конфликт задаётся явно в центре «тучи».
Имеет две ветви:
  • Действие A → Необходимость A
  • Действие B → Необходимость B
Действия конфликтуют, а потребности обе ценны.
Далее выявляются ложные убеждения, породившие этот конфликт.
Пример: руководитель проектов должен тратить время и на текущих, и на новых клиентов.
  • Действие A: «работать с текущими» → необходимость: «сохранять репутацию»
  • Действие B: «привлекать новых» → необходимость: «рост продаж». Ложное убеждение «я быстрее сделаю сам, чем научу другого» удерживает эту «тучу» над процессом.

Принцип «Барабан – Буфер – Канат»

  • Барабан. Формирует ритм всей системы — план работы узкого ресурса (bottleneck).
  • Буфер. Запас времени (или материала), который гарантирует, что ограничение не простаивает.
  • Канат. Механизм выпуска новых заказов: не раньше, чем «Время обработки – Буфер».
Типовой пример (типография):
  • Ограничение — фальцевальная машина (барабан).
  • Буфер — время, за которое заказ доходит до фальцевки и ждёт в очереди.
  • Канат — запуск заказа в работу только по сигналу «остаток времени» > буфера.

Виды буферов в Теории ограничений

  • Временной буфер — для производства (планирование запуска).
  • Буфер товарных запасов — для управления SKU (минимальный и максимальный уровни).
  • Резерв мощности — «буфер» квалифицированных ресурсов (20 % избыточной мощ ности на случай неопределённости).
Буфер не просто «запас» — это инструмент управления для приоритизации и непрерывного улучшения.

TOC vs Kanban и TPS

Toyota Production System (TPS). +Основан на детерминированном планировании, Kanban-карточках и контроле качества (Эдвард Деминг, Шухарт).
Kanban-метод (не мате риальное производство). Фокусируется на WIP-лимитах и потоке знаний.
TOC (высокая неопределённость). Отказывается от детальных расписаний в пользу DBR-механизма и управления вариативностью через буферы.

Узкое место и ресурс с ограниченной мощностью

Бутылочное горлышко (100 % загрузка). Ресурс работает без простоев 24/7, формирует «барабан» системы.
Ресурс с ограниченной мощностью (> 70 % загрузки). Из-за вариативности создаёт очереди и требует резервов (буфера мощности).

Пять фокусирующих шагов Теории ограничений

  1. Найти ограничение. Выявить узкое место (ресурс или процесс), которое тормозит весь поток. Иногда это очевидный «станок», а порой — человеческий ресурс или координация.
  2. Максимально использовать. Организовать работу так, чтобы ограничение не простаивало. Пример: руководители проектов чаще обучают подчинённых вместо самостоятельного выполнения каждой задачи.
  3. Подчинить системе. Скорректировать все остальные процессы под ритм ограничения. Запускать новые заказы только после прохождения предыдущих через «барабан» ограничения.
  4. Увеличить мощность (при необходимости). Лишь после первых трёх шагов оценить, нужно ли расширять ресурс — добавить смену на станке или привлечь помощника. Чаще всего хватает оптимального использования и подчинения системы.
  5. Вернуться к шагу 1. После решения одного узкого места ограничение смещается дальше по процессу. Циклически повторяем поиск и оптимизацию.

Сферы применения и роль TOC в цифровой трансформации

Любой бизнес: от производства до сервисных компаний и IT-проектов.
Логистика и цепочки поставок: отказ от локальной оптимизации и детального планирования.
Нематериальные процессы: маркетинг, HR, цифровые продукты — идеальная среда высокой неопределённости.
Цифровая трансформация: в эпоху быстрых изменений и экспериментов TOC предоставляет мыслительные инструменты для выявления устаревших убеждений и поиска прорывных решений.

Итог

Теория ограничений — универсальный подход к улучшению любого процесса через фокус на настоящем узком месте и последовательное устранение корневых конфликтов.
]]> Канбан-доска против Канбан-системы: в чём разница http://neogenda.ru/blog/h7aoty7gn1-kanban-doska-protiv-kanban-sistemi-v-chy http://neogenda.ru/blog/h7aoty7gn1-kanban-doska-protiv-kanban-sistemi-v-chy?amp=true Wed, 14 May 2025 06:20:00 +0300 Артур Нек В профессиональной среде «Канбан» нередко воспринимается исключительно как визуальная доска, на которой размещаются карточки с...

Канбан-доска против Канбан-системы: в чём разница

В профессиональной среде «Канбан» нередко воспринимается исключительно как визуальная доска, на которой размещаются карточки с задачами. Однако такая интерпретация сильно упрощает суть метода. Канбан — это не только инструмент визуализации, но и полноценная система управления потоком работы, которая помогает организациям выстраивать прозрачные, предсказуемые и адаптивные процессы.
Спикеры:
  • Алекс Цыбульник — аккредитованный тренер Kanban
  • Дмитрий Самойлов — аккредитованный тренер Kanban, Senior Agile Coach в ОТП Банке

Почему Канбан — это не только доска

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

Что такое Канбан-система

Канбан-система — это набор взаимосвязанных элементов, которые помогают управлять потоком задач от запроса до доставки. Она включает:
  • Визуализацию потока (доска с колонками и карточками).
  • Ограничение незавершённой работы (WIP-лимиты).
  • Явные правила и политики работы.
  • Обратную связь и регулярные обсуждения.
  • Измерение и прогнозирование на основе данных.
Канбан-система отвечает на вопросы:
  • Какие задачи находятся в работе?
  • Где именно возникают задержки?
  • Какова пропускная способность команды?
  • Что можно улучшить в потоке?
Таким образом, Канбан помогает командам не просто отображать задачи, а управлять потоком работы, улучшая предсказуемость, ритмичность и удовлетворённость клиентов.

Кто может инициировать внедрение Канбана

Важно понимать, что инициатором внедрения Канбана не обязательно должен быть менеджер или руководитель. Чаще всего изменения начинают обычные сотрудники, которым не всё равно. Это может быть любой человек, замечающий проблемы в текущих процессах и заинтересованный в улучшениях. Главное качество — неравнодушие и интерес к тому, как устроена работа, а не формальная должность.
Первые запросы на улучшения, как правило, звучат в форме:
  • «Помогите нам разобраться, почему мы буксуем»
  • «Хотим понять, как улучшить поток задач»
  • «Нужно научиться управлять процессом, а не просто выполнять задачи»

С чего начинается работа с Канбаном

В любой ситуации ключевой принцип — «начни с того, что есть». На первом этапе важно не выдумывать идеальную модель, а честно посмотреть на текущий процесс. Для этого и используется доска: она становится зеркалом, в котором команда видит, как задачи действительно перемещаются в процессе работы.
Визуализация — это только отправная точка. Дальше появляется возможность анализировать и улучшать:
  • Где скапливаются задачи?
  • Почему одни этапы перегружены, а другие — пустуют?
  • Какова фактическая скорость выполнения задач?
Именно через такие наблюдения формируется понимание, что доска — лишь инструмент, а не цель.
От Kanban-доски к Kanban-системе: эволюция управления потоком работы
Одним из наиболее распространённых поводов для внедрения Kanban-доски в команде становится перегрузка отдельных сотрудников. Такой сигнал служит отправной точкой для визуализации потока работы:
«Давайте покажем, сколько задач действительно проходит через нас».
Сделав нагрузку видимой, команда и заинтересованные стороны получают фактическую картину, на основе которой можно принимать обоснованные управленческие решения — перераспределять ресурсы, ограничивать поток или усиливать команду.
Однако важно понимать, что Kanban-доска — лишь часть более широкой системы.
Kanban-система охватывает весь производственный процесс поставки ценности клиенту: от возникновения запроса до его финальной реализации. Это может включать несколько команд, специалистов, релизные циклы — всю цепочку, по которой проходит рабочий элемент. В то время как доска может отображать только один этап или сегмент работы (например, задачи, проходящие через архитектуру или безопасность), система фиксирует путь полностью.
В теории возможна ситуация, при которой доска полностью отражает Kanban-систему — как правило, в стартапах с небольшой командой, где полный цикл выполняется одной группой без привлечения внешних ресурсов. Но на практике это скорее исключение.
Ключевые отличия Kanban-системы от Kanban-доски:
  • End-to-End подход — описание полного потока ценности от запроса до реализации.
  • Вытягивающая природа — ограничения по этапам, позволяющие работе поступать только при наличии свободных ресурсов.
  • Фокус на потоке, а не людях — управление задачами, а не индивидуальной загруженностью.
Переход от доски к системе — это эволюционный процесс. Начинается всё с индивидуальных Kanban-досок, описывающих задачи конкретного человека. Затем появляются агрегированные доски — объединяющие задачи всей команды, но с фильтрами по каждому участнику. Следующий этап — командная доска, где задачи организованы по этапам выполнения, а не по исполнителям.
Дальнейшее развитие включает установку WIP-лимитов (ограничений на количество задач в работе).
Сначала — на человека, затем — на узкие участки процесса, и далее — на каждый этап.
Так формируется полноценная вытягивающая система, обеспечивающая сбалансированную загрузку и предсказуемость выполнения задач.
Преимущества вытягивающей системы особенно заметны в контексте снижения стоимости переключения между задачами. Когда сотрудник работает над одной задачей, он погружен в ее контекст. Но при постоянной смене задач и возвращении к ним спустя дни — контекст теряется, и приходится тратить ресурсы на повторное вникание. Это снижает эффективность.
Рассмотрим пример:
Сотрудник работает над тремя задачами, каждая из которых находится на предпоследнем этапе — ревью. Вместо того чтобы завершить их, он берёт четвёртую.
Итог — ни одна не доведена до конца. Установив лимиты на этапе ревью и договорившись начинать рабочий день с проработки «узкой» колонки, команда за один квартал улучшила производительность на 25%.
Таким образом, применение Kanban-принципов, включая лимиты и ориентацию на поток, позволяет не просто визуализировать работу, а активно управлять ею, повышая эффективность команд и прозрачность процессов в организации.

Предсказуемость в зависимости от организации вытягивания

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

Правила взаимодействия и квотирование

Если у сервиса несколько заказчиков, критично определить и зафиксировать, как и в каком объеме они могут подавать запросы. Для этого применяются инструменты вроде capacity allocation (выделение мощностей), револьвера задач или другие механизмы согласования. Главное — установить правила взаимодействия, чтобы все знали, сколько работы может быть принято, и от кого чего ожидать.

Классы обслуживания должны быть сквозными

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

От визуализации к управлению

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

Как начать: доска, STAtIK или KMM?

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

Итоги

В выпуске мы обсудили:
  • Разницу между Kanban-доской и Kanban-системой.
  • Что делает систему предсказуемой: вытягивание, WIP-ограничения, классы обслуживания.
  • Почему важны правила взаимодействия при множестве заказчиков.
  • Как STAtIK помогает в осмысленной эволюции процессов.
Главный вывод: не бойтесь пробовать. В худшем случае — ничего не изменится. В лучшем — вы получите более прозрачную, управляемую и эффективную систему.
]]> Таск-менеджер для команды: выбираем трекер задач http://neogenda.ru/blog/9b75ub8aj1-task-menedzher-dlya-komandi-vibiraem-tre http://neogenda.ru/blog/9b75ub8aj1-task-menedzher-dlya-komandi-vibiraem-tre?amp=true Thu, 15 May 2025 06:23:00 +0300 Артур Нек Чтобы сотрудники работали эффективно, важно грамотно управлять проектами. Для этого применяют таск-менеджеры. Они помогают выстроить...

Таск-менеджер для команды: выбираем трекер задач

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

Что значит таск-менеджер

Таск-менеджер (трекер задач) — инструмент, благодаря которому легко организовывать, отслеживать и управлять задачами в контексте проекта. Ключевые цели — упорядочить процессы, повысить продуктивность, наладить связь между коллегами.
Выделяют несколько значимых функций task-менеджеров:
  • Постановка задач. Для каждой задачи можно назначить главного, указать дедлайн, описать требования.
  • Чек-листы, списки дел. Позволяют разбить задачу на более мелкие шаги, которые отмечают по готовности.
  • Подзадачи. Если делить большую задачу на более мелкие, можно легче выполнять работу и контролировать каждый ее этап.
  • Канбан-доска. Визуализация задач в формате карточек — их перемещают по колонкам согласно статусу, например «Запланировано», «Завершено».
  • Диаграмма Ганта. Графическое изображение сроков выполнения задач и взаимосвязей, чтобы визуализировать пошаговое продвижение проекта.

Кому и для чего нужен таск-менеджер

Таск-менеджеры полезны тем, кому важно лучше планировать и работать над задачами, поднять эффективность, четче выстраивать дела:
  • Командам либо предприятиям, чтобы грамотно ранжировать задачи, видеть прогресс, делать этапы прозрачными. Таск-менеджеры помогают следить за сроками и налаживать связь между всеми участниками проекта. Особенно полезны они для удаленщиков.
  • Проектным менеджерам, чтобы держать под контролем все стадии работы — от планирования до финала проекта.
  • Фрилансерам сервис помогает структурировать свой день, планировать задачи, следить за тем, как они выполняются. Актуально для специалистов, которым нужно контролировать множество проектов одновременно.
  • Разработчикам, которые используют Agile и SCRUM, таск-менеджеры помогают делать процессы прозрачными и проверять, как задачи выполняются по спринтам.
  • Малому и среднему бизнесу task-менеджеры нужны, чтобы настроить рабочие процессы, увеличить общую продуктивность и снизить риски задержек.

Как выбрать таск-трекер

Рассмотрим основные критерии, которые помогут составить рейтинг таск-менеджеров:
1. Специфика работы
Если думаете управлять задачами самостоятельно, лучше выбрать простой вариант с простым набором опций. Например, Google Задачи, Things. Для работы команды пригодится наличие kanban-доски, диаграммы Ганта, а еще не будет лишним, если права доступа можно настроить без проблем. Популярные решения — Pyrus, Kaiten.
2. Адаптивность и масштабируемость
Трекеры задач должны закрывать потребности и расти с проектом. Разберитесь, насколько просто будет добавлять новых пользователей, расширять возможности за счет интеграций, адаптировать рабочий процесс к своему подходу. Для небольших команд подойдет такой таск-трекер, как WEEEK. Крупные компании могут выбрать что-то вроде Yandex Tracker или Битрикс24.
3. Интеграции с нужными сервисами
Чтобы не переносить данные вручную, проверьте, с какими сервисами совместим task tracker. Например: Гугл Драйв, Dropbox — для файлов; Telegram, Microsoft Teams — для общения; CRM-системы — для масштабной работы над проектами, задачами.
4. Удобство, понятный интерфейс
Если таск-менеджмент требует долгого обучения, сотрудники могут отказаться его использовать. Хороший менеджер задач должен быть понятным и удобным. Поэтому оцените простоту навигации, доступность необходимых функций в несколько кликов, возможность персонализировать интерфейс под себя.
5. Поддержка и обучение
Чем сложнее система управления проектами и задачами, тем важнее качественная поддержка. Перед тем, как определиться с task-трекером, проверьте наличие документации, обучающих видео, вебинаров; быстро ли отвечает техподдержка; есть ли русскоязычный вариант.
6. Кроссплатформенность и мобильные версии
Важно, чтобы программа таск-менеджер работала не только в браузере. Если нужно управление проектом на ходу, выбирайте решения, которые поддерживаются на iOS, Android, macOS, Windows.
В 2022 году популярные инструменты Trello и Jira ушли из России, но альтернативных решений осталось достаточно.
Теперь подробнее разберем топ трекеров, их сильные и слабые стороны, функции, особенности. Это поможет подобрать таск-менеджер для команды именно под ваши цели.

Kaiten

Продвинутый таск-менеджер для команд, предпочитающих Agile. Сочетает оптимальные практики канбан-досок, Scrum, гибких подходов. Благодаря инструменту можно организовать рабочий процесс с учетом взаимосвязей между задачами, их важности и командной нагрузки.
Kaiten предоставляет больше перспектив для автоматизации и анализа процессов, чем Trello, а если сравнивать с Jira — у него более понятный интерфейс. Это удобный сервис, который помогает управлять проектами в компаниях любых размеров.
Можно использовать веб-версию, iOS, Андроид. Есть тестовый период две недели, затем платная подписка.
Плюсы:
  • Гибкость, кастомизация. Адаптируется под любые процессы: от классического таск-менеджмента до сложных сценариев управления продуктом.
  • Современные инструменты аналитики. Дает возможность проверять, сколько времени уходит на задачи, выявлять проблемные области.
  • Канбан-доски с выбором опций. Можно настраивать чек-листы, создавать подзадачи, просматривать статус задач в режиме реального времени.
  • Внедрение нужных для работы сервисов. Поддерживает Slack, GitHub и др.
  • Доступность для каждого участника. Видно взаимосвязи задач, сроки, приоритеты, чтобы делать совместную работу проще.
Минусы:
  • Отсутствие бесплатного тарифа. Нет полноценной базовой версии.
  • Требуется время, чтобы все настроить. Несмотря на понятный интерфейс, для полного раскрытия потенциала нужно детально настроить систему под себя.
Таск-менеджер подходит:
  • Agile-командам, работающим с Kanban или SCRUM.
  • ИТ-компаниям или стартапам, если нужна альтернатива Trello и Jira.
  • Менеджерам проектов, которым важно детально все планировать и анализировать процессы.
  • Командам, работающим с удаленными сотрудниками.

YouGile

Российский task-менеджер с гибкой визуализацией. Сочетает канбан-доски, чек-листы, подзадачи, встроенный чат для простого взаимодействия.
Есть веб-версия, можно работать на iOS, Андроид, macOS, Windows. Можно выбрать бесплатный тариф или платные версии где больше возможностей.
Плюсы:
  • Российская разработка. Отвечает нормам локального законодательства и заботится о защите данных.
  • Удобная настройка интерфейса. Можно адаптировать таск-менеджер для сотрудников под любые бизнес-процессы.
  • Встроенные чаты, комментарии. Можно обсуждать задачи в карточках, чтобы не переключаться на сторонние сервисы.
  • Внедрение популярных сервисов. Поддержка CRM, 1С, Телеграм, Slack и др. инструментов.
  • Автоматизированная канбан-доска. Можно настраивать триггеры и правила, чтобы оптимизировать процессы.
Минусы:
  • Не самая развитая экосистема. Хотя YouGile предлагает множество опций, он пока уступает Jira в глубине аналитики.
  • Ограниченный бесплатный тариф. Чтобы получить доступ ко всем возможностям, потребуется подписка.
Таск-менеджер подходит:
  • Российским компаниям, которым важна локальная поддержка с защитой данных.
  • Командам, которым нужен task-трекер с удобной визуализацией.

Мегаплан

Платформа управления задачами и бизнес-процессами родом из РФ. Ориентирована на малый и средний бизнес. Помогает строить рабочие процессы, наблюдать за выполнением задач, эффективно взаимодействовать в рамках команды. В системе можно назначать ответственных, определять сроки и контролировать, как продвигаются проекты. «Мегаплан» включает CRM, инструменты для автоматизации и коллективной работы.
Сервис доступен через веб-версию, iOS, Андроид, Windows или macOS. можно воспользоваться бесплатным двухнедельным периодом, далее — платные тарифы, стоимость которых зависит от числа пользователей и функций.
Плюсы:
  • Комплексное бизнес-решение. Здесь и таск-менеджер, и CRM, и документооборот, и аналитика.
  • Гибкие настройки. Адаптация под любые процессы бизнеса.
  • Продвинутая отчетность. Позволяет контролировать производительность сотрудников и эффективность проектов.
  • Российская разработка. Не зависит от западных сервисов и поддерживает внедрение отечественных инструментов.
  • Возможности для командной работы. Встроенный чат, уведомления и контроль дедлайнов.
Минусы:
  • Отсутствие бесплатного тарифа. После пробного периода требуется оформить подписку.
  • Не подходит для использования одним человеком. Это больше корпоративное решение, а не персональный таск-менеджер.
Подходит:
  • Малому и среднему бизнесу — для организации задач, CRM, управления процессами.
  • Руководителям — для контроля за работой сотрудников, эффективностью проектов.
  • Командам, которым нужна российская альтернатива зарубежным сервисам.

Todoist

Таск-менеджер как для индивидуальной, так и для командной работы. Благодаря ему можно заводить списки дел, выбирать сроки, расставлять приоритеты, следить за динамикой задач в понятном интерфейсе.
Todoist отличает простота, кроссплатформенность и приятная система напоминаний.
Доступен в веб-версии и в приложениях для iOS, Андроид, macOS, Windows. Можно использовать браузерные расширения. Есть бесплатный тариф с базовыми функциями и платные подписки.
Плюсы:
  • Интуитивный интерфейс. Todoist актуален даже тем, кто раньше не пользовался таск-менеджерами.
  • Гибкость организации задач. Можно работать с проектами, подзадачами, применять теги и фильтры.
  • Доступ на всех устройствах. Данные синхронизируются в облаке, поэтому можно заниматься ими с любого гаджета.
  • Поддержка интеграций. Совместим с Google Calendar, Slack, Zapier и др. сервисами.
  • Геймификация продуктивности. Встроенная система Karma помогает пользователям выполнять задачи вовремя.
Минусы:
  • Ограниченный функционал в бесплатной версии. Например, нет напоминаний и продвинутой аналитики.
  • Не подходит для сложных проектов. Todoist больше ориентирован на дела отдельного человека, чем на управление крупными командами.
Таск-менеджер подходит:
  • Фрилансерам и самозанятым — для ведения личных задач и небольших проектов.
  • Людям, стремящимся к эффективному тайм-менеджменту.
  • Небольшим командам, которым нужен простой таск-менеджер для совместной работы.

WEEEK

Российский task-менеджер. Объединяет канбан-доску, чек-листы, подзадачи, списки дел. Актуален для индивидуального использования и командной работы.
WEEEK — это простой таск-менеджер для управления задачами без мишуры, но с достаточным количеством функций.
Доступен в веб-версии, на iOS, Андроид, macOS, Windows. Есть бесплатный таск-трекер и платные тарифы.
Плюсы:
  • Понятный интерфейс. WEEEK легко освоить даже новичкам.
  • Гибкая организация работы. Можно использовать канбан-доски, списки дел, чек-листы, адаптировать процессы под свои цели.
  • Внедрение популярных сервисов. Поддерживает Google Календарь, Telegram и др.
  • Мобильные приложения. Позволяет вести трекинг задач с любых гаджетов.
  • Синхронизация в реальном времени. Мгновенное обновление данных для всех участников.
Минусы:
  • Ограниченный функционал в бесплатной версии. Для расширенных возможностей нужно оформить подписку.
  • Отсутствие продвинутых аналитических инструментов. WEEEK больше ориентирован на простое управление задачами, чем на детальный анализ.
Таск-менеджер подходит:
  • Фрилансерам и самозанятым, которые ищут простой инструмент для личных задач.
  • Небольшим командам, которым нужен бесплатный таск-трекер для совместной работы.
  • Менеджерам проектов, которым важно управление задачами без сложных настроек.
  • Компаниям, работающим удаленно, благодаря синхронизации в режиме реального времени.

Pyros

Универсальная платформа для автоматизации бизнес-процессов. Здесь есть управление проектами и задачами, документооборот, согласование заявок. Pyrus оптимален для корпоративного сегмента, где важны четкие процессы и взаимодействие отделов.
Этот менеджер задач работает в режиме онлайн, предлагает гибкую систему отчетности с удобным распределением ролей. В нем можно создавать задачи, делегировать их коллегам, контролировать срок выполнения.
Можно использовать web-версию, iOS, Андроид, macOS, Windows. Есть бесплатный тариф для маленьких команд и платные варианты с бизнес-возможностями.
Плюсы:
  • Корпоративное решение. В отличие от простых таск-трекеров, в Pyrus есть интеграция с документооборотом и согласование заявок.
  • Гибкая настройка доступа. Можно задавать уровни прав для разных сотрудников и отделов.
  • Внедрение популярных сервисов. Поддерживает 1С, Google Workspace, API для кастомных решений.
  • Автоматизация рутинных задач. Можно разрабатывать шаблоны процессов, чтобы минимизировать ручной труд.
  • Эффективный контроль сроков. Позволяет отслеживать, сколько времени уходит на выполнение задач и анализировать продуктивность сотрудников.
  • Удобное мобильное приложение. Позволяет отслеживать трекинг задач и согласовывать документы прямо с телефона.
  • Групповые чаты внутри системы. Можно обсуждать задачи без необходимости использовать сторонние мессенджеры.
Минусы:
  • Нужно время на настройку. Для использования в команде придется сначала настроить роли, права доступа и процессы.
  • Ограниченная кастомизация интерфейса. В отличие от Trello или Kaiten, Pyrus не дает такой глубокой персонализации визуального отображения задач.
Таск-менеджер подходит:
  • Корпоративным командам, которым нужно структурированное управление проектом.
  • Компаниям с документооборотом, которым нужен таск-менеджер с интеграцией в бизнес-процессы.
  • Менеджерам, которые следят за исполнением задач и сроками.
  • Организациям, если им нужно согласование заявок и автоматизация рабочих процессов.

Битрикс24

Популярная в России платформа для управления бизнес-процессами, которая объединяет функции таск-менеджера, CRM-системы, а еще помогает строить коммуникацию и коллективную работу. Битрикс24 подходит как для стартапов, так и для крупных фирм, потому что помогает организовывать проекты, задачи и общение.
Возможно, будет достаточно облачной или серверной версии, а если нет, можно выбрать приложение для iOS, Android. Есть бесплатный базовый тариф и платные версии с расширенными опциями.
Плюсы:
  • CRM-система. В отличие от других таск-трекеров, Битрикс24 предлагает комплекс функций для ведения и анализа продаж, работы с клиентами и документами.
  • Все инструменты в одном месте. Встроенные чаты, видеозвонки, почта, календари и задачи — все это интегрировано в одну экосистему.
  • Гибкое управление задачами. Поддерживает канбан-доски, чек-листы, подзадачи, а также отслеживание статусов в режиме реального времени.
  • Интеграция с другими сервисами. Поддержка Google Workspace, Microsoft 365, Slack, Mailchimp и других популярных инструментов.
  • Мобильное приложение. Легко управлять задачами и проектами с мобильных устройств.
  • Аналитика и отчеты. Помогает отслеживать выполнение задач, анализировать продуктивность сотрудников и принимать управленческие решения.
Минусы:
  • Сложность в настройке. Из-за большого количества функций новичкам может потребоваться время, чтобы освоить все возможности Битрикс24.
  • Перегруженный интерфейс. Некоторые пользователи отмечают, что изобилие опций усложняет навигацию.
  • Высокая цена платных тарифов. Несмотря на наличие бесплатной версии, для получения полного функционала нужно перейти на платную подписку, которая может оказаться дорогой для небольших команд.
Таск-менеджер подходит:
  • Крупным фирмам и корпорациям, которым нужно собрать все бизнес-процессы в одной системе.
  • Командам с комплексными задачами, чтобы сочетать управление проектами и задачами с CRM и другими сервисами.
  • Менеджерам проектов, которым нужно организовать работу команды, отслеживать сроки и приоритеты, а также взаимодействовать с клиентами.
  • Отделам продаж и маркетинга, которым важна интеграция с CRM-системой и удобное управление клиентскими данными.

Yandex Tracker

Корпоративный таск-трекер от Яндекса для комфортного управления проектами и задачами. Ориентирован на бизнес и команды, которым важно гибкое и детальное планирование процессов. Он особенно популярен среди IT-команд, аналитиков, отделов разработки, но также используется в других сферах.
Одно из ключевых преимуществ Yandex Tracker — глубоко проработанная система таск-менеджмента с поддержкой канбан-досок, диаграмм Ганта, гибкой автоматизацией. Благодаря тесной интеграции с другими сервисами Яндекса task-трекер позволяет легко создавать задачи, делегировать их коллегам, следить за сроками.
Можно работать в веб-версии, на iOS или Android. Есть бесплатный пробный период и платные тарифы для бизнеса.
Плюсы:
  • Гибкая настройка бизнес-процессов. Можно адаптировать таск-менеджер под конкретные нужды команды или компании.
  • Интеграция с сервисами Яндекс. Поддерживает Яндекс Диск, Yandex Cloud, API Яндекс.Метрики и т. д.
  • Развитая система отчетности. Позволяет анализировать, сколько времени уходит на задачи, отслеживать производительность сотрудников и эффективность проектов.
  • Автоматизация процессов. Можно создавать кастомные бизнес-правила, автоматизировать распределение задач и уведомления.
  • Канбан-доска и диаграмма Ганта. Визуальные инструменты для удобного планирования работы команды.
  • Безопасность и соответствие российскому законодательству. Подходит для корпоративного сегмента, так как хранит данные на российских серверах.
Минусы:
  • Сложность освоения. Новичкам потребуется время, чтобы разобраться в функционале и возможностях таск-трекера.
  • Ориентация на бизнес. Yandex Tracker не слишком удобен для задач отдельного человека.
  • Нет полностью бесплатной версии. Хотя есть пробный период, для долгосрочного использования необходимо приобретать подписку.
Подходит:
  • IT-агентствам и разработчикам, которым нужны полезные инструменты для управления проектами и задачами.
  • Аналитическим и маркетинговым командам, которые ищут лучшие трекеры с глубокой системой отчетности.
  • Среднему и крупному бизнесу, которому требуется корпоративный таск-менеджер с гибкой настройкой процессов.
  • Компаниям, работающим в экосистеме Яндекса, которые хотят интегрировать таск-менеджер с привычными сервисами.

Shtab

Task manager, созданный в РФ для управления проектами и рабочими процессами. Основан на Канбан Методе. Предлагает удобные инструменты для распределения задач, аналитики, контроля времени, планирования финансов.
Платформа поддерживает интеграции с различными сервисами и доступна на Windows, macOS, Linux и iOS, так что это универсальное решение для команд, работающих на разных устройствах. Есть пробный период, но для полноценной работы нужно будет оформить платную подписку.
Плюсы:
  • Интеллектуальный тайм-трекер. Позволяет автоматически фиксировать затраты времени на задачи и анализировать продуктивность.
  • Гибкость в управлении процессами. Можно адаптировать систему под любые рабочие сценарии, включая проектное управление, учет финансов и планирование ресурсов.
  • Соответствие российским требованиям. Включен в реестр отечественного ПО, поэтому гарантирует защиту данных и соответствие законодательству.
Минусы:
  • Требует ресурсов на освоение. Обширный функционал может потребовать времени на настройку и обучение команды.
  • Меньшая экосистема интеграций. В сравнении с мировыми аналогами количество поддерживаемых сервисов пока ограничено.
Таск-менеджер подходит:
  • Проектным командам, которым нужен инструмент с мощной аналитикой и тайм-трекингом.
  • Организациям, которым важны защита данных и соответствие российскому законодательству.
  • Менеджерам, которые ищут универсальную систему для контроля проектов, задач и финансов.

ПланФикс

Таск-менеджер, который объединяет управление задачами, клиентами и бизнес-процессами. Предлагает мощные возможности автоматизации и глубокую кастомизацию — можно адаптировать систему под любые бизнес-потребности.
Сервис подходит для разных сфер: от ИТ до розничной торговли и сферы услуг. Он поддерживает внедрение популярных мессенджеров, CRM и сервисов аналитики.
«ПланФикс» доступен через web-версию и через приложения для iOS и Android. Есть пробный период для знакомства с инструментом, хотя для дальнейшего использования нужна будет платная подписка.
Плюсы:
  • Гибкая настройка интерфейса. Можно адаптировать систему под любые задачи, от управления проектами до ведения клиентской базы.
  • Автоматизация рабочих процессов. Позволяет настраивать сценарии, которые упрощают рутинные операции.
  • Широкий набор интеграций. Поддерживает связь с Telegram, WhatsApp, Google Drive, 1С и другими сервисами.
Минусы:
  • Сложность освоения. Много функций, поэтому новичкам понадобится дополнительное время на изучение возможностей системы.
  • Цена полной версии. Чтобы получить доступ ко всем возможностям, нужна платная подписка.
Task-менеджер подходит:
  • Предпринимателям, которые хотят управлять задачами и вести клиентскую базу.
  • Фирмам, которым необходима автоматизация процессов и внедрение различных сервисов.
  • Менеджерам, которые хотят выстроить прозрачную и управляемую структуру работы внутри команды.

Вместо итога

Подробно рассмотрели список трекеров — российские таск-менеджеры и зарубежные. Каждое из этих решений предлагает возможности, чтобы значительно упростить управление задачами, наладить коммуникацию в команде, увеличить общую эффективность работы.
Однако даже лучшие инструменты не принесут желаемого результата, если не внедрить эффективные управленческие практики. Компания Neogenda помогает в этом. Работали с такими крупными компаниями, как Tinkoff, Яндекс, Авито, Сбер, Билайн и Skyeng. Обучили более 5000 сотрудников. Наш опыт и индивидуальный подход помогут вашей команде достичь максимальных результатов.
Чтобы получить консультацию от наших экспертов, оставьте заявку на бесплатную встречу в Zoom, и мы расскажем, как улучшить процессы вашего бизнеса.
]]> Кто такой тимлид в IT-компании: задачи, навыки и возможности карьерного роста http://neogenda.ru/blog/jn1b91j8f1-kto-takoi-timlid-v-it-kompanii-zadachi-n http://neogenda.ru/blog/jn1b91j8f1-kto-takoi-timlid-v-it-kompanii-zadachi-n?amp=true Fri, 16 May 2025 06:27:00 +0300 Артур Нек Профессия тимлид становится все более востребованной в IT-сфере. Компании ищут тех, кто умеет решать технические...

Кто такой тимлид в IT-компании: задачи, навыки и возможности карьерного роста

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

Кто такой тимлид

Тимлид (от англ. team lead, или лидер команды) — специалист, который организует рабочие процессы, совмещает технические и управленческие обязанности.
Это центральная роль в команде, и она отличается от других:
Иногда тимлида ошибочно могут называть «лид команды» или «тимлидер», но суть остается — это человек, который берет на себя ответственность за слаженную работу специалистов и эффективное выполнение задач.

Как выглядят задачи тимлида

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

Распределяет задачи

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

Отвечает за приоритизацию задач

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

Делегирует задачи

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

Выступает в роли наставника

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

Контролирует выполнение задач

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

Мотивирует команду

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

Общается с руководством и заказчиками

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

Организует рабочие процессы

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

Работает с бизнес-целями

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

Что должен уметь тимлид

Тимлид — лидер, который должен обладать рядом ключевых навыков. Их можно разделить на две категории:

Hard skills

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

Soft skills

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

Как стать тимлидом

Для тех, кто хочет стать тимлидом, существуют разные карьерные пути:
1. От технической роли
Один из наиболее распространенных вариантов — путь от разработчика или инженера к тимлиду. В этом случае специалист начинает как рядовой сотрудник, решая технические задачи, но постепенно берет на себя больше ответственности. С ростом опыта и навыков он начинает координировать задачи, помогать коллегам и в итоге становится тимлидом.
2. От архитектора и старшего специалиста
Иногда специалисты, работающие архитекторами или старшими разработчиками, могут перейти на должность тимлида. В этом случае важным шагом становится развитие навыков управления командой, так как работа архитектора связана с более высокими техническими требованиями и стратегическим планированием, а тимлид должен уметь эффективно управлять людьми и планировать рабочие процессы.
3. От менеджера проектов или программ
Менеджеры, ориентированные на организацию и координацию задач в рамках всего проекта, могут становиться тимлидами и управлять не только проектами, но и командой специалистов.
Чтобы стать успешным тимлидом и продолжать развиваться в этой роли, необходимо постоянное обучение и прокачка навыков. Существуют различные методы развития как hard, так и soft skills:
  • Технические тренинги и курсы помогут поддерживать актуальность знаний в своей области.
  • Книги, подкасты и вебинары по менеджменту и лидерству позволят развить навыки коммуникации и разрешения конфликтов.
  • Практика наставничества и обратная связь от команды дадут возможность корректировать стиль управления и улучшать эффективность работы.
Стать успешным тимлидом — это процесс, который требует не только практического опыта, но и готовности к изменениям и совершенствованию своих навыков.
Можно ли вырасти внутри компании? Как уже выяснили, да. Для этого важно:
  • Демонстрировать лидерские качества. Даже если вы не занимаете руководящую должность, всегда можно проявлять инициативу, помогать коллегам, брать на себя ответственность за выполнение задач и координировать небольшие проекты. Эти шаги могут стать основой для перехода на более высокую позицию.
  • Активно развивать навыки взаимодействия с командой. Умение находить общий язык с коллегами, разрешать конфликты, мотивировать команду и делегировать работу — важнейшие компетенции для тимлида.
  • Следить за результатами работы команды. Важно не только хорошо выполнять свою работу, но и помогать коллегам добиваться успеха, оптимизировать процессы и улучшать качество работы.
  • Развивать технические и управленческие навыки. Начинать стоит с углубления знаний в своей области, а также обучения основам управления проектами и командами. Участвуйте в тренингах, читайте специализированную литературу и проходите курсы по лидерству.
  • Участвовать в проектировании процессов. Чем больше вы вовлечены в рабочие процессы и чем чаще решаете организационные задачи, тем быстрее сможете перейти к роли тимлида. Постепенно вам будет легче управлять не только проектами, но и командой.

Почему профессия тимлид настолько востребована

Компании нуждаются в профессионалах, которые могут сочетать технические знания с управленческими навыками. Востребованность тимлидов особенно заметна в таких отраслях как IT. У этого явления есть несколько причин:
  • Управление командами. Когда количество проектов постоянно растет, компаниям нужны квалифицированные специалисты, которые смогут координировать работу команд и эффективно управлять проектами.
  • Технические знания и лидерские качества. Тимлид должен обладать как техническим опытом, так и навыками управления людьми. Такой баланс делает специалиста востребованным.
  • Рост спроса на цифровые технологии. С развитием цифровизации и новых технологий компании чаще ищут тимлидов, которые могут эффективно внедрять современные решения и управлять процессами.

Где работает тимлид: сферы и типы компаний

Рассмотрим основные области, в которых активно работают тимлиды, а также типы компаний, которые ищут таких специалистов:

IT-компании

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

Технологические стартапы

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

Кросс-функциональные команды

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

Консалтинговые и аутсорсинговые компании

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

Финансовая сфера

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

Что ждет профессию тимлида в будущем

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

Что в итоге

Тимлид в компании — это лидер, который способен вдохновить команду, решать сложные задачи и отвечать за достижение бизнес-целей. От него требуются не только технические и управленческие знания, но и умение работать с людьми, меняться и развиваться вместе с коллегами.
Если хотите улучшить процессы и повысить эффективность вашего бизнеса, поможет Neogenda. Мы специализируемся на Agile, Scrum, OKR, Канбан. Наша цель — оптимизация работы команд, улучшение стратегического планирования и достижение бизнес-целей. Более 100 компаний доверяют нам решение своих управленческих задач. Если вам нужно улучшить бизнес-процессы и достичь реальных результатов, запишитесь на бесплатную консультацию в Zoom, и мы предложим решение, которое подойдет вашему бизнесу.
]]> Что такое Discovery и зачем он нужен? http://neogenda.ru/blog/i1v69y1t21-chto-takoe-discovery-i-zachem-on-nuzhen http://neogenda.ru/blog/i1v69y1t21-chto-takoe-discovery-i-zachem-on-nuzhen?amp=true Sat, 17 May 2025 06:31:00 +0300 Артур Нек Алекс Цыбульник (Kanban Coach) и Егор Ткачёв (Agile Coach, эксперт по OKR и масштабированию Agile...

Что такое Discovery и зачем он нужен?

Алекс Цыбульник (Kanban Coach) и Егор Ткачёв (Agile Coach, эксперт по OKR и масштабированию Agile Policy) поговорили о Discovery — этапе в разработке, про который все слышали, но далеко не все понимают, как он работает и зачем нужен.

Что такое Discovery и почему он важен

«Время от идеи до результата — это time to market. Всё, что до попадания задачи в бэклог, — это Discovery. А то, что после — это Delivery», — Егор Ткачёв.
Если упростить:
  • Discovery — этап исследования. Что именно мы хотим сделать, зачем, как и для кого.
  • Delivery — этап реализации: разработка, тестирование, выкладка ценности клиенту.

Почему это важно

Разработка — самый дорогой этап. Хорошие разработчики стоят дорого, и компания хочет выжать из их времени максимум пользы. Но если в разработку пускать всё подряд, потом оглядываешься — и оказывается, что половина сделанного никому не нужна. Бюджеты потрачены, люди выгорели, пользы — ноль.
Discovery помогает экономить: отсечь ненужное, уточнить задачи, не переделывать. Это особенно актуально не только в IT, но и в любой сфере — от маркетинга до строительства.
Пример из жизни: дом без подвала
Представьте, вы строите дом:
  • Сказали строителям: «Хочу четыре этажа» — и они начали строить.
  • В середине процесса вспомнили: «А подвал бы не помешал».
  • Чтобы добавить подвал после фундамента — нужно ломать, переделывать, тратить деньги и время.
Вот зачем нужен Discovery: чтобы заранее выяснить всё, что важно. Лучше на этапе планирования потратить время на уточнение, чем потом исправлять.

Где начинается Discovery и как его выстраивать

Когда Егор приходит в команду, он первым делом смотрит на бэклог:
  • Насколько он чистый и структурированный?
  • Есть ли оценки задач?
  • Используется ли Definition of Ready — критерии, по которым задача считается готовой к началу работы?
После этого он спрашивает продукт-менеджера: «А как эти задачи сюда попали?» — и отсюда начинается выстраивание Discovery-процесса.

Где проходит точка принятия обязательств: команда, заказчик и реальность

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

А если команд несколько?

Допустим, у нас не одна команда, а несколько: одна по Scrum, другая по внедрению, третья — исследовательская. Как быть с обязательствами?
Если это компонентные команды (каждая отвечает за кусок процесса), то точка принятия обязательств наступает, как только первая команда начинает работу. Проблема в том, что дальше задача «гуляет» между другими командами, и это:
  • увеличивает простой;
  • вызывает потери информации;
  • снижает общее качество продукта.
Поэтому Scrum и Kanban рекомендуют создавать end-to-end команды, которые ведут задачу от бэклога до прода. Это позволяет:
  • избежать лишней координации между этапами;
  • повысить скорость;
  • сократить потери при передаче.

Что такое компонентная команда?

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

А если end-to-end команда невозможна?

Бывает, что создать кросс-функциональные команды нереально. Например, DevOps-специалистов или дизайнеров всего двое на компанию. Как встроить их в поток?
Есть два подхода:
  1. Частичное встраивание: выделить специалиста хотя бы на 10 % в команду. Например, сотрудник compliance подключается заранее, чтобы команда учла его требования до выхода в прод.
  2. Развитие компетенций внутри команды: на время берётся нужный эксперт, команда учится, перенимает навыки — и компетенция появляется внутри.
«Такое мы делали в банке — сначала было сложно, но через несколько итераций работало уже как часы».

Про факапы на этапе Discovery

Факапы бывают у всех. Особенно на этапе Discovery — этапе исследования и формирования идеи. Главная ошибка — начинать додумывать и брать на себя роль визионера, а не исследователя.
«Один раз я предложил на этапе Discovery сразу писать тест-кейсы — казалось, будет удобно. А потом оказалось, что задача даже не до конца понята. Всё откатили».
Вывод: сначала — критерии готовности. Всё остальное потом. И никаких тест-кейсов, пока не ясно, что вообще делаем.

Что такое критерии READY?

Definition of Ready (DoR) — набор условий, при которых задача готова к тому, чтобы её взяла команда. Спикер предлагает собирать эти критерии вместе с командой. Просто задать вопрос:
«Что вам нужно, чтобы сделать задачу быстро и качественно?»
Ответы команды — и есть база для DoR. Их можно чуть обогатить, но без фанатизма.

Как отказаться от идей, которые не проходят в бэклог?

Особенно в больших компаниях сотрудники пытаются любой ценой «протащить» идею: через руководство, через давление. Тут важно различать:
  • Мечта и недоработка — иногда идею можно доработать и попробовать позже.
  • Неподходящая идея — нужно уметь отказывать.
Пример из банка: председатель принёс идею, которая «точно принесёт миллионы». Сделали. Через квартал выяснилось — эффект на 2 500 рублей. После этого даже он начал задумываться.

Выводы: где на самом деле создается ценность

Хорошая Discovery — это не только про идеи и гипотезы. Это про чёткие рамки, вовремя сказанное «нет» и понимание командой своей зоны ответственности. Только тогда можно строить устойчивый поток ценности: от идеи до реализации — без догадок, паники и внезапных поворотов в проде.
Важно:
  • Команда должна понимать, когда начинается её обязательство.
  • Не все идеи обязаны дойти до реализации.
  • Отказ — тоже часть продуктивного процесса.
  • End-to-end команды — наше всё (если возможно).
  • Discovery — это про честность, ясность и уважение ко времени.
А еще, как показывает практика, даже самые горячие идеи от руководства могут не сработать. И это нормально. Главное — уметь исследовать, проверять и не бояться отклонить лишнее. Так продукт становится по-настоящему полезным, а команды — спокойными и эффективными.
Хотите улучшить управление в вашей компании?
Если вы хотите вывести управление в вашей компании на новый уровень, специалисты Neogenda помогут в этом. Мы работаем с крупнейшими компаниями, такими как Tinkoff, Яндекс, Авито, Сбер и Билайн, и уже обучили более 5 000 сотрудников. Наши эксперты подберут для вас индивидуальные решения, основанные на реальном управленческом опыте и современных практиках.
Запишитесь на бесплатную консультацию в Zoom, чтобы найти способы сделать вашу команду еще эффективнее.
]]> http://neogenda.ru/blog/romprg2c11-pochemu-scrum-stal-takim-populyarnim-raz http://neogenda.ru/blog/l4817o37z1-kak-opredelit-klassi-obsluzhivaniya-s-po http://neogenda.ru/blog/5b9e18xo81-kak-motivirovat-it-sotrudnikov-vzglyad-i http://neogenda.ru/blog/7d7o38nhm1-menedzher-dvigat-zadachki-ili-prinosit-p http://neogenda.ru/blog/uvrvz7ahk1-kak-stroit-i-ispolzovat-dashbordi-dlya-a http://neogenda.ru/blog/taduch8l81-kak-otsenit-uroven-zrelosti-upravleniya http://neogenda.ru/blog/0bhls9otv1-strategii-i-instrumenti-kotorie-povisyat http://neogenda.ru/blog/ibj247hhu1-kak-vnedryat-krupnie-izmeneniya-v-komand http://neogenda.ru/blog/a2fljsluh1-kak-ustroena-rabota-s-gipotezami-i-steik http://neogenda.ru/blog/46smot4so1-kak-vnedrit-sistemu-kpi-v-kompanii-posha http://neogenda.ru/blog/sa2cscxo01-marina-gladisheva-kak-smenit-kareru-pere http://neogenda.ru/blog/ct93n9czr1-preodolenie-soprotivleniya-izmeneniyam-s http://neogenda.ru/blog/yvegi2fdd1-kak-kanban-prishyol-v-lentu-istoriya-ot http://neogenda.ru/blog/6g0fv8npi1-klyuchevie-metriki-otsenki-biznes-protse http://neogenda.ru/blog/srhpdddat1-konflikti-i-upravlenie-imi-mnenie-eksper http://neogenda.ru/blog/23mc1a31k1-kanban-standart-kak-v-rossii-poyavilsya http://neogenda.ru/blog/eykgsacei1-kak-agile-i-kanban-pomogayut-top-menedzh http://neogenda.ru/blog/7fma2zf2y1-o-scrum-bez-prikras-razgovor-s-ilei-pavl http://neogenda.ru/blog/meehd51xm1-delivery-manager-kak-vladelets-produkta http://neogenda.ru/blog/et4exb09c1-borba-s-proshlim-v-biznese-kto-derzhitsy http://neogenda.ru/blog/698o14dvk1-kak-sobrat-dashbord-zdorovya-produkta-kl http://neogenda.ru/blog/ky1azbspo1-pochemu-agile-transformatsii-terpyat-kru http://neogenda.ru/blog/ondla1oxr1-evolyutsionnie-izmeneniya-i-vnedrenie-ka http://neogenda.ru/blog/1zla5neeh1-sozdanie-produktovoi-strategii-kak-razra http://neogenda.ru/blog/x5ic7hu4o1-lyubaya-kompaniya-periodicheski-upiraets http://neogenda.ru/blog/c36um46xs1-kak-postroit-kommunikatsiyu-mezhdu-steik http://neogenda.ru/blog/t7d28fg5m1-kak-nauchit-otdeli-i-podrazdeleniya-vzai http://neogenda.ru/blog/0zchoy58x1-kto-ne-riskuet-tot-ne-upravlyaet-kak-rab http://neogenda.ru/blog/rfzzbfhyl1-printsipi-kanban-kouchinga-vzglyad-ekspe http://neogenda.ru/blog/durbtpfg21-dialogi-o-itil-put-k-servisnomu-mishleni http://neogenda.ru/blog/386adbca01-safe-extreme-kak-adaptirovat-freimvork-p http://neogenda.ru/blog/sfaa0g2p11-kak-menedzheru-ispolzovat-ai-v-rabote http://neogenda.ru/blog/44dpo3au21-right-to-left-kak-stroit-protsessi-nachi http://neogenda.ru/blog/ev3vr5tms1-agile-bez-korobki-kak-ilya-pavlichenko-p http://neogenda.ru/blog/44m9l0hyg1-inzhenernie-praktiki-dlya-agentov-izmene http://neogenda.ru/blog/jxdhu734j1-kak-upravlyat-komandoi-razrabotki-dazhe http://neogenda.ru/blog/n77pinm6s1-kak-produktovoe-mishlenie-pomogaet-sozda http://neogenda.ru/blog/8pjaamc231-prostie-smisli-v-slozhnih-strategiyah-ka http://neogenda.ru/blog/zftl5kku81-masshtabirovanie-bez-illyuzii-rost-riski http://neogenda.ru/blog/kkub07ub71-teamlead-conf-kuda-rastyot-industriya-i http://neogenda.ru/blog/6cx2tas4e1-pro-product-discovery-svoimi-slovami-pro http://neogenda.ru/blog/no7mxyb891-kak-pravilno-gotovit-fasilitatsionnie-se http://neogenda.ru/blog/3p7mog4re1-effektivnaya-fasilitatsiya-udalennih-vst http://neogenda.ru/blog/3gbu5lf7d1-chto-takoe-tochka-prinyatiya-obyazatelst http://neogenda.ru/blog/09xtz2ev11-instrumentarii-menedzhera-chto-lezhit-v http://neogenda.ru/blog/0t4jfkeac1-personalnii-kanban-ot-haosa-k-sisteme-up http://neogenda.ru/blog/32j579jkp1-kak-izmerit-udovletvorennost-klientov-me http://neogenda.ru/blog/keaj1br7u1-wip-limiti-v-kanban-ne-magiya-a-upravlya http://neogenda.ru/blog/l8masotyj1-klientoorientirovannost-kompanii-printsi http://neogenda.ru/blog/rzbrzc4x51-upravlenie-neproduktivnimi-situatsiyami http://neogenda.ru/blog/s6etjx7gj1-4-situatsii-v-kotorih-obuchenie-sotrudni http://neogenda.ru/blog/lpmlutcxo1-sekreti-statik-opit-i-praktika http://neogenda.ru/blog/43srxpmry1-time-to-market-lead-time-i-customer-lead http://neogenda.ru/blog/c2lngu3ua1-petli-obratnoi-svyazi-v-kanban-metode http://neogenda.ru/blog/1pglyth951-strategicheskaya-sessiya-v-realnih-uslov http://neogenda.ru/blog/4azo2a4ig1-kanban-v-fortebank-opit-vnedreniya http://neogenda.ru/blog/ho6mbl7o91-flight-levels-universalnii-instrument-dl http://neogenda.ru/blog/0bt9ce6y41-organizatsii-urovnya-enterprise-praktika http://neogenda.ru/blog/6u5fkevg31-b2b-b2c-ili-b2g-kak-ponyat-svoyu-model-p http://neogenda.ru/blog/xxbjztsb51-prakticheskoe-primenenie-kanban-metoda-o http://neogenda.ru/blog/bvk9pdoh91-proektnii-ofis-chto-eto-funktsii-i-zadac http://neogenda.ru/blog/u8y6bf0ht1-safe-60-i-vosem-praktik-uskoreniya-potok http://neogenda.ru/blog/d8ris3atk1-mozgovoi-shturm-tehniki-praktiki-primeri http://neogenda.ru/blog/knek5shim1-vsyo-o-value-stream-mapping-karte-potoka http://neogenda.ru/blog/immvxricv1-custdev-chto-eto-kak-provodit http://neogenda.ru/blog/8o1ptxauj1-kak-protestirovat-i-vivesti-novii-produk http://neogenda.ru/blog/jfbi1t7tz1-produktovie-fichi-chto-eto-takoe-kakie-b http://neogenda.ru/blog/a3r14ciig1-daily-miting-tseli-struktura-i-oshibki-k http://neogenda.ru/blog/2v0u1gydg1-spike-v-agile-legalnii-sposob-skazat-mi http://neogenda.ru/blog/s0sbza0pv1-kriterii-priyomki-dokument-kotorii-resha http://neogenda.ru/blog/18ntejc7a1-prototipirovanie-produkta-kak-ne-potrati http://neogenda.ru/blog/60izpeyev1-agile-manifesto-pochemu-komandi-vnedryay http://neogenda.ru/blog/5kn52b2z81-forum-format-kak-predprinimatelyam-peres http://neogenda.ru/blog/0908ibs8s1-iskusstvennii-intellekt-v-menedzhmente-o http://neogenda.ru/blog/rzjxn6nhb1-vihod-iz-operatsionki-kogda-biznes-dolzh http://neogenda.ru/blog/6k67j8bd91-universitet-mishleniya-zachem-uchitsya-d http://neogenda.ru/blog/hko3p5o8m1-kak-iz-hobbi-virastaet-biznes-istoriya-y http://neogenda.ru/blog/n85ox0xfs1-kak-popast-v-federalnie-smi http://neogenda.ru/blog/dz6jgmk9u1-kak-initsiativnost-i-smekalka-prevrascha http://neogenda.ru/blog/b1gxxvnoi1-podkast-s-pavlom-smirnovim-sport-sistemn http://neogenda.ru/blog/m6fufou8t1-2025-god-kogda-ii-agenti-stali-praktikoi http://neogenda.ru/blog/ll09bpr4k1-lideri-pod-davleniem-stress-toksichnost http://neogenda.ru/blog/enatg0c7k1-kak-podbirat-lyudei-pod-biznes-zadachi-o http://neogenda.ru/blog/t6npdglbb1-kitai-kak-laboratoriya-buduschego-chto-m http://neogenda.ru/blog/lu6smvn5s1-git-dlya-neprogrammistov-zachem-on-nuzhe http://neogenda.ru/blog/6txjj8ipn1-karta-protsessa-opita-kak-ispolzovat-i-z http://neogenda.ru/blog/d5sou4bga1-otsenka-rukovoditelei-po-tsifrovim-sleda http://neogenda.ru/blog/nj6kfs6ns1-kak-sovmestit-okr-i-kpi http://neogenda.ru/blog/iulosyl1x1-gpt-dlya-menedzhera-kak-za-chas-prokacha http://neogenda.ru/blog/mazg9y3zy1-okr-v-bolshih-kompaniyah-okr-v-bolshih-k http://neogenda.ru/blog/85a4k3mli1-kak-ne-peregret-transformatsiyu-upravlen http://neogenda.ru/blog/e8y6m4ov01-korporativnie-mitapi-kak-semeinoe-kafe http://neogenda.ru/blog/mxkgavsx11-kak-naiti-pravilnih-lyudei-i-sobrat-siln http://neogenda.ru/blog/ro3yijtve1-tri-sposoba-masshtabirovaniya-kanban-na http://neogenda.ru/blog/39xrytln51-kak-okr-pomogli-sozdat-slazhennuyu-it-ko Российская инфраструктура без иллюзий: разговор с Евгением Карповым, CEO vStack http://neogenda.ru/blog/024ujg6xv1-rossiiskaya-infrastruktura-bez-illyuzii http://neogenda.ru/blog/024ujg6xv1-rossiiskaya-infrastruktura-bez-illyuzii?amp=true Wed, 01 Apr 2026 16:22:00 +0300 Евгений Карпов Евгений Карпов — генеральный директор компании vStack, российского разработчика сложного инфраструктурного ПО.

Российская инфраструктура без иллюзий: разговор с Евгением Карповым, CEO vStack

Евгений Карпов — генеральный директор компании vStack, российского разработчика сложного инфраструктурного ПО.

Что такое vStack и что именно он замещает

vStack — это отечественная платформа виртуализации и гиперконвергенции, которая позволяет компаниям строить сложные IT-инфраструктуры и поверх них уже запускать корпоративные сервисы, информационные системы и приложения. Фактически речь идет о слое, который обеспечивает вычисления, хранение и отказоустойчивость, а затем становится базой для всего остального IT в компании.
До 2022 года этот рынок почти полностью принадлежал западным вендорам: VMware, Microsoft, Nutanix и другим. Именно с ними приходится сравнивать себя российским разработчикам. По оценке Евгения, vStack уже достиг примерно 75–80% функциональной зрелости западных решений. При этом важно понимать, что западные компании шли к этому десятилетиями в спокойном режиме, а российским игрокам пришлось за несколько лет догонять то, что формировалось годами — но с одним важным преимуществом: они не тащат за собой 20–30 лет старого кода и архитектурных компромиссов.

Импортозамещение как новая реальность, а не временный режим

Для vStack импортозамещение не началось в 2022 году — тренд на развитие собственных решений был понятен уже в 2010-х. Сначала он существовал в головах инвесторов и технологических лидеров, затем стал политикой технологического суверенитета, а в какой-то момент превратился в объективную необходимость.
Идея, что «всё откатится обратно, запад вернётся — и мы снова поставим привычный софт», — это, по словам Евгения, стадия отрицания из модели Кюблер-Росс. Даже если какие-то западные вендоры формально вернутся, доверие к ним уже будет другим. Бизнес понимает: если однажды поставщик ушёл с рынка, он может сделать это снова. Когда речь идёт о критической инфраструктуре, такой риск становится неприемлемым.
Переход на отечественные решения не делается за одну ночь. Это перенос инфраструктуры, переобучение команд, пересборка процессов. В кейсах vStack полноценное импортозамещение по продукту занимает от полугода до двух и более лет. А обратно, к старым решениям, вернуться ещё сложнее: это не просто вопрос «поставить другую коробку», это пересборка всей архитектуры и повторный риск.
Есть и прагматичный мотив: сегодня многие компании получают западное ПО либо по «серым» схемам, либо взломанным, либо через параллельный импорт. Это дешево или почти бесплатно. Если вендоры вернутся, они не будут раздавать лицензии бесплатно. Перепрыгивать туда-сюда между решениями в такой ситуации становится слишком дорого и в деньгах, и в рисках.

Что реально толкает компании на переход

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

Как формируется стоимость и почему сейчас рынок странный

Рынок сейчас находится в турбулентной фазе. С одной стороны, есть зрелые сегменты, где уже сформировались лидеры, которые могут повышать цены вслед за ростом команды и функциональности. С другой — есть направления, которые ещё далеки от насыщения, как, например, классическая серверная виртуализация: по оценке Евгения, импортозамещение там пока на уровне 10–15%.
В таких сегментах многие игроки готовы идти на предельный демпинг, иногда работать почти в ноль, лишь бы занять долю и получить ключевые референсы. vStack в этой логике тоже вынужден участвовать: если речь идёт о стратегически важном заказчике, компания может предложить эксклюзивные условия, рассчитывая на долгосрочную отдачу и эффект «снежного кома».
При этом ценовая конкуренция и демпинг не отменяют одного факта: для самого заказчика переход всё равно дорогой — по времени, людям, перестройке процессов. Дешёвая лицензия не отменяет затрат на внедрение, миграцию и обучение. И чем позже компания начинает двигаться, тем выше плотность задач и тем выше вероятность принимать решения в режиме паники.

Архитектура: почему vStack не стал очередным клоном на KVM

Один из ключевых архитектурных выборов vStack был сделан ещё в 2018 году, когда команда писала первые строки кода. Тогда стоял вопрос: взять готовый open source-продукт, «обшить» его своим интерфейсом и API — или идти более сложным путём и строить собственное решение, используя только технологическую основу.
Большинство российских продуктов в виртуализации пошли по первой дороге: взяли типовой стек на базе Linux и KVM, добавили оркестратор и свой пользовательский интерфейс администратора. vStack выбрал вторую: в качестве технологической базы взял FreeBSD (с её BSD-лицензией) и поверх неё реализовал собственный проприетарный гипервизор и платформу. Это означало больше работы — но и гораздо больше контроля над архитектурой.
Такой подход дал ряд преимуществ: более «тонкий» гипервизор, высокая производительность, управляемая масштабируемость и гибкость доработок. Но есть и обратная сторона: всё, что другие просто «подтягивают» из готового open source-репозитория, vStack должен реализовывать сам. Отсюда необходимость тщательного управления roadmap’ом, приоритизации фич и честного диалога с заказчиками: чего у нас нет сейчас, когда это появится и за чей счёт.
Отдельная тема — лицензирование. Использование BSD-лицензии позволяет не раскрывать исходный код и работать корректно с точки зрения международного права, что критично, если компания смотрит не только на внутренний, но и на экспортный рынок. GPL в этом случае накладывает ограничения, к которым далеко не все готовы.

Безопасность, отказоустойчивость и сертификация

По сути, vStack строился вокруг двух опор: отказоустойчивость и производительность. В инфраструктуре крупного бизнеса платформа, которая «падает» или не выдерживает нагрузки, просто не имеет смысла — особенно если на ней крутится критичный бизнес-функционал.
С точки зрения безопасности у vStack закрытый исходный код и выстроенные внутренние процедуры безопасной разработки. Дополнительно компания идет по пути интеграции с отечественными средствами защиты, тестирует совместимость с российскими вендорами в области безопасности и проходит сертификацию ФСТЭК. Это не просто формальная бумага, а довольно жесткий технический фильтр, который требует менять не только процессы, но иногда и архитектурные решения.

Как строится работа с крупными заказчиками: пилоты, доработки и «джентльменские соглашения»

В Enterprise-сегменте никто не покупает «чистую коробку». Для средних компаний коробочное решение еще возможно, но чем крупнее заказчик, тем больше проект похож на совместную инженерную работу.
Типичный сценарий выглядит так: сначала партнер или сам вендор проводит первичную квалификацию, выясняет контекст, ограничения, задачи. Затем подключаются технические специалисты vStack, проводится серия встреч и технических сессий, где разбирается архитектура, сценарии, ограничения. После этого почти всегда стартует пилот — на реальных нагрузках заказчика, в его инфраструктуре, с его данными.
Уже в ходе пилота появляются фич-реквесты: новые функции, изменения в поведении платформы, специфические требования к интеграции. Часть из них команда внедряет сразу, если это небольшие доработки. Для крупных изменений формируется пул, оцениваются сроки и трудоёмкость, и фичи либо попадают в roadmap, либо фиксируются в контракте.
При работе с крупными корпоративными заказчиками часто используются «джентльменские соглашения», когда стороны договорились о доработках и начали движение, а юридическая фиксация догоняет чуть позже. Но это возможно только там, где есть доверие к команде и готовность выдерживать обязательства.

Кадровый голод и команда: инфраструктурщиков не хватает всем

По оценке Евгения, дефицит кадров в IT в целом и в инфраструктурной части в частности — огромный. Большая часть опытных специалистов в своё время была «вычищена» крупными компаниями с высокими зарплатами и комфортными условиями.
Команда разработки vStack сегодня — порядка пятидесяти человек, преимущественно уровня senior. Ядро работает с 2018 года, над тем же продуктом.
Разработка ведётся в основном на C, что накладывает дополнительные требования к квалификации. Сейчас компания активно запускает программы работы со студентами и выращивания разработчиков внутри, потому что на рынке готовых специалистов просто не хватает.
При этом мотивация не сводится только к деньгам. Важный элемент — осмысленность работы. Команда регулярно получает обратную связь по ключевым внедрениям, видит имена клиентов, реальные истории, где их код помог решить конкретную инфраструктурную задачу. Это создаёт ощущение причастности и поддерживает вовлечённость — особенно в такой «низкоуровневой» и сложной области, как виртуализация.

Грабли импортозамещения: маркетинг вместо реальности и «галочки» вместо пилотов

Одна из ключевых проблем рынка — подмена понятий. В маркетинговых материалах многие решения выглядят почти одинаково: одинаковые таблицы сравнения, одинаковые списки возможностей, одинаковые обещания «аналогов западных продуктов».
Евгений приводит простой критерий настороженности: если в буклетах много фраз типа «кнопки такие же, как в продукте X», почти наверняка поведение системы и взаимосвязь этих «кнопок» будут другими. В ещё более ярком виде это проявляется в темах вроде VDI, где подключение по RDP часто продаётся как полноценная VDI-платформа.
Ещё один типичная ловушка — батл-карты, которые поручают собрать ассистенту. В результате получается красивый Excel, где напротив всех пунктов стоят галочки. При этом никто не проверял, как это работает под нагрузкой, насколько реализовано глубоко и пригодно ли к эксплуатации. Решение принимается по таблице, внедрение начинается, а настоящие проблемы вылезают уже в продакшене.
Отсюда главный вывод: без пилота, без теста на реальных сценариях и нагрузках импортозамещение превращается в лотерею. И чем крупнее инфраструктура, тем дороже стоят ошибки.

Перспектива: от импортозамещения к экспортозамещению

Если первые годы российский рынок жил под знаком импортозамещения, то, по мнению Евгения, следующая фаза — это экспортозамещение: выход российских решений на международные рынки и конкуренция уже не только внутри страны, но и в мире.
Стратегически vStack и группа ITG уже смотрят в сторону СНГ, Ближнего Востока, Африки, Латинской Америки. Многие российские разработчики давно присутствуют на мировом рынке под другими брендами, и инфраструктурные решения тоже могут идти этим путём.
Конкурировать придется не лозунгами, а качеством, архитектурой, производительностью, отказоустойчивостью и тем, как продукт ведет себя в реальных боевых условиях. Но в этом, по сути, и есть взросление рынка: из режима «экстренной замены» он переходит в режим нормального технологического развития.
]]> Амбициозность и трансформация компаний http://neogenda.ru/blog/b94zcm0zu1-ambitsioznost-i-transformatsiya-kompanii http://neogenda.ru/blog/b94zcm0zu1-ambitsioznost-i-transformatsiya-kompanii?amp=true Tue, 07 Apr 2026 16:23:00 +0300 Дарья Спиридонова Спикер: Дарья Спиридонова — эксперт по корпоративной культуре, изменениям, трансформации бизнеса и управлению людьми.

Амбициозность и трансформация компаний

Спикер: Дарья Спиридонова — эксперт по корпоративной культуре, изменениям, трансформации бизнеса и управлению людьми.

Что такое амбициозность на самом деле

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

Оценка людей: потенциал, компетенции и поведенческие индикаторы

В профессиональной оценке персонала обычно смотрят две большие плоскости: потенциал и компетенции. Поведение человека «разбирают» на индикаторы: как он относится к изменениям, к стабильности, как организует себя и других, как выбирает приоритеты, от чего его реально мотивирует.
Если смотреть через эту рамку, становится заметно, что высокая организованность редко живёт в паре с очень высокой амбициозностью. Человек, который любит порядок, процессы и предсказуемость, часто менее склонен к постоянным рискованным скачкам. Но при этом амбициозная цель в компании реализуется только тогда, когда есть и те, кто бросает вызов, и те, кто обеспечивает организованное достижение результата.
Отсюда важный вывод: в компании должны присутствовать разные типы людей. И когда мы говорим, что «нам нужны амбициозные топ-менеджеры», это не означает, что амбициозными должны быть все сотрудники.
Амбициозность для топ-менеджера — нормальное требование. Но для операционного контура нам часто нужны другие профили — с более высокой устойчивостью, организованностью, склонностью к стабильности.

Амбициозный человек и амбициозная компания

Амбициозный человек и амбициозная компания — это не одно и то же.
Амбициозная компания — это не просто «у нас у всех X2 в целях». Это способность собрать правильный «набор людей»:
  • тех, кто умеет видеть дальнюю перспективу, формулировать крупные цели, задавать вектор изменений;
  • тех, кто умеет превращать эти цели в структуру, процессы и контролируемую реализацию;
  • тех, кто выдерживает операционный ритм и держит систему в устойчивом состоянии.
Важно не только то, кто в этой системе есть, но и где эти люди находятся. Амбициозный SEO и топ-менеджмент бессмысленны, если на уровень ниже нет сильных операционистов с высоким «достигаторством». И так же бессмысленно ожидать стратегических прорывов, если все ключевые роли заняты людьми с фокусом только на стабильности.

Чем амбициозность отличается от достигаторства и стратегического мышления

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

Можно ли развить амбициозность: личный опыт Дарьи Спиридоновой

Дарья приводит свой кейс. Несколько лет назад она проходила дорогой, валидный опросник оценки личности и компетенций.
Результат:
  • очень низкая амбициозность,
  • высокая организованность,
  • высокий профиль «эксперта» и «достигатора» по результату.
То есть работать много и эффективно она умеет, но масштаб целей и внутренний «размах» у неё по профилю — низкий.
Дальше — эксперимент: за полгода целенаправленно качать именно амбициозность. Что использовалось:
  • терапия и работа с личными установками;
  • менторство;
  • плотное общение с топ-менеджерами и акционерами, в том числе через подготовку их выступлений и докладов;
  • осознанное «подсаживание» себя в контекст стратегических разговоров — чтобы перенимать модель мышления, а не только техники.
Через шесть месяцев показатели по амбициозности по повторному тесту заметно выросли: с условных 15–20 из 100 до примерно 30. Это всё ещё не «бешеная амбициозность», но разница стала ощутимой как в цифрах, так и в стиле мышления.
Вывод Дарьи — амбициозность действительно можно развивать, но:
  • стартовый диапазон задается типажом личности и темпераментом;
  • «докрутить до космоса» удаётся далеко не всем;
  • динамика возможна, но дельта для интровертных, «ручных» людей часто ограничена.
Поэтому стратегия «поднять амбициозность всем руководителям до одного уровня» — иллюзия. Гораздо эффективнее опираться на сильные стороны людей и точечно развивать то, что действительно требуется для их роли.

Среда, характер и «выстрелит ли человек»

Амбициозность и стратегическое мышление могут долго не проявляться, если человек живёт в среде, где нет ни пространства для роста, ни разных ролей, ни «воздуха» для инициативы.
Вариантов развития несколько:
  • если среда агрессивная и подавляющая — человек может сломаться и пойти по пути минимальной адаптации, даже имея сильный потенциал;
  • если среда сложная, но даёт выходы — амбициозный человек будет искать другие окружения, людей, проекты, где можно реализоваться.
Дарья приводит пример с двумя своими сыновьями — с противоположными профилями личности, выросшими в одной семье. Один — мягкий, рациональный, очень эрудированный, с богатым словарём. Второй — более жёсткий, аскетичный в общении, с мышлением «да/нет/не знаю», но при этом с очень точным, почти стратегическим видением сути любого конфликта.
Это про то, что «правильных» и «неправильных» типажей нет. Есть разные потенциалы, разный стиль мышления и разная реакция на среду.

Адаптивность и устойчивость: амбиции без выгорания

Одна амбициозность без адаптивности и устойчивой психики — путь к выгоранию.
Достигать можно по-разному:
  • лбом в стену, пока не сломаешь лоб;
  • через поиск вариантов, обходных путей, креативных решений.
Амбициозным людям особенно важно:
  • получать адекватную обратную связь;
  • иметь доступ к информации, которая снижает тревожность;
  • строить не только планы рывков, но и режим восстановления.
Дарья подчёркивает: в эпоху высокой тревожности, нестабильности и постоянных изменений к амбициозности обязательно нужно добавлять адаптивность — умение корректировать маршрут, а не упираться в один-единственный сценарий.

Трансформации, сопротивление и роль трансформатора

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

Как нанимать амбициозных людей

Амбициозные люди идут не в «абстрактную компанию», а на вызов. Им важны:
  • интересная, сложная задача;
  • заметный эффект от результата;
  • адекватный уровень ответственности и полномочий;
  • достойное вознаграждение.
Нельзя ждать, что амбициозный и зрелый специалист придёт на маленькую зарплату и скучные задачи.
При поиске таких людей:
  • не стоит рассчитывать только на отклики по вакансии — чаще всего нужен прямой поиск по компаниям и контекстам, где такие люди вообще могут быть;
  • важно, чтобы на уровне интервью совпали «языки» — руководитель и кандидат должны понимать друг друга, даже если сильно различаются по типажу;
  • не стоит брать «копию себя» — наоборот, эффективнее добирать людей с другими индикаторами, которые закрывают ваши слабые места;
  • для топовых ролей полезно использовать не только интервью по компетенциям, но и профессиональную оценку (опросники, assessment), особенно если делаются большие ставки.
Ключевая ловушка: руководители по привычке нанимают тех, с кем психологически комфортно и «всё понятно». Но для амбициозного роста нужны как раз те, кто немного «царапает» привычную картину и способен расширять границы.

Лидерство, ценности и бренд работодателя

Люди приходят в компанию, но уходят от руководителя.
Бренд работодателя начинается не с красивых постов, а:
  • с понятного продукта и реальной ценности, которую компания создаёт;
  • с здравого смысла в управленческих решениях;
  • с того, как себя ведут лидеры и как относятся к людям.
Амбициозные сотрудники идут на смысл и вызов. Если внутри компании декларируются одни ценности, а в реальности люди сталкиваются с другим, доверие быстро разрушается.
Важно:
  • честно описать, что значит быть лидером именно в этой компании — какие поведения и решения считаются «нормой»;
  • фиксировать и проговаривать критерии лидерства и амбициозности на понятном языке, а не только в презентациях;
  • не забывать про закрепление результата: празднование успехов, признание вкладов, ритуалы «мы это сделали» — всё это превращает разовое достижение в часть культуры.

Что делать собственнику или SEO: с чего начать

Амбициозность компании начинается с честного разговора с самим собой.
Дарья предлагает несколько простых, но честных шагов:
  • Ответить себе на вопрос: готов ли я управлять, а не просто «ставить задачи». Управление амбициозной, неоднородной командой требует времени, внимания, эмоциональных затрат. Это не про «я один раз объяснил».
  • Проверить: могу ли я выдержать сильного, но неудобного сотрудника. Готов ли я взять к себе в команду человека, который умнее меня в своей области, спорит, задаёт неудобные вопросы, но приносит прорывной результат?
  • Начать с маленьких шагов. Не обязательно сразу перестраивать всю компанию. Можно начать с одного сильного игрока, одного направления, одного пилотного изменения и посмотреть, как система реагирует.
  • Быть честным по поводу инвестиций. Амбициозные цели, трансформация, привлечение сильных людей — это не «волшебная таблетка». Это английский газон: ежедневная стрижка, постоянный уход и долгосрочное вложение.
]]> Максим Дорофеев: эффективность без цифр, ярлыков и самобичевания http://neogenda.ru/blog/1u6blotnj1-maksim-dorofeev-effektivnost-bez-tsifr-y http://neogenda.ru/blog/1u6blotnj1-maksim-dorofeev-effektivnost-bez-tsifr-y?amp=true Thu, 09 Apr 2026 16:29:00 +0300 Максим Дорофеев В рамках рубрики «Нетипичные вопросы профессионалу» обсудили с Максимом Дорофеевым — автором книг «Путь джедая»...

Максим Дорофеев: эффективность без цифр, ярлыков и самобичевания

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

О самооценке и иллюзии объективности

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

Об опасности «цифро блудства»

Современный культ измерений создаёт иллюзию научности.
Методики, которые обещают «повысить эффективность на 24%», вызывают у Максима скепсис:
«ни ссылок на исследования, ни операциональных определений — просто красивые цифры».
Он приводит пример из Деминга: утверждение «одеяло на 50% состоит из шерсти» бессмысленно, пока не описан процесс измерения. Важно не число, а способ, которым оно получено.
«Описывайте процесс получения данных — иначе вы не измеряете, а гадаете».
Деминг также писал, что наиболее значимые для бизнеса метрики — неизмеримы.
То, что действительно важно удовлетворение клиента, чувство уюта, доверие — не сводится к процентам.

Кто такие «инфо-цыгане» и чем они отличаются от специалистов

На вопрос, не стали ли консультанты по эффективности инфо-цыганами, Дорофеев отвечает с иронией:
«Инфо-цыган — это агент 007: ноль опыта, ноль практики, семь постов в день».
Он признаёт, что не любит слово «продуктивность» — оно стало слишком узким.
На деле люди приходят не за методиками, а за способами жить легче:
  • меньше выгорать,
  • перестать откладывать важное,
  • соединить «хочу» и «делаю».
Это уже ближе к психологии, чем к тайм-менеджменту. Поэтому вместо бесконечного «контента» нужна работа с убеждениями.

Почему учить взрослых — это не про контент

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

Почему большинство практик не приживаются

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

Эффективность против креатива: враги или союзники

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

Эффективность в команде: когда лучше не спешить

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

Что нового появилось в сфере эффективности

За последние десятилетия ничего принципиально нового не придумано. Все современные подходы — переупаковка древних идей: внимание, осознанность, работа с умом.
«Со времён просветления Будды ничего радикально нового не появилось», — отмечает Дорофеев.
Главные прорывы сегодня — в способах «доставки в мозг», то есть в том, как помочь человеку реально внедрить изменения, а не просто услышать о них.

Какие техники персональной эффективности реально работают, а какие устарели

Связанный вопрос: какие из широко известных техник персональной эффективности на деле оказались не такими уж эффективными или со временем потеряли актуальность?
Честно говоря, абсолютных универсальных практик не существует. То, что работает для одного человека, может совсем не подойти другому. Вот, например, правило двух минут Дэвида Алина — многие его хвалят, но иногда оно выстреливает обратным эффектом. Две минуты в современном мире — это много, а постоянное выполнение мелких задач может буквально “сжечь” твой мыслительный ресурс к середине дня. И тогда на сложные задачи сил уже не хватает, и весь цикл повторяется снова и снова.
Дэвид Алин не учитывает мыслительный ресурс — только время. Поэтому иногда имеет смысл адаптировать правило под себя, например, до 15 секунд на небольшие действия. Всё индивидуально.

Логическое мышление и “хули-логика”

Мы с Рустамом Агамолиевым начали разрабатывать курс по неформальной, “хулиганской” логике, потому что людям катастрофически не хватает базового логического мышления. Идея проста: не научить людей строить сложные формальные схемы, а помочь избегать самых частых логических ошибок в повседневной жизни и при планировании проектов.
В основе — когнитивно-поведенческая психотерапия и элементы джедайских техник: сначала развиваем навыки логики, потом учимся пересматривать свои убеждения и принимать сложные решения.
Примеры наших практик: вопросы планирования типа “А что бы что? А то что? А чего предъявишь?” — с хитрыми правилами валидации ответов. Всё это весело, но эффективно. Мы называем это хули-логика.

Изменить жизнь за год — реально ли?

Вопрос: можно ли за год изменить свою жизнь, если раньше “проживал овощем”?
Да, можно. Но важно уточнить, что значит “овощ”. Это может быть клиническая депрессия или просто низкая активность без серьезных медицинских проблем. Если подходить системно и аккуратно, первые улучшения видны уже через 2–3 недели. Иногда достаточно выковырять одну ключевую установку и жизнь меняется сразу.

Замер собственной ёмкости дел

Как понять, сколько задач реально вместить в to do лист? Мы придумали “критерий впихуемости”: оцениваешь, сколько задач сделал за прошлую неделю — грубая зона твоей вместимости на следующие дни. Главное избегать явного перегруза.
Неважно, что ты планируешь точность до последней галочки. Плюс-минус 20% и это уже отлично. Большинство людей сталкиваются с кратным превышением, особенно в персональной организации, и это нужно контролировать.

От личной боли к обучению других

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

Упаковка и продажа опыта

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

Советская школа психологии и ускоренное обучение

Мы вдохновляемся советскими методиками (Гальперин, Талызин, Бадмаев) по быстрому обучению взрослых.
Принцип: полное целостное знание редко входит в голову с первого раза, а вот четверть информации усваивается быстро и эффективно.
Современные западные тренинги теряют часть контента, но всё же адаптируют полезное. Нам важно комбинировать лучшее из обоих подходов для максимально практичного обучения.
]]> Почему HR становится громоотводом и как выйти из этой роли http://neogenda.ru/blog/ipzet2ri51-pochemu-hr-stanovitsya-gromootvodom-i-ka http://neogenda.ru/blog/ipzet2ri51-pochemu-hr-stanovitsya-gromootvodom-i-ka?amp=true Tue, 14 Apr 2026 16:32:00 +0300 Яна Федорова Спикер: Яна Федорова — карьерный консультант, ментор для HR и старший HR-бизнес-партнер компании «ВсеИнструменты.ру».

Почему HR становится громоотводом и как выйти из этой роли

Спикер: Яна Федорова — карьерный консультант, ментор для HR и старший HR-бизнес-партнер компании «ВсеИнструменты.ру».
Во многих компаниях HR оказывается в позиции буфера между бизнесом, руководителями и сотрудниками. К HR идут с жалобами, через HR пытаются «разрулить» сложные ситуации, на HR спускают непопулярные решения. В итоге именно HR ловит на себя максимум эмоций, хотя реальные причины напряжения лежат в процессах, управленческих практиках и культуре.
Содержание:
  • почему HR так часто оказывается «громоотводом»;
  • какие корневые причины создают постоянный поток сложных разговоров;
  • какие инструменты есть у HR, чтобы выйти из роли вечного посредника;
  • что нужно менять на уровне системы управления в компании.

Три корневые причины, почему HR становится буфером

Роль HR как «сервисной функции»

Во многих организациях HR-функцию воспринимают как сервис:
это «те ребята, которые решат любые проблемы» и которым можно передать все неприятные, некомфортные, неоднозначные задачи.
В результате HR:
  • постоянно в операционке;
  • выполняет роль посредника между бизнесом и сотрудниками;
  • становится «заложником» ожиданий: руководители отдают туда всё, что им самим делать неудобно.
Это следствие двух факторов:
  • Оргмодель и позиционирование функции. HR изначально выстроен как сервис: «обслужить, оформить, разрулить».
  • Слабая экспертиза внутри HR. Там, где HR сами не умеют работать на стратегическом уровне, они естественным образом застревают в операционной роли.
Отсюда первый вывод: чтобы выйти из роли «громоотвода», HR-команде нужно усиливать свою экспертность и перестраивать ожидания бизнеса: от сервиса к партнёрству.

Менеджерская незрелость

Вторая большая причина — уровень зрелости руководителей.
Ключевые проявления:
1. Руководиавленческие ошибки, которые почти гарантированно создают конфликт:
  • смена KPI или системы премирования посреди периода;
  • резкое изменение условий работы без подготовки;
  • отсутствие прозрачных ожиданий к результатам и поведению.
Яна приводит фразу из опыта международной компании:
Если руководитель не уделяет время социальному диалогу, вскоре он будет тратить всё время только на социальный диалог.
2. Когда руководители не инвестируют в отношения с командой и культуру открытого диалога:
  • простые вопросы не решаются вовремя;
  • накапливаются обиды и недосказанность;
  • в какой-то момент это выстреливает в виде тяжёлых конфликтов — чаще всего через HR.

Культура и система: когда people-фокус отсутствует

Третий фактор — то, как устроены система управления и HR-процессы.
Примеры типичных системных проблем:
  • У руководителей нет ни одного KPI по людям: только выручка, маржинальность, производительность.
  • Метрики по текучести, вовлечённости, преемственности либо отсутствуют, либо считаются «чужими» и живут только в HR.
  • HR-показатели называются «HR KPI», а не people KPI, и бизнес не чувствует свою ответственность за них.
Когда же people-метрики становятся общими:
  • цель по текучести одновременно стоит и у HR, и у директора направления;
  • это не «их KPI», а наша совместная зона ответственности;
  • руководитель воспринимает работу с людьми как часть своей основной задачи, а не как то, что можно делегировать HR.

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

Неадекватный перформанс-цикл и размытые стандарты

Классический сценарий: performance review раз в год.
Что это создаёт:
  • Руководитель «копит» обратную связь весь год — в лучшем случае что-то себе помечает, в худшем просто опирается на память.
  • Через год сотруднику говорят: «Ты ниже ожиданий, и вообще в январе ты сильно не дотянул».
Для сотрудника это шок:
  • он не помнит январь;
  • он жил в ощущении, что «всё нормально»;
  • решение уже принято, хотя шансов что-то скорректировать по ходу года ему не давали.
Дополнительно усугубляет ситуацию:
  • размытые ожидания: «надо работать лучше», «старайся больше»;
  • отсутствие конкретных стандартов и критериев «в ожиданиях / выше ожиданий».
В такой системе:
  • обратная связь всегда запоздалая;
  • любые итоги воспринимаются как несправедливость;
  • HR оказывается между разъярённым сотрудником и растерянным руководителем.

Отсутствие инструментов и несостыкованная оргмодель

Пример из производства:
  • есть начальник смены с 20 сотрудниками;
  • у каждого сотрудника — 15 смен в месяц, производство непрерывное;
  • компания «раскатывает» стандарт: регулярные one-to-one по часу.
Может ли руководитель при таком графике качественно провести 20 часовых встреч в месяц? Очевидно, нет.
Возникает эффект:
  • формальные требования «для всей компании одинаковые»;
  • в реальности на операционном уровне это:
  • либо не выполняется,
  • либо превращается в «галочку».
В результате:
  • формально «процесс есть»;
  • по сути — нет ни реальных разговоров, ни изменений поведения.

Нехватка компетенций: давать и принимать обратную связь

Обычно вспоминают про навык давать обратную связь, но не менее критично — умение принимать её.
Типичные ситуации:
  • Руководителей обучают, как давать feedback,
  • но их собственные руководители обратной связи не дают.
Сотрудники не видят «замкнутого контура»: сверху вниз — да, снизу вверх — нет.
Добавим сюда страхи:
  • «Если я скажу Васе, что он плохо работает, он обидится и перестанет помогать».
  • «Если похвалю, зазнается и перестанет работать».
Иногда у этих страхов есть реальные корни (бывали случаи, когда после публичной похвалы человек «потерял берега»), но как универсальная стратегия это разрушительно.
Без навыка безопасного обмена обратной связью:
  • всё копится внутри;
  • напряжение растёт;
  • в какой-то момент HR получает «готовый конфликт».

Типичные кейсы, когда HR тушит пожар вместо причин

«Давайте срочно уволим Васю»

Классика: руководитель приходит к HR: «Васю надо увольнять. Вообще не работает. Подготовь документы».
HR начинает спрашивать:
  • Давали ли вы Васе обратную связь раньше?
  • Обсуждали ли ожидания?
  • Пытались ли менять задачи под его сильные стороны?
Часто оказывается:
  • полгода никаких разговоров не было;
  • руководитель внутренне давно «списал» сотрудника;
  • перестал давать ему новые задачи;
  • дистанцировался, но открыто ничего не говорил.
В такой ситуации HR сталкивается с:
  • шокированным сотрудником («я думал, всё нормально»);
  • раздражённым руководителем («я уже всё решил»);
  • отсутствием нормальной документации и шагов работы с результативностью.
То, что могло быть решено через регулярную обратную связь и корректировку задач, превращается в конфликт, который «падает» на HR.

Внезапные изменения условий: графики, KPI, рейтинги

Другой типичный пример:
  • бизнес меняет графики смен,
  • или систему KPI,
  • или формулу рейтинга и премий уже посреди периода.
Даже если причина объективна (изменился рынок, новые приоритеты собственника), решают часто так: «С завтрашнего дня живём по-новому. Вот новые правила».
Результат:
  • буря недовольства;
  • ощущение несправедливости («мы уже отработали половину периода по старым правилам»);
  • мощный эмоциональный фон, который снова летит в HR.
Как можно было бы иначе:
  • заранее объяснить, что изменилось во внешнем контексте;
  • вовлечь команду в обсуждение:
  • «Вот что происходит, давайте вместе подумаем, как адаптировать систему»;
  • честно проговорить:
  • на этот период — такой временный компромисс, на следующий — обновлённая, более справедливая модель.
Особенно важно:
  • объяснять бизнес-контекст простым языком;
  • показывать причинно-следственные связи: «Если мы не изменим X, произойдёт Y».
Сотрудники гораздо лучше принимают изменения, если понимают, зачем и как это связано с их вкладом.

Как HR выходить из роли буфера: данные и проактивность

HR-данные как радар

Первое, что может делать HR на своём уровне — видеть проблемы до того, как они превращаются в пожар.
Для этого можно использовать:
  • результаты опросов вовлечённости и удовлетворённости;
  • динамику индексов по командам;
  • тональность комментариев;
  • показатели текучести и причины увольнений.
Примеры «сигналов»:
  • индекс вовлечённости в команде падает;
  • в комментариях усиливается негатив и агрессия;
  • растёт текучесть по причинам «отношения с руководителем» или «условия работы».
Это повод HR:
  • не ждать, пока конфликт станет личной драмой,
  • а идти в команду и к руководителю заранее — с диагностикой и поддержкой.

Постоянное присутствие в бизнес-повестке

Второй важный элемент — быть в контексте бизнеса:
  • участвовать в ключевых совещаниях;
  • слышать тон и динамику общения между руководителями;
  • понимать, какие решения назревают.
Иногда данные ещё «молчат», но:
  • на планёрках уже чувствуется скрытая конфронтация;
  • выходит новый руководитель, и понятно, что команду «потрясёт»;
  • появляются признаки недоверия или конкуренции между подразделениями.
Задача HR:
  • увидеть это заранее;
  • предложить формат работы (командные сессии, диагностики, фасилитацию);
  • помочь провести команду через стадии притирки управляемо, а не «само как-то».

Инструменты разделения ответственности: HR ≠ пожарная команда

Треугольник ответственности

Простой, но мощный инструмент — условный «треугольник ответственности».
Когда руководитель приходит с запросом «увольняем/спасай/сделай что-нибудь», HR последовательно исследует три стороны:
1. Руководитель.
  • Что ты уже сделал?
  • Давал ли ты обратную связь?
  • Проговаривал ли ожидания?
  • Менял ли задачи/формат работы?
2. Сотрудник.
  • Какие конкретные факты поведения ты наблюдаешь?
  • Чем подтверждается гипотеза, что человек «не тянет»?
  • Есть ли сферы, где он стабильно силён?
3. HR.
  • На каком шаге тебе нужен мой опыт?
  • Чем я могу поддержать:
  • репетиция разговора, подготовка формулировок, участие в встрече как наблюдатель, настройка процессов?
Важный момент — формулировки:
  • не «я пойду и всё сделаю за тебя»,
  • а «давай посмотрим, где тебе нужна моя поддержка, а где это твоя зона ответственности».
Так HR остаётся партнёром, а не тем, кто «разрулит всё сам».

Модель GROW для сложных кейсов

Для более комплексных ситуаций подходит модель GROW:
1. G — Goal (цель).
  • Чего на самом деле хочет руководитель?
  • Часто не «уволить Васю», а «выполнить план», «собрать сильную команду», «перестать постоянно тушить пожары».
2. R — Reality (реальность).
  • Что происходит сейчас?
  • Какие ресурсы есть?
  • Каковы реальные ограничения (например, юридические, социальные, ценностные)?
3. O — Options (варианты).
  • Какие шаги возможны?
  • Что будет, если…?
  • Какие сценарии есть помимо «уволить» или «терпеть»?
4. W — Will (воля/план действий).
  • Что конкретно ты сделаешь?
  • В какие сроки?
  • Чем я как HR могу поддержать?
Модель помогает:
  • уйти от эмоций к структуре;
  • увидеть шире, чем «чёрно-белый» выбор;
  • совместно найти решения, которые учитывают интересы бизнеса, людей и реальность ограничений.

Что нужно менять на уровне компании

Даже самый сильный HR не вытянет системную историю только индивидуальной работой. Нужны изменения в управленческой системе.
Ключевые элементы:

Перформанс-цикл разумной частоты

Частота зависит от уровня:
  • топ-менеджмент — раз в полгода;
  • эксперты и ведущие специалисты — раз в квартал;
  • операционные сотрудники (производство, колл-центр) — раз в месяц.
Важно:
  • чётко прописать стандарты и критерии оценки;
  • завязать обсуждение результатов на реальные решения: развитие, корректировка задач, изменения процессов.

Управленческие ритуалы

В повестку руководителя должны быть встроены:
  • регулярные one-to-one с сотрудниками;
  • командные встречи, где обсуждаются результаты и ожидания;
  • форматы обмена обратной связью «по кругу».
Это не разовые акции, а ритуалы, которые:
  • формируют культуру открытого диалога;
  • позволяют ловить вопросы до того, как они превращаются в конфликт.

Обратная связь как управленческая компетенция

Важно, чтобы:
  • умение давать и принимать обратную связь было зашито в профиль компетенций руководителя;
  • оценивалось при:
  • подборе,
  • аттестации,
  • калибровках и talent review;
  • топ-менеджмент демонстрировал это поведение лично, а не только требовал снизу.
Люди очень быстро считывают реальную модель: если наверху обратной связи нет, все формальные программы «ниже» будут восприниматься как формальность.

Обучение: просто, коротко, много практики

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

Кейс 1: производство и ежемесячная обратная связь

8.1. Исходная задача
На производстве:
  • сменные графики;
  • начальники смен с большими командами;
  • новая система премирования, связанная:
  • с командной целью на смену;
  • с поведенческими стандартами каждого сотрудника.
Каждый месяц подводились итоги, проходила калибровка, и руководитель должен был:
  • вернуться к каждому сотруднику;
  • дать обратную связь: «ниже / в ожиданиях / выше ожиданий» с конкретикой.
На бумаге — идеальная схема. В реальности:
  • после запуска опрос показал:
  • только около 15% сотрудников реально получают обратную связь.
Что тормозило? В процессе диагностики выявили:
  • страхи руководителей:
  • «обидится, перестанет помогать»;
  • «у нас сложившиеся отношения, не хочу их портить»;
  • ощущение «нет времени»:
  • 20 человек, непрерывное производство, час на каждого — нереально.
Что сделали? Собрали типовые страхи и отработали их на практикумах и разбирали, как говорить честно и при этом поддерживающе.
1. Изменили формат обратной связи: вместо часовых разговоров сделали короткий, структурированный формат;
подготовили одностраничный шаблон с опорными фразами:
  • «В этом месяце у тебя хорошо получилось…»;
  • «Вот где можно сделать лучше…»;
Разговор стал занимать 10–20 минут и мог проходить в неформальной обстановке (например, в кофе-зоне).
2. Расширили «цепочку обратной связи» вверх.
  • Обратили внимание, что руководители начальников смен сами не получают регулярную обратную связь.
  • Начали развивать этот навык на всех уровнях, а не только «снизу».
Результат.
Со временем:
  • увеличилась доля сотрудников, которые подтверждали, что получают обратную связь;
  • стал расти процент оценок «выше ожиданий» — люди начинали понимать, что сделать, чтобы вырасти;
  • параллельно вырос индекс вовлечённости.
Ключевой вывод: когда обратная связь встроена в циклы работы и систему премирования, и под неё адаптированы инструменты — это начинает работать и на производстве.

Кейс 2: культура 360 и живой обратной связи во «ВсеИнструменты.ру»

В компании «ВсеИнструменты.ру» одновременно используются:
1. Регулярная 360-обратная связь для руководителей.
2. Каждые 6 месяцев каждый руководитель получает оценку:
  • от своих подчинённых,
  • от своего руководителя,
  • от коллег по кросс-функции.
3. Чёткие стандарты и критерии помогают видеть реальные зоны роста.
4. Живые сессии обратной связи в дирекции.
5. Раз в полгода проходят встречи, где:
  • руководитель дирекции даёт обратную связь команде;
  • команда даёт обратную связь руководителю;
  • участники дают обратную связь друг другу.
Это формирует:
  • безопасную среду;
  • видимую модель: «обратная связь — норма»;
  • практику диалога «в обе стороны», а не только сверху вниз.
]]> Тимлид, который должен стать ненужным: как на самом деле устроена эта роль http://neogenda.ru/blog/pu07o0ava1-timlid-kotorii-dolzhen-stat-nenuzhnim-ka http://neogenda.ru/blog/pu07o0ava1-timlid-kotorii-dolzhen-stat-nenuzhnim-ka?amp=true Thu, 16 Apr 2026 16:39:00 +0300 Иван Ботанов Интервью со спикером: Иван Ботанов, тимлид и автор блога «В офисе»

Тимлид, который должен стать ненужным: как на самом деле устроена эта роль

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

«Если команда самоорганизована, тимлид ей не нужен»

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

Менеджмент, в котором ты должен стать ненужным

Здесь возникает естественный вопрос: неужели работа тимлида — это неблагодарная миссия?
Иван улыбается: кому-то кажется, что да. Но на самом деле это высшая форма управленческого мастерства.
Тимлид — не контролёр и не надсмотрщик. Он ближе к коучу: помогает людям расти, вместе с командой строит процессы, снимает барьеры, выводит работу на новый уровень. И если кто-то из команды «перерастает» тимлида — это не угроза, а лучший результат.

Можно ли понять кандидата за одно собеседование

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

Как тимлид прогнозирует сроки

Тот самый вопрос, который преследует каждого менеджера: «Когда всё будет готово?»
Иван считает, что тимлид обязан опираться не на интуицию, а на данные. В Scrum это velocity команды, история выполнения задач, прогнозы по стори поинтов.
Иногда прогнозы попадают удивительно точно — но это не «французская палата мер и весов», а просто глубокое знание своей команды и её динамики.

Можно ли «подсидеть» тимлида

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

Тимлид ради повышения зарплаты? Нет.

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

Тимлид как призвание? Скорее — склад личности

Иван не любит слово «призвание», но признаёт: да, это про предрасположенность.
Тем, кто любит писать код, нравится работа с системами и архитектурой, вовсе не обязательно переключаться на людей.
Тимлид — это про:
  • мотивацию,
  • ожидания,
  • работу с конфликтами,
  • сложные разговоры,
  • эмпатию и в то же время трезвость.
Тем, кому это не нравится, туда идти не стоит.

Как нанимают тимлидов

Технические навыки — важны, но вторичны.
Главное — это:
  • умение работать с метриками,
  • навык ведения one-to-one,
  • способность разрешать конфликты,
  • способность объяснять и продавать идеи команде,
  • понимание мотивации людей.
Тимлид — это гибрид коуча, аналитика, фасилитатора и иногда психолога.

Почему плохие решения начинаются с плохой коммуникации

Один из самых сильных фрагментов разговора — про ситуацию, когда новый разработчик видит плохой код и сразу предлагает «переписать всё».
По мнению Ивана, настоящий профессионал начинает не с критики, а с вопроса: почему так?
Нередко плохой код — это не некомпетентность, а наследие бизнес-ограничений, старых систем или высокой нагрузки.
Зрелость разработчика — в умении понять контекст.

Конфликты тимлид — scrum мастер

Здесь Иван довольно категоричен: в команде не должны одновременно существовать две роли, конкурирующие за процесс.
  • Если есть сильный тимлид, он выполняет часть функций scrum мастера.
  • Если есть сильный scrum мастер — тимлид не нужен.
Параллельное существование двух менеджеров процесса — почти гарантированный конфликт.

Откуда берётся выгорание

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

Как тимлид увольняет людей и уходит сам

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

Тимлид нужен не всегда. Но чаще — да

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

Как оценивать себя и нужно ли учиться

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

Нужно ли разрушать миф о том, что тимлид — это «главный разработчик»

Иван уверен: да, нужно.
Индустрия постепенно взрослеет, меняется, и роль тимлида становится ближе к коучинговой, а не технической. Но для этого нужно говорить, объяснять, показывать примеры.
Именно такие разговоры, как сегодняшний, и помогают менять культуру.
]]> «Особенности трансфера: специалист — руководитель — владелец» http://neogenda.ru/blog/bsi2z6fh41-osobennosti-transfera-spetsialist-rukovo http://neogenda.ru/blog/bsi2z6fh41-osobennosti-transfera-spetsialist-rukovo?amp=true Tue, 21 Apr 2026 17:37:00 +0300 Александр Синютин Спикер: Александр Синютин — бизнес-наставник, тренер, кандидат психологических наук, экс-банкир и владелец бизнеса.

«Особенности трансфера: специалист — руководитель — владелец»

Спикер: Александр Синютин — бизнес-наставник, тренер, кандидат психологических наук, экс-банкир и владелец бизнеса.
На первый взгляд эта тема может показаться слегка абстрактной: вроде бы не разбор конкретного кейса, а разговор про роли, уровни и трансформации. Но Александр сразу честно говорит: если бы он каждый день не видел в живой работе, как неправильный переход между ролями ломает людям карьеры и бизнесы, он бы эту тему даже не предлагал.
Трансфер «специалист → руководитель → владелец» — это не красивая схема для презентации, а одна из ключевых линий развития человека в бизнесе. И проблема в том, что внешне человек уже перешёл на новый уровень (его назначили, повысили, он открыл бизнес), а в голове — нет.
Тогда начинается самое интересное:
  • руководитель продолжает жить как специалист,
  • владелец — как руководитель,
  • бизнес — как система — начинает болеть.

Личный путь как пример трансформаций

Чтобы не говорить абстрактно, Александр встраивает в тему свою собственную историю — сразу по нескольким «линиям роста».

Спорт: «я был не заточен под дзюдо — но стал мастером спорта СССР»

В первом классе отец отвёл его в секцию дзюдо. Сам Александр с детства любил рисовать, был замкнутым ребёнком, мог часами сидеть под столом с карандашом. Но у отца была простая логика: «Рисовать сам научится, а вот защищаться надо. В художественную школу — девчонок отдают».
Дзюдо он не любил и, по его словам, «совершенно не был под это создан». Но у него не было опции «не ходить», и за десять лет он дорос до мастера спорта СССР по дзюдо, обладателя чёрного пояса. Это первая важная линия:
даже если ты «не создан» под что-то, при длительном усилии рост всё равно происходит.

Обучение: от «я буду переводчиком» до кандидата наук

В школе он мечтал быть переводчиком и собирался поступать в иняз. В самый последний момент передумал и заявил родителям, что пойдёт в МГИМО — «потому что переводчик переводит чужие мысли, а я хочу, чтобы переводили мои».
С первого раза не вышло, но со второго он поступил и закончил МГИМО по специальности международные финансы.
Дальше была банковская карьера и параллельный образовательный путь:
  • сначала МГИМО — как самая ценная «медаль на груди»,
  • затем защита кандидатской по психологии,
  • сейчас работа над докторской диссертацией.
То есть рост по линии знаний тоже идёт ступенчато и долго.

Карьера и бизнес: от курьера до владельца холдинга за несколько лет

Поскольку учился на вечернем, днём нужно было зарабатывать. Александр решил пойти в банк. Его полгода никуда не брали, и только по большому блату взяли курьером.
Дальше началась быстрая лестница вверх:
курьер → специалист → и.о. начальника отдела → начальник отдела → начальник департамента → начальник крупного департамента → зампред правления → первый зампред → председатель правления → владелец холдинга.
Всё это заняло примерно 4–5 лет. Но важно понимать контекст — это были 90-е, другая скорость процессов и другой уровень риска.
Характерный момент: студент без денег и перспектив превращается в «холеного мужчину с уверенной физиономией». Это иллюстрация того, как сильно меняются среда, статус, ощущение себя.

Кризисы: «меня не убили — это главная победа 98-го»

Первая серьёзная встряска — банковский кризис 1995 года. Банк, в котором он работал, развалился, и его просто выгнали на улицу.
Следующий удар — кризис 1998 года. Александр говорит, что главное достижение того времени — его не убили. Несколько коллег этот период не пережили.
Сам он остался жив, но лишился практически всего, подписывая на себя огромные расписки. Смысл этого фрагмента не в драме, а в том, что трансформации в жизни происходят волнами. То ты наверху, то снова у обнуления, то снова строишь с нуля. И каждый раз ты проходишь этапы: «никто → специалист → сильный специалист → руководитель → владелец» — но уже на других уровнях.

Три вселенные: специалист, руководитель, владелец

Ключевая идея выступления: специалист, руководитель и владелец — это не ступеньки зарплаты, а три разные вселенные.
У каждого — свои задачи, своя логика, своё мышление. И если человек формально поднялся, но внутренне остался на прежнем уровне, он становится источником системной проблемы.
Александр предлагает сначала разобраться: что вообще отличает специалиста, руководителя и владельца?

Функции специалиста: оркестровый музыкант

Специалист — это «музыкант в оркестре», даже если он первая скрипка.
Его роль — делать работу, а не организовывать чужую.
Ключевые задачи специалиста:
  • знать свои задачи, компетенции, зоны ответственности и придерживаться их;
  • понимать и соблюдать принципы работы компании;
  • быть профессионалом своего дела;
  • выполнять работу строго по ТЗ, а не «как мне кажется лучше»;
  • делать работу в срок, потому что «ложка хороша к обеду».
Александр отдельно подчеркивает боль каждого руководителя: часто вместо выполнения ТЗ появляются «улучшайзеры», например, «А мне кажется, так лучше».
И в этот момент руководитель мысленно говорит: «Сука…» — и дальше цензурирует себя.
Работу, сделанную отлично, но сильно позже дедлайна, бизнесом часто воспринимают как проблему, а не заслугу. Специалисту это не всегда очевидно.

Функции руководителя: дирижёр, а не лучшая скрипка

Руководитель — это уже не музыкант, а дирижёр. И его задача — не играть лучше всех, а обеспечить её согласованный звук.
Основные функции руководителя:
  • обеспечивать чёткую и слаженную работу подразделения или компании;
  • обеспечивать получение прибыли, а не только «делать интересные проекты»;
  • улучшать и оптимизировать бизнес;
  • управлять коллективом.
Ситуация, когда руководитель увлечён «развитием команды» и «клевыми проектами», а владелец спрашивает: «А деньги где?» — очень типична.
Если дирижёр спускается в оркестр и начинает каждому скрипачу объяснять пальцовку, он в этот момент перестаёт быть дирижёром. И оркестр остаётся без управления.

Функции владельца: мечтатель, стратег и энергетическое ядро

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

Чем выше роль — тем опаснее неправильное поведение

Александр формулирует важное предостережение:
Чем выше положение человека, тем больше вреда он может нанести, нарушая свои компетенции.
  • Если специалист делает ошибки, ущерб ограничен его задачами.
  • Если руководитель продолжает жить как специалист — страдает уже отдел.
  • Если владелец продолжает жить как руководитель и залезает во всё сам — страдает целый бизнес.
Отсюда — очень частая картина: владелец по три года не отдыхает, выглядит убитым, но продолжает «героически тянуть». Александр таким людям говорит:
«Ты три года убивал свой бизнес. Твоя прямая обязанность — отдыхать минимум два раза в год и возвращаться живым».

Мантры ролей: как мысли мешают трансферу

Мантра специалиста: «Хочешь сделать хорошо — сделай сам»
Эта фраза знакома многим. В мягком варианте она звучит так: «Да, они все делают хуже меня. Я сделаю быстрее и качественнее».
Проблема в том, что у человека есть ограниченная ёмкость:
время, внимание, силы.
Он правда может делать лучше всех, но только ограниченное количество задач. В какой-то момент его разрывает — начинается выгорание, ненависть к работе, желание всё бросить и уехать в дауншифтинг, запой, эзотерику — каждый выбирает своё.
Почему это происходит? Потому что по должности человек уже должен был стать руководителем, а по мышлению — остался специалистом.
Мантра руководителя: «Кто, кроме меня, это сделает?»
У руководителя другая версия проблемы:
«Да, они все делают хуже. Если поручить — всё запорят. Лучше сделаю сам».
Александр предлагает жёсткую, но очень здравую логику:
  • Да, они сделают хуже.
  • Но они сделают больше.
  • А вы — ничего (и будете получать деньги за управление, а не за ручную работу).
Фокус руководителя в том, чтобы смириться: да, команда вначале делает не идеально, но масштаб и системность важнее индивидуального качества.

Ключевой принцип: если человек делает не свою работу

Одна из фраз, которые Александр повторяет клиентам постоянно:
  • Если человек делает не свою работу, у него не остаётся ресурсов выполнить свою.
  • Если руководитель делает работу сотрудников — он не руководит.
  • Если владелец делает работу руководителя — он перестаёт быть энергетическим ядром и становится «ушатанной батарейкой».

Практика: три кейса из наставничества

Чтобы показать, как это работает в реальности, Александр приводит три кейса из своей работы.

Кейс 1. Детская школа тхэквондо: «назвать школу своим именем было страшнее всего»

Город небольшой, владелец — бывший тренер по тхэквондо. Пять лет назад он пришёл к Александру с идеей: «Хочу свою школу».
Первая реакция на предложение назвать школу своим именем была показательной: человек буквально вскочил и начал бегать — настолько сильным был внутренний протест.
  • Для тренера назвать школу своим именем — почти кощунство.
  • Для владельца — нормально: вспомните ресторанные сети, где портрет владельца и фамилия — элемент бренда.
Дальше начался длинный путь: юридические вопросы, документы, организационные решения. Тренер каждый раз пытался всё делать сам, в том числе то, что давно придумано и делается другими специалистами.
Пять лет спустя — это уже крупная городская школа с ~100 детьми, амбициями по развитию и открытию филиалов. Александр отмечает, что только сейчас видит, как человек действительно начал переходить в роль владельца, мыслить категориями бизнеса, а не «я тренер, у меня секция».
И важная мысль здесь: пять лет он жил в состоянии постоянной тяжёлой жизни. Не потому что так устроен бизнес, а потому что в голове он продолжал быть тренером, тащащим всё на себе.

Кейс 2. Типография: владелец = бизнес

Второй случай — типография с полноценным производством, станками, сотрудниками.
Формально есть владелец. Фактически же бизнес — это он сам. Он:
  • приходит первым, уходит последним;
  • лезет в CRM, донастраивает, контролирует, кому звонят;
  • лично разговаривает с клиентами;
  • вмешивается в каждую операцию.
Объём работы давно превысил его физические возможности. В результате — рак. И уже лечить надо не только бизнес, но и самого человека.
Он передаёт управление жене, но продолжает каждый день вмешиваться: «Ты всё делаешь не так».
  • Сейчас жена учится быть владелицей, а не суперспециалистом;
  • управляющий учится быть руководителем;
  • сам бывший «всё в одном лице» учится не ходить на работу и переставать убивать и себя, и компанию.
И да, мозг при этом сопротивляется изо всех сил.

Кейс 3. Международный финансовый брокер: «состояние кентавра»

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

Как перестраивать бизнес, если внутри «компот из борща»

На вопрос из зала о матричных структурах и сложных орг. схемах Александр отвечает просто: в большинстве случаев он сталкивается не с красивой теорией, а с хаосом.
Пример: владелец крупных заводов, молодой, но уже полностью дёрганый человек.
Внутри — Bittrex, сотни задач, тысячи нерешённых пунктов, странная система согласований (месяц согласовывали покупку циркулярки, потому что её рассматривал юротдел).
Когда Александра спрашивают: «Как же это всё перестроить?» — он предлагает контринтуитивный ход:
  • Забыть на время о текущей системе.
  • Нарисовать идеальную модель — как если бы компанию строили с нуля.
  • Только потом задаваться вопросом «как перейти», а не наоборот.
Ключевое: сначала «зачем», потом «что», и только потом «как».
Если начинать с «как», всё превращается в бесконечную попытку подлатать старый хаос.

Как запускать изменения: стресс или поддержка?

Один из вопросов из зала касался классического подхода: сначала создать стресс (разрыв), чтобы люди захотели меняться, а потом их вести.
Александр честно признаётся: он сам много лет так делал.
Орал, создавал давление, «шёл в жёсткость».
Результат — первые 10 наставнических клиентов ушли. Формально что-то улучшилось, но эффект был далеко не тем, что хотелось.
Потом он задал себе вопрос: «А как расту лично я? Что меня на самом деле вдохновляет?»
Ответ оказался простым и неожиданным: его больше всего развивали поддержка и похвала, а не критика и стресс.
И он начал экспериментировать с другой моделью:
  • много хвалить;
  • поддерживать даже маленькие успехи;
  • всерьез относиться к людям, даже если они пока делают всё медленно и криво;
  • уменьшить «напряжение» и агрессию.
Результат оказался лучше, чем от «стресс-подхода»: люди начинали верить, что у них получится, и вытаскивали себя сами.
Стресс не исчез полностью — бизнес без него невозможен — но он перестал быть основным инструментом.

Сапожник без сапог: может ли наставник прокачать себя сам?

На вопрос «ты сам — сапожник без сапог или уже всё проработал?» Александр отвечает очень приземленно:
  • каким бы крутым парикмахером ты ни был, сам себя идеально не пострижешь;
  • каким бы прекрасным стоматологом ни был — зубы себе сам не вылечишь.
Мы всегда находимся внутри собственной коробки, и увидеть себя так же ясно, как клиента, невозможно.
Поэтому, несмотря на опыт, он:
  • честно признаёт, что сам по себе не может выстроить для себя всё так же качественно, как для других;
  • собрал вокруг себя команду людей, чьему мнению доверяет;
  • разрешил им его поддерживать, хвалить, но при этом честно отражать слабые места.
И здесь снова всплывает идея: даже если ты умеешь проводить других через трансфер, по отношению к себе ты всё равно уязвим и слеп в каких-то зонах. Это нормально.
]]> Тестирование как искусство качества: путь Ольги Ермолаевой от инженера до руководителя QA http://neogenda.ru/blog/roourmnfd1-testirovanie-kak-iskusstvo-kachestva-put http://neogenda.ru/blog/roourmnfd1-testirovanie-kak-iskusstvo-kachestva-put?amp=true Thu, 23 Apr 2026 17:40:00 +0300 Ольга Ермолаева Сегодня в гостях — Ольга Ермолаева, менеджер по обеспечению качества с более чем 15-летним опытом...

Тестирование как искусство качества: путь Ольги Ермолаевой от инженера до руководителя QA

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

Путь в профессию и первые шаги в тестировании

Ольга пришла в тестирование в 2008 году — в то время, когда сама профессия еще была туманной и мало кем понимаемой.
Первый работодатель увидел в ней склонность к аналитике и аккуратности и предложил попробовать себя в тестировании. Так началась история, которая спустя годы привела её от позиции младшего инженера до руководителя группы из 25 человек, распределенных по восьми кросс-функциональным командам.
Сегодня в её зоне ответственности — команды, работающие сразу с несколькими направлениями: веб, мобильные приложения, API, 1С и даже десктопные продукты. Она называет это «зоопарком», но таким, который ей искренне нравится.

QA, QC и тестирование — в чём разница на самом деле

Ольга объясняет, что в теории область качества обычно изображают в виде нескольких вложенных кругов:
  • Quality Assurance (QA) — самый широкий круг: обеспечение качества всего продукта и процессов.
  • Quality Control (QC) — проверки, направленные на выявление дефектов перед релизом.
  • Тестирование — только одна из частей QC.
Но в реальности названия смешались: компании хотят звучать современно и поэтому всех называют инженерами по качеству. Суть при этом остаётся простой: один человек не может «обеспечивать качество» в одиночку. Это — зона ответственности всей команды.

Почему тестировщиков распределяют по кросс-функциональным командам

Ольга поддерживает тренд распределения QA по продуктовым командам — это усиливает коммуникацию, ускоряет цикл разработки и повышает качество.
Когда тестировщики сидели отдельно, разработка часто превращалась в игру «перекидывания задач через забор».
Теперь же, работая вместе:
  • люди видят контекст друг друга,
  • быстрее договариваются,
  • меньше спорят,
  • раньше подключают QA к обсуждению требований.
Главный минус такого подхода — может нарушиться обмен опытом между тестировщиками. Поэтому в её компании введён формат QA-клубов: внутренние митапы, где тестировщики делятся находками, инструментами и лучшими практиками.

Как изменились требования к тестировщикам

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

Могут ли разработчики сами тестировать?

Ольга отвечает: могут, но не так, как нужно бизнесу.
Разработчики умеют писать код, но тестирование требует другого взгляда:
  • умения анализировать требования,
  • понимания поведения пользователя,
  • проверки корректности бизнес-процесса,
  • умения выделять риски,
  • поиска сценариев, которых разработчик не видит.
Разработчик тянет окно интерфейса аккуратно.
Тестировщик — дёргает резко, кликает в неожиданных местах и ломает так, как никогда бы не стал автор кода.
«Они люди разные. Разработчик заботится о продукте как о своём детищe, а тестировщик обязан быть немного бессердечным», — улыбается Ольга.

Заменит ли тестировщиков искусственный интеллект

Ольга считает: пока нет.
ИИ может:
  • подсказать тест-кейсы,
  • подсветить сценарии, о которых человек не подумал,
  • ускорить выполнение рутинных задач.
Но не может:
  • интерпретировать требования,
  • мыслить как пользователь,
  • понимать контекст бизнеса,
  • определять ценность функциональности.
Если когда-нибудь появится ИИ умнее человека, исчезнут не только тестировщики — исчезнет индустрия как таковая. До этого момента тестировщик нужен, и нужен всё больше.

Что делает руководитель тестирования

Когда тестировщики распределены по кросс-функциональным командам, роль руководителя меняется.
Ольга выделяет три направления своей работы:
1. People management
  • найм,
  • развитие,
  • карьерные планы,
  • обратная связь,
  • адаптация новичков.
2. Построение процессов качества
Она помогает командам выстраивать тестовые стратегии, проверочные списки, форматы анализа требований.
3. Единые стандарты и контроль качества
Руководитель отвечает за общие практики, регламенты и подходы, которые должны быть едиными для всего департамента.
При этом KPI строятся не только вокруг дефектов, но и вокруг метрик продукта: lead time, время жизни дефекта, доля критических багов, количество ошибок на проде.

Как устроен карьерный рост в QA

Горизонтальный путь
  • углубление в предметную область;
  • работа с вебом, мобильными приложениями, бэкендом, 1С или другими стеками;
  • переход в автоматизацию;
  • развитие в аналитику, разработку или продукт-менеджмент;
  • экзотические специализации: нагрузочное тестирование, безопасность, пентесты.
Вертикальный путь
  • мидл / сеньор,
  • лидер направления,
  • руководитель группы,
  • менеджер департамента,
  • директор по качеству,
  • движение выше — вплоть до CTO.
Ольга подчёркивает: тестировщики нередко становятся отличными руководителями.
Они чаще ориентированы на процессы, коммуникацию и продукт целиком.

Берут ли на работу выпускников быстрых курсов

Да, берут.
Но из-за огромного количества выпускников конкурс высокий, а многие «входят в IT» с завышенными ожиданиями.
Частые проблемы:
  • слабая практическая база,
  • отсутствие понимания процессов,
  • уверенность, что «я уже мидл, потому что знаю теорию».

Главное, что отличает хорошего тестировщика

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