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

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

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

SCRUM — планируем законченными итерациями

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kanban — разбиваем задачу на части

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

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

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

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

Для канбан-доски по этому проекту агентству понадобятся такие колонки:

— Входящие — задачи, которые поставили юристы.

— В работе — сейчас автор пишет эту новость.

— На проверке у эксперта — юрист проверяет новость.

— Текст для соцсетей — готовят короткую версию новости.

— Дизайн — иллюстратор рисует картинку к постам.

— Готово — новость опубликована на сайте и в соцсетях.

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

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

В столбике «Дизайн» копятся задачи, и посты в соцсетях не получается опубликовать по нескольку дней. Команда видит проблему и ищет решение: может быть, надо найти второго дизайнера или, наоборот, упростить задачу — не рисовать каждый раз иллюстрации с сюжетом, а сделать стандартный шаблон.

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

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

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

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

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

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

Юрист говорит: «Скорее публикуйте новость, там все просто, главное — рассказать подписчикам сегодня».

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

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