Чаще всего, причины проблемы предельно ясны. У меня высокий инсулин, это плохо. Эндокринолог говорит, что главная его причина — лишний вес. Похудею — уйдёт высокий инсулин. Всё довольно очевидно.

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

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

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

ВНЕЗАПНО при помощи этой диаграммы можно также проанализировать причины успеха. Да, причины успехов надо анализировать, так же как причины провалов.

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

Но если ваша команда, как и моя сейчас, разбросана по пяти-шести часовым поясам, можно и онлайн. Неплохие средства есть в Miro, но с некоторых пор её нельзя купить, а в бесплатной версии ограничено количество досок, с которыми может работать команда. Я буду сейчас рисовать в Mindjet Mindmanager, благо там есть подходящий шаблончик.

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

Получается нечто подобное:

Хорошая диаграмма Исикавы обычно обширная, с большим количеством «костей». Если получилось простенько, возможно, у команды создания недостаточно компетенций, надо расширить состав участников.

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

1. Уклонение;
2. Митигация (смягчение);
3. Делегирование (передача);
4. Принятие.

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

А теперь советы и лайфхаки, которые помогут вам в составлении этой диаграммы:

Давайте структурируем плюсы и минусы метода:

Плюсы:

1. Метод легкоосваиваем и легкоприменяем. Низкий порог вхождения;
2. Позволяет кратковременно включить креативное мышление у команды;
3. Позволяет установить однозначную связь между разноуровневыми причинами и корневой проблемой;
4. Дает возможность оценить влияние причин и факторов на проблему.

Минусы:

1. Диаграмму невозможно проверить в обратном направлении (начиная от начальной причины к результатам);
2. Не всегда имеет четкую структуру, что затрудняет ее анализ и возможность сделать объективные выводы;
3. В диаграмме нет временного разреза;
4. Плохо работает для слишком комплексных и системных проблем.

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

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

Дальнейшее уменьшение влияния поисковиков в пользу соцсетей

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

Повсеместное внедрение ИИ

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

Гиперперсонализация

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

Мегагибкие подписки

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

Ускорение доставки

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

Селебрити уступят место инфлюенсерам

Благодаря соцсетям, многие пользователи узнали, что их кумиры (классические селебрити):

1. Тупые.
2. Мерзкие.

Из-за этого влияние рекламы с использованием селебрити всё ниже, эффект от неё снижается.

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

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

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

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

Но перед этим прочтите, пожалуйста, пост Дениса Сиденко про «управление бровями» (Линкадин под блокировкой, чтобы блок отобразился, поставьте какой-нибудь плагин с автоматическими прокси или врубите vpn):

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

Хочешь сделать хорошо — сделай сам.

Лучшего программиста делают тимлидом. Лучшего продавца — РОПом. Лучшего дизайнера — арт-директором.

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

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

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

Невозможно быть руководителем на 80 %. Вы либо управляете, либо исполняете. А кроме того, невозможно управлять системой, будучи её частью.

Не обучать

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

Да и в конце концов, вас же никто ничему не учил, вы всё сами постигли, правильно? Чем они лучше?

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

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

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

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

Давать распоряжения и инструкции только устно

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

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

Каждая повторяющаяся работа должна быть регламентирована, а ещё лучше, автоматизирована. Это позволяет значительно быстрее погружать в контекст новых сотрудников и освобождать свой мозг для работы более интеллектуальной, чем в сотый раз объяснять сотому по счёту офис-менеджеру, как правильно печатать на конвертах. Короче, читайте статью про регламенты.

Да, тут есть другая крайность. Можно дорегламентироваться до многостраничных мануалов, которые будет трудно воспринимать (как, например, в айти-подразделениях «Комуса»). Но в целом, и это лечится, просто не требуйте от новичков знания их наизусть, пусть ознакомятся и разок на практике их пройдут и всё получится. Читайте правило про обучение.

Не давать сколько-нибудь детальных планов

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

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

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

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

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

Не координировать людей

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

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

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

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

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

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

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

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

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

Мы будем обсуждать восьмишаговую модель изменений по Джону Коттеру.

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

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

1. Создание ощущения срочности
2. Создание коалиции
3. Формулирование стратегического и инновационного видения
4. Донесение видения изменений
5. Создание условий для действий путем устранения барьеров
6. Достижение краткосрочных побед
7. Поддержание импульса
8. Закрепление изменения

