Очень плохой лес
В английском языке есть прекрасное слово — complain. Как и большинство английских слов оно очень емкое по своему содержанию. Исторически так сложилось, что “комплейнить” мы научились достаточно хорошо, при этом культурно сложилось так, что свой огород мы стараемся защитить больше всего.
Если наложить наш менталитет на командную работу, приправить это все Agile/Continuous Improvement подходами, получим Continuous Complaining процесс. Что делать, если команда постоянно жалуется, но при этом не хочет предлагать выходы из сложившейся ситуации?
Мухи и котлеты
Для начала примите все как есть. Не стоит убеждать людей в том, что они не правы.
Ничего не происходит просто так. Для любого действия есть причина, ваша задача узнать в чем она
Начните с простого. Создайте список жалоб. Слушайте людей и дополняйте свой список. В какой то момент вы поймете, что жалобы можно легко свести к категориям. Сделайте это. Категоризация поможет вам лучше понять источник проблем.
Фокус и цели
Когда понятен фронт работ, необходимо разобраться, что будет самое важное, а что может подождать.
Вопрос — что делать дальше? С чего начинать? Как выбрать фокус?
Начните с того, что разберитесь, где именно вы имеете достаточно инструментов/влияния, что бы сдвинуть ситуацию к лучшему. Отбросьте категории, где вы заведомо ничего не можете изменить, что бы не заниматься популизмом.
Осталось дело за малым — пригласить всех обсудить что делать в первую очередь. Зачем всех? На то есть несколько причин:
- Это хороший показатель того, что вы слышите людей вокруг. Это сильный мотивационный толчок вперед
- Вы можете расширить список проблем или же, наоборот, узнать, что некоторые пункты уже не проблема
- Люди сами дадут вам приоритеты. Не вам же решать что для них важнее?
Лучшее время и место для такой встречи это ретроспектива. Если у вас не Scrum, это будет отличным началом хорошей традиции проводить Process Improvement встречи.
И так, есть список. Есть люди. На очереди приоритеты, то есть выбор фокуса, постановка целей.
Самым важным вопросом будут приоритеты. Вам необходима комплексная оценка каждого улучшения для того, что бы брать только то, что принесет максимальный результат за минимальное время. Мы используем немного видоизмененный подход из Scaled Agile Framework — Weighted Shortest Job First: Value, Impact, Size.
Weighted Value = (Value + Impact)/Size
где Value это значение для компании (или команды, как вы договоритесь), которое мы получим; Impact это влияние этого изменения на процессы; Size это объем работы, необходимый для выполнения изменения.
Каждое изменении, которое мы хотим взять в работу, мы оцениваем по ряду Фибоначчи используя Planning Poker, максимальная оценка 21. Каждый член команды высказывает свое мнение по оценке Value, Impact, Size. Команда договаривается какое значение должно быть присвоено в итоге для каждого показателя. Таким образом, значение каждого улучшения для команды является осознанным.
В итоге у вас получится список улучшений отсортированный по приоритетам, где самым высоким приоритетом будет самое большое значение Weighted Value (в примере это колонка Total, для первого элемента в списке WV = (5+3)/3 = 2.67).
Координация и выполнение
Для координации и прозрачности изменений, мы используем доску в TFS. Если вы используете Jira, то создайте новый проект. В нашем случае это выглядит так:
Используя единую доску, особенно для распределенных команд, позволит вам легко видеть прогресс и планировать выполнение, также выделать время и контролировать его использование.
Ваши встречи должны носить регулярный характер, тогда вы сможете отслеживать прогресс, пересматривать приоритеты и поддерживать беклог изменений в актуальном состоянии.
Проще всего использовать Kanban, но можно и Scrum, и Waterfall. Главное, сделать лес лучше!
Удачи в улучшениях! :)
Follow me on Facebook!
