Каталог решений - Бывает ли Agile в проектах 1С?

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

Маленький спойлер для тех, кто не успеет дочитать до конца: в четверг 9 декабря в 12:00 пройдет открытый мастер-класс “Как представить Заказчику проект по Agile, чтобы он на него согласился?” как раз в рамках обсуждения темы “А бывает ли Agile в 1С?”. Присоединяйтесь, пообщаемся вживую! Желательно с микрофоном.

Сразу два уточнения:

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

Во-вторых, бывает, что под лозунгом “мы работаем по Agile” люди пытаются скрыть недостаток профессионализма. “Мы не документируем, у нас Agile”… “Зачем нужно продумывать архитектуру, будем всё планировать по ходу” — такие заявления показывают, что применяемый подход ближе к “Do&Fix” или “Тяп-ляп”, чем собственно к Agile.  В действительности, при запуске любого проекта разработки или внедрения, несомненно, нужно нарисовать примерную дорожную карту продукта (или проекта). Нюанс в том, что она, во-первых, будет без мелких деталей, а во-вторых, может существенно корректироваться в процессе. 

Вкратце — про что мы вообще говорим — что такое Agile подходы?

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

• Небольшую кросс-функциональную самоорганизующуюся команду, которая работает над продуктом
• Отсутствие подробного ТЗ на старте и уточнение требований в процессе работы
• Частые поставки готового продукта
• Тесное сотрудничество заказчиков и исполнителей
• Корректировки по итогам обратной связи

Звучит привлекательно, но из второго и пятого пунктов (черт, опять этот пятый пункт) следует то, что на старте проекта по Agile крайне сложно определить это объем, стоимость и продолжительность.  И именно в этом и заключается основной затык: заказчик удивленно поднимает брови и спрашивает у исполнителя: “А как мы можем с вами договориться на проект, если вы не можете внятно сказать, что вы сделаете и сколько это будет стоить???”. 

Итак, как же можно запустить проект с высокой степенью неопределенности?
Рассмотрим несколько ситуаций по мере возрастания сложности.

Ситуация №1, простая. Внутренний проект (в не очень бюрократизированной компании)

Изначально Agile-подходы (в первую очередь Скрам) и создавались для внутренних проектов. Когда у нас нет контракта с внешним подрядчиком, когда у нас в любом случае есть команда ИТ-специалистов на зарплате, договориться с лицами принимающими решения чаще всего оказывается не так уж сложно. 
Достаточно описать ситуацию: 
Бизнес жалуется на отсутствие четкой системы работы с клиентами, что приводит к косякам, потерям клиентов, сложности контроля. Есть такая-то бизнес-проблема. Для ее решения предлагается внедрить и кастомизировать CRM-систему. Высокий уровень неопределенности не позволяет обозначить объем работ на старте. Мы как профессионалы, понимаем, что в текущей ситуации писать подробное ТЗ — просто потеря времени, и можем объяснить почему. Поэтому мы предлагаем работать по Agile (если это слово еще не является ругательным в компании),  у нас есть вот такая дорожная карта, и будем уточнять требования по ходу, чтобы выдать именно нужный результат.  Когда будет готово мы точно сказать не можем, но будем держать всех в курсе работы. 
Кстати, буквально недавно читала регламент по проектному управлению в крупной окологосударственной банковской структуре. И там черным по белому было написано — что если ИТ-проекты не предполагают привлечения подрядчиков, то их рекомендуется делать по Скрам. Так что лед в этом направлении двигается все быстрее и быстрее… 

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

