#10. Пример работы клиента с компанией-разработчиком.

В этой статье мы взглянем на процесс кооперации между клиентом и компанией-разработчиком. Цель этой статьи в том, чтобы показать структуру IT компании-разработчика "изнутри".  
То, что я описываю здесь – наиболее часто встречаемые практики, однако у любой компании есть своя специфика, где структура, иерархия, роли и обязанности участников могут сильно отличаться.

Разберемся с терминологией. Компания, которая занимается разработкой ПО под заказ, называется Аутсорсинговой компанией (IT Outsourcing company). Основной (и обычно, единственный) сервис таких компаний – это аутсорсинг.  
Аутсорсингом называется процесс, когда некая компания, у которой появляется необходимость в разработке какого-то ПО, находит Аутсорсинговую компанию и делегирует это дело ей.

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

Первым шагом Фин. компания изучит рынок и готовые продукты. Очевидно, что они не первые у кого возникли такие желания. Предположим, им не удалось найти удобного готового решения, и они решили разработать собственное приложение.

Их следющий шаг - составить документ с описанием того, какие опции (features) они хотят видеть в своем приложении. В рунете этот документ называют "ТЗ". На зарубежных рынках этот документ называется RFP (Request For Proposal, Запрос Предложения). Часто, к составлению этого документа компании привлекают технических специалистов, которые могут отличить возможные вещи от невозможных, и все это грамотно описать в ТЗ.

Как только документ готов, его рассылают разным аутсорсинговым компаниям. Иногда клиент заодно указывает бюджет и сроки. Чаще, клиент ждет эти данные от компании-исполнителя.

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

Крайне редко бывает так, чтобы аутсорсинговая компания отправила цену и сроки проекта без уточняющих вопросов. Посудите сами: если даже в одной маленькой User Story грамотный специалист может допустить ошибку, то очевидно, что в документе состоящем из десятков (а то и сотен) страниц будет немало ошибок и неточностей.

Итак, аутсорсинговая компания собрала все вопросы и направила их Клиенту. Клиент на все вопросы ответил. Аутсорсинговая компания провела конечную оценку, и отправила свое предложение (Financial proposal) Клиенту.

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

Дальше компания отправляет своего Бизнес Аналитика чтобы вникнуть в бизнес нашего клиента еще больше и так далее. Мы об этом уже говорили в статье "Что такое проект?"

 

Справа у нас расположены сотрудники компании "PlumbusSoft LLC", занимающейся аутсорсом (Исполнитель).  
Так, у нас есть CEO (Исполнительный директор). Ему подотчетен проект менеджер, который находится в постоянном контакте с Тимлидом и (опционально) Бизнес Аналитиком/Владельцем Продукта.

Тимлид координирует проектную команду, состающую из разработчиков, дизайнера и тестировщиков.

С левой стороны, на картинке мы видим Владельца Продукта (Product Owner, PO), который является сотрудником компании клиента.  
Его ключевая обязанность, - это координация деятельности команды работающей над проектом и помощь в постоянно возникающих вопросах.  
Эта координация осуществляется согласно заранее обговоренному протоколу (Звонки по скайпу, чаты, имейлы, совместное написание Историй и так далее).

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

Если в компании нет Product Manager-а, тогда PO должен обладать правом принимать все ключевые решения по продукту.

Найти хорошего PO бывает сложно, если мы говорим о качестве. Иначе, на рынке полно «сертифицированных» PO с кучей разных грамот и наград.

Вернемся к картинке. Практически всегда аутсорсинговая компания работает над более чем одним проектом одновременно. При этом они всегда стараются экономить на ресурсах, что приводит к следующей орг. структуре.

 

Подобные сетапы используются исключительно чтобы сэкономить.  
Тимлиды, как и PM-ы являются дорогим ресурсом. Вдобавок к этому, у PM-а работающего над одним проектом часто может появляться свободное время, которое как-раз таки и использует руководство, назначая его работать сразу на два, три а то и больше проектов. Было время я работал одновременно на пяти проектах, в сумме координируя 35 человек (Это не весело и не хорошо).

По мере того, как компания разрастается, в какой-то момент она нанимает Менеджера Программы (Program Manager, PrM) (либо, чаще, просто повышает одного из своих PM-ов).

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

Более грамотный сетап компании:

 

Здесь, как мы видим, у компании уже три крупных проекта. Представлен также Менеджер Программы, который координирует проект менеджеров.

Приставка «Web Division» здесь не случайна. Множество аутсорсинговых компаний предоставляют свои сервисы сразу в нескольких направлениях. Так, они могут заниматься одновременно разработкой мобильных и веб приложений, блокчейном, видеоиграми и др. В таких случаях компания создает дивизионы, делая логическое разделение в орг. структуре компании по портфелям.

 

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

Последней картинкой мы добавим несколько ролей, которые присутствуют только в крупных компаниях, размеры которых исчисляются сотнями/тысячами сотрудников.

 

Когда у компании огромное кол-во проектов, на сцену выходит Senior Program Manager. Из названия становится очевидно, что он в ответе за братьев своих младших – PrM-ов.

Именно он координирует дивизионы (портфели) компании.  
Непосредственно над ним находятся COO (Chief Operating Officer - Операционный Директор), CEO а также, в некоторых случаях, партнеры компании и другие ключевые stakeholder-ы.

Итог  
Надеюсь, эта статья помогла вам представить как выглядит аутсорсинговая компания изнутри, и как происходит кооперация между ними и Клиентом.

Следующая статья будет посвящена карьерному пути менеджера проектов, развитию его навыков + будет дано несколько советов.