Дальше мы их последовательно разберём.

Шаг 1. Создание ощущения срочности

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

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

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

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

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

Запаситесь аргументами. Кейсы из других компаний, практические примеры.

Затем очень спокойно, но честно и откровенно расскажите всё это сотрудникам. Если вам удастся до них достучаться, считайте, что половина дела сделана.

Шаг 2. Создание коалиции

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

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

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

Шаг 3. Формулирование стратегического и инновационного видения

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

Нужно определить главную ценность изменения и всё время держать её в голове.

Проведите мозговой штурм с коалицией, извлеките максимум идей и превратите этот набор идей в чёткий план. Хорошо помогает составление майндмапа.

Вполне нормально использовать для планирования хорошо знакомый вам проектный подход. Накидайте ИСР, нарисуйте диаграмму Ганта.

Убедитесь, что коалиция понимает составленный план.

Шаг 4. Донесение видения изменений

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

Помните статью о мягкой силе? Ваша сила в настойчивости, системности и неумолимости.

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

Шаг 5. Активизация действий путем устранения барьеров

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

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

В целом, по устранению барьеров набор действий таков:

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

Шаг 6: Создание краткосрочных побед

У любого проектного менеджера всегда есть под рукой три вещи:

1. Средней детализации план с вехами.
2. Бутылка шампанского на случай успеха.
3. Резюме на случай провала.

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

Как определить, что вы одержали важную краткосрочную победу? Она соответствует трём критериям:

1. Ваш успех должен быть однозначным
2. Успех должен быть ощутимым и заметным для всей организации
3. Успех должен быть четко связан с усилиями по проведению изменений

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

Ещё важные моменты для краткосрочных побед:

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

Шаг 7. Поддержание динамики

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

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

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

Шаг 8. Закрепление изменений

Достигнутые успехи нужно закреплять. Для этого необходимо:

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

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

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

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

Если же эта проблема неактуальна, то применяем следующие решения:

Привлеките внимание

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

Дайте решение

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

Распределите роли

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

Повторите сказанное

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

1. Сказать, о чём вы собираетесь говорить.
2. Сказать это.
3. Сказать, о чём вы только что говорили.

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

Ответьте на вопросы

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

История и суть явления

Метод появился в компании «Toyota» в 1959 году. К айти имеет косвенное отношение, почитать про него можете в Википедии.

Канбан, как инструмент в IT-менеджменте был представлен Дэвидом Дж. Андерсоном в компаниях Microsoft (2005) и Corbis. А широкое распространение и название, как метод, получил в 2007 году.

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

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

Канбан-доска

Главный принцип Канбана — визуализация при помощи канбан-доски. Рассмотрим её подробно.

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

Правее очереди следует расположить колонки допроизводственных этапов, на которых происходит сбор требований, оценка и утверждение задачи. Дальше идёт черта — точка принятия обязательств. Если задача пересекает эту черту, это означает, что она передана в производство и совершенно точно должна быть сделана и влита в продукт.

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

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

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

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

WIP-лимиты

WIP (work in progress) — это количество элементов, находящихся в работе в настоящий момент. Его не надо путать с WIP-лимитом, ограничением на количество элементов в работе на настоящий момент времени, введённым для достижения некой цели.

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

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

Для того, чтобы посмотреть максимальный WIP-лимит по команде, потребуется отчёт CFD (cumulative flow diagram) или накопительная диаграмма потока. 

Каденции

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

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

Пятнадцатиминутная ежедневная встреча. Команда собирается и обсуждает:

• Что нам мешает?
• Как осуществляется поток работы?
• Что мы можем улучшить?

Очень важно обсудить все заторы и затруднения в работе над задачами. Возможно, кому-то из участников нужно оказать помощь.

Встреча по пополнению

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

Обзор сервиса поставки

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

Встреча по планированию поставки

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

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

Обзор рисков

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

Обзор операций

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

Обзор стратегии

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

Метрики в Канбане

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

• Cycle Time – время, которое задача находилась в разработке от момента, когда ей начали заниматься, до момента, когда она прошла фазу конечной поставки.
• WIP – количество задач одновременно находящихся в работе. Разделяется по разным стадиям работы над задачей.
• Wasted Time – время, которое задача проводит в различных очередях, а не непосредственно в работе.
• Effectiveness – процент времени, которое тратится непосредственно на работу с задачей, а не на ожидания в различных очередях.
• Throughput – количество задач, которое может выполнять команда в единицу времени (день, неделя, месяц).

