Как использовать Agile-планирование в бизнесе

Agile — гибкие системы планирования. Раньше их использовали разработчики ИТ-продуктов, но теперь применяют во всех сферах бизнеса и для реализации личных целей. Agile — скорее способ мышления, чем конкретные правила.

Главное в Agile — прозрачность: нужно всегда точно знать, что сейчас происходит с задачей. Это помогает адекватно рассчитывать сроки и ресурсы, а если что-то пошло не так, можно сразу внести корректировки, чтобы потом не переделывать все с начала. Прозрачность должна быть и в отношениях между участниками задачи: нельзя скрывать проблемы от коллег и заказчиков.

На основе Agile появляются разные способы планирования и ведения проектов. Самые популярные из них — SCRUM и Kanban.

В подходе SCRUM работу над большим проектом делят на отрезки-спринты. Обычно спринт длится от одной до четырех недель. В конце каждого спринта проверяют, правильно ли движется работа.

Если это заказ клиента, в конце спринта нужно показать ему результат и свериться — продолжать работу в том же направлении или скорректировать курс.

Бывает, что нужно свериться не только с конкретным заказчиком, а с рынком в целом.

Чтобы было что оценивать по итогам спринта, за одну итерацию нужно создать что-то рабочее, пусть и в упрощенном варианте.

Чтобы держать процесс под контролем, в SCRUM приняты регулярные встречи участников команды.

Каждый день проводят короткое собрание — stand-up, на котором сотрудники говорят, что сделали вчера, что планируют сделать сегодня и что им в этом может помешать. На таких собраниях нельзя критиковать исполнителей — это скажется на работе команды: сотрудники перестанут честно отвечать на вопросы, и в конце спринта окажется, что на самом деле ничего не готово. Цель такого собрания — иметь реалистичное представление о том, как идет работа.

В конце спринта участники собираются на большое собрание: спринт-ревью. На нем оценивают, как пройден спринт, что успели, а что нет, и ставят цели на следующий.

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

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

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

Чтобы не допускать таких ситуаций, надо хорошо проработать понимание задачи: еще на старте зафиксировать, что и зачем нужно сделать. Если все обсудили, но доработки продолжаются, лучше еще раз собраться и свериться с пониманием задачи, чем несколько спринтов заниматься мелкими переделками.

Растет стоимость проекта. Стоимость может расти просто из-за того, что команда тратит больше времени. А еще в процессе у заказчика могут появиться новые идеи, которые не были согласованы на старте. Например, клиент решил, что нужны не просто фотографии, а еще и виртуальный тур.

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

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

При канбан-подходе типовые задачи как бы перемещаются по конвейеру — от идеи до реализации. Это перемещение можно отследить визуально — на доске или в программе. Каждый член команды четко понимает, где сейчас задача.

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

Программ для канбан-досок много, среди популярных — Kaiten, Trello, Asana.

Задача не всегда движется только в правую сторону. Если что-то нужно доработать, задача может переместиться обратно. Например, юрист нашел в новости неверную трактовку закона, тогда задачу нужно будет переложить снова в столбик «В работе», пока автор правит текст.

Доска помогает увидеть узкие места в работе — на каком этапе задача тормозится.

При работе по методу Канбан тоже есть несколько нюансов, на которые руководителю нужно обратить внимание.

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

Рекомендуем разработать внутренние правила, которые помогут подтвердить, что задача прошла тот или иной этап. Например, после проверки новости юрист оставляет пометку в карточке задачи: «Проверил, можно публиковать».

Процесс сложно изменить. Сотрудники привыкают дисциплинированно вести задачи по колонкам. Но может случиться, что задача срочная.

Можно заранее прописать, как действовать в «экстремальных» ситуациях и в каком случае сотрудники могут пропустить некоторые этапы. Или заранее найти запасных исполнителей, которые смогут в форс-мажорных случаях подключиться к задаче — оперативно проверить текст или нарисовать картинку.