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

Поэтому правильный подход – учитывать такую статистику на планировании и ранжировать задачи по желательности их исполнения. Для этого можно применять шкалу MoSCoW(Must – Should – Could – Would) или ее сокращенный вариант, и не ставить максимальное значение достаточному количеству задач. Кроме того, учитывая статистику, необходимо не заполнять весь бэклог крупными задачами, в нем должен быть достаточный буфер мелких задач. Конечно, планирование спринта обычно не является заключением какого-то принципиально нового контракта, речь обычно идет лишь о целях и объеме работ на спринт. Однако, в общем случае, стейкхолдерами проекта после любого спринта может быть принято решение о прекращении проекта.

Ценность и содержание работ.

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

Мы думали, что пользователи смогут, увидев названия документов в результате поиска по базе, выбрать наиболее подходящий, а выяснилось, что для очень много запросов выдает совершенно однотипные списки названий, начинающихся с «Письмо Минфина от DD.MM.YY разъяснением по практике применения…», и выбрать совершенно невозможно. Мы думали, что пользователь сформирует список из 10—20 любимых песен для запуска по циклу в фоне, а оказалось, что у многих есть несколько списков для разных настроений, и любимое произведение в одном состоянии превращается нестерпимым в другом. Мы сделали специальную форму для оформления заказов с доставкой со склада на тренажеры прямо из магазинов, а оказалось, что сотрудники магазинов по-прежнему звонят в офис и резервируют товар по телефону, а только потом заполняют форму. Потому что боятся, что пока они будут оформлять заказ и подробности доставки, тот единственный тренажер уйдет по другому назначению, и не хотят, чтобы покупатель почувствовал тоже самое, что чувствуют многие из вас, когда после заполнения сведений о пассажирах при покупке билетов получают сообщение, что билеты уже проданы или подорожали…

То есть уже после реализации оказывается, что создание ценности требует дополнительных объемов работ. И на это тоже надо закладывать резервы при планировании. Но если у вас задачи похожие, то статистика позволит оценить качество, с которым команда превращает ценность в содержание работ, и требуемый размер буфера.

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

Сейчас мы поговорим о месте Agile-команд в большой компании. Вполне возможно, когда вся компания состоит из agile-команд. Но если речь идет о большой компании, которая сейчас работает, применяя другие управленческие подходы, то трансформацию стоит проводить постепенно. И, более того, далеко не всегда всю компанию стоит перестраивать. Есть смысл оценивать сравнительную эффективность разных методов, основываясь на характере деятельности и доступном персонале. А можно руководствоваться классическим «солнце всходит и заходит, ничего не надо трогать», в большинстве компаний можно найти хорошо работающие подразделения.

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

Успех Agile определяется тем, что он позволяет уверенно работать в условиях большой неопределенности, связанной с динамикой внешнего мира, а также при отсутствии компетентного персонала. Таким образом, можно сформулировать следующее обобщенное правило по выбору способа сделать новый проект или организовать деятельность.

– Если вы в компании собираетесь сделать новый проект или организовать деятельность, и у вас есть компетентные сотрудники для этого – пусть они организуют работу известным им способом и придут к успеху.

– Если в индустрии известны способы, которым можно достичь успеха в новом деле, но у вас нет компетентных в нем сотрудников – попробуйте их найти.

– А вот если нет ни способа работы, ни компетентных сотрудников, то сделайте ставку на самоорганизующуюся вовлеченную команду и используйте Agile-методы или другие способы самоорганизации для организации ее работ.

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

Кеневин-фреймворк – можно ли найти компетентных сотрудников.

Если с компетентностью собственных сотрудников более-менее понятно, то со вторым способом могут быть проблемы. Компания решила начать новую деятельность или сделать проект – как узнать, есть ли в индустрии способы ее успешной организации? Помимо поиска информации об аналогичных проектов есть обобщенный способ получения ответа на этот вопрос – Кеневин-фреймворк ( Cynefin framework) из теории сложности.