Каденции что это в бизнесе
Каденции что это в бизнесе
Данная статья является продолжением цикла публикаций о прото-Канбан системах.
Что это такое
Командный Канбан с развязанными каденциями и постоянным WIP-лимитом – форма прото-Канбан системы уровня зрелости 2 из KMM
Для чего нужен
Данная форма прото-Канбана в явном виде применяется на практике довольно редко в силу отсутствия простой визуализации в JIRA (до недавнего времени. Сейчас проблема визуализации WIP-лимитов в JIRA успешно решается с помощью плагина Jira-Helper). Не смотря на это, командный Канбан с развязанными каденциями и постоянным WIP-лимитом можно можно довольно успешно использовать для команды, которая раньше использовала Скрам.
Как устроен
У данной формы есть две характерные черты. Первая – это единый постоянный лимит на этапы “Сделаем” и “В работе”. Вторая – частота пополнения может не соответствовать частоте поставки (речь о красной и зеленой стрелках – они обозначают разную частоту пополнения и поставки).
Первая помогает команде постепенно уйти от временных рамок спринта. Поначалу команда берет какое-то единое количество задач в работу, как и прежде на планировании спринта. Цель – взять столько задач, чтобы хватило до следующего пополнения. Но потом она понимает, что вовсе не обязательно придерживаться постоянного лимита на всю длину каденции. Лимит на пополнение можно сделать более гибким, учитывая и другие факторы системы. Например, не ждать следующего пополнения, а сделать это раньше.
Вторая помогает команде принять тот факт, что время выполнения по разным типам задач не ограничивается единым циклом системы. Есть более длинные задачи, есть более короткие. У каждого типа работы может быть своё время выполнения. Например, дефекты исправляем за день и сразу устанавливаем, пользовательские истории ждут приёмки с более долгим циклом установки.
Со временем система становится более гибкой и проще подстраивается к ожиданиям заказчиков.
Пример использования
На рисунке 2 приведен пример командного Канбана с постоянными WIP-лимитом. Раньше данная команда использовала элементы Скрам-фреймворка в работе: планирование спринта, обзор спринта, ежедневный Скрам.
Но в какой-то момент руководитель осознал для себя, что нет жесткой необходимости в двухнедельных спринтах. И стал постепенно отходить от этой практики.
Как работают развязанные каденции
В команде по-прежнему есть отдельная встреча по планированию (прото-пополнение очереди «Сделаем» – зеленая стрелка на рисунке 1) и отдельная встреча по обзору того, что команда сделала (красная стрелка на рисунке 2). Но эти встречи не привязаны к жесткому таймбоксу. Они могут сдвигаться или отменяться по необходимости. Например, когда в команде есть задачи в колонке «Сделаем», необходимость во встрече по планированию отпадает.
Как работает постоянный WIP-лимит
Несмотря на то, что в каждой колонке установлены WIP-лимиты, руководитель смотрит на общее количество задач в системе. Для него это важный параметр при планировании работ, который остался еще со времен Скрама. Так он примерно планирует количество задач, которые нужно сделать до следующего пополнения.
Отдельно стоит отметить, что колонка Blocked не учитывается в общем WIP-лимите. Это не канонический случай, а контекстуальное решение менеджера команды.
Заключение
Командный Канбан с развязанными каденциями и постоянным WIP-лимитом – довольно редкий зверь в мире Канбан-систем в силу отсутствия инструментов визуализации в JIRA.
На сегодняшний день есть плагин Jira-Helper для браузера Chrome, позволяющий настроить отображение постоянных WIP-лимитов. Поэтому данную форму можно использовать для команд, желающих улучшить процессы в Скрам-командах с помощью Канбан практик.
Данная форма прото-Канбана довольно гибкая в применения, поэтому позволяет снизить сопротивление у команд, привыкших к Скрам-фреймворку.
Командный Канбан с развязанными каденциями и постоянным WIP-лимитом можно использовать, как стабилизирующую практику при переходе на уровень зрелости ML2.
Подробно пример из этой формы разбирается на онлайн-тренинге Team Kanban Practitioner.
На этом у меня всё. Следующая публикация – последняя в данном цикле. В ней я расскажу об агрегированном командном Канбане.
С вами был Игорь Филипьев, руководитель школы Канбана.
За ревью спасибо Евгению Степченко (Telegram – @StepEv).
Подпишитесь на ежемесячную рассылку
Один раз в месяц вам будет приходить письмо с новыми публикациями и новостями школы. Никакого спама. Честно!
Что такое каденция в B2B-маркетинге и с чем ее едят
Достаточно ли активны ваши подписчики? Может быть, пришло время взять пример с компаний, работающих с частными лицами и изменить расписание отправки емейлов, чтобы лучше соответствовать потребностям, желаниям и жизненным обстоятельствам подписчиков? Отвлекитесь от привычной работы по усовершенствованию содержания писем, сосредоточьтесь на выборе оптимального времени рассылки: будьте внимательны к получателям, не отправляйте им письма тогда, когда ВАМ заблагорассудится. Из этой статьи вы узнаете, что такое каденция в маркетинге.
Не просто частота, а каденция в маркетинге
«Каденция». Этот термин имеет несколько значений, но мы будем использовать его для обозначения совокупности параметров рассылки. Маркетологи, работающие с частными клиентами, придают этому понятию большое значение. Они, как правило, осуществляют рассылки чаще, чем маркетологи «корпоративного сектора», потому что индивиды принимают решение о покупке гораздо быстрее и чаще, чем целые компании.
Каденция в маркетинге иногда понятийно смешивается с частотой, поскольку она тоже показывает, как часто вы отправляете емейлы по своему списку рассылки. Однако термин «каденция» более широк: он учитывает потребности клиента, а также стремление маркетологов вовлечь его во взаимодействие.
Другими словами, чтобы определить оптимальный ритм рассылки, вы не должны задавать себе вопрос: «Как часто следует отправлять клиентам письма?» Спросите себя: «Когда нужно отправлять получателям информацию, которая им действительно необходима?»
Рассылки можно осуществлять чаще, но каждая из них должна иметь собственную цель.
Представьте, что в первый понедельник каждого месяца вы отправляете одно информационное письмо, затем каждый четверг — обзорный пресс-релиз. Т.е. всего вы осуществляете 5 рассылок в месяц. Возможно, такой режим удобен для вашей компании, но он может не подходить подписчикам.
Если вы не готовы осуществлять рассылку чаще, то попробуйте хотя бы изменить даты или дни недели, в которые отправляете емейлы, чтобы лучше соответствовать потребностям читателей и быть уверенными в том, что они отреагируют на ваше письмо.
Таким образом, вы меняете не частоту отправки сообщений, а каденцию, подстраиваясь под свою аудиториию.
Однако вы можете и не менять частоту рассылки и по-прежнему отправлять 5 писем в месяц, вкладывая в каждое из них различный контент, чтобы оставаться на виду и не перегружать ящик входящих сообщений.
Как определить, какой ритм верен?
Единого ответа на вопрос «Как часто следует отправлять письма?» или «В какой день недели лучше всего осуществлять рассылку?» не существует. Вы должны самостоятельно определить подходящий для ваших читателей ритм.
К счастью, ответы найти не сложно — все они содержатся в информации о подписчиках, которую вы собрали, а также в общих сведениях о вашем сегменте рынка.
Если вы проводите рассылку раз в месяц, то тщательнее изучите аналитические данные (коэффициент кликов или уровень просмотра) и выясните, когда получатели наиболее активно реагируют на ваши письма. Вы также можете понять, как следует изменить расписание рассылки, если ответите на некоторые из вопросов:
Если вы осуществляете более 2 рассылок в месяц, то выясните, на какую из них получатели реагируют более активно.
Однако активность получателей может оставаться стабильной в течение месяца. Тогда вам придется поработать над содержанием письма.
Влияние каденции на содержание емейлов
Для начала выясните, когда получатели более активно реагируют на ваши емейлы. Затем соотнесите эти данные с тем, что вы знаете о желаниях и потребностях подписчиков, а также о том, на каких элементах емейла и вашего сайта они чаще всего кликают. Добавьте общие сведения о вашем сегменте рынка — и вы получите ответы на все вопросы, касающиеся содержания рассылок.
Возможно, вам придется разбить единый ежемесячный информационный емейл на несколько значимых частей.
Если вы составите письмо по каждому из пунктов, перечисленных ниже или подходящих для вашей целевой аудитории, то сможете определить оптимальную каденцию и перестать рассылать неуместные емейлы:
Разумеется, никакие изменения нельзя вводить, предварительно не протестировав их. Особенно если они касаются увеличения частоты рассылки емейлов.
Но если вы используете информацию о своих подписчиках для нововведений и подтверждаете их правомерность в ходе тестирования, то сможете правильно подобрать каденцию и увлечь читателей.
Конечно, для достижения целей компании и отдельных емейл-программ, а также для удовлетворения потребностей подписчиков вам потребуется огромное желание и способность широко мыслить. Но в результате вы создадите идеальные емейлы, которых подписчики будут с нетерпением ждать и высоко ценить.
OKR для начинающих #2
Перевод книги “OKR для начинающих” Фелипе Кастро, часть 2
Предыдущие части книги читайте здесь: 1 часть.
Стратегические или Тактические OKR: Встроенные Каденции
То, что OKR работают только квартальными циклами — типичное заблуждение, унаследованное от модели, которую до 2011 года использовали в Google. После того как должность CEO занял Ларри Пейдж, в компании стали использовать как квартальные, так и годовые OKR.
Мы можем только догадываться о том, что стояло за этим решением Пейджа, однако, в какой-то момент сразу несколько компаний внезапно обнаружили, что использование краткосрочных OKR приводит к тому, что команды теряют общую картинку и концентрируются только на том, чего могут добиться за три месяца.
Опытные практики OKR знают, что цели могут иметь разные ритмы, и тактические цели меняются гораздо чаще стратегических. Философия OKR разделяет стратегию и тактику, используя модель встроенных циклов, которую я упоминал в первой главе:
Воспринимайте стратегические OKR как то, что может заинтересовать совет директоров.
Многие успешные внедрения OKR работают так:
Некоторые компании также ставят квартальные OKR для всей организации, однако начинать с этого я не рекомендую.
Как выбрать OKR-каденцию
Важно отметить, что организация может подстраивать каденции под собственные нужды. Spotify, например, живет с шестимесячным стратегическим циклом, в то время как их команды ставят OKR каждые шесть недель. Их история вообще довольно примечательна, поскольку сначала они пытались создать собственный подход но, потерпев неудачу, вернулись к использованию OKR.
Некоторые компании внедряют более короткие каденции для OKR. В книге “Взрывной рост” Салим Исмаил, соучредитель и исполнительный директор Сингулярного университета, пишет:
«Многие [организации] сейчас внедряют высокочастотные OKR, устанавливающие цель на неделю, месяц или квартал для каждого сотрудника или команды».
Большинство команд, которые ставят OKR ежемесячно, начинают использовать их как список задач. Если OKR используется для измерения реальной ценности, целесообразно выбрать каденцию длиной в квартал, поскольку, чтобы проработать инициативу, измерить ее влияние и завершить итерацию, потребуется время. Примеры мы увидим в последующих главах.
Общий принцип такой: для коротких каденций накладные расходы на постановку OKR должны быть минимальны. А более длинные каденции применимы только в компаниях с высоким уровнем предсказуемости бизнеса.
То есть, если вы хотите внедрить у себя более короткие циклы, вам нужно обеспечить максимально простой процесс разработки OKR, иначе вы будете тратить слишком много времени на поставку целей.
С другой стороны, если ваш бизнес работает в условиях неопределенности или рынок меняется слишком быстро, длинные циклы OKR будут для вас бесполезны.
Если вы только начинаете свое знакомство с OKR, я рекомендую начать с квартальных тактических каденций и проводить обзор в середине квартала. Это позволит вам лучше понять и адаптировать модель под себя. Для большинства организаций такая модель является вполне рабочей.
Начните с Общих Каденций
Некоторые развитые компании Кремниевой Долины разделяют каденции по функциям. Например, они используют годовые OKR для отдела продаж и квартальные для проектных и продуктовых команд.
Следуя инкрементальному подходу, я советую вам начать с простой модели с общими каденциями и развивать ее по мере приобретения опыта и знаний.
Если же вы хотите сразу установить разные каденции в вашей организации, вам необходимо максимизировать число “точек синхронизации”. Например, если одна команда использует 4-месячный цикл, в то время как остальная компания работает с трехмесячным, это означает, что все вместе будут синхронизироваться один раз в год. Это может серьезно отразиться на общем выравнивании.
OKR не Каскадные
В традиционных организациях цели спускаются сверху — кажется, это ровно то, для чего существует организация. Цели ставятся на самом верху и каскадируются вниз. Это очень типично и в корне неправильно.
В чем основные характеристики каскадной (водопадной) модели?
Каскад — это необратимый поток, движущийся строго сверху вниз, без циклов обратной связи, который в конце разбивается о скалы — все, чем инновационная Agile-организация быть не хочет.
Каскадная модель является побочным эффектом мировоззрения командования и контроля, в котором решения спускаются сверху вниз. Нам нужно прекратить уже так работать. Поощряйте прямое общение и визуализацию — эти инструменты гораздо лучше помогают сформировать культуру в компании.
И хотя постановку целей сверху вниз последнее время значительно доработали, все равно это требует слишком много времени. Как писал Джеймс Харви:
«[Традиционная модель] — это подход сверху-вниз, который зачастую требует немало времени, чтобы достичь согласованности. Подотчетные лица слишком часто зависят от целей своих руководителей, чтобы быстро сформировать собственный план по целям».
Я знаю глобальные корпорации, в которых процесс постановки целей занимал 4-6 месяцев. И проблема не только в бесполезной трате массы ресурсов, но также в том, что сотрудники по полгода живут без четких целей.
Этому должна быть какая-то альтернатива.
Двунаправленная Постановка Целей
Вот, что писал Ласло Бок, бывший HR-директор Google, в своей книге «Работа Рулит!»:
«В вопросах постановки целей научные исследования подтверждают то, о чем вы и так интуитивно догадывались: наличие целей улучшает производительность. А бесконечные часы, в течение которых цели каскадом движутся внутри компании, наоборот, производительности вредят. Задача выравнивания становится крайне сложной и занимает слишком много времени. Мы же используем рыночный подход: поскольку самые верхние OKR известны всем, а остальные OKR доступны, со временем все цели сходятся. Команды, которые выбиваются из общего выравнивания, видны сразу, а несколькими крупными инициативами, которые касаются каждого, уже несложно управлять напрямую. И это вполне работает!»
Вот почему я написал Первое Правило OKR от Фелипе Кастро:
OKR никогда не спускаются сверху.
OKR Способствуют Выравниванию.
Постановка OKR — это параллельный процесс, в котором команды определяют свои OKR в соответствии с целями организации, а руководители проводят их валидацию. Процесс идет одновременно как снизу вверх, так и сверху вниз.
OKR уровня компании помогают командам получить четкое направление и понять, что они могут сделать для их выполнения.
Каждая команда определяет набор тактических OKR на квартал, способствующих достижению стратегических OKR и проводит предварительное выравнивание по ним. OKR команд не обязательно должны на 100% соответствовать OKR компании — они могут также включать и локальные OKR.
Постановка Тактических OKR
В процессе постановки Тактических OKR каждой команде необходимо ответить на два вопроса:
Тактическими Ключевыми Результатами могут быть:
Команды могут иметь «локальные» OKR, но большинство командных целей должно работать на достижение Стратегических OKR.
Практическое правило — что около 60% OKR должны определяться командой, снизу вверх, то есть, руководители тоже должны иметь слово при постановке OKR.
По моему опыту, в здоровой организации измерить это соотношение непросто. Поэтому обычно команды разрабатывают черновик OKR, который обсуждают вместе с руководителями. Компания может также стандартизировать OKR для похожих команд (например: всем продуктовым командам необходимо работать над увеличением вовлеченности клиентов).
Это была 2 часть книги. Но это еще не все! В следующей серии вы узнаете, каким критериям должны соответствовать цели и ключевые результаты. Продолжение следует…
Следующие части книги читайте здесь: 3 часть, 4 часть.
Что такое Канбан-метод – максимально коротко
Максимально коротко о Канбан-методе, его основные термины и области применимости.
1. Что такое Канбан-метод?
Канбан-метод – это метод улучшения вашей работы. Чем бы вы ни занимались, есть гипотеза, что практики Канбан-метода позволят вам делать вашу работу еще лучше. С позиции Канбана это значит, что вы будете лучше попадать в ожидания заказчика.
Канбан, как инструмент в IT-менеджменте был представлен Дэвидом Дж. Андерсоном в компаниях Microsoft (2005) и Corbis. А широкое распространение и название, как метод, получил в 2007 году.
2. Канбан-метод и Канбан Тойоты – это одно и то же?
(Самая большая карточка). Не совсем так. Канбан на заводах Тойоты – это бережливое производство, определяющим принципом которого является понятие “точно в срок”. Канбан, как термин в управлении, действительно пошел от Тойоты. В переводе с японского это слово означает “сигнал” или “карточка”. На автомобильных заводах такие карточки использовались, чтобы передать информацию с одного этапа на следующий о том, сколько и каких деталей потребуется.
Давайте разберем короткий пример. Нам нужно сделать три автомобиля “точно в срок”. Это значит, что мы точно заранее можем определить, сколько нам потребуется деталей на определенных этапах, и начинаем с конца вытягивать необходимое количество деталей для создания этого автомобиля, отвечая на вопросы: “Сколько литров краски нам потребуется?”, “Сколько колес?”, “Сколько двигателей?” и так далее. Таким образом, мы не создаем излишки запасных частей в виде остатков и экономим на складах, логистике и прочих издержках.
Канбан-метод тоже придерживается понятия “точно в срок”, но в отличие от заводов Тойоты здесь речь идет об интеллектуальном труде. Иными словами, код программиста или идею маркетолога нельзя пощупать и увидеть обычному человеку, пока он(она) не превратится в конечный продукт или сервис. Таким образом, Канбан-метод используется для визуализации потока интеллектуальной работы и сокращения количества этой незавершенной работы. За счёт этого достигается равномерная и предсказуемая скорость оказания услуги конечному потребителю.
3. Можно ли использовать Канбан-метод не в IT?
Да. Канбан-метод подходит для визуализации потока любой творческой и интеллектуальной работы. Но гораздо эффективнее использовать его через призму сервисной парадигмы. Посмотрите на то, что вы делаете, как на сервис. Через какие стадии проходит работа, чтобы сервис был оказан? По каким критериям вы поймете, что сервис оказывается в соответствии с ожиданиями Заказчика? Это отправная точка в применении Канбан-метода. Канбан-практики называют эту точку “начните с того, что есть сейчас”.
4. Канбан – это как Скрам?
Нет. Скрам – это фреймворк с жесткими правилами и границами. Вы можете использовать разные инструменты и методологии внутри Скрама, но если вы отказались от чего-то обязательного в Скраме, он уже не может считаться Скрамом. Канбан – это метод, инструмент с набором практик и принципов. Вы можете использовать все практики, часть практик или не использовать их вообще. В Канбане нет строгого понятия, что есть Канбан, а что не есть Канбан. Однако, разумное использование практик может существенно помочь вам сделать сервис максимально качественным и соответствующим ожиданиям клиентов. Подробнее об отличиях Scrum и Kanban.
5. У Канбана есть ценности?
Да. Их девять: прозрачность, баланс, сотрудничество, клиентоориентированность, поток, лидерство, понимание, согласие, уважение.
6. Вы написали о принципах Канбана. Какие они?
У Канбана действительно есть базовые принципы, которые еще называют принципами управления изменениями:
Так как Канбан-метод живет в сервисной парадигме, он придерживается ее принципов:
7. А что за практики в Канбане?
Это непосредственно практические приемы, которые мы используем для улучшения нашей работы и повышения качества сервиса.
8. О, каденции! Что такое каденции в Канбане?
Каденция – термин из музыки. В контексте Канбан-метода она обозначает ритм. Каденциями называют регулярные встречи, которые еще являются петлями обратной связи. Регулярность задает ритм, с которым течет поток работы. Каденций семь:
9. Я что-то слышал про классы обслуживания. Что это?
Канбан использует классы обслуживания для того, чтобы повысить приоритет определенным типам работ, заказчикам или нивелировать такое воздействие на бизнес, как стоимость задержки. Стоимость задержки – это недополученная прибыль или понесенные издержки из-за не вовремя оказанных услуг. Рассмотрим влияние стоимости задержки и соответствующий класс обслуживания на примерах:
10. Что на счет метрик? Как померять эффективность работы сервиса?
У Канбан-метода есть метрики, которые позволяют ответить на вопросы: какие проблемы в потоке работы, какая пропускная способность у сервиса, какое время выполнения, какое время разрешения блокировок, какое время цикла и по каким типам распределяется работа? Все это позволяет менеджеру сервиса принимать решения о развитии и улучшении качества сервиса на основе накопленных данных.
11. С какими проблемами сталкивается Канбан при внедрении?
Основная трудность – это объяснить людям на всех уровнях ценность практик Канбана: визуализации и ограничения незавершенной работы. Из-за того, что люди не видят объем интеллектуального труда, им сложно понять, какой нагрузке они подвергаются. А ведь мозг, к примеру, такая же мышца, как и бицепс. Представьте себе тренажерный зал: вы приходите и видите вес на штанге: “Так, это слишком мало. А сейчас – слишком много. А вот это в самый раз!” С мозгом нужно работать точно также: “Вот эта – большая задача, а эта – маленькая, да и вообще как-то много я на себя взвалил. Ограничу-ка я нагрузку”. Когда на всех уровнях мы делаем сквозную визуализацию потока работы и ограничиваем количество незавершенной работы, мы создаем вытягивающий принцип для интеллектуального труда и делаем равномерный поток его результатов для наших клиентов.
12. А какие есть программы для Канбан-метода?
Их тоже много. Перечислим только профессиональные, разработанные специально под метод. Наше сердце отдано российской разработке Kaiten. Кроме нее есть еще TargetProcess, SwiftKanban, LeanKit и другие.
13. И в каких компаниях уже используется Канбан-метод?
Среди российских это Альфа-Банк, Хоум Кредит Банк, Почта-Банк, Додо Пицца, HeadHunter, Clever и другие. Из иностранных: Wargaming, Microsoft, Automotive IT, Blizzard Sports, Dr Dobb’s, Siemens, Tupalo. Этот список можно продолжать долго.
14. Есть еще что-то важное?
Да. Напоследок хотелось бы отметить важность двух ролей в Канбан-методе. Это менеджер сервиса поставки (service delivery manager) и менеджер сервиса запросов (service request manager). Первый отвечает за устранение препятствий в потоке поставки. Второй – за управление потоком запросов к сервису от множества заказчиков. Очень важно, чтобы эти две роли были партнерами и работали в паре.
Как использовать Канбан для удобной работы не только менеджеров, но и программистов
Канбан — методология управления, которая используется примерно в 10 раз реже, чем Scrum, но от этого не становится менее интересной. В ее основе лежит представление процесса всей организации, как набора взаимосвязанных сервисов, которые в конечном итоге являются сервисом для конечного потребителя.
Канбан особенно легко внедряется начиная с топ-менеджмента и прекрасно комбинируется с теорией ограничений, изложенной в книге «Цель» Элияху Голдрата. Канбан выбирают для себя отделы техподдержки, системные администраторы, и даже менеджеры по персоналу и бухгалтеры, тесно работающие с IT.
Одной из основных отличительных черт являются принципы внедрения Канбана: «Начните с того, что имеете, визуализируйте процесс, договоритесь об эволюционном изменении процессов».
Заметьте, что речь идет не о том, чтобы громогласно объявить о внедрении Канбана, а лишь о том, чтобы эволюционно менять процессы в сторону улучшения. Наверное, вы подумали: «Звучит не страшно. Кто же от такого откажется?». И тем не менее, добиться заметных результатов с точки зрения бизнеса без серьезных изменений не выйдет.
Следом за невинной фразой «давайте договоримся об эволюционном изменении процессов» может поступить много разных предложений. И если внедряющий Канбан достаточно опытен, это все пройдет весьма аккуратно. Ниже описаны выгоды, ради которых стоит внедрять канбан, и практики, которые можно использовать для улучшения процессов.
Никто не научит программистов программировать быстрее с помощью этих методов, естественно. Но большую часть времени задачи скорее лежат в очереди или блокируются по тем или иным причинам, а иногда просто оказываются забытыми в гуще недоделанных дел. С наведением порядка в задачах канбан справиться вполне может.
Выгоды внедрения
В наше время, когда интерес к слову Agile, мягко говоря, перегрет, ее может и не предполагаться изначально. Но все-таки, даже если это было затеяно с целью выполнить поручения, из внедрения все еще можно извлечь пользу.
1) Канбан создан для того, чтобы увеличить прозрачность процессов внутри организации
Как часто происходит, что люди не понимают, как устроены процессы в той части компании, с которой им приходится взаимодействовать, но которая выполняет другую функцию? Например, как много маркетологи знают о работе программистов? А программисты о работе маркетологов?
Незнание устройства процессов другого подразделения часто вызывает иллюзии и пренебрежительно отношение к труду других, в таких условиях становится сложнее наладить контакт, и отделы могут даже превратиться во враждующие государства.
2) Канбан помогает бороться с «многозадачностью» в самых плохих ее проявлениях
Где-то на курсах учат «эффективных менеджеров», которые потом делают сами и советуют другим если задача не превышает 5 минут, отложить то, что ты делаешь прямо сейчас и сделать короткую задачу, чтобы навсегда избавиться от маленького балласта, а потом вернуться к основной, но самые догадливые заказчики начинают представлять каждую задачу как сверхмаленькую и требующую такого приоритетного подхода.
3) Канбан позволяет больше не заниматься оценкой сроков выполнения конкретной задачи
Вместо этого предполагается использовать статистические методы. Представьте себе, что вы измеряете диаметр сечения водопроводной трубы и скорость потока, а не занимаетесь предсказанием, как быстро конкретная капля(пусть даже помеченая синим красителем) пролетит через трубу из точки A в точку B.
Полезные инструменты, делающие Канбан эффективным
В отличие от Scrum, внедрение которого сопряжено с целым рядом ритуалов, внедрение Канбана происходит гораздо более плавно и незаметно. Однако оно также дает меньший экономический эффект в первое время, так как простая доска, какой бы красивой она не была, все еще не является внедренным Канбаном.
Канбан-доска
Канбан-Доска организации в целом и связанные с ней доски более низкого уровня для подразделений. Является важным аттрибутом, но ее наличие еще не гарантирует наличие гибкого мышления и наличия какой-либо методолоии в управлении организацией. Много внедрений в России заканчивается на этой стадии, впрочем также можно увидеть много внедрений скрама, из которых успели заработать только спринты.
Инструкция по внедрению:
1) Определите, через какие состояния реально проходит ваша типичная задача. Вариант «гнев, отчаяние, торг, депрессия, принятие», конечно, не принимается, но звучит поразительно часто.
Например, это могут быть такие столбики для общего IT-процесса(стратегический уровень):
В очереди | В работу | Анализ | Проектирование | Дизайн | Разработка | Тестирование | Выкладка
Или такие(для выделенного подразделения UX-дизайнеров):
В очереди | В работу | Макет | Прототип | Верстка | Передано в разработку
И вторая доска может быть расшифровкой слова «Дизайн» в первой доске, когда одна карточка на большой доске выглядит, как много мелких подзадач на дизайн в технической.
Физическое перемещение карточек по доске вместо электронного варианта дает определенное удовольствие, хотя и доставляет неудобства, особенно распределенным командам. Через 2-3 недели, когда вы поймете, какие именно состояния бывают у ваших работ на самом деле, можно перейти к электронному варианту.
Ограничение на количество работ в процессе. (WIP Limit)
Эта практика является важнейшей частью Канбана и без нее экономический эффект достижим с гораздо меньшей вероятностью. В практике автора внедрение лимита всегда происходит с серьезным сопротивлением, так как ограничение на задачи в каждом статусе воспринимается интуитивно как органичение прав и свобод трудящихся, что на самом деле конечно не так.
Как внедрить:
1) обсудите завалы недоделанных задач(если они есть) и примите решение с ними бороться;
2) введите ограничение на самый заваленный столбец и только на него;
3) как только мы начинаем уделять особенное внимание какой-то части процесса и ликвидируем «завал» в этом месте, то самым узким местом станет другой участок производства, найдите новое самое узкое место и поставьте ограничение и на этот столбик
(даже если для этого вам придется убедить смежное подразделение тоже обзавестись канбан-доской, почему нет);
4) последовательно внедрите и ужимайте ограничения по столбикам досок, связанных с нужным вам процессом, но не до такой степени, чтобы люди сидели без работы просто из-за введенного правила, небольшой целесообразный запас работ в любом статусе должен оставаться.
Инициатива по внедрению этой практики лучше всего принимается от самих исполнителей, ее почти невозможно внедрить «сверху», но она того стоит. Коучу достаточно легко подговорить ее использовать людей, показав ее преимущества на игре-симуляции Канбана.
SLA — Service level agreement, или соглашение об уровне сервиса
Несмотря на то, что название переводится как соглашение, на самом деле это элемент статистики, говорящий о том, как быстро в среднем раньше выполнялись задачи и позволяющий в связи с этим построить реалистичные ожидания.
Но, в отличие от статистики, этот уровень может включать небольшой запас при сообщении его внутренним или внешним заказчикам.
Внедрение
1) Подсчитайте статистическими методами, сколько времени в среднем проходит от постановки задачи в очередь заказчиком (внутренним или внешним). А также, в какой временной промежуток уложились наиболее быстрые 10% (назовем его X), и в какой уложились только 90% (назовем его Y). Подсчитайте также время Z для «долгостроев», сколько времени занимали самые длинные задачи.
2) Возьмите Х и прибавьте к нему Y, и вы получите реалистичные сроки выполнения 90% задач, даже если заказчики будут «набегать» со срочными поручениями, которые не могут ждать указанный срок и будут отодвигать ваши задачи. Скажем по секрету, что они наверняка приходят со срочными задачами и сейчас тоже в особом порядке. Автору известны случая «внутренней коррупции», где нарушение приоритетов стоило чашку кофе или шоколадку, некоторые рассказывают о реально заплаченных деньгах.
3) Договоритесь с заказчиком(не имеет значения, внутренним или внешним) о том, что в штатной ситуации задача обрабатывается за время X+Y, и лишь 10% задач могут выполняться крайне долго по тем или иным причинам вплоть до времени Z.
Классы сервисов
На самом деле мы немного схитрили, рассказав вам о классах сервисов на пару абзацев выше, но не назвав их. Это название звучит слишком сложно и местами пугающе, но сам подход является важнейшей частью внедрения Канбана для обеспечения гибкости в работе со внутренними и внешними заказчиками.
Как внедрить?
Обсудить эту возможность, написать официальное письмо и добавить разделение строк на доску, оно обычно называется Swimlines, и если в Jira с этим проблем не было в старой версии, то в Asana кажется без дополнительных скриптов это невозможно.
Роль Менеджера запросов(SRM)
В материалах по Канбану авторы изредка честно говорят, что эта роль нужна скорее для того, чтобы не увольнять Product Owner при переходе со скрама, но и в этой позиции (SRM) нет особенной нужды, если нет проблем с получением заданий от заказчика. Эта роль может быть полезна тем командам, которые страдают от отсутствия «единой точки входа» в продуктовых компаниях. Тогда этот человек может устанавливать формальные политики и разбираться с входящей очередью, но это точно не предполагается как работа на полную ставку. Как вариант, можно иметь одного реквест менеджера на несколько команд, и превратить в него бывшего менеджера проектов или руководителя группы разработки(в общем того, кто в новом процессе остался без лишней работы).
Роль Менеджера поставки(SDM)
Service delivery manager — гораздо более сильная роль, и в нее чаще всего ставят именно менеджера проектов, как того, кто нужен изначально, чтобы дела доводились до конца. При наличии деливери менеджера в большинстве случаев роль реквест менеджера практически не нужна, хотя формально они вместе обеспечивают двоевластие, реквест менеджер занимается теми задачами, которые еще не решили, нужно делать или нет, а деливери менеджер теми, которые уже точно нужно делать и доводить до конца.
Каденции. Различные встречи с изменяемой под процесс периодичностью
Таких встреч в канбане много, даже слишком много. Различные встречи от ежедневных до встреч планирования поставок и и планирования наполнения очереди(аналог планирования спринта в скраме).
Ежедневная «летучка» standup
На стендапах в отличие от скрама обсуждаются гораздо более приятные для исполнителей вопросы. Не нужно вспоминать мучительно, что же ты делал вчера, достаточно вместе со всеми посмотреть на доску и определить, что мешает каждой задаче справа налево перейти правее, и чему может помешать она
Operations Review
Как при работе не уйти в формализм и следование правилам в ущерб продукту?
В этом очень помогает проведение встречи Operations Review, отличающейся от аджайл-ретроспектив тем, что рассматривает процессы в организации в целом, чтобы не заниматься локальной оптимизацией на встречах ретроспектив каждой команды, так как в соответствии все с той же теорией ограничений локальная оптимизация скорее вредит эффективности организации, чем помогает ей.
Предсавьте себе инженеров техподдержки, которые без увеличения штата и других внешних признаков наличия проблемы все более и более эффективно и быстро отвечают нарастающему числу жалующихся пользователей, но поскольку им нужно отвечать быстро, не передают полученную информацию в команду разработки. Представить такое не сложно, такое происходит в техподдержках огромного числа российских и зарубежных компаний. Как бы эффективно, быстро, и красиво они не отвечали, если они не сигнализируют об источнике проблемы, то проблему сложнее обнаружить и исправить, а им будет все сложнее сравляться с нарастающей нагрузкой.
Планирование поставки
На этой встрече, которая не обязана происходить ровно раз в 2 недели, а происходит ровно тогда, когда есть какие-то проблемы с поставкой или неопределенность, например, в маркетинге, можно провести ревью того, что более готово к завершению и выбрать те задачи, которые являются более приоритетными на ближайшую поставку.
Наполнение бэклога
Честно говоря, особой необходимости в этой встрече у подопечных команд автора никогда не было, скорее была проблема в его переполненности из-за большого количества заказчиков, но тем не менее необходимость этой встречи легко понять тем, кто когда-либо делал продукт с нуля и помнит свежезаведенный например проект в Jira. На подобной встрече можно создать совместно наиболее приоритетные задачи в масштабах продукта или даже организации. С декомпозицией на технический уровень прекрасно справятся уже инженеры.
Метрики
Существует стандартный набор метрик продукта: выручка, прибыль, ARPPU(average rate per paying user), чуть более нелюбимая ARPU(average rate per user, которая учитывает выручку в пересчете на всех пользователей, а не только платящих) и другие. Эти метрики очень полезны для любого процесса в продуктовой компании, немного другие, но весьма схожие — для аутсорсной. Но это конечно касается стратегического уровня.
На уровне функциональных подразделений важно внедрить те метрики или их косвенные проекции, которые действительно направят процесс в нужное русло. И это не всегда среднее количество задач, выполняемых в день, или время, за которое задачи делаются в среднем. Хотя эти метрики по умолчанию предлагаются в канбане, процесс априори должен подстраиваться под нужды конкретного внутреннего и внешнего заказчика. Только так компания сможет стать набором взаимосвязанных сервисов друг для друга с целью оказания сервиса конечному клиенту.
Взаимодействие с управлением продуктом
Профессия менеджера продукта сродни работе стартапера, с той только разницей, что у менеджера продуктов есть только зарплата и, если повезет, процент от прибыли, а вот у стартапера зарплаты нет, но зато потенциальная прибыль принадлежит ему полностью(или в доле с партнерами).
Менеджеры продуктов существуют в компании для того, чтобы развивать отдельные продукты, заботиться о повышении их прибыльности и в принципе причинять добро своим клиентам, через решения реальных проблем реальных людей, а не реализации очередного набора задумок генерального директора, у которого к тому же может быть уже давно закончилась фантазия или никогда не было особого видения именно для этого направления.
Менеджеры продуктов являются владельцами бюджетов и формируют стратегию, включая виды сервисов, оказываемых клиенту и зарплатные бюджеты на реализацию задуманного. Менеджеры продуктов определяют ключевые метрики, которые должны достигнуть продукты. Подразделения могут быть в прямом подчинении у менеджера продуктов, а также возможна традиционная матричная структура, что гораздо хуже для управляемости и повышает нагрузку на коммуникации отдельных людей(руководителей отделов, пытающихся заниматься ручным управлением).
Менеджер продуктов может спроектировать нужный ему процесс и задать нужные ему метрики. Он может выборочно использовать скрам или канбан или даже fast waterfall на разных участках своего процесса, ведь в конечном итоге любая методология — лишь способ достижения цели.
Кросс-функциональные команды
Вы можете использовать кросс-функциональные команды в скраме. Вы можете даже использовать кроссфункциональную скрам-команду, как ячейку общей канбан-структуры организации.
Но не стоит прямо противопоставлять канбан скраму и спешить заменять одно другим. Канбан лучше всего подходит подразделениям-сервисам, а не кросс-функциональным «боевым» командам, каждая из которых может все от маркетинга до техподдержки.
В кросс-функциональных командах лучше не разделять работы по разным типам и не создавать противостояние в духе «эта задача еще не в моей колонке», в подразделениях же с одинаковой функцией сотрудников и большим количеством однотипных задач этот подход покажет себя хорошо с меньшими усилиями.
И снова про доску, которую многие по ошибке принимают за сам канбан
Как сделать так, чтобы программиста, тестировщика или любого другого инженера больше не дергал менеджер или любой представитель смежных подразделений с вопросом «когда будет готово?»
Достаточно научить людей читать доску и ставить задачи на доску. Ведь в представлении многих канбан = доска, хотя это на самом деле не так.
Обычно внутренние заказчики приходят в восторг, а если показать им команду в которой используются все вышеперечисленные методы, а некоторые из них даже внедряют канбан у себя в подразделении, если им нравится результат, не дожидаясь никаких требований сверху, что дает возможность запустить канбан в качестве вирусной методологии управления внутри средних по размерам организаций.
В практике автора даже был случай потери клиента, так как канбан «довнедрял» себя сам силами начавших его подробнее изучать специалистов, и генерального директора отстранили от ручного управления процессами, чем он при этом остался доволен.