Соглашусь. В целом беда начинающих (и не очень) менеджеров в том, что они отталкиваются от инструмента, а не от решаемой проблемы. Я достаточно давно на рынке и работаю с разработкой, менеджерами, топами, чтобы всякого повидать и могу сказать, что до этой мысли надо просто дойти самостоятельно. Кому-то нужен rocketscience и его не устраивает объяснение механики, ему пофиг на теорию ограничений Голдратта, кому-то надо просто сказать инструкцию: "возьми вот это, сделай так и не спрашивай", а кто-то работает в среде, где срабатывает эксперимент. Я сам лично был во всех стадиях и переосмыслял эти вещи, сам видел менеджеров в этих стадиях и до сих пор вижу. Если погуглите какие-то видео со мной, то увидите мою позицию относительно того, какие мысли я вгружаю в менеджмент в своей работе, через публичные мероприятия.
В статье я пишу не об одном единственном варианте: "поставьте лимит по количеству людей", в статье я специально пишу, что есть ситуации, в которых лимит не нужен, если это, с ваших слов: "команда - это очень дорогой и хорошо настроенный инструмент." - я бы с такой пылинки сдувал и кофе приносил бы. Так же, я набрасываю разные варианты того, как это можно сделать. В статье я отвечаю на просто вопрос: "как их внедрить и какие бывают ошибки". Тонкой красной линией я говорю о том, что это не надо делать бездумно. Ну и, конечно, хочу сказать, что на основании своего опыта, я не могу утверждать, как это должно работать во всех ситуациях. В каких-то командах, от установки лимита приходило понимание, что взаимодействовать - это хорошо, что это снимает перегруз, где-то меня прям просили их поставить, где-то я не мог внедрить лимиты ни под каким соусом, хотя они были нужны и я аргументировал, показывал проблемы, графики и т.д., меня просто игнорили, а где-то это работало и мы приходили к ним эволюционно. Ну и, конечно, были ситуации с экспериментами "на шару", которые были, как успешные, так и нет. Поэтому я описал точно рабочие варианты.
Как это делали мы: концептуально - мы создали совместную гибкую и эволюционирующую система договоренностей (набор правил), собственно это одна из практик Канбан метода. Она выглядит как матрица классов обслуживания и приоритетов, на которой видно, что и по каким критериям занимает большую емкость команды, что меньшую, что берется в первый приоритет, что во второй, что не берется. Так же она включала в себя правила, какой тикет у куда создавать ,что в нем писать. Она прозрачная и понятная. Лежит на виду у любого сотрудника. Тут важно, что это не регламент. На специальной встрече мы отработали возражение, внесли корректировки и согласовали эту матрицу между всеми участниками процесса: службы поддержки, менеджеры, другие команды. Сделали специальную систему тегирования, по которой сразу видно, как приоритет поступил к ни на входящую доску. То есть внутри нашей компании любой прилетающий инцидент из Upstream доски уже с тегом и понятно, куда его пихать. Далее мы эту систему корректировали в зависимости от возникающих кейсов в системе. Целью было автоматизировать большую часть потока, чтобы менеджер принимал решение действительно по важным кейсам, а не по основной массе задач. Конечно, там множество различных кейсов. Когда система считает ,что это незначительно, а на самом деле кто-то очень громко говорит, что это очень важно. Мы просто шли и разбирались ,в чем суть кейса, почему это важно или неважно и по необходимости вносили корректировки в систему. Примерно 99% всех случаев наша система договоренностей автоматизировала. В среднем осталось меньше 1 случая в месяц в среднем, когда было непонятно, куда положить ту или иную задачу. Тут вопрос именно гибкости. Мы , как менеджмент были полностью открыты к диалогу, явно и прозрачно оповещали всех участников об изменениях, пропагандировали это в команды разработки. В дальнейшем было желание выйти с подобной системой на диалог с клиентами и попробовать откорректировать нашу матрицу на основании обратной связи от них. Но я ушел оттуда раньше. P.S. Я понимаю, что это общие слова. Если где-то есть уточнения - спрашивайте. Можете зайти в личку, я прокомментирую.
Оххх, так это реально печально. По сути мы выдаем желаемое за действительное, при этом еще и клиента в неловкое положение ставим. Я такое встречал в компаниях. Как правило это из-за фокуса только на задачи/проекты/работу. Без взгляда на ценность. Я эту тему здесь разводить не буду, пожалуй) Об этом готов в личке общаться с теми, кому интересно)
Спасибо за комментарий. По поводу инструментов я написал честный дисклеймер. Да и когда писал статью предполагая, что это так может быть воспринято.
Я тут по факту вижу два основных вопроса: 1. Инструмент или практики помогли сделать изменения и добиться результата? 2. 56% неактуальных запросов - вдруг там действительно что-то важное и не было ли такого, что важное для клиента мы считали неактуальным.
На первый вопрос отвечу однозначно так: именно практики, такие ,как приоритизация, классы обслуживания, изменения договоренностей с командами и службами поддержки помогли сделать хорошие изменения. Инструмент в данном случае - это удобство реализации этих практик. Я старался акцентировать внимание на кайтен специально в разрезах его фишек и удобстве. Например, в других инструментах невозможно нормально реализовать такие вещи, как кластеризщция блокировок, сквозные классы обслуживания, удобные лимиты, несколько досок под разные нужды. Несколько графиков, которые можно выгрузить достаточно быстро и посмотреть, не колдуя с ексель. В общем, мой акцент был в этом.
По второму вопросу: мы взяли для себя матрицу ZeroBugPolicy, основанную, на количестве клиентов, которых затронул инцидент и работоспособности бизнес процесса. То есть, если один клиент столкнулся с косметической проблемой и оповестил нас, то это будет считаться неактуальным. Так же в неактуальные попадают запросы, которые на момент создания были действительными, но в момент проверки стали уже неактуальными (починилось, показалось и т.д.). Там много различных кейсов. Все описывать не буду. Такая система не идеальна и действительно может в каких-то случаях упустить из вида важные нгеобходимые доработки типа путаницы с UI и т.д.. Для этого по ходу мы внедряли несколько решений, таких как кластеризация таких одиноких запросов при взаимодействии с самими службами поддержки. Ретроспективный анализ всего входящего потока для выявления кластеров таких запросов. Передавали часть в продуктовые команды. Кое-где даже зарядили большой рефакторинг одной из систем, которая вызывала по паре десятков инцидентов в месяц.
В общем, тут действительно можно отдельную статью писать. Спасибо вам за комментарий, всегда интересен взгляд на написанное со стороны.
Но мне больше всего интересно, как в своей деятелности вы собираете и учитываете мнения конечных клиентов о результатах ваших нововведений. Тех, кому приходится с ними сталкиваться и страдать от этого процесса?
Могу сказать, как на тот момент своей деятельности мы это делали. Сейчас я давно перешел на другие проекты. Напомню - контекст в данном случае касается только решения инцидентов. Вопросами учета мнений о доработках и прочих изменениях в продуктах - занимаются отдельные владельцы продуктов. Когда только мы запустили сервис, мы задались вопросом о том, как мы проверим, что конечным клиентом стало лучше/хуже/все равно. Мы поработали по трём основным направлениям: 1.Стали внимательно следить за ежемесячными отчетами NPS - внимательно читая контекст в поисках отзывов людей, которые относились именно к нашей работе. Как я уже писал - таких отзывов было очень много. По этой части были видны незначительные изменения, которые косвенно можно связать с нашими нововведениями. Отзывов о долгих ожиданиях решений проблем стало меньше (незначительно) 2.Далее я применял инструменты из f4p, а именно fitness box score (специальные опросники) на разной выборке людей для того, чтобы снять более контекстные данные. Специфика такого опроса подразумевала меньше эмоций и больше конкретики. Здесь ничего значительного накопать не удалось, в основном были достаточно высокие оценки работы служб поддержки (быстрое решение вопросов и т.д.) что-то порядка 80%. По итогу fbs бросили, потому что трудозатратно. 3.Пробовали так же копать в оценки работы служб поддержки, которые оставляли клиенты, чтобы посмотреть, что они пишут. Там были видны улучшения. которые в основном касались того, что теперь инцидент, который явно должен быть взят в одну из первых очередей (много ожидающих клиентов, сложно достичь своей цели в процессе) - действительно брался и решался в одну из первых очередей.
На самом деле, пробовали много всякого, но в сухом остатке я могу сказать следующее. Офигенно сложно в чистом виде получить мнения клиентов, напрямую связанные с теми изменениями которые мы сделали. Честно говоря, практически нигде я такого прям в живую не видел. Поэтому, в основном это косвенные признаки. P.S. По поводу "профессионального новояза" не до конца понял, что вы имели ввиду. С вашего позволения спрошу в личке.
Хороший коммент. Вот прям понимаю о чем вы))) Мы следили за NPS и контекстом отзывов от реальных клиентов по нашей части. Из общей массы обращений ежемесячно их было не так много, но мы трепетно относились к тому, чтобы не просадить показатели. Наша система отсева показала себя хорошо и падения пользовательских оценок не было. В общем мы даже заметили положительную динамику в росте оценок касательно обращений в поддержку.
Попробую прокомментировать, чтобы не нарушить nda. Изначальной задачей выделения сервиса и внедрения и организации работы с потоком были: -создание управляемой системы -создание прозрачности в том, как работа движется. С целью снизить количество проблем и негатива клиентов и внутренних заказчиков, участвующих в процессе. Различные бонусы в виде того, что нам стало понятно, сколько времени на каком этапе работа залипает, где какие зависимости и задержки появились в том числе благодаря этому. Выкатка - да, тут имеется ввиду деплой. Дело в том, что так массово статистику по деплою особо не собирали до того, как мы начали собирать статистику именно в этом сервисе. Если масштабировать всю ситуацию на компанию, то там может быть приличная экономия. В разрезе данного сервиса мы в итоге прилично сэкономили благодаря оптимизациям в деплое. Система управления инцидентами позволила сделать практически безпроблемное взаимодействие между службами поддержки и разработкой. То есть временные затраты на взаимодействие свелись к ревью 1 раз в месяц по 1 часу, где мы собирали обратную связь и вносили изменения в систему. Где именно удалось сэкономить больше, а где меньше мы считать не стали, так как не было в этом нужды. Обратная связь от внутренних заказчиков и других команд, участвующих в процессах показала, что количество неудовлетворенностей друг к другу снизилось практически до нуля. В этом плане цель была полностью достигнута. В целом гипотезу того, что оптимизациями можно сэкономить больше денег и времени, чем внедрением систем управления я понимаю. Оспорить или, наоборот подтвердить именно в данном случае, не могу. Спасибо за комментарий.
Соглашусь. В целом беда начинающих (и не очень) менеджеров в том, что они отталкиваются от инструмента, а не от решаемой проблемы. Я достаточно давно на рынке и работаю с разработкой, менеджерами, топами, чтобы всякого повидать и могу сказать, что до этой мысли надо просто дойти самостоятельно.
Кому-то нужен rocketscience и его не устраивает объяснение механики, ему пофиг на теорию ограничений Голдратта, кому-то надо просто сказать инструкцию: "возьми вот это, сделай так и не спрашивай", а кто-то работает в среде, где срабатывает эксперимент. Я сам лично был во всех стадиях и переосмыслял эти вещи, сам видел менеджеров в этих стадиях и до сих пор вижу. Если погуглите какие-то видео со мной, то увидите мою позицию относительно того, какие мысли я вгружаю в менеджмент в своей работе, через публичные мероприятия.
В статье я пишу не об одном единственном варианте: "поставьте лимит по количеству людей", в статье я специально пишу, что есть ситуации, в которых лимит не нужен, если это, с ваших слов: "команда - это очень дорогой и хорошо настроенный инструмент." - я бы с такой пылинки сдувал и кофе приносил бы. Так же, я набрасываю разные варианты того, как это можно сделать. В статье я отвечаю на просто вопрос: "как их внедрить и какие бывают ошибки". Тонкой красной линией я говорю о том, что это не надо делать бездумно. Ну и, конечно, хочу сказать, что на основании своего опыта, я не могу утверждать, как это должно работать во всех ситуациях. В каких-то командах, от установки лимита приходило понимание, что взаимодействовать - это хорошо, что это снимает перегруз, где-то меня прям просили их поставить, где-то я не мог внедрить лимиты ни под каким соусом, хотя они были нужны и я аргументировал, показывал проблемы, графики и т.д., меня просто игнорили, а где-то это работало и мы приходили к ним эволюционно. Ну и, конечно, были ситуации с экспериментами "на шару", которые были, как успешные, так и нет. Поэтому я описал точно рабочие варианты.
Как это делали мы: концептуально - мы создали совместную гибкую и эволюционирующую система договоренностей (набор правил), собственно это одна из практик Канбан метода. Она выглядит как матрица классов обслуживания и приоритетов, на которой видно, что и по каким критериям занимает большую емкость команды, что меньшую, что берется в первый приоритет, что во второй, что не берется. Так же она включала в себя правила, какой тикет у куда создавать ,что в нем писать. Она прозрачная и понятная. Лежит на виду у любого сотрудника. Тут важно, что это не регламент. На специальной встрече мы отработали возражение, внесли корректировки и согласовали эту матрицу между всеми участниками процесса: службы поддержки, менеджеры, другие команды. Сделали специальную систему тегирования, по которой сразу видно, как приоритет поступил к ни на входящую доску. То есть внутри нашей компании любой прилетающий инцидент из Upstream доски уже с тегом и понятно, куда его пихать. Далее мы эту систему корректировали в зависимости от возникающих кейсов в системе. Целью было автоматизировать большую часть потока, чтобы менеджер принимал решение действительно по важным кейсам, а не по основной массе задач.
Конечно, там множество различных кейсов. Когда система считает ,что это незначительно, а на самом деле кто-то очень громко говорит, что это очень важно. Мы просто шли и разбирались ,в чем суть кейса, почему это важно или неважно и по необходимости вносили корректировки в систему. Примерно 99% всех случаев наша система договоренностей автоматизировала. В среднем осталось меньше 1 случая в месяц в среднем, когда было непонятно, куда положить ту или иную задачу.
Тут вопрос именно гибкости. Мы , как менеджмент были полностью открыты к диалогу, явно и прозрачно оповещали всех участников об изменениях, пропагандировали это в команды разработки.
В дальнейшем было желание выйти с подобной системой на диалог с клиентами и попробовать откорректировать нашу матрицу на основании обратной связи от них. Но я ушел оттуда раньше.
P.S. Я понимаю, что это общие слова. Если где-то есть уточнения - спрашивайте. Можете зайти в личку, я прокомментирую.
Оххх, так это реально печально. По сути мы выдаем желаемое за действительное, при этом еще и клиента в неловкое положение ставим. Я такое встречал в компаниях. Как правило это из-за фокуса только на задачи/проекты/работу. Без взгляда на ценность. Я эту тему здесь разводить не буду, пожалуй) Об этом готов в личке общаться с теми, кому интересно)
Спасибо за комментарий. По поводу инструментов я написал честный дисклеймер. Да и когда писал статью предполагая, что это так может быть воспринято.
Я тут по факту вижу два основных вопроса:
1. Инструмент или практики помогли сделать изменения и добиться результата?
2. 56% неактуальных запросов - вдруг там действительно что-то важное и не было ли такого, что важное для клиента мы считали неактуальным.
На первый вопрос отвечу однозначно так: именно практики, такие ,как приоритизация, классы обслуживания, изменения договоренностей с командами и службами поддержки помогли сделать хорошие изменения. Инструмент в данном случае - это удобство реализации этих практик. Я старался акцентировать внимание на кайтен специально в разрезах его фишек и удобстве. Например, в других инструментах невозможно нормально реализовать такие вещи, как кластеризщция блокировок, сквозные классы обслуживания, удобные лимиты, несколько досок под разные нужды. Несколько графиков, которые можно выгрузить достаточно быстро и посмотреть, не колдуя с ексель. В общем, мой акцент был в этом.
По второму вопросу: мы взяли для себя матрицу ZeroBugPolicy, основанную, на количестве клиентов, которых затронул инцидент и работоспособности бизнес процесса. То есть, если один клиент столкнулся с косметической проблемой и оповестил нас, то это будет считаться неактуальным. Так же в неактуальные попадают запросы, которые на момент создания были действительными, но в момент проверки стали уже неактуальными (починилось, показалось и т.д.). Там много различных кейсов. Все описывать не буду. Такая система не идеальна и действительно может в каких-то случаях упустить из вида важные нгеобходимые доработки типа путаницы с UI и т.д.. Для этого по ходу мы внедряли несколько решений, таких как кластеризация таких одиноких запросов при взаимодействии с самими службами поддержки. Ретроспективный анализ всего входящего потока для выявления кластеров таких запросов. Передавали часть в продуктовые команды. Кое-где даже зарядили большой рефакторинг одной из систем, которая вызывала по паре десятков инцидентов в месяц.
В общем, тут действительно можно отдельную статью писать. Спасибо вам за комментарий, всегда интересен взгляд на написанное со стороны.
Могу сказать, как на тот момент своей деятельности мы это делали. Сейчас я давно перешел на другие проекты.
Напомню - контекст в данном случае касается только решения инцидентов. Вопросами учета мнений о доработках и прочих изменениях в продуктах - занимаются отдельные владельцы продуктов.
Когда только мы запустили сервис, мы задались вопросом о том, как мы проверим, что конечным клиентом стало лучше/хуже/все равно.
Мы поработали по трём основным направлениям:
1.Стали внимательно следить за ежемесячными отчетами NPS - внимательно читая контекст в поисках отзывов людей, которые относились именно к нашей работе. Как я уже писал - таких отзывов было очень много.
По этой части были видны незначительные изменения, которые косвенно можно связать с нашими нововведениями. Отзывов о долгих ожиданиях решений проблем стало меньше (незначительно)
2.Далее я применял инструменты из f4p, а именно fitness box score (специальные опросники) на разной выборке людей для того, чтобы снять более контекстные данные. Специфика такого опроса подразумевала меньше эмоций и больше конкретики.
Здесь ничего значительного накопать не удалось, в основном были достаточно высокие оценки работы служб поддержки (быстрое решение вопросов и т.д.) что-то порядка 80%. По итогу fbs бросили, потому что трудозатратно.
3.Пробовали так же копать в оценки работы служб поддержки, которые оставляли клиенты, чтобы посмотреть, что они пишут.
Там были видны улучшения. которые в основном касались того, что теперь инцидент, который явно должен быть взят в одну из первых очередей (много ожидающих клиентов, сложно достичь своей цели в процессе) - действительно брался и решался в одну из первых очередей.
На самом деле, пробовали много всякого, но в сухом остатке я могу сказать следующее. Офигенно сложно в чистом виде получить мнения клиентов, напрямую связанные с теми изменениями которые мы сделали. Честно говоря, практически нигде я такого прям в живую не видел. Поэтому, в основном это косвенные признаки.
P.S. По поводу "профессионального новояза" не до конца понял, что вы имели ввиду. С вашего позволения спрошу в личке.
Хороший коммент. Вот прям понимаю о чем вы))) Мы следили за NPS и контекстом отзывов от реальных клиентов по нашей части. Из общей массы обращений ежемесячно их было не так много, но мы трепетно относились к тому, чтобы не просадить показатели. Наша система отсева показала себя хорошо и падения пользовательских оценок не было. В общем мы даже заметили положительную динамику в росте оценок касательно обращений в поддержку.
Попробую прокомментировать, чтобы не нарушить nda.
Изначальной задачей выделения сервиса и внедрения и организации работы с потоком были:
-создание управляемой системы
-создание прозрачности в том, как работа движется.
С целью снизить количество проблем и негатива клиентов и внутренних заказчиков, участвующих в процессе.
Различные бонусы в виде того, что нам стало понятно, сколько времени на каком этапе работа залипает, где какие зависимости и задержки появились в том числе благодаря этому.
Выкатка - да, тут имеется ввиду деплой. Дело в том, что так массово статистику по деплою особо не собирали до того, как мы начали собирать статистику именно в этом сервисе. Если масштабировать всю ситуацию на компанию, то там может быть приличная экономия. В разрезе данного сервиса мы в итоге прилично сэкономили благодаря оптимизациям в деплое.
Система управления инцидентами позволила сделать практически безпроблемное взаимодействие между службами поддержки и разработкой. То есть временные затраты на взаимодействие свелись к ревью 1 раз в месяц по 1 часу, где мы собирали обратную связь и вносили изменения в систему.
Где именно удалось сэкономить больше, а где меньше мы считать не стали, так как не было в этом нужды. Обратная связь от внутренних заказчиков и других команд, участвующих в процессах показала, что количество неудовлетворенностей друг к другу снизилось практически до нуля. В этом плане цель была полностью достигнута.
В целом гипотезу того, что оптимизациями можно сэкономить больше денег и времени, чем внедрением систем управления я понимаю. Оспорить или, наоборот подтвердить именно в данном случае, не могу. Спасибо за комментарий.