cover

Мы с коллегами из Itransition подготовили серию статей о том, что происходит перед началом любого IT-проекта и как себя вести, если вы — клиент. Эти советы подойдут при работе с любым IT-вендором:

  1. Предпродажа
  2. Анализ
  3. Старт проекта

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

Большую часть работы на этом этапе вендор должен сделать сам: передать проект в производство, подобрать команду, проверить оценки аналитиков, спланировать работы и познакомить вас с командой. Вам же следует проконтролировать, что проект пошел в нужном направлении. Чтобы вы ничего не упустили, я расскажу, что зависит от вас и как проверить работу вендора на данном этапе.

Познакомьтесь с командой

Первым делом нужно встретиться с теми, кто будет реализовывать ваши планы. Хорошая команда — это та, которая может сделать именно такой самолет, как нужно вам. Пассажирский, военный и орбитальный самолёт — это совершенно разные проекты.

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

На ознакомительной встрече менеджер проекта представит костяк команды и объяснит всем участникам проекта, кто чем будет заниматься в проекте и кто за что будет отвечать. А вы, в свою очередь, задайте вопросы относительно опыта и целей участников команды.

Плохо Хорошо
Сколько у тебя лет опыта в строительстве самолетов? Какие три самых главных урока ты вынес из твоих предыдущих «самолетных» проектов?
Сколько процентов заклепок в конструкции самолета имеют потайные закладные головки? Какой опыт ты хочешь получить на проекте по созданию этого самолета?

Расскажите команде про ваш проект

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

Если специалисты на проекте не самолёт строят, а ставят 800 000 заклепок — такой проект далеко не улетит. Чем больше у команды контекста, чем лучше участники проекта представляют и понимают, для кого они работают. А чем лучше команда понимает портрет конечного пользователя и его ожидания, тем эффективней команда будет с самого начала.

Поэтому расскажите команде о ваших целях и видении проекта, чего хотите этим проектом добиться, что это даст бизнесу и как поможет конечным пользователем. Зажигайте, вдохновляйте, но оставайтесь честными — на данном этапе от вас зависит насколько хорошо стартанет ракета и насколько успешным будет ее полет. Посмотрите на Илона Маска, я уверен, что с его проектом под кодовым названием «BFR» все будет отлично

spacex presentation

Элон Маск о проекте BFR и не только

Обсудите с командой рискованные гипотезы

На проекте могут быть такие задачи, которые никто никогда не делал, а значит не может гарантировать, что оценка адекватная. Эксперт с фазы анализа предположил, что так можно будет сделать, но как выйдет на самом деле — неизвестно.

Если проект по каким-то причинам заранее нереализуем или убыточен в рамках выделенного бюджета, то менеджер должен остановить его как можно раньше, чтобы вы не тратили деньги впустую. Поэтому перед началом проекта команда берёт из списка предположений самые рискованные гипотезы и изучает их дополнительно. И здесь нужна ваша помощь.

Отвлечемся от самолетов. Положим, вам нужны отчеты из вашей внутренней ERP-системы. Эта задача состоит из двух: собрать данные и построить графики. Все знают, как делать системы, которые строят графики, и сколько это занимает времени. А вот сбор данных из вашей внутренней системы — неизвестная территория. Возможно, удастся настроить импорт в нужном формате за столько-то часов, а может и нет.

Этот вопрос нужно исследовать как можно раньше не просто обсудить, а «потрогать» вашу систему или настроить выгрузку одного поля. Если риск выстрелит и гипотеза окажется нереализуемой – выбросить в мусорку как можно меньше  ресурсов. Если оставить рискованные гипотезы на конец проекта, то провал на них будет слишком дорого стоить.

После детального разбора рискованных гипотез вместе с командой проведите reality check. Для этого есть разные техники. Одна из самых быстрых – голосование «от одного до пяти» (Fist of Five). Попросите команду показать на пальцах от одного до пяти насколько они уверены, что при этих сроках, бюджете и условиях проект будет реализован. Если все дают в среднем четыре из пяти, то всё хорошо, проект можно стартовать. А если вы с аналитиком напридумывали кучу гипотез, а программисты показывают два или один — надо вернуться на шаг назад прежде, чем начинать проект. Люди, которые реально будут делать проект, должны быть уверены, что у них всё получится.

