Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах Пользователи Компании Лента заказов Курс по ITSM

Опасность аутсорса в web-разработке

Опасность аутсорса в web-разработке

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

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

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

Рассмотрим упрощённую схему решения организационно-технических вопросов, возникающих в процессе разработки (пропал доступ к серверу, некорректно настроена работа 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 дня».

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

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

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

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

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

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

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

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

 

 

 

оригинал статьи на нашем сайте

Комментарии (8)

  • Аватар

    Ланцев Андрей [Sansey], 25 марта 2013, 13:57

    1
    Всего один вопрос. Нахрена было нанимать веб-аутсорсера в Новосибе??? Москва такой маленький город, что не нашлось среди местных? Я понимаю, что пример вымышленный. Но все-таки...
    • Аватар

      Задойный Алексей [lexnekr], 25 марта 2013, 14:06

      3

      Андрей, я начал статью с того, что сказал о наличии опыта (как позитивного, так и негативного). Описанный выше случай - из моей практики.

      Я был IT-PRO на стороне клиента, а ген подрядчик нанял субподрядчика (аутсорсера) из Новосибирска. Не уведомив об этом клиента. Я выяснил сей факт совершенно случайно в ходе реализации проекта, проведя инспекцию кода (хотя меня убеждали не делать этого под предлогом "там ещё сыро, но к сдаче всё будет"). С удивлением нашёл папку с АПИ сторонней компании. Позвонил в компанию, пообщался и они проговорились.

      А потом получил нагоняй от своего начальства, которому настучали со стороны ген подрядчика и попросили заткнуть мещающего процессу человека.

       

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

      Но опыт показывает, что в Москве хорошего исполнителя для субподряда по низкой цене найти сложно. Поэтому и ищут в Новосибирске. Выигрывают проект на 150-300 тысяч, перепродают за 30-50. У нас есть ещё статьи на эту тему с живыми примерами (только названия конечно мы убрали) - следите за публикациями - постараемся заинтересовать!

      • Аватар

        Ланцев Андрей [Sansey], 25 марта 2013, 14:19

        0

        Низкая цена - залог отменного геморроя, имхо:))

        Не нужно жмотничать и не будет таких проблем. Т.к. дешево и качественно не бывает никогда! Всегда чем-то приходится жертвовать. Это не в ваш огород камень, т.к. не вы выбирали исполнителя. Но суть я думаю вы поняли. Товарищи из Москвы взяли проект "дешево" и им ничего не оставалось делать, как передать его на исполнение в регионы, чтобы втиснуться в эту цену. Это нормально. Глупо, что спалились))) А вот тут зачет вам, как IT Pro... вы свою работу выполнили на ура:))

        • Аватар

          Задойный Алексей [lexnekr], 25 марта 2013, 14:30

          2

          Спасибо, Андрей!

          На самом деле статья была изначально написана для другого ресурса, про грабли на которые наступают клиенты. Правда из-за лобби крупных московских веб студий её там не опубилковали (описанная выше стратегия - "норма" на нашем рынке). Подумав немного мы решили, что над этим стоит задуматсья не только заказчикам, но и исполнителям, поэтому опубликовали здесь.

           

           

          P.S. а вообще мы стараемся делать хорошо всё за что берёмся. Иногда такой перфекционизм не сочетаем с нормой прибыли, однако такова моя жизненная позиция...

  • Аватар

    [Сергей Николаевич], 26 марта 2013, 09:40

    1
    Может быть какие-то рекомендации для аутсорсеров?
    • Аватар

      Задойный Алексей [lexnekr], 26 марта 2013, 10:26

      1

      не попадать в такие переплёты.

       

      Ну что ещё можно порекомендовать кроме "укорачивайте цепочку коммуникаций, контролируйте проект, делайте работу хорошо"? =)

      • Аватар

        [Доктор], 10 апреля 2013, 14:35

        0

        Как не заболеть гриппом? Не болеть вообще.

         

        При этом статья конечно интересная. Только решения не предложено.

        • Аватар

          Задойный Алексей [lexnekr], 11 апреля 2013, 11:57

          0

          Решения в данном случае не может быть предложено. На наш взгляд это типичная ошибка. Зло в чистом незамутнённом виде, если хотите. Надо избегать таких ситуаций любой ценой (ну конечно не совсем уж любой, а ценой меньшего зла).

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