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


25.03.2013

Аутсорсинг – модное и действительно эффективное направление построения бизнес-процессов с привлечением внешних ресурсов.

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

Растягивание цепочки коммуникаций.

Рассмотрим упрощённую схему решения организационно-технических вопросов, возникающих в процессе разработки (пропал доступ к серверу, некорректно настроена работа php, недостаточно прав доступа или иная проблема).

Действующие лица:

  • IT-PRO на стороне заказчика (человек, ответственный за непосредственное решение технических задач, системный администратор, администрор сайта или баз данных, …) – часто не имеет непосредственного интереса в реализации проекта.
  • Куратор проекта на стороне заказчика (человек, уполномоченный общаться с исполнителем по проекту) – заинтересован в реализации проекта, однако редко является техническим специалистом. Иногда так же является лицом, принимающим решения (в небольших компаниях может быть владельцем или директором)
  • Менеджер по работе с заказчиком и менеджер по работе с подрядчиком (может быть 1 лицо, может быть 2 в зависимости от бизнес-процессов генподрядчика)
  • Менеджер проекта исполнителя (тимлид, ведущий разработчик или иное лицо, которое принимает решение о соответствии задачи договорённостям, переформулирует их и переводит с «птичьего» языка программистов на «крокодилий» менеджерский)
  • IT-PRO исполнителя (программист, верстальщик, дизайнер, контент-менеджер, администратор, …) – непосредственно выполняющий уже поставленные задачи человек.

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

Например, у исполнителя может быть цепочка Менеджер – ведущий программист – программист-стажёр. А у генерального подрядчика информация между менеджерами может передаваться только после прохождения бизнес-процесса с участием собственного IT-PRO или архитектора. В исключительных случаях IT-PRO заказчика выполняет функции куратора проекта.

Учитывая, что информация от одного участника процесса передаётся обычно не мгновенно (её необходимо проанализировать, принять решение, да и просто увидеть пришедшее письмо удаётся не всегда сразу из-за массы ежедневных дел), выделим на её передачу в рамках нашей упрощённой схемы 1 час.

Так же предположим, что для реализации проекта крупного Московского заказчика, крупный Московский же генеральный подрядчик нанимает исполнителя из региона (например, из Новосибирска) в рамках аутсорса.

растянутая цепочка коммуникаций при использовании аутсорс ресурсов в разработке сайта

Сценарий критической ситуации:

6.00 Москва (9.00 Новосибирск) – начало работы Аутсорсера. IT-PRO обнаруживает проблему (не авторизованные пользователи не видят разработанный функционал, в коде проверок на авторизацию нет). Запрашивает менеджера проекта.

7.00 Москва (10.00 Новосибирск) – Менеджер проекта Аутсорсера запрашивает генерального подрядчика.

9.00 Москва (12.00 Новосибирск) – Начало работы Генерального подрядчика и Заказчика. Менеджер генподрядчика получает запрос от аутсорсера, но ещё не успевает его обработать (регламент на обработку 1 час)

10.00 Москва (13.00 Новосибирск) – Менеджер генподрядчика запрашивает куратора проекта Заказчика

11.00 Москва (14.00 Новосибирск) – Куратор проекта запрашивает IT-PRO (заказчика)

12.00 Москва (15.00 Новосибирск) – IT-PRO заказчика получает информацию о проблеме, приступает к решению.

12.15 Москва (15.15 Новосибирск) – IT-PRO заказчика решает проблему (не настроены права доступа для группы «все пользователи, в том числе неавторизованные» к вновь созданной директории с разрабатываемым функционалом). Отправляет отчёт куратору проекта.

13.15 Москва (16.15 Новосибирск) – Куратор проекта заказчика отправляет отчёт о решении проблемы менеджеру генподрядчика

14.15 Москва (17.15 Новосибирск) – менеджер подрядчика отправляет отчёт о решении проблемы менеджеру проекта Аутсорсера

15.00 Москва (18.00 Новосибирск) – конец рабочего дня аутсорсера. Менеджер проекта Аутсорсера не успевает обработать и передать информацию об отчёте о решении проблемы IT-PRO! IT-PRO Аутсорсера целый день не мог приступить к дальнейшей разработке функционала из-за проблемы с доступом о которой написал в начале своего рабочего дня!

Только в начале следующего рабочего дня работа будет возобновлена.

Факторы, не рассмотренные в сценарии, но которые могли затянуть возобновление разработки ещё больше:

  • Генеральный подрядчик в Москве мог начать работать не в 9.00, а в 10.00 (увеличение лага ещё на 1 час)
  • Информация о проблеме или отчёт о её решении мог прийти к любому частнику процесса в момент начала обеда сотрудника (увеличение лага в зависимости от числа таких счастливых «совпадений» может составлять до 3-4 часов)
  • Цепочка коммуникаций может быть длиннее в зависимости от бизнес-процессов участников

Таким образом, мы получаем более суток простоя в разработке проекта из-за крошечной проблемы, которую IT-PRO заказчика и Аутсорсера теоретически могли решить совместными усилиями за час (даже с учётом задержки в передаче информации), если бы имели прямой канал доступа друг к другу.

К сожалению, данный сценарий не является сугубо умозрительным. В пору работы в одной мебельной компании мы стали его участником (IT-PRO заказчика). Для нас задержка даже в 1 день была очень критична, поскольку к запуску сайта уже была жёстко привязана рекламная сетка по телевидению (оплаченная и согласованная), отложить которую нельзя было никак и подобная задержка вылилась бы как в упущенные прибыли, так и в репутационные потери (в рекламе фигурировал сайт, так что зайдя на недоработанный ресурс потенциальные клиенты могли сформировать крайне негативное мнение о компании).

Недостаточный контроль непосредственного исполнителя

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

Однажды к нам пришёл на разработку срочный проект на довольно редкой платформе (Bitrix .NET Forge CMS), который надо было сделать «за 2 дня».

При этом мы наблюдали цепочку:

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

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

К сожалению, попытка оказалась неудачной.

Это был проект для очень крупного международного бренда.

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

Удивлению нашему не было предела, когда в середине проекта мы выяснили, что указанные нами требования не то чтобы не соблюдаются… Исполнитель вообще не стал использовать возможности платформы. Сайт так можно было написать и на любом другом движке или без движка вообще.

Мы рады что не вняли убеждениям генерального подрядчика «не смотрите пока сайт, там всё ещё сыро, подождите сдачи проекта» и провели инспекцию кода самостоятельно ещё в середине проекта – переделывать пришлось гораздо меньше!

Что посоветовать?

Не пускайте проект на самотёк!

  1. Не растягивайте цепочку коммуникаций. Дайте возможность IT-PRO по возможности решать проблемы и задачи совместно в обход регламентов и менеджеров, уведомляя руководство. Лучше прервать решение незапланированной задачи в середине и потерять 2 часа, чем получить 2 дня простоя.
  2. Не доверяйте генеральному подрядчику. Не доверяйте субподрядчику. Не доверяйте своим IT-PRO. Даже себе не доверяйте. Все эти люди будут уверять вас, что всё идёт «почти по плану», хотя на самом деле катастрофа уже может быть неизбежна.
  3. Периодически проводите проверку состояния проекта. Если проект очень большой и сложный возможно имеет смысл создать для этого собственную команду или привлечь независимых экспертов.

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

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

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


Сайт https://nowyny.com шашлык поможет готовить.

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

<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>

Возврат к списку

Яндекс.Метрика