В 2001 году меня назначили на должность начальника сектора. Команда была небольшая и была сформирована только что, как, в общем, и сам сектор. Поначалу мы втягивались в работу, брали наработки смежников, формировали свою культуру, внутрикомандные стандарты, выстраивали процесс и т. д. Все понимали: работы будет много, но никто не думал, что ее будет ТАК много 😄. В течение двух лет она только прибавлялась. Я постоянно поднимал вопрос у руководства, что неплохо было бы увеличить и количество специалистов пропорционально увеличивающемуся потоку задач. Все понимающе кивали головами, сочувствовали, обещали рассмотреть и т. д., но всё оставалось на том же месте. Каждый новый руководитель бил себя в грудь: «Вот я-то сейчас точно добуду вам штатную единицу, и всё будет ок». Конечно, ничего не случилось, и единицу никто не дал. Сейчас я понимаю почему. А тем временем количество задач увеличивалось, сроки горели, прогнозировать время выполнения было практически невозможно, потому что всем нужно было как можно скорее, а лучше еще вчера 😄. Как следствие — команда в постоянном аврале, сотрудники начали выгорать причем синим пламенем. Конечно, мириться с таким положением я не собирался. Первый вопрос, который у меня возник: как справляются с такими проблемами другие люди? В инете нашел один из способов управления интеллектуальной работой — канбан-метод. Начал собирать информацию. Параллельно начал готовить команду к внедрению. Я понимал, что высоконагруженные люди согласятся на любой эксперимент, лишь бы снизить нагрузку, — сопротивления по внедрению у команды не возникло. Подготовил базу: объяснил, для чего нужно, как всё будет происходить, какие правила будут существовать и т. д. Взял в хозотделе обычную маркерную доску. Нарисовал на ней процесс работы сектора. Это был простой процесс (позже он перестраивался неоднократно): он состоял из обычных столбцов: «Бэклог», «В работе», «Контроль», «Выполнено». Этого уже было достаточно, чтобы работа началась. Команда вдохновилась. Первое, что мы сделали, — начали фиксировать всю работу, которую мы делали. Поступающие задачи фиксировались на обычных стикерах: дата поступления, от кого, что делаем, срок исполнения. Они падали в бэклог, и каждое утро я с командой по приоритету распределяли, что будем делать, как, кто и что делает. По итогу дня мы смотрели, сколько задач выполнено, сколько времени потрачено, какие проблемы, блокеры и т. д. Данные с доски я кидал в эксель-таблицу. По итогу недели мы смотрели, что сделано, как долго делали, почему долго и т. д. Весь процесс со всеми косяками стал виден, всё стало прозрачно. Столбец «В работе» переполнился мгновенно 😄. Тогда я ввёл WIP-лимиты. Команда вздохнула, и люди наконец-то стали работать как положено, без постоянных переработок, авралов и т. д. Но так как поток поступающих задач был кратно выше пропускной способности системы, он начал копиться в бэклоге, несмотря на то что количество выполняемых задач выросло и сроки их выполнения сократились. Рукам это, конечно, перестало нравиться 🤦‍♂️. Когда я объяснял, почему происходят задержки в поставке, слушать, конечно, никто не хотел. Итог: мы выстроили процесс внутри команды, оцифровали его, улучшили, подняли показатели и пропускную способность, но со стороны руководства изменения были не нужны. Команда выполняет задачи — бизнесу хорошо, но какими усилиями команда это делает — плевать. Одно дело ставить задачи и совсем другое — их выполнять. Никто не хотел погружаться, как команды работают, почему перерабатывают, что делают и зачем. Поэтому, когда возник вопрос о сокращении (хотя мне и предлагали остаться и оптимизировать штат за счет других сотрудников), я не задумываясь решил, что пора менять работу. Если нет заинтересованности у руководства, то смысла во всех улучшениях нет. P.S. Канбан — это действительно работающий, очень нужный командам инструмент, но он должен работать для всех, кто вовлечён, иначе он превращается в партизанский канбан: вы просто упретесь в потолок своих возможностей (полномочий), и получится, что «низы не могут, а верхи не хотят».

#книги