Максим Цепков - Менеджмент цифрового мира

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

Метрики и индикаторы.

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

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

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

– Как сделать, чтобы моя ферма давала больше молока, а расходы на корма уменьшились?

– Очень просто, коров надо чаще доить и реже кормить!

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

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

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

Приведем пример работы с интересной метрикой «дни касания». Мы берем общий срок, когда задача была в работе, и считаем, какой процент из этих дней задачи реально касались, для чего анализируем следы: записи в таск-трекере или изменения в коде, связанные с этой задачей. Естественно ожидать, что в хорошей ситуации над задачей работают ежедневно пока не сделают. Однако, при расчете реальных метрик часто оказывается, что задача очень долго ожидает выполнения в различных внутренних очередях, и коэффициент касания может составлять 50, 30 или даже 10%. О чем свидетельствует низкий коэффициент? О том, что задачи можно было бы делать гораздо быстрее без дополнительной работы, просто устранив задержки, и это повысит скорость потока. Но метрика тут служит лишь индикатором больного процесса, ведь человек не просто так откладывает задачу. Причины могут быть различны: срочные поручения руководства, ошибки и проблемы эксплуатации, ошибки тестирования ранее сделанного, ожидания внешних работ, ожидания согласований, прояснение постановки на задачу со стейкхолдерами и так далее. И нужен следующий такт анализа – выявить конкретные причины и провести работу по их системному устранению, для которого может потребоваться наладить сбор специализированных метрик, позволяющих различить причины задержки.

Отметим, что часть из перечисленных выше проблем представляют собой примеры тех или иных потерь (waste) в рабочем процессе, то есть работ, не несущих ценности: согласовать без необходимости, сделать оказавшееся ненужным, переделывать ранее сделанное и так далее. В IT-разработке и в любой другой интеллектуальной работе потери тоже присутствуют, как и в физическом производстве, просто они носят другой характер, поэтому производственный lean напрямую не применим. А задача метрик – наблюдать за ходом процесса и потерями, и служить сигналом, что какие-то из них превысили допустимый объем и требуют устранения.

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

Agile-методы предъявляют к метрикам и их визуализации особые требования: работа с ними перестает быть уделом избранных, а становится предметом заботы всех членов команды. А это означает наглядное представление, позволяющее быстро провести анализ ситуации по графикам, с тем, чтобы возникла эмпатия к графикам, подобная эмпатии к доске. Scrum решил такую задачу в частном случае, там придумали burndown chart.