Итак, усложняем ситуацию. Руководство хочет точно планировать бюджет на квартал и на год (и его можно понять). Здесь у нас есть два варианта тактики. 
Бюджетирование не проекта, а портфеля.  Допустим, в организации есть несколько портфелей проектов (критические проекты “для выживания”, проекты развития, стратегические проекты и т. п.), каждый привязан к своей стратегической цели, и на каждый определяется сумма расходов. В начале года Инвестиционный комитет определяет сумму затрат на портфель проектов развития ИТ (или даже более узко — проектов развития 1С). Фактически, здесь речь идет в основном про затраты на зарплату ИТ-специалистов и амортизацию оборудования — то есть мы договариваемся, например, что вот эти 8 специалистов 50% своего рабочего времени занимаются проектами развития. Ура, бюджет у нас есть!.. Мы даже готовы примерно обрисовать план, какие именно проекты внедрения и доработки мы успеем реализовать в рамках этого портфеля за год. Но — ключевое слово “примерно”. Также как и в прошлом примере, мы честно предупреждаем, что мы работаем по Agie, и точный объем работ, также как и точные сроки каждого проекта мы сможем уточнить уже по ходу. Но пусть это не пугает наш уважаемый Инвестиционный комитет!
Потому что, во-первых, у нас есть четкий бюджет — мы знаем, сколько денег мы потратим на развитие.
Во-вторых, мы уверены, что это будут наиболее актуальные перспективные направления развития, потому что мы будем работать в тесном контакте с бизнес-заказчиками.
В-третьих, мы будем регулярно представлять Инвестиционному комитету результаты, чтобы он был уверен в том, что мы двигаемся правильно.
Ну и, в-четвертых, если уважаемый Инвестиционный комитет настаивает, мы можем заявить итоговые KPI по итогам портфеля — например, рост удовлетворенности клиентов, уменьшение числа ошибок, повышение производительности системы и так далее. Мы еще не до конца знаем, что именно мы сделаем для достижения поставленных целей (потому что, как вы помните, в рамках Agile мы строим гипотезы и проводим эксперименты), но нам в любом случае понятно, куда надо стремиться.

Ситуация №3, опять простая. “Согласие на Agile от безысходности”.

Организация может сколько угодно не хотеть или не мочь работать по Agile (ограничения 44-ого ФЗ, корпоративные регламенты, необходимость проведения тендера с детализированным ТЗ и так далее). Но очень часто, увы, ситуация оказывается безвыходной: проект по Водопаду был заявлен, подробное ТЗ написано, проект запущен, реализован, его результат получен… И оказался совершенно бесполезен. Потому что либо заказчик в начале проекта не мог написать реалистичные требования, либо ситуация за время проекта изменилась настолько, что цели в настоящий момент уже совершенно другие.  И вот, как показывает практика внедренцев, на этом месте сколь угодно упертые изначально заказчики оказываются куда сговорчивее. Если людям действительно нужен результат (а если проект и так был “для галочки” — то всё и так в порядке — “галочку” можно с чистой совестью поставить), то они найдут возможность работать гибкими методами, что с внутренним подразделением, что с внешними подрядчиками.  Многие внедренцы как раз и признают, что работать по Agile хорошо получается с заказчиками, у которых только что всё провалилось по Водопаду. И залог успеха здесь не только в том, что Agile позволяет более гибко решать проблемы, а еще и в том, что заказчик после проваленного проекта — это уже немного другой заказчик, чем был до. Мне очень понравилась фраза, высказанная в рамках дискуссии на форуме Инфостарта (я даже взяла ее в заголовок одного из докладов) — “Agile — это спасательный круг для проектов, утонувших в Водопаде”. Если речь идет про внешний проект — то технически взаимодействие в таком случае обычно оформляется как договор сопровождения, так как в такой ситуации нет обязательных правил про тендер с фиксированными на старте условиями. 

Ситуация №4, чуть посложнее. Внешние проекты: типовое внедрение при помощи 1С:Технологии быстрого результата.

И здесь, опять же, легко проверить, что это бывает на практике. Мы работаем с применением 1С:ТБР, многие другие компании работают с применением 1С:ТБР. Довольные заказчики пишут хвалебные отзывы про 1С:ТБР. 
В чем суть Технологии быстрого результата в двух словах? 
Поставка функционала небольшими работающими кусочками (одна итерация — не дольше 1 месяца)
Подписывается договор на каждый блок, и по итогам каждый кусочек актируется заказчиком и работа оплачивается сразу.
Тесное сотрудничество заказчиков и исполнителей в процессе, возможность у заказчика контролировать исполнителя благодаря прозрачности, максимально упрощенная процедура согласования изменений.
Есть готовый набор шаблонов документации, простой и понятный, ничего лишнего.

