Консультанты Hewlett Packard Enterprise выполняют подобные проекты в области управления ИТ: ITSM, управление проектами и портфелями, мониторинг на любом уровне и т.д.
В последние пару лет во всём мире мы сталкиваемся с тем, что заказчики всё чаще просят или активно настаивают на применении подхода Agile к реализации подобных проектов. Уже и в России появились такие прецеденты.
Понятное дело, что за многие годы подход к реализации консалтинговых проектов в области управления ИТ был отработан в HPE на «пять с плюсом». Тысячи реализованных проектов по всему миру, огромное количество выученных уроков и строгая методология, которая говорит, как правильно. И это всё, разумеется, в формате waterfall. То есть «Пуск проекта», «Проектирование», «Создание», «Развёртывание и опытная эксплуатация». «Пришёл, увидел, победил».
Зачем
Здесь всё просто – заказчику нужен результат как можно быстрее. Посудите сами. Возьмём почти любую российскую компанию среднего или крупного масштаба:
1. Планирование бюджета начинается где-нибудь в августе:
- формируем инициативы,
- они оцениваются и «просеиваются» через сито экономической эффективности,
- превращаются в проекты,
- потом кто-нибудь пишет к ним детальные требования,
- и появляется соответствующая строчка в ИТ-бюджете.
2. В начале года берём бюджет и играем тендер – процедура занятная и мало где быстрая.
3. В марте, если повезёт, начинаем работы.
4. Результаты надо так или иначе выдать в конце года, ведь у всех KPI (как на стороне заказчика, так и на стороне подрядчика).
Итого: жизненный цикл проекта от инициативы до результатов проекта – порядка одного года-полутора лет. Это очень долго.
Что не так
Причин у такой ситуации несколько, но как минимум:
- Бюджетные и тендерные процедуры «победить» (сократить их сроки) тяжело. После 4-6 месяцев от появления инициативы до итогов тендера требования заказчика могут поменяться, пусть и в рамках той же темы. Нужен инструмент для гибкой переприоритизации задач.
- В рамках проекта работать по waterfall заказчик, конечно, тоже привык. И это написано во всех его внутренних регламентах, стандартах по управлению проектами и т. д. Но ждать результатов 6, 9 или 12 месяцев – очень скучно. Опять же, за это время уже в ходе реализации проекта многое может поменяться. Да если и не поменялось, результат хочется получать по частям и сразу же использовать его в работе.
Что делать
Заказчик должен понять, что выделять деньги под решение конкретных задач – прошлый век. Постановка задач, как мы уже выяснили, успевает часто меняться в ходе реализации этих задач. Поэтому деньги нужно выделять на развитие какого-то магистрального направления (в случае консалтинговых проектов, которые делает наша компания – на ITSM, управление портфелями и проектами, на мониторинг инфраструктуры или услуг и т.д.), задавая определённый вектор развития, но не конкретные требования и результаты. Безусловно, это потребует изменения способа мышления, перестройки внутренних процедур, но без этого – никуда.
Кроме того, нужно обеспечить гладкое прохождение организационных изменений, изменений в способах работы людей. Во многих организациях мы сталкиваемся с тем, что люди привыкли к быстрым и многочисленным изменениям – обычно это результат «ручного управления» на том или ином уровне в организации. Нужно использовать лучшие практики управления организационными изменениями – MoC, Management of (Organizational) Changes – в том числе, чтобы показать людям, что эти изменения не носят хаотический характер, а обеспечивают тот самый вектор развития, который был задан ранее.
Наконец, если мы говорим именно о консалтинговых проектах, то мы в HPE используем так называемую «модель бутерброда» (sandwich model):
- В начале проекта формируется исходный backlog задач, которые нужно реализовать. Можно считать это «микропроектированием», похожим на то, как мы проектируем процессы и функциональные требования к системе в рамках подхода waterfall.
- Данный backlog приоритизируется, как велит нам, например, ScrumXP. Далее работаем в режиме Agile, требования могут корректироваться и меняться. Разумеется, необходима жесткая дисциплина, наличие соответствующих ролей (product owner, scrum master и т.д.). Параллельно с разработкой кода пишем необходимые документы, готовим организационные изменения (кстати, в рамках DevOps есть мантра «everything is code», которая очень хорошо трансформирует сознание процессных консультантов).
- От понятия проекта мы всё равно не избавимся, когда работаем в связке «заказчик-подрядчик». А проект по определению – это ограниченная во времени деятельность. Поэтому Agile-историю в какой-то момент нужно подытожить, и сдать заказчику результат проекта (возможно, снабдив его необходимой дополнительной бюрократией). Кстати, это совсем не значит, что работа завершена – заказчик, привыкнув к тому, что в рамках середины «бутерброда» (п. 2) он регулярно получает новые релизы и новую ценность, с большей охотой и заранее будет готов позаботиться о продолжении работ и о выделении новых средств.
Как можно видеть, мы обворачиваем Agile с двух сторон waterfall-ом, что позволяет, с одной стороны, делать релизы и выдавать ценность заказчику чаще, с другой стороны, за счёт начала и окончания проекта, близкого к подходу waterfall, внешне проект выглядит как нечто, что имеет начало и конец. Это необходимо, в т. ч., потому что заказчики очень часто хотят реализовывать даже Agile-проекты по схеме fixed price, а не по схеме time & material.
Данная тема нам кажется весьма перспективной, и уже сейчас идут достаточно много проектов в таком формате. Например, есть крупный проект в компании, работающей по всему миру, где между релизами product owner собирает до 200 ключевых пользователей системы со всего мира, им демонстрируются результаты работы, а с них собирается обратная связь и при их помощи добавляются новые пункты в backlog. Это лишь небольшой штрих, показывающий возможный масштаб таких проектов, ведь традиционно Agile хорошо живёт в небольших командах. Впрочем, когда мы говорим об уровне предприятия, на помощь приходит SAFe, о котором мы уже рассказывали.
Подводя итог, хочется сказать следующее: консалтинговые проекты в формате Agile или «почти Agile» возможны. Мы даже их делаем. Будем рады услышать вопросы и комментарии по данной теме, в том числе с учётом специфики отечественных компаний и организаций.
Комментарии (14)
rsn81
07.06.2016 01:32мы обворачиваем Agile с двух сторон waterfall-ом
Поясните это утверждение? Под водопадом вы подразумеваете последовательный процесс: бюджетирование, реализация и закрытие проекта?
lykovaa
08.06.2016 23:28Нет, под водопадом и «оборачиванием» я подразумеваю то, что в начале проекта мы делаем некую «постановку задачи» (как бы делали это в waterfall-е), а в конце — некую «приёмку результатов проекта». То есть начало и окончание проекта — как в типичной каскадной модели реализации проектов. А середина, где дополнительная постановка задачи, разработка, тестирование, уже частично эксплуатация выпущенных релизов — agile.
rsn81
09.06.2016 00:58По мне вы немного сгущаете краски. Если мы проходим стандартные стадии проектного управления, это еще не означает, что жизненный цикл разработки продукта у нас водопадный. В принципе, проектное управление не то же самое, что водопад, и проектное управление с Agile не противоречат друг другу. За несколькими исключениями. Во-первых, традиционно принято команды собирать под проекты, как следствие, многозадачность, когда люди работают в нескольких проектах одновременно, а в Agile нужны стабильные команды, которым мы даем проекты (можно несколько). Во-вторых, длительные многомиллионные (натыкаюсь и миллиардные) проекты и Agile несовместимы или «невыносимосовместимы». То есть идет смещение фокуса на продукт (услугу, сервис и т.п. ценность), а проект становится просто упаковкой работ в рамках развития продукта, сильно теряет такой сакральный смысл, как ранее в него вкладывали.
lykovaa
10.06.2016 00:08Я не утверждаю, что использование Agile переворачивает с ног на голову проектное управление. Разумеется, многое остаётся похожим. Но всё же, некоторые коррективы необходимы. И не только в проектном управлении, но и в подходе к финансированию разработки в формате Agile. Если в waterfall-е мы финансируем скоуп, то в agile мы финансируем value, а скоуп у нас может быть очень подвижным.
Краски, возможно, немного сгущаю — но без этого не было бы дискуссии :)
Diaver
07.06.2016 05:39Немного оффтопа для любителей F1:
1. Что за машина?
2. Гонщик?
И вопрос для самых задротов:
3. Что за трек?
kmmbvnr
07.06.2016 08:46+1Немного офтоппа — это почему для иллюстрации быстрого пистопа постоянно используют фотографии с Ferrari, когда как самые быстре остановки у Мерседеса?
bipiem
07.06.2016 14:55Свое видение на Agile и не Agile привел (03.06.2016 23:33):
club.cnews.ru
«Разговор про Bimodal IT — ведется несколько десятилетий (хотя термин и «свеженький»). Людям же нужно что-то обсуждать годами, но „как-бы новое“.
Обсуждения, как правило, в ключе: Стабильность — качество против Гибкость-скорость изменений (внедрения). Консерватизм и выдержка против Быстрых инноваций, не проверенных временем …
Там же постоянно задаю вопрос: Есть ли: „Простой пример простого EA“?
Hewlett Packard Enterprise также любит произносить странные слова „Enterprise Architecture“ (EA). Лучше бы привели пример, пусть совсем крошечного предприятия и даже на „HPE Enterprise Maps“, но комплексный.
О проблеме запутанности — см. мои статьи на Habra.lykovaa
08.06.2016 23:44Once industries and professions reach a certain level of maturity, efforts arise to standardize key terminology and concepts to foster improved knowledge exchange and collaboration. When done using an Enterprise Architecture framework or method, such attempts may be termed “reference architecture” or “reference models”. Notable examples of such efforts include:
- Frameworx (eTOM), by the TM Forum
- BIAN – the Banking Industry Architecture Network
- ARTS – the work of the Association for Retail Technology Standards, an affiliate of the National Retail Federation
- The ACORD framework – an Enterprise Architecture for the insurance industry
- EMMM – the work of The Open Group Exploration, Mining, Metals & Minerals Forum
bipiem
09.06.2016 22:16Да, я знаю. Enterprise Architecture: есть ARIS для EA, есть ARIS для TOGAF, а есть TOGAF для EA и много тому подобного. Фреймворки, философии, алхимии …
Нет только просто: „Простой пример простого EA“
Поэтому: Alchemy — forever!
Давно «эти отрасли и профессии достигли» бы «определенного уровня развития» если бы не палки в колеса алхимиков и маркетологов.
Что касается сетей, которые network.
С такими сетями такого «финта ушами» как с ЕА сделать сложно.
Сети LAN-WAN, во-первых по определению стандартизированы. Иначе они не работают, во всяком случае «большие». Во-вторых, там нет — как в ЕА и ВРМ — «бизнес-составляющей»: миссия и цели компании, постоянное совершенствование и т.п. – о чем я много потратил букв в своих статьях.
В сетях есть законы физики и математики, начиная от Котельникова и помехоустойчивого кодирования. Ничего подобного в известных мне Фреймворках ЕА неет. Пока нет Фреймворка + комплексного примера – это не инженерная дисциплина, а …
Хотя уже и «в сети» лезут разные «умники» и немецкие профессора.
Посмотрим на примере BIAN. Это же «круто»?
Есть хоть что-то рациональное в статьях про BIAN от российских банков? Что рационального, например, здесь
Часто BIAN — это когда или рядом с квадратиком «Business Strategy» дорисовывают (и соответственно, монетизируют) квадратик «Business Network» или начинают говорить, что есть некая SOA исключительно для банков. Вообще, зачем в BIAN упомянут «network»?
«Маркетинговый BIAN» мне понятен, а инженерный – нет. Покажите, что это не так. Было бы очень здорово.
Покажите на конкретном комплексном примере этот самый-самый «BIAN Service Landscape» или что там они еще «продвигают». Не обязательно на Сбербанке, покажите на условном банке из пятой сотни. Отсылать на bian.org за теорией не нужно. Нужны конкретные примеры и практика.
И про „Простой пример простого EA“ тоже не забудьте, пожалуйста.
К сожалению маркетинговый мир ИТ превзошел реальный сектор ИТ точно так же, как финансово-биржевой (виртуальный) превзошел реальный сектор экономики. Многим проще жить и зарабатывать в виртуальном мире ИТ (не путать с ИТ-направлением «виртуальная реальность»), чем в реальном.
«Нет ничего практичнее хорошей теории». Только вот такой теории очень мало.
Amareis
Можете вот это расшифровать?
ivanbolhovitinov
Хороший вопрос. И мне так кажется, что имеется в виду ситуация, что если консалтинг не может решить проблему, значит чтоб её решить нужно написать код.
Я считаю, что ДевОпс — это уровень выше консалтинга.
Например, если есть возможность конфигом-гуи-галочками-итд достигнуть нужного эффекта, то консталтинг просто скушает её, решит внутри себя.
И если уж консалтинг выносит проблему наверх, то без кода не обойтись.
lykovaa
Это значит, что всё, что вы делаете — это код. Инфраструктура — это код, документы — это код. Со всеми этими штуками нужно работать по тем же (или почти по тем) правилам, как с кодом. Версионный контроль, тестирование, релизы, приёмка и всё такое.
MBurov
«everything is code» в DevOps означает что абсолютно все, чем вы манипулируете является кодом.
Это распространяется как на исходный код приложения, так и на Infrastructure as Code, к которой в свою очередь применяются те же правила как Версионирование (versioning).
На любой момент вы можете восстановить и протестировать любую версию кода (GIT ветка с вашим приложением), к которой соответствует полная топология IT архитектуры (GIT ветка ИТ инфраструктуры), на которой было установлено приложение и смоделировать возникший баг с целью его исправления.
lxsmkv
В DevOps входят к примеру, услуги по устройству процесса интеграции и автоматизированного тестирования, хостинга и техподдержки инфраструктуры и т.д и т.п Это все обеспечивается с помощью людей и программного обеспечения, которое, нужно настроить, написать, отладить, поддерживать, мигрировать и т.п. Вся эта инфраструктура имеет жизненный цикл и является такой же «dеliverable» — грубо говоря программной «плюшкой» которая каждый день выкатывается из «печи», но для разработчиков. Т.о. IT-инфраструктура для программного проекта имеет все те же свойства, которые имеет продуктивный код в продукте конечного потребителя. Это значит к ней применимы те же требования которые предьявляют к коду — качество, надежность, удобство использования и т.п… Поэтому k DevOps уместен тот же подход как к разработке программного продукта для клиента, несмотря на то, что конечный пользователь DevOps — это разработчик.