Так вот, позволю себе ответить: да, видела. И у себя в компании, и в других организациях, и очень часто результаты были очень позитивные. Не всегда, но часто. И даже готова поделиться где и при каких условиях это работает.
Маленький спойлер для тех, кто не успеет дочитать до конца: в четверг 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 работать.
До встречи на Инфостарте!
