multi-vendor projects

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

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

Из-за NDA рассказывать подробно о реальных проектах я не могу, поэтому опишу собирательный образ мультивендорного проекта. Я представил проект, на котором допустили все ошибки в управлении, с которыми мы сталкивались на практике. Вот их список и советы, как делать правильно. Не наступайте на наши грабли.

Беспорядок внутри

Что случилось: Представьте себе стартап с неплохой идеей нового IoT-девайса. CMO нашел рыночную нишу. CEO идею благословил, но сказал: «вы как-нибудь сами-сами, а мне докладывайте». CFO прикинул объемы необходимых инвестиций, ужаснулся и сказал: «только через мой труп». VP of Delivery промолчал, но затаил обиду. В общем, каждый думал о своем, и никто не брал на себя ответственность за конечные решения и указания дизайнерам, разработчикам и тестировщикам. А проект стоял на месте.

Что делать: сразу разобраться, кто и как вовлечен в проект, как принимаются и кем согласуются решения по проекту. Выбрать ответственного за проект, который, в идеале, будет единой точкой входа/выхода из компании всех проектных активностей. Того, кто знает продукт изнутри и у кого есть время на бесконечные встречи и составление ТЗ.

Спорить о мелочах можно вечно, но всем будет лучше, если VP of Engineering вызовется добровольцем и возьмёт на себя ответственность за все проектные решения. «Ребята, — скажет он, — я знаю, что вы профи и с удовольствием вас всех выслушаю. Но выбирать идеи к реализации и нести ответственность за результат буду я. Давайте раз в две недели встречаться — я буду рассказывать вам о ходе проекта, собирать ваш фидбек, фильтровать его и вваливать в подрядчиков. В понедельник всем удобно?». И проект сдвинется с мёртвой точки.

Нет плана

Что было дальше: прототип девайса заказали на фабрике в Китае, UX и фронт — в Беларуси, бэкенд — в Штатах, тестирование — в Канаде. Бэкенд начали делать сразу после того, как заказали прототип, а вот с выбором фронтендщиков и тестировщиков провозились. В итоге бэк и девайс уже вроде как готовы, а фронтендщики об этом ни сном ни духом. Да и тестировщики доставали вопросами «ну чё, когда тестировать-то будем». Вендоры сидели без работы, а менеджеры не понимали статус проекта.

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

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

Классическая диаграмма Гантта

Для 4 функций понадобилось 20 строк

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

Теперь 4 функции — 4 строки

Теперь 4 функции — 4 строки

Работа молча

Что случилось потом: Чтобы интерфейс «ожил», API должен передавать данные из базы на фронтенд. Бэкендщики сорвали сроки — проект остался без API и баз данных. API не передает – интерфейс не «оживает». Фронтендщики и тестировщики простаивали, а менеджеры узнали о проблеме слишком поздно.

Что делать: настроить программы для планирования задач и хранения документов. Подойдет любая удобная связка программ — мы обычно используем Jira и Confluence.

Чтобы контролировать, всё ли идёт по плану, нужно регулярно созваниваться с вендорами в скайпе. Пусть тот ответственный VP of Engineering перед каждым звонком составляет агенду и следит за тем, чтобы время проведения устраивало всех участников. Да, придется попотеть, выбирая время, удобное и для Китая, и для Канады. Зато вендорам не нужно будет придумывать, как и когда сообщить, что они не успевают. VP of Engineering будет сам их регулярно спрашивать.

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

План впритык

Что случилось потом: Бэкендщики запустили API и подняли базы — нужно всё протестировать. В этот момент выяснилось, что тестировщики из Канады не работают с иностранными юрлицами, а сам договор не устраивает юристов. Проект встал, пока юристы обменивались письмами и точили формулировки.

Что делать: заложить запас времени на риски. На проекте обязательно что-то пойдёт не так: кто-то сорвет сроки, юристы не договорятся, деньги не переведут, дизайнер уйдёт в отпуск.

План «съехал» на два с половиной месяца

План «съехал» на два с половиной месяца

Чтобы выпустить продукт в срок, время на риски надо добавить еще до начала работ. С тестировщиками нужно было встретиться, когда бекенд не был до конца готов. Всё обсудить без юристов, чтобы им осталось выбрать формулировки и оформить документы. Менеджеры успели бы всё проверить и исправить, тестировщики начали бы работу, а продукт вышел бы вовремя.

Всё пойдёт по плану, если подписать договор заранее

Всё пойдёт по плану, если подписать договор заранее

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

Нет технической документации

Что было дальше: когда половина бэкенда была готова, выяснилось, что девайс-то хорош, но почему-то данные в бэкенд шлет по FTP, а не по TCP, как договаривались. Половина бэкенда уже написана под TCP, поддержка FTP никак не вписывается. Нужно всё переделывать — проект встал.

Что делать: записывать всё, о чем договорились вендоры на звонках. Идеально, когда все сидят в одной комнате и перед тем, как что-то внедрять, можно посоветоваться с коллегами. Но мир не идеален — когда вендоры договорятся по каким-то техническим вопросам, сразу запишите это.

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

Шпаргалка

  • Решите, кто будет принимать решения и общаться с вендорами
  • Разделите проект на небольшие фазы
  • Регулярно проверяйте, всё ли идёт по плану
  • Заложите в план время на юристов и риски
  • Записывайте все технические подробности, о которых договорятся вендоры