Честно скажу, название статьи навеяно старым анекдотом…
Как заставить себя вставать пораньше? Как просыпаться выспавшимся? Как приходить на работу радостным? Как уехать из Крайнего Севера и жить в Сочи? Как есть всё подряд и не толстеть? Обо всем этом читайте в новой книге "Никак, б*”%#*!" "Никак, б*”%#*!" - теперь и в твердом переплете.
Дисклеймер. Я ни секунды не утверждаю, что именно вам нужно срочно переходить с Водопада на Agile. Универсальной и идеальной методологии вообще не существует. Я ни секунды не утверждаю, что в вашем случае возможен переход на Agile, а мешающие этому проблемы преодолимы. Я просто констатирую, что у многих компаний есть успешный опыт руководства ИТ-проектами при помощи гибких методологий, и этот опыт может оказаться полезным.
Управление требованиями: больная тема
Начну, с вашего позволения, с небольшого списка литературы.
Я уже рассказывала, какие бывают подходы в управлении проектами. Чтобы у нас была возможность говорить на одном языке, рекомендую перед прочтением этой статьи ознакомиться с моими материалами на эту же тему Можно ли объять необъятное или чем Agile отличается от водопада? и Почему Agile превращается в Тяп-ляп. Кто виноват и что делать? Тема написания ТЗ и уточнения требований была в свое время частично раскрыта в статье Александра Чавалаха Разработка технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть? Классические подходы (водопад/итеративный подход) разбирает в своих статьях Иван Селиховкин, так что не буду его дублировать, и поговорю подробнее про применение гибких методов в управлении.
Опрос среди руководителей проектов внедрения 1С, проведенный на сайте Инфостарт, показал, что из всех проблем лидируют “Изменение требований в ходе проекта” (около 25% опрошенных) и “Нечеткие требования заказчика” (около 24% опрошенных).
Итак, в чем ключевая особенность управления по Agile в вопросах создания ТЗ и управления требованиями?.. Очень просто - ограничения не фиксируются в начале проекта. То есть у нас нет той самой “скорлупы яйца” - жестких сроков-бюджета-содержания, о которых говорится в статье Ивана Селиховкина Три фундаментальных принципа проектного управления.
Мы понимаем окончательную цель проекта - допустим, переход от зоопарка разных программ и приложений ("лоскутная автоматизация") на 1С: Комплексную автоматизацию. Но не знаем подробности: сроки, стоимость, и даже подробное содержание (бизнес-функциональные требования, а тем более технические задачи для выполнения этих требований).
Если и заказчик и исполнитель привыкли работать по водопаду, то на этой точке (неопределенность общих сроков, содержания и бюджета) дальнейшее сотрудничество может быть признано невозможным.
Но в Agile - все так и работают, и считают, что так и надо )))... Давайте попробуем разобраться, за счет чего это может получиться.
Водопад: его недостатки и ограничения
Водопад, несомненно, большой шаг вперед по сравнению с технологией “тяп-ляп” - здесь четко структурирован порядок деятельности.
Скажем, вот так выглядит технология корпоративного внедрения (ТКВ) от 1С, предполагающая последовательное внедрение по водопаду.
Весь проект разделен на четкие последовательные фазы, каждая из фаз регламентирована.
В чем же основные недостатки водопадного подхода?
- В начале проекта Заказчик не может написать хорошие требования
Чем серьезнее и комплекснее проект внедрения, чем большие изменения бизнес-процессов компании предполагаются, тем сложнее Заказчику сформулировать, что именно ему требуется. Скажем, в ходе внедрения Документооборота в Почте России, эта проблема возникла в полный рост - будущие пользователи смутно понимали, что от них требуется.
- Список требований пополняется до самого конца проекта
Очень часто, знакомясь с документами по тому или иному проекту, я встречаю упоминание пополнения списка требований в графе “Риски проекта”. Увы, по моему опыту, это скорее не риски, а ограничения проекта - я пока не видела ни одного проекта внедрения, где новые требования бы не появлялись в процессе. Может различаться только отношение к этим требованиям. Исполнитель может делать лицо кирпичом и отказываться их учитывать, ссылаясь на подписанный контракт. Но новые требования будут появляться обязательно (если заказчик хоть сколько-то вовлечен в процесс разработки и тестирования).
- Самые точные и полные требования Заказчик сформулирует на стадии внедрения
Одна из типичных проблем при сборе требований, сформулированная Дмитрием Безуглым в его онлайн-курсе “Постановка задачи на разработку ПО” - “Заинтересованный стороны и пользователи думают, что знают, чего именно они хотят, до тех пор, пока им не дали именно то, что они попросили”.
Опять же, можно обвинять в этой проблеме аналитиков и пользователей, но по мне, это примерно как обвинять небо, что идет дождь...
- Аналитиков не волнуют трудности будущей разработки
В моей практике в больших командах внедрения часто возникают конфликты внутри команды между разными “лагерями”:
Аналитики обвиняют продажников, в том, что они обещали реализацию функционала, который с их точки зрения, мало возможен при помощи предложенного продукта.
Разработчики обвиняют архитекторов, что они призывают реализовать громоздкое и неработоспособное решение.
Тестировщики обвиняют разработчиков, что они пишут кривой код...
Ну, и так далее (кстати, как у вас? поделитесь в комментариях)...
- Заказчики не знают возможностей и ограничений технологии
Любое внедрение, предполагающее смену инструментов с разной бизнес-логикой (переход с 7 на 8 бухгалтерию, переход с УПП на ERP и т. п.) обычно сопровождается довольно болезненными запросами “сделайте мне также как было” и объяснениями консультантов, почему именно это невозможно.
С другой стороны, если заказчикам не приходит в голову, что приложение может решать какую-либо задачу, они и не включат запрос об этом в бизнес-функциональные требования.
- Существуют проблемы (ошибки), о которых можно узнать только завершив работу в этой фазе и начав работу в следующей
Кривые и непродуманные аспекты архитектуры очень часто становятся заметны только на этапе внедрения. Если в вашем проекте по занесению пианино на 17-ый этаж вы совершили ошибку на этапе планирования - неправильно выбрали подъезд - то вы ее заметите только перейдя к этапу внедрения в квартиру…
Agile: подход к сбору требований и написанию ТЗ
Итак, мы поговорили о проблемах и ограничениях водопадного подхода. Как же можно минимизировать эти проблемы?
При помощи итеративности и инкрементальности. То есть выдавать конечный результат маленькими порциями (инкрементами), и осуществлять планирование на протяжении всего проекта (итеративно). Детализация требований при этом тоже осуществляется на каждом этапе отдельно. См, например, схему работы предлагаемую компанией 1С в технологии быстрого результата (ТБР), относящейся к гибким методологиям:
Детализация требований и планирование осуществляется на каждой фазе отдельно, то есть непонимание заказчиком своих запросов на старте уже не является проблемой.
Работает ли Agile в ИТ-проектах и проектах внедрения 1С в частности?
В ходе вебинара для руководителей проектов мы провели опрос более чем 100 руководителей проектов внедрения 1С. И результаты опроса показали, что около 22% РП применяют гибкие методы в управлении проектами.
Мировой опыт тоже явно указывает на тенденцию перехода в Agile.
Скажем, очередной Chaos Report от Standish Group International показал, что шансы на успех ИТ проекта (то есть полное выполнение целей и удовлетворение заказчика) по Agile более чем в полтора раза выше, чем управляемого по водопаду.
Итак. Мы выяснили, что Agile возможен, что уход от водопадной модели обладает некоторым количеством преимуществ. Теперь прикладной вопрос - как это может выглядеть на практике, при внедрении 1С-продукта?
Вариант первый. Внедрение внутри предприятия своими специалистами.
Здесь, как мне кажется, Agile просто напрашивается. Большинство известных мне крупных успешных компаний, где ИТ-решения предлагают внутренние подразделения, постепенно уходят от крупных комплексных проектов, с тщательным продумыванием деталей на старте. Потому что к концу долгого водопадного проекта чаще всего выясняется, что проект успешно реализован согласно ТЗ, но… в таком виде уже давно никому не нужен.
Как выглядит управление проектом по Agile в этом случае?
На старте четко понимается целевой результат. На старте максимально четко понимается архитектура решения в целом. На старте формулируются наиболее важные бизнес-функциональные требования. На старте определяется функционал первого релиза. На старте мы не пытаемся понимать весь бюджет, сроки внедрения в целом, полный объем содержания. Дальше проект запускается, и обеспечивается взаимодействие между ключевыми заинтересованными сторонами.
Вариант второй. Внедрение во внешней организации. Серия небольших договоров.
Как уже описывалось выше, в начале проекта заказчик и исполнитель не пытаются понять общую стоимость, продолжительность и содержание проекта. В начале - оформляется рамочное соглашение, договор о намерениях, включающий общую цель. Дальше заключается серия небольших контрактов, каждый из которых предполагает законченный результат, подлежащий использованию. Неоднократно наблюдала компании франчайзи, которые успешно выполняли многомиллионные контракты на крупные компании/холдинги “по кусочкам” - каждый конкретный контракт заключался на небольшую сумму.
Вариант третий. Внедрение во внешней организации. Один большой контракт.
Вариант, описанный выше, хорош, но не всегда возможен. Скажем, когда у вас идет речь о госконтракте, объявляется тендер, подписывается договор на старте - и в нем должны быть жестко зафиксированы сроки, бюджет и содержание ТЗ. Как можно действовать в такой ситуации? Мы же помним все те недостатки водопадного метода, про которые мы говорили в начале статьи - заказчик физически не способен на старте четко сформулировать исчерпывающие требования, появление новых требований и уточнение старых в ходе проекта неизбежно.
Чтобы иметь возможность применять гибкие подходы Agile, вам нужно суметь реализовать две лазейки.
Во-первых, не пытаться четко прописывать подробные требования на старте. На старте в ТЗ указываются высокоуровневые требования, а дальше они, по методу набегающей волны, детализируются уже в ходе проекта.
Во-вторых, заложить в контракт опцию замены требований на аналогичные по трудоемкости. Знакомая, думаю, всем ситуация - в ходе проекта заказчику становится понятно, что ему крайне необходим дополнительный функционал. При этом контракт подписан и утвержден на старте, и исполнитель не жаждет делать дополнительные работы за бесплатно. В такой ситуации можно предложить заменить часть функционала из контракта, которую заказчик на настоящий момент оценивает как менее ценную, на новые функции. Причем приоритетность функций (что важнее всего) оценивает заказчик, а трудоемкость работ (что значит “заменяем работу на аналогичную”) - исполнитель.
Важно, чтобы договор предполагал выполнение работ по этапам, и была возможность при помощи дополнительных соглашений менять состав работ на каждом этапе.
Скажем честно, на практике так очень часто в водопадных проектах и делают “мимо договора”, просто “договариваясь по понятиям”... Но в этой ситуации мы имеем расхождение между документом и действительностью, что осложняет дальнейшее сопровождение и вообще усложняет коммуникацию. Оптимальное решение, повторюсь, указано выше - заложить в условия договора возможность замены одного функционала на другой.
Ограничения Agile
Гибкие методы управления проектами - не панацея.
В рамках вебинара для руководителей проектов 1С, который мы провели некоторое время назад на Инфостарте, руководители проектов, успешно применяющие Agile, поделились за счет чего им это удается, а что - мешает. Ниже рекомендации по моему опыту и опыту моих коллег:
Что мешает внедрять Agile?
- Как я писала в предыдущей статье - гибкие методы подходят для проектов с высокой степенью неопределенности требований, высокой степенью технической неопределенности и возможностями частых поставок.
- Agile ограниченно подходит для решений со сложной архитектурой. Компания 1С, разработавшая Технологию быстрого результата (ТБР), по сути, являющуюся фреймворком в рамках гибких методологий, не рекомендует применять ее для сложных архитектурных решений. Потому что частыми маленькими релизами как раз легко сломать типовую архитектуру и нагородить решений, которые сложно будет использовать для других задач.
- Гибкие методы подразумевают очень сильное вовлечение специалистов заказчика (вплоть до участия в определении фич в начале каждой итерации) - а это время заказчика и немалое. Не все заказчики к этому готовы.
- Неопределенность бюджета и сроков проекта усложняет коммуникацию с руководством заказчика
- При работе по небольшим кусочкам заказчик всегда может разорвать контракт с исполнителем посередине, или отложить реализацию следующего фрагмента. Это удобно заказчику, но уменьшает уверенность исполнителя в завтрашнем дне. Разрывы между итерациями увеличивают себестоимость проекта.
Что помогает внедрять Agile на практике?
- Отношения, основанные на доверии, и готовность обеих сторон к сотрудничеству.
- Приемка каждую итерацию. Или хотя бы демонстрация заказчику.
- Документальная фиксация согласия заказчика с промежуточным результатом - актировать этапы.
- Вовлечение в тестирование на промежуточных стадиях широкого круга пользователей от заказчика (зачастую против воли основного представителя заказчика)
- Практически любой заказчик хочет быстрый результат. Поэтому обещанием работающего инкремента с урезанным функционалом по итогам первой итерации - позволяет уговорить заказчика на применение гибких методологий.
- Обжегшись на молоке заказчики начинают дуть на воду. Если у заказчика был опыт неудачных ИТ-проектов по водопаду - уговорить его на Agile будет несколько проще ))).
Резюме данной статьи хорошо сформулировал мой коллега, Дмитрий Кузнецов:
Использование гибких методов не гарантирует успех проекта. Но в некоторых ситуациях (например, высокой неопределенности требований) не применение Agile предопределяет его провал...
В следующей статье я расскажу про то, какие техники и инструменты по сбору и приоритизации требований предлагают гибкие методологии. Следите за обновлениями.
Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах
