Опасность аутсорса

Опасность аутсорса

<p style="text-align: justify;">Аутсорсинг – модное и действительно эффективное направление построения бизнес-процессов с привлечением внешних ресурсов.</p> <p style="text-align: justify;">К сожалению, проработав длительное время на стороне Заказчика нам довелось неоднократно столкнуться и с негативными последствиями подобного делегирования полномочий. О некоторых из таких рисков мы и хотели бы поговорить в рамках этой статьи.</p> <p> </p> <h2><font color="#790000">Растягивание цепочки коммуникаций.</font></h2> <p style="text-align: justify;">Рассмотрим упрощённую схему решения организационно-технических вопросов, возникающих в процессе разработки (пропал доступ к серверу, некорректно настроена работа php, недостаточно прав доступа или иная проблема).</p> <p> </p> <p><b>Действующие лица:</b></p> <ul type="disc"> <li style="text-align: justify;">IT-PRO на стороне заказчика (человек, ответственный за непосредственное решение технических задач, системный администратор, администрор сайта или баз данных, …) – часто не имеет непосредственного интереса в реализации проекта.</li> <li style="text-align: justify;">Куратор проекта на стороне заказчика (человек, уполномоченный общаться с исполнителем по проекту) – заинтересован в реализации проекта, однако редко является техническим специалистом. Иногда так же является лицом, принимающим решения (в небольших компаниях может быть владельцем или директором)</li> <li style="text-align: justify;">Менеджер по работе с заказчиком и менеджер по работе с подрядчиком (может быть 1 лицо, может быть 2 в зависимости от бизнес-процессов генподрядчика)</li> <li style="text-align: justify;">Менеджер проекта исполнителя (тимлид, ведущий разработчик или иное лицо, которое принимает решение о соответствии задачи договорённостям, переформулирует их и переводит с «птичьего» языка программистов на «крокодилий» менеджерский)</li> <li style="text-align: justify;">IT-PRO исполнителя (программист, верстальщик, дизайнер, контент-менеджер, администратор, …) – непосредственно выполняющий уже поставленные задачи человек.</li> </ul> <p> </p> <p style="text-align: justify;">В реальных ситуациях участников может быть как больше, так и меньше (в зависимости от обстоятельств и бизнес-процессов конкретных организаций).</p> <p style="text-align: justify;">Например, у исполнителя может быть цепочка Менеджер – ведущий программист – программист-стажёр. А у генерального подрядчика информация между менеджерами может передаваться только после прохождения бизнес-процесса с участием собственного IT-PRO или архитектора. В исключительных случаях IT-PRO заказчика выполняет функции куратора проекта.</p> <p> </p> <p style="text-align: justify;">Учитывая, что информация от одного участника процесса передаётся обычно не мгновенно (её необходимо проанализировать, принять решение, да и просто увидеть пришедшее письмо удаётся не всегда сразу из-за массы ежедневных дел), выделим на её передачу в рамках нашей упрощённой схемы 1 час.</p> <p> </p> <p style="text-align: justify;">Так же предположим, что для реализации проекта крупного Московского заказчика, крупный Московский же генеральный подрядчик нанимает исполнителя из региона (например, из Новосибирска) в рамках аутсорса.</p> <p style="text-align: center;"><img src="/upload/medialibrary/642/64211a94f4a3d6cec8982d62cbd0344b.png" title="растянутая цепочка коммуникаций при использовании аутсорс ресурсов в разработке сайта" hspace="5" vspace="5" border="0" alt="растянутая цепочка коммуникаций при использовании аутсорс ресурсов в разработке сайта" width="600" height="500" /></p> <p> </p> <p><b>Сценарий критической ситуации:</b></p> <p> </p> <p style="text-align: justify;"><u>6.00 Москва (9.00 Новосибирск)</u> – начало работы Аутсорсера. IT-PRO обнаруживает проблему (не авторизованные пользователи не видят разработанный функционал, в коде проверок на авторизацию нет). Запрашивает менеджера проекта.</p> <p style="text-align: justify;"><u>7.00 Москва (10.00 Новосибирск)</u> – Менеджер проекта Аутсорсера запрашивает генерального подрядчика.</p> <p style="text-align: justify;"><u>9.00 Москва (12.00 Новосибирск)</u> – Начало работы Генерального подрядчика и Заказчика. Менеджер генподрядчика получает запрос от аутсорсера, но ещё не успевает его обработать (регламент на обработку 1 час)</p> <p style="text-align: justify;"><u>10.00 Москва (13.00 Новосибирск)</u> – Менеджер генподрядчика запрашивает куратора проекта Заказчика</p> <p style="text-align: justify;"><u>11.00 Москва (14.00 Новосибирск)</u> – Куратор проекта запрашивает IT-PRO (заказчика)</p> <p style="text-align: justify;"><u>12.00 Москва (15.00 Новосибирск)</u> – IT-PRO заказчика получает информацию о проблеме, приступает к решению.</p> <p style="text-align: justify;"><u>12.15 Москва (15.15 Новосибирск)</u> – IT-PRO заказчика решает проблему (не настроены права доступа для группы «все пользователи, в том числе неавторизованные» к вновь созданной директории с разрабатываемым функционалом). Отправляет отчёт куратору проекта.</p> <p style="text-align: justify;"><u>13.15 Москва (16.15 Новосибирск)</u> – Куратор проекта заказчика отправляет отчёт о решении проблемы менеджеру генподрядчика</p> <p style="text-align: justify;"><u>14.15 Москва (17.15 Новосибирск)</u> – менеджер подрядчика отправляет отчёт о решении проблемы менеджеру проекта Аутсорсера</p> <p style="text-align: justify;"><u>15.00 Москва (18.00 Новосибирск)</u> – конец рабочего дня аутсорсера. Менеджер проекта Аутсорсера <b>не успевает</b> обработать и передать информацию об отчёте о решении проблемы IT-PRO! IT-PRO Аутсорсера целый день не мог приступить к дальнейшей разработке функционала из-за проблемы с доступом о которой написал в начале своего рабочего дня!</p> <p style="text-align: justify;">Только в начале следующего рабочего дня работа будет возобновлена.</p> <p> </p> <p style="text-align: justify;">Факторы, не рассмотренные в сценарии, но которые могли затянуть возобновление разработки ещё больше:</p> <ul type="disc"> <li style="text-align: justify;">Генеральный подрядчик в Москве мог начать работать не в 9.00, а в 10.00 (увеличение лага ещё на 1 час)</li> <li style="text-align: justify;">Информация о проблеме или отчёт о её решении мог прийти к любому частнику процесса в момент начала обеда сотрудника (увеличение лага в зависимости от числа таких счастливых «совпадений» может составлять до 3-4 часов)</li> <li style="text-align: justify;">Цепочка коммуникаций может быть длиннее в зависимости от бизнес-процессов участников</li> </ul> <p> </p> <p style="text-align: justify;"><b>Таким образом, мы получаем более суток простоя в разработке проекта из-за крошечной проблемы, которую IT-PRO заказчика и Аутсорсера теоретически могли решить совместными усилиями за час</b> (даже с учётом задержки в передаче информации), если бы имели прямой канал доступа друг к другу.</p> <p> </p> <p style="text-align: justify;">К сожалению, данный сценарий не является сугубо умозрительным. В пору работы в одной мебельной компании мы стали его участником (IT-PRO заказчика). Для нас задержка даже в 1 день была очень критична, поскольку к запуску сайта уже была жёстко привязана рекламная сетка по телевидению (оплаченная и согласованная), отложить которую нельзя было никак и подобная задержка вылилась бы как в упущенные прибыли, так и в репутационные потери (в рекламе фигурировал сайт, так что зайдя на недоработанный ресурс потенциальные клиенты могли сформировать крайне негативное мнение о компании).</p> <p> </p> <p> </p> <h2><font color="#790000">Недостаточный контроль непосредственного исполнителя</font></h2> <p> </p> <p style="text-align: justify;">К сожалению, генеральный подрядчик редко бывает столь же заинтересован в конечном результате, как заказчик. Поэтому подчас контроль аутсорсерва снижается и реализуются даже относительно маловероятные риски, а узнают о них участники процесса в последний момент.</p> <p> </p> <p style="text-align: justify;">Однажды к нам пришёл на разработку срочный проект на довольно редкой платформе (Bitrix .NET Forge CMS), который надо было сделать «за 2 дня».</p> <p style="text-align: justify;">При этом мы наблюдали цепочку:</p> <p style="text-align: justify;">Заказчик – генеральный подрядчик – субподрядчик (аутсорсер) – программист фрилансер (поскольку платформа была редкая и хороших специалистов для работы с ней не хватало аутсорсер так же не смог выделить своего человека, а прибег к услугам фрилансера, который неожиданно «испарился»).</p> <p style="text-align: justify;">Знал ли генеральный подрядчик о кризисе или нет, нам не известно. Однако субподрядчик до последнего пытался кризиса избежать, в том числе обратился к нам, для того, чтобы сдать этап в срок.</p> <p style="text-align: justify;">К сожалению, попытка оказалась неудачной.</p> <p style="text-align: justify;">Это был проект для очень крупного международного бренда.</p> <p> </p> <p style="text-align: justify;">Второй пример относится к заказчику из нашего первого кейса про растягивание цепочки коммуникаций. Во время написания Технического Задания на проект мы заложили определённые требования по соблюдению архитектуры проекта. В тот момент нам казалось это само собой разумеющимся и поэтому формулировки были достаточно общими.</p> <p style="text-align: justify;">Удивлению нашему не было предела, когда в середине проекта мы выяснили, что указанные нами требования не то чтобы не соблюдаются… Исполнитель вообще не стал использовать возможности платформы. Сайт так можно было написать и на любом другом движке или без движка вообще.</p> <p style="text-align: justify;">Мы рады что не вняли убеждениям генерального подрядчика «не смотрите пока сайт, там всё ещё сыро, подождите сдачи проекта» и провели инспекцию кода самостоятельно ещё в середине проекта – переделывать пришлось гораздо меньше!</p> <p> </p> <p> </p> <h2>Что посоветовать?</h2> <p><b>Не пускайте проект на самотёк!</b></p> <p> </p> <ol> <li style="text-align: justify;">Не растягивайте цепочку коммуникаций. Дайте возможность IT-PRO по возможности решать проблемы и задачи совместно в обход регламентов и менеджеров, уведомляя руководство. Лучше прервать решение незапланированной задачи в середине и потерять 2 часа, чем получить 2 дня простоя.</li> <li style="text-align: justify;">Не доверяйте генеральному подрядчику. Не доверяйте субподрядчику. Не доверяйте своим IT-PRO. Даже себе не доверяйте. Все эти люди будут уверять вас, что всё идёт «почти по плану», хотя на самом деле катастрофа уже может быть неизбежна.</li> <li style="text-align: justify;">Периодически проводите проверку состояния проекта. Если проект очень большой и сложный возможно имеет смысл создать для этого собственную команду или привлечь независимых экспертов.</li> </ol> <p></p> <p> </p> <p> </p> <p> </p> <p style="text-align: justify;"><b>И последнее.</b> Обязательно уточните у генерального подрядчика будет ли привлечён аутсорс, выясните кто это будет. Пропишите в договоре соответствующие правила использования аутсорс-ресрусов.</p> <p style="text-align: justify;">Аутсорс – действительно очень эффективная стратегия. Мы не хотим к ней прибегать, чтобы сократить цепочку коммуникаций до минимально возможной, но для больших проектов иногда только аутсорс может стать единственно эффективным решением.</p> <p style="text-align: justify;">Не считайте, что вы сможете контролировать аутсорсеров сами – веб студии, практикующие этот подход наступили на множество грабель о которых они вряд ли расскажут вам вот так сходу.</p>