Основным ограничением технологии является то, что она рассчитана в первую очередь на типовые решения, и не предполагает существенных изменений в архитектуре. Зато перед началом каждого блока несложно понять его объем и стоимость — так как решение достаточно понятное. Ну, и да — заказчик должен быть готов работать в тесном контакте. Глеб Стальной (Первый бит Савеловский), один из активных внедренцев по Agile поделился как ему однажды на предварительном совещании с заказчиком строго сказали: “ну надо же всё согласовать со всеми!”.  На этом месте Глебу сразу стало понятно, что проект по Agile не взлетит. 

Ситуация №5. Ещё сложнее. Предстоит делать сложное внедрение по Agile: объем непонятен, но заказчику нужно четко определить бюджет.

Здесь сразу надо оговорить один момент. Одним из условий работы по Agile должно быть наличие достаточно высокого уровня доверия между заказчиками и исполнителями. Без доверия не стоит и начинать.  Доверие не складывается в одночасье, к нему нужны некоторые предпосылки. 

• Во-первых, заказчик и исполнитель должны быть уже сколько-то знакомы друг с другом, и иметь опыт конструктивной работы вместе (во время предпроекта, или других проектов или какой-то еще ситуации).
• Во-вторых, оба должны быть нацелены на долговременное сотрудничество (а не быстро что-то сделать, получить деньги и убежать).
• И в-третьих, должен присутствовать определенный уровень взаимопонимания и прозрачности. 

Только в таких условиях возможна стратегия, которую Стивен Кови в своей книге “Семь навыков высокоэффективных людей” назвал “Выиграл-выграл” (в противоположность стратегии “Выиграл-Проиграл”. Вернее, даже не так. “Выиграл-выиграл или не связывайся” — когда мы не идем на сотрудничество если видим, что партнер не поддерживает такую стратегию.
Кстати, на своих курсах по управлению проектами я обычно предлагаю участникам поиграть в игру по Дилемме заключенного. Очень хорошо промывает мозги на тему, почему люди в разных ситуациях ведут себя так, а не иначе…

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

В этих условиях высоки шансы договориться на то, что я в своей статье Контракты в Agile называла “перевернутым проектным треугольником”: когда в контракте фиксируются сроки и стоимость проекта, но жестко не фиксируется функционал (обычно примерно в формате размытого ТЗ). При этом исполнитель может озвучить заказчику примерно следующее:
Давайте подпишем с вами контракт на полгода на кастомизацию под вас Комплексной автоматизации 2. За это время мы гарантированно сможем сделать MVP (Minimum Viable Product — минимальный жизнеспособный продукт) и нарастить его наиболее ценным функционалом (даже если пока не до конца понятно, что именно будет для вас ценным). Так как проект сложный, мы с вами понимаем, что на старте невозможно четко описать итоговый функционал. Мы понимаем, что многие требования будут появляться у вас уже в процессе работы, в процессе тестирования первых модулей. Обращаем ваше внимание, что риски с вашей стороны минимальны — так как мы в начале каждого месяца (недели, двух недель) будем обсуждать с вами, какие именно функции для вас наиболее приоритетны на данном этапе. Вы сможете сразу начать пользоваться уже внедренным функционалом, если что-то пойдет не так — всегда сможете разорвать контракт (хотя мы уверены, что этого не понадобится).

Как-то так. Я описала основные ситуации, с которыми приходилось сталкиваться. Кому интереснее поговорить об этом подробнее — приходите на мастер-класс 9 января. 
Ну, а кому интересно разобраться еще подробнее — приходите на мои курсы на Инфостарте )))

• В январе почти одновременно стартуют Базовый курс — для того, чтобы разобраться, что такое Agile.
• И Практический курс Agile-лидера — чтобы всерьез научиться по Agile работать.

До встречи на Инфостарте!