Делаем правила явными

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

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

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

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

Оказалось, что отдел использует TFS (сейчас Azure DevOps Server), однако совершенно бессистемно. Кто-нибудь из руководства заводит запрос на доработку, вешает его на рандомного разраба и заказчики ждут у моря погоды. Если какой-то запрос нужен срочно, ответственный внедренец прибегает к руководству департамента и начинает орать. CIO транслирует ор в программиста, он в приоритетном порядке запиливает доработку. Тестировать её некогда, поэтому она сразу накатывается на базу заказчика. Если возникают проблемы, они никак не регистрируются, внедренец просто приходит в отдел SQL, подсаживается к программисту и просит поправить.

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

В первую очередь было принято решение визуализировать очередь. Хотелось использовать веб-приложение, потому что внедренцы крайне не любят ставить сторонние приложения (лол) и вообще, большую часть времени проводят в аутлуке. Выбор пал на trello. Первоочередной задачей стало завести на трелло-доске все открытые запросы на доработку из TFS. Trello тогда умел создавать карточки на основании писем, отправленных на специальную почту, а TFS умел экспортировать воркайтемы в эксель. Мой разраб минут за сорок накидал VBA-скрипт, импортировали запросы.

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

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

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

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

kanbanize.com, в отличие от trello на тот момент поддерживал свимлайны. То есть, можно было завести для каждого разраба дорожку, а колонками сделать уже актуальные статусы, что сильно ближе к нормальному канбану. Кроме того, этот сервис позволял добавить кастомные поля к каждой карточке, что было для нас очень важно, так как кроме TFS-идентифкатора, каждый запрос имел CRM-идентификатор, которыми оперировали внедренцы.

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

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

У вас четыре варианта подхода к найму исполнителей. 

1. Инхаус-команда.
2. Один или несколько фрилансеров. 
3. Аутстаф команда под полным вашим контролем. 
4. Подрядчик, которому вы поручаете работу под ключ. 

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

Инхаус команда

Создаём штатные единицы исполнителей, поручаем рекрутеру найти кандидатов в штат. Вносим им записи в трудовые книжки, платим зарплату. 

Вариант хорош, когда приложение планируется очень сложным и дорабатывать его предполагается длительный период (в нынешних условиях «длительно» — это 2-3 года). По деньгам вариант получается чуть ли не самым дешёвым, дешевле только фрилансеры. 

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

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

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

Один или несколько фрилансеров

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

Чаще всего, фрилансеры не требуют договор. Есть пространство для бухгалтерских манёвров с расходами на них. Нет официального оформления отношений — в ваших руках большая свобода в формировании команд и их переформатировании. 

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

Ранее практиковался найм разработчиков-фрилансеров из Украины, они стоили ещё дешевле, относительно российских. Но теперь этому мешает СВО и препятствия для трансграничных переводов. 

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

Аутстаф команда под вашим контроем

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

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

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

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

Подрядчик для работы под ключ

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

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

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

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

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

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

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

Правила жизни Владимира Бычко

Так как сделать, чтобы ключевые сотрудники не уходили как можно дольше?

Культура

Однажды уборщицу в офисе Аэрофлота спросили, почему она не уволится и не устроится на что-нибудь более денежное, а она ответила: «Вы что! Бросить авиацию?» Но ведь верно. Невозможно организовывать авиаперевозки из офиса с грязными полами, забитыми унитазами, заваленного мусором. Уборщица тоже в авиации, как и ведущий инженер, и гендиректор.

Есть мнение, что деньги — главное. Достаточно платить чуть выше рынка и всё будет хорошо. Это не совсем так.

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

Видение будущего

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

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

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

В Манифесте:

• Методологии человеческим языком
• Арсенал инструментов PM
• Технические и продуктовые нюансы
• Метрики
• Рекомендации по созданию культуры в команде
• Про CI/CD
• Шаблоны
• Вопросы к собеседованиям и т. д.

За документ спасибо Александру Коновалову.

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

Мне кажется, что одна буква из этой аббревиатуры сильно важнее остальных. Но сначала давайте разберём их все.

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

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