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