Наша компания представляет собой экосистему для сотрудников и клиентов, в которую входят не только программные обеспечения, которые мы разрабатываем, и проекты, которые мы внедряем, но и люди.
Я поделюсь информацией о гибридных технологиях и экспериментах, которые у нас проводятся. Не все клиенты знают об этих экспериментах, но они есть. Поясню, как клиенты делают выбор, почему мы предлагаем им эти подходы, и расскажу об итерационном подходе.
Статья строится на двух основных кейсах, которые взяты в качестве примера. Это длительное поэтапное/попроцессное внедрение и скоростное внедрение. Названия компаний не привожу из-за NDA. Оба кейса интересные и показывают максимальный подход с точки зрения итерационного метода.
Также я остановлюсь на перспективах, которые открываются после внедрения, и на том, что видит заказчик со своей точки зрения.
Два кейса
Мы работаем по водопадной (waterfall) технологии – технологии стандартного корпоративного внедрения. Она адаптировалась со временем, отшлифовалась на наших проектах, и мы сталкиваемся, в зависимости от проблематики клиента, с необходимостью использовать гибридный подход.
В первом из озвученных примеров это был запуск с января при условии, что договор подписывается в конце декабря. Клиенту что-то нужно срочно и быстро, у них жесткие дедлайны, им требуется показать результат зарубежным партнерам, и к концу января мы уже выдаем работающий фрагмент системы.
Второй пример – запуск, максимально растянутый во времени, с бережным попроцессным переходом. Клиент не готов выделять сотрудников и тратить дополнительную трудоемкость: требуется минимально задействовать сотрудников клиента и внедрять постепенно.
Информирование клиента и важность коммуникаций
Знают ли они об эксперименте? Скорее всего, нет, однако мы изначально погружаем их в процесс, чтобы они понимали, что с ними происходит, почему выбрана именно эта технология. Особенно, если они знают различия подходов, имеют собственную проблематику, сталкивались с предыдущими внедрениями, проблемами и ошибками, или если мы заходим после другого подрядчика (такое бывает).
Основные трудности возникают в коммуникациях, и мы сразу объясняем, что их необходимо выстроить заранее. Если этого нет, о гибкости речи не идет.
Далее – фиксация. Мы фиксируем на старте, что мы должны получить по каждому этапу, сроку и дедлайну, иначе все расползается.
И еще – результативность. Ее трудно измерить. Понятно, что система должна работать и заказчик будет доволен, но важно видеть ощутимые результаты и метрики. Мы также стараемся фиксировать их вместе с клиентом.
В первом из приведенных примеров было так: в январе старт, система уже должна работать, ее нужно показать, она должна функционировать.
Мы дорабатываем ее и доводим в соответствии с Agile-методологией, однако важно синхронизироваться с клиентом, чтобы он не ожидал, что к концу января будет готово все. Мы с этим столкнулись и заранее проговаривали с ним, что входит в текущий этап и что будет дальше.
У другого клиента подход был противоположным: сроки его не интересовали, ему был важен физически готовый результат. Мы ориентировались на это. Внедренный бизнес-процесс работает определенным образом, все фиксируется, и мы привязываемся именно к этому результату.
По методологии мы циклично что-то доделываем, дозапускаем и одновременно сопровождаем предыдущие результаты. Так работают не только с функционалом, крупными доработками, но и с документацией, которая на проекте часто страдает. Например, один из этапов был выделен под большое написание ТЗ и сложный обмен. Это и стало итоговым результатом этапа. Было 10 или 12 версий, много подводных камней, НСИ, синхронизаций, мейпингов – мы фиксировались на этом и двигались дальше.
Основные принципы гибридного подхода
Здесь все тоже достаточно очевидно и понятно. Мы выделяем основное и синхронизируем с этим клиента. Это люди и общение, работающий продукт в срок, сотрудничество с заказчиком и готовность к изменениям.
Чтобы соответствовать ожиданиям, и заказчик, и мы должны понимать, к чему идем. Если коммуникации проваливаются, если нет скорости согласования, которая необходима, если нет людей, готовых выделять время и погружаться в проект со стороны заказчика, будет отставание.
Эта картинка работает всегда, когда мы движемся по такой технологии. Как уже сказал, так можно запускать не только функционал, но и почти все остальное. И смайлики действительно будут.
Особенности подхода и работа с командой
Особенности подхода тоже очевидны с точки зрения того, как мы идем и что получаем. Заказчик видит быстрые изменения и свободу принятия решений. Мы понимаем, что у нас быстрая реакция, но сталкиваемся с вопросом профита для сотрудников. Мы стараемся сохранять их на всем протяжении проекта, не переводить на другие направления, не смещать, работать с выгоранием. Мы понимаем, что важно мотивировать их, в том числе материально, вдохновлять, чтобы они продолжали заниматься проектом и сохраняли воодушевление.
С этим сталкивались, с этим боролись, иногда спотыкались, но по обоим примерам команду удалось удержать, она не расползлась. При этом со стороны заказчика видели обратные эффекты: у них менялся руководитель проекта, иногда дважды. Это было тяжело, но мы справились за счет того, что наша команда стояла до конца как единое целое.
Преимущества гибридного подхода для клиента
Преимущества, которые сразу подчеркиваем для клиента и выделяем как рекомендованные:
-
Говорим, что подход идеально подходит для больших и сложных проектов.
-
Очень гибкий и можно легко вносить изменения.
-
Более быстрая сдача проекта. Можно сдавать по частям, можно сдавать целиком.
-
Поскольку все фиксируется и есть итерации, повышается удовлетворенность клиентов.
-
Улучшение качества продукта.
-
Большая прозрачность и общение между членами команды.
-
Расширение сотрудничества между членами команды.
-
Снижение рисков. Когда у клиента меняется руководитель проекта, все в курсе заранее, и мы не получаем ситуацию, когда проект уходит на паузу или затухает. Смена стейкхолдера или руководителя проекта учитывается, и мы продолжаем работать с рисками.
-
Больше контроля над проектом, причем не только с нашей стороны, но и со стороны заказчика. Он видит прозрачность и понимает, что есть десять этапов, которые нужно пройти. Они зафиксированы, укладываются в девять месяцев. Сроки могут немного сдвигаться, но в пределах контролируемых рамок, за дедлайн мы не выйдем.
-
Принятие решений становится более быстрым, эффективным и качественным. Если что-то идет не так, это видно сразу, мы обсуждаем это с заказчиком, определяем, что требуется сделать, он принимает решение, и мы движемся дальше.
Недостатки и вызовы гибридного подхода
Дисциплина – то, с чем столкнулись. Старались держать ее на уровне, но это специфический момент: когда каждую неделю нужно сдавать функционал в тестовом режиме, это сложно. Важно подготовить не только свою часть, но и учесть работу разработчиков, обеспечить корректное взаимодействие коллег по функциональному блоку. Если кто-то подвел, а срок очень короткий, и на тестовой эксплуатации кнопка не работает, то говорим: «Да, не работает. Так бывает».
В связи с этим члены команды могут чувствовать себя подавленными. Мы максимально отрабатываем это и мотивируем их.
Для небольших проектов с четко определенными требованиями подход не подходит, потому что будет провал. Если нам не за что зафиксироваться, если нет четких сроков и дедлайнов, мы предложим другое решение.
Документация может быть очень длинной. Клиенту важно оставлять артефакты, иначе при выходе проектная документация отсутствует, и техническая служба не понимает, как поддерживать систему. Что-то нужно оставлять, но поскольку такая трудоемкость, как по «водопаду», не заложена, то оставить концепцию, все технические решения, ТЗ на уровне архитектуры и системных данных не получается.
Перспективы сотрудничества и сопровождение
Наконец, возможности и перспективы сотрудничества. Мы видим и сразу говорим клиенту со старта, что будем развивать систему в разных направлениях. Он приходит к нам с развитием своего, допустим, производственного блока. Мы говорим: «Сейчас идем здесь», но пользователи хотят больше, аппетиты растут. Мы понимаем, что можем предложить, и будем предлагать. Чьими силами – вопрос отдельный, но система будет развиваться, потому что нет общего плана и нет границ.
Большой и серьезный плюс – сопровождение системы силами внедрения. Часть заказчиков понимает, что когда проект выйдет на сопровождение, у них не останется никого из тех, кто был с ними на протяжении работы. Да, есть гарантия, есть отдел сопровождения, но это другие люди, другие случаи, другие инциденты. Здесь, поскольку проект идет, тот функционал, который запущен, поддерживает предыдущая команда, она не меняется, и клиент получает максимальный профит.
И вопрос формата сотрудничества – это вопрос бюджета. Не все готовы работать под ключ, не все готовы обозначать проект сразу на десять месяцев вперед. Поэтому мы предлагаем тайм-материал или аналогичный формат, разбиваем работу и делим ее на небольшие части.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.
