Про Scrum и Agile слышали все

Про Scrum и Agile слышали все.

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

Давайте разберем это на примере того, как мы ведем управление задачами в бобдей.

Манифест Agile говорит:

«Ценность важнее формальностей, а готовность к изменениям важнее следования плану.»

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

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

Мы строим работу так, чтобы сохранить дух Agile, но учитывать реальность больших контуров.

1) Рабочий результат важнее отчета о работе

Вместо формулировки «согласовали на встрече» мы используем фиксируемый документ — протокол решения.

В нем всегда есть:

⭕️ решение

⭕️ владелец правила со стороны заказчика

⭕️ срок

⭕️ критерий результата

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

2) Сотрудничество с заказчиком важнее согласований

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

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

3) Изменения нормальны, но ими нужно управлять

Agile говорит: “быть готовыми к изменениям. Мы с этим согласны. Но в больших внедрениях изменения без фиксации превращаются в размывание периметра, сроков и бюджета.

Поэтому у нас есть:

📍 устав проекта как фиксация ключевых параметров,

📍 отдельный реестр изменений, где видно что меняем, почему, как это влияет на сроки и ресурсы, кто согласовал.

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

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

Если вы его не читали - вот ссылка

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