Бухгалтерские проекты по Agile: как использовать методологию scrum не только в разработке ПО

Мы перешли на Agile-методологию в реализации бухгалтерских проектов в 2019 году. Но на самом деле, по принципам, изложенным в Agile-манифесте, мы работаем давно, пожалуй, работали всегда, просто не знали, что называется это таким английским словом. Вот эти принципы:

• Люди и взаимодействие важнее процессов и инструментов — да.
• Работающий продукт важнее исчерпывающей документации — да.
• Сотрудничество с клиентом важнее согласования условий контракта — да.
• Готовность к изменениям важнее следования первоначальному плану — да.

Поскольку для нас правильным будет четыре из четырёх, то было очевидно, что стоит развивать технологию и инструменты для работы команд в проектах.

Какие проекты мы делаем по Agile

"Бухгалтерия — это же рутина!", — скажете вы. Заведение первички, формирование отчётности, начисления, платежи... Но когда мы хотим качественных изменений для клиента — не просто отражать в учёте те документы, которые предоставил клиент, а улучшать процессы — тогда мы начинаем проекты. Какие это проекты? Например: восстановить учёт за год; перейти из 1С.Управление производственным предприятием на 1С.Комплексная автоматизация; интегрировать программу учёта товаров в ресторане с 1С; придумать процесс учёта в производстве, которого раньше не было. И многое другое.

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

Читайте также

Аутсорсинг бухгалтерии = объективные данные для собственника

Как отдел бухгалтерского аутсорсинга использует Scrum-методологию

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

Как это работает у нас:

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

Если проект касается не только наших внутренних процессов, сотрудники клиента всегда будут частью команды. Например, ни один проект восстановления не обходится без инвентаризации, а в ней обязательно активное участие специалистов клиента. От того, как быстро и точно инвентаризация будет проведена, будет зависеть успех восстановления. В других проектах сотрудники клиента собирают данные, заполняют справочники, разрабатывают калькуляции. Только когда они внутри проекта, они видят — как их задачи влияют на общий результат.

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

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

• Договариваемся о продолжительности отдельных отрезков — спринтов — обычно, неделя или две, в течение которых выполняется определённое количество задач. Цель задач в спринте — получить промежуточный результат, который можно оценить, посмотреть. Перед каждым спринтом мы проводим планирование и решаем, какие задачи пойдут в работу. В течение спринта мы собираемся ежедневно на короткие — около 15 минут — встречи, которые называются скрамами. По завершении спринта мы проводим ретроспективу — разбор результатов. Затем цикл повторяется.

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

Визуализация

В технологии scrum важна визуализация. Доски, цветные стикеры, фломастеры — обязательно, особенно в начале, пока процесс не стал понятным и привычным. Это скажет каждый: передвигать цветные стикеры с задачами из "выполняется" в "сделано", да ещё и при всей команде — особое удовольствие! В целом, наглядность помогает управлять процессом и не терять мотивацию на протяжении всего проекта.

Встреча scrum-команды, планирование

Сейчас мы используем электронные доски в Битрикс24 или в Miro, до этого — в Trello. Но бэклог все равно привычнее на бумаге.

В чём преимущества гибкого подхода для клиента и для нас

Что важно — Agile подразумевает, что нет необходимости фанатично следовать первоначальному тех. заданию, даже если оно подписано вместе с договором.

Мы и наши клиенты часто слышим от программистов 1С: "Напишите техническое задание. Не можете? Тогда мы напишем его за деньги. Не знаете что вам нужно? Тогда это ваши проблемы. Результат соответствует ТЗ. А если он вам не нравится — раньше надо было думать, когда ТЗ согласовывали". Замкнутый круг.

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

Ещё полгода назад клиент тратил несколько часов в день, чтобы вести таблицу по маржинальности проектов. Сейчас стали появляться первые данные в 1С, при этом руководитель не тратит на это своего времени. Конечно, возникает желание добавить новые разрезы аналитики: по заказу, по договору, по типу номенклатур. Конечно, мы не скажем "нет, мы так не договаривались" — мы возьмём задачу в следующий спринт.

Технология scrum с её короткими отрезками позволяет нам, получая промежуточные результаты, сразу давать им оценку — соответствуют ли они ожиданиям, туда или не туда идём, нравится заказчику или нет, возможно, появились новые вводные, которые меняют приоритеты.

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