За успешным проектом стоит не только сплоченная команда, но и умение договориться с заказчиком, правильно нащупать его «боль», а также вовремя отследить и обезвредить возможные риски. Рассказываем, как сделать процесс максимально прозрачным, а результат рабочим.

С чего начинается родина проект

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

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

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

  • Техническое задание. После того, как вы определили точку Б, кажется, что теперь дело за малым, — отправить проект в разработку. Однако это далеко не так. Верхнеуровневое бизнес-описание необходимо преобразовать в детальное техническое задание. Техническое задание является необходимым фундаментом для успешного завершения проекта — никто не идет строить дом без проекта на бумаге. Даже если вы попытаетесь построить что-либо по верхнеуровневому описанию вроде «Хочу дом с крышей, четырьмя стенами, газом с водой» на выходе получится нечто несуразное.

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

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

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

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

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

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

  2. Некорректно определена бизнес-цель. Прежде чем приступать к декомпозиции проекта, а уж тем более к описанию технического задания, убедитесь, что заказчик правильно определил задачу или проблему, которую необходимо решить, а также ожидаемые результаты от реализации проекта. Не стоит соглашаться на проект ради проекта, иначе вы потеряете не только время, но и прибыль, а заказчик будет искренне убежден, что проблема в вас.

    Если вам все же пришлось столкнуться с подобным, вынесите на обсуждение свои метрики и цели, основываясь на похожих проектах. Или эскалируйте проблему клиента, чтобы четко увидеть, где «болит» больше всего, а также какие пути ее решения у вас есть (если они есть).

  3. Нечеткое техническое задание. Если ТЗ больше напоминает сочинение «Как я провел лето», будьте уверены, что в ходе реализации будет «плыть» все — от сроков до постоянно появляющихся проблем, которые нужно решать в срочном порядке.

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

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

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

План всему голова

Если вам кажется, что проект слишком большой, и ваша команда вряд ли потянет такой объем, не паникуйте. Выработайте четкий план на старте — пропишите необходимые ресурсы, соберите оценки времени от вовлеченных отделов, декомпозируйте крупные задачи и т. д. Это нужно не только для спокойствия заказчика, но и для своевременной корректировки плана, например, если одна из задач сорвала дедлайн и потянула за собой остальные. Более того, благодаря четко и прозрачно обрисованному процессу в команде появляется ощущение личной ответственности за успех или провал проекта.

Однако опасайтесь перфекционизма. Конечно, хорошо, когда ваш план проработан до мельчайших деталей, но не стоит ставить качество разработки выше сроков. Иначе вы можете оказаться в ситуации, когда команда пытается дожать 5% проработки ценой увеличения сроков в пять раз.