Договоритесь о процессах коммуникации

Коммуникации на проекте — это любой обмен информацией между любыми участниками проекта. К коммуникациям относятся встречи, созвоны, письма и т.д. Участникам команды постоянно приходится принимать множество решений, которые затрагивают не только их работу, но влияют на проект в целом. Договорившись на старте проекта к кому и по каким вопросам бежать, в какой форме лучше спрашивать и какими каналами коммуникации пользоваться, вы сэкономите и время, и усилия, а также снизите риски взаимонепонимания.

Scheme 1

Пример коммуникационных потоков в рамках проектной команды

Пример коммуникационного плана:

Тип встречи Цель
Еженедельные встречи по статусу проекта Синхронизация по прогрессу проекта
Демо промежуточных версий разрабатываемого продукта Сбор обратной связи по продукту от стейкхолдеров для последующего анализа
Ежемесячные встречи со стейкхолдерами Обсуждения статуса и возможных вариантов дальнейшего развития продукта

Финализируйте календарный план

В зависимости от требований и модели сотрудничества планы на проектах всегда выходят разные: где-то краткое описание, где-то подробная диаграмма Гантта.

Scheme 2

Пример высокоуровневого календарного плана проекта

Главное требование к любому календарному плану — из него вы должны четко видеть основные майлстоуны проекта и измеримые показатели успешности проекта на каждом из них — что к этому майлстоуну будет готово и в каком виде.

Можно, конечно, и так: к майлстоуну 1 мы получим 18 страниц в формате psd, напишем 5 000 строк кода, сделаем 25 коммитов и выпьем 48  банок энергетика.

Конкретно? Да. Измеримо? Да. Помогает понять, как проект движется к успеху? Нет.  Вспоминается один из уроков истории. Когда бриты колонизировали Индию они очень страдали от укусов змей. Чтобы с этим справиться, они ввели KPI — головы убитых кобр, за которые платили деньги. Что начали делать местные? Они начали разводить кобр.

Система адаптируется под метрики, которые мы в неё вводим. Поэтому с KPI стоит быть осторожнее. Единственная метрика — хороший продукт. Поэтому нужно ориентироваться на него, а не только на косвенные показатели. Для измеримого «майлстоунирования» проекта, мы частенько используем «пресс-релизы из определенного будущего» (looking-backward press releases) — к такому-то числу мы зарелизили первый прототип системы, позволяющий делать то-то и то-то.

Возвращаемся к самолетам. К майлстоуну 1  будут готовы все необходимые алюминиевые заготовки и двигатели. К майлстоуну 2 крылья и флюзеляж. Доставлена и протестирована авионика. К майлстоуну 3 крылья прикреплены к флюзеляжу, авионика и двигатели установлены в самолет. 

Планирование должно быть максимально наглядным, а изменения – очевидными для всех участников процесса. Менеджер вашего проекта наверняка будет использовать какой-то современный онлайн-инструмент, для того чтобы держать прогнозы актуальными. Не поленитесь изучить этот инструмент вместе с менеджером и почаще поглядывать на общую картину сражения, будь то Jira, Feature Map, TargetProcess, GanttPRO или что-либо ещё.

Что будет дальше

А дальше надо работать, руководствуясь достигнутыми договоренностями в зависимости от выбранного вами процесса.

При гибкой организации проекта придется постоянно «щупать» продукт, общаться с вендором, планировать итерации  — фактически жить с командой. От вас может, например, понадобиться полная вовлеченность пяти сотрудников вашей компании:  владельца продукта и бизнес-экспертов, чтобы на первой же итерации проверить рисковые гипотезы.

При каскадной —  жить с командой не придется Но может оказаться, что вам нужно два месяца ждать, прежде чем наступит какой-то майлстоун и вы сможете увидеть результаты. Вам придется сделать шаг в темноту — проект стартанули и наступил информационный вакуум. Это не значит, что вендор ничего не делает – наоборот, идет очень много работ невидимых для вас: настройки среды, выбор фреймворков, разработка архитектуры.  Нужно запастись терпением и не мешать вендору работать. И отслеживать здоровье проекта по метрикам, помня про «эффект кобры».

Какой бы подход к реализации проекта вы ни выбрали, не забывайте, ради чего вы все это затеяли,  будьте в курсе происходящего и оставайтесь на связи. Удачи!