Отдавать ли на аутсорсинг или делать самим?

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

    Поводом для написания этой статьи явилось несколько известных мне проектов в моей компании, где решение о передаче на аутсорсинг, как в конце концов выяснилось, было неправильным. Этих ошибок уже нам не избежать, но, возможно, мои рекомендации помогут избежать новых проблем.
    Сразу оговорюсь, что все нижеследующее будет относиться преимущественно к ИТ. Про передачу на аутсорс бухгалтерии, логистики или других неайтишных направлений, я намеренно не упоминаю. Если принципы, на ваш взгляд, будут распространяться на них — пробуйте. Сейчас же пока сосредоточимся на ИТ-решениях.
    ПЕРВОЕ. Принимая решение, отдавать ли на аутсорсинг разработку нового ПО и на каких условиях, я стараюсь оценить влияние разрабатываемого продукта на конкурентные преимущества компании. Очевидно, что в отношении корпоративного веб-сайта такое влияние значительно меньше, чем, скажем, для интернет-магазина, поддерживающего розничные или оптовые продажи. Если же, например, электронная коммерция является основным бизнесом компании, то такой сайт становится поистине «стратегическим ресурсом». Его передавать сторонней компании нельзя.
    Один из показательных примеров — наш интернет-магазин. После сдачи компанией-разработчиком нам сайта интернет-магазина, полноценно поддерживать его могли только сами разработчики, потому что уровень «кривизны» программных решений зашкаливал за все мыслимые и немыслимые рамки. Если предположить, что разработчики имеют свой особый склад ума, позволивший им это создать, то, наверное, они способны это и поддерживать. Нам же пришлось многое переписать заново. В итоге, дополнительных сил было вложено столько, что проще было с самого начала делать все внутри компании.

    ВТОРОЕ. Подрядчику нужно отдавать или мало, или много. Под «мало» я понимаю небольшой проект, качество которого внутренняя команда может оценить на стадии технической приемки, к которому можно неплохо описать требования и хорошо протестировать. Под «много» я понимаю комплексный проект, в который входит полноценное внедрение и обучение техспециалистов, подготовка технической документации, сдача работ «под ключ», передача подрядчику права принимать самостоятельные решения в рамках бюджета и поставленных перед ним высокоуровневых целей. Я хочу отметить, что в этой схеме нет места «средним» проектам. Потому что, на мой взгляд, нельзя их сделать качественно на стороне. Для небольших задач (вариант «мало») можно даже привлекать фрилансеров, но в этом случае необходимо иметь по крайней мере двухкратный запас времени и расширенный резервный бюджет на покрытие связанных с этим рисков.

    ТРЕТЬЕ. Подрядчик должен быть высокоответственнен, надежен и стабилен. А для этого им должна стать компания, соответствующая уровню и масштабу поставленных перед нею задач. Правило про первый блин комом работает здесь как нигде — ни один подрядчик не сможет вникнуть во все особенности вашей инфраструктуры, не «наступив на грабли», не «испробовав» все ручки и рычажки. Именно поэтому плохо менять подрядчиков как перчатки — каждый новый стоит не только денег и времени, но и совместных ошибок.

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

    ЧЕТВЕРТОЕ. По окончании проекта, разработанное решение должно целиком и полностью перейти к заказчику. Техническая поддержка решения должна производиться уже силами компании-заказчика. На мой взгляд, ни при каких условиях, подрядчик не должен оставлять за собой какие-либо «сокровенные знания». Всякого рода гарантийная поддержка после завершения контракта, обязательства исправлять ошибки — от лукавого. Это не работает. Нужно делать всё, чтобы проект сразу вставал на собственную техническую поддержку.

    Как пример из собственного опыта, в Web Media Group при разработке одного из сайтов я настоял на необходимости включить в проектную команду подрядчика специалистов из нашей компании и замкнуть на него ключевые этапы разработки. В результате мы получили сайт вместе со знанием, как он работает «внутри», а подрядчик лучше уловил наши «хотелки» на самом раннем этапе. Обычно такая схема очень непопулярна на рынке веб-разработок, потому что она добавляет рисков разработчику, которых он в других случаях избегает. Но если смотреть с позиции заказчика, для него эта схема работает на ура.

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

    Единственное оправдание в передаче на аутсорсинг — экономия денег и времени. Всегда сопоставляйте ценность этой экономии с рисками, которые сулит такое решение.
    Поделиться публикацией

    Комментарии 30

      0
      Четвертое положение распадается на несколько слабосвязанных моментов.
      1. Включение спецов в проектную команду аутсорсера сказывается и на контроле за исполнением, и, как правильно Вы заметили, на точном следовании ТЗ, а не только на передаче в техподдержку.
      2. Минусом «аренды» продукта, как следует из Вашего примера, стало лишь неверное соотношение качество/стоимость техподдержки/развития, но это риск любого заказчика/разработчика.
        +2
        Я бы посоветовал каждому читателю вернуться к пункту 2 и внимательно перечитать. Можно вслух. Потому что этот принцип должен быть вбит в голову крепко-накрепко.
          0
          >Если же, например, электронная коммерция является основным бизнесом компании, то такой сайт становится >поистине «стратегическим ресурсом». Его передавать сторонней компании нельзя.

          Позвольте не согласится с этим высказыванием.
          На примере нашей компании, я могу сказать, что мы сделали очень серьезные интернет магазин, для крупнейшей компании. И для нашего заказчика, это является «стратегическим ресурсом» для них.

          Как мне кажется, вся суть передачи на аутсорсинг заключена в п. три, а именно «Подрядчик должен быть высокоответственнен, надежен и стабилен.», плюс квалифицирован.
            +1
            ключевые слова здесь «мы сделали магазин для нашего заказчика». Очевидно, что с вашей точки зрения все супер. Я допускаю даже, что клиент счастлив. Но я уверен, что если бы была возможность у клиента пойти параллельно по второму пути, в итоге он был бы успешнее. Разумеется, это не более, чем мое мнение.

            При этом я не исключаю, что на месте клиента бы принял решение обратиться к вам. Например, у меня могли бы быть сомнения, что серьезные вложения денег и времени в интернет-магазин уместны на этом этапе, а создание своей команды — это серьезные вложения, обязательства, время в конце концов требуется на организацию. Но остаюсь при своем мнении, что если хочешь хорошо в долгосрочной перспективе — делай core product своей командой.
              0
              Спорное утверждение. Я предполагаю, что Вы не делаете core product, например ERP систмему, бухгалтерскую систему или любую другую (core system) самостоятельно.
          • НЛО прилетело и опубликовало эту надпись здесь
              +2
              «По одному из наших программно-аппаратных решений по продажам через киоски»

              Вот так у нас и сделали. Написали свой софт с нуля и убили софт конкурентов.
              Все кто работает с софтом оказались очень довольны.
                0
                и оставили всю команду для дальнейшего саппорта и развития софта?
                или разогнали 90% по окончании разработки продукта?
                или это изначально были контракты «на проект»?
                  0
                  Нет. Команда осталась, продукт развивается.
                  Вот сейчас некоторые части продукта отданы на аутсорс, именно по той схеме, когда один из локальных разработчиков является частью команды.

                  Именно я тот локальный… По окончании проекта попробую описать впечатления.
                    0
                    удачи, и буду рад почитать впечатления от такой формы разработки
                0
                Больше похоже на проблемы распределенной команды фрилансеров.
                  0
                  Это не единственный вид аутсорса.
                0
                Аутсорсинг без своего отдела IT — длинная и толстая игла…
                Однозначно, свой отдел IT, который согласует функционал с «бизнесами», составляет ТЗ и полностью контролирует как процесс разработки, так и приемку конечного продукта.
                За счет аутсортсеров этот отдел можно значительно сократить, но не упразднить полностью.

                Ну и процесс передачи конечного продукта заказчику, как описано в статье. То есть, ни каких подводных камней.

                Держать свою команду разработчиков почти всегда невыгодно.
                Универсалов нет, или они очень дорого стоят, а разрабатывать нужно весьма широкий спектр…
                • НЛО прилетело и опубликовало эту надпись здесь
                    0
                    Так в сфере разработки специализированного софта и аутсорсинг теряет смысл.
                    Разработчики софта выступают, как частный случай, с другой стороны «баррикад», то есть, сами выступают в роли аутсорцеров. ;)
                    Если же специализированный софт является ключевым, стратегическим элементом бизнеса, то отдавать его на внешнюю разработку самоубийственно, о чем и пишет автор.
                    • НЛО прилетело и опубликовало эту надпись здесь
                        +2
                        Вся прелесть аутсорцеров в том, что их не нужно обучать.
                        То есть, предполагается, что они такой софт уже умеют писать, написали его много и внедрили неоднократно…

                        У вас же ситуация тупиковая. Опытных разработчиков нет. Или писать самому, или привлекать персонал с последующим обучением и неизбежным увольнением после внедрения. Это не выгодно как вам, так и потенциальным сотрудникам (фрилансерам).
                        Разве что студентам, которым интересно научиться чему-то и набраться опыта.

                        Если же ваш софт специализирован и затрагивает какие-либо производственные ноу-хау, то ситуация усугубляется еще и конфиденциальностью.

                        Думаю, потерять можно не только деньги.
                        • НЛО прилетело и опубликовало эту надпись здесь
                            0
                            Тем более, если вы разрабатываете софт, ориентированный на конкурентоспособность.
                            Тут про аутсорсинг и вспоминать не стоит…
                            А вот вопрос организации команды разработчиков весьма инетресен для обсуждения.
                            Имею печальный опыт…
                            В свое время был координатором одного проекта, который зачах именно из-за отсутствия команды.
                            Хотя, проект был достаточно интересным и даже сегодня не потерял актуальности, хотя и похоронен уже как 4 года…
                            Но там про аутсорсинг и речи быть не могло…

                            P.S.
                            Мы уже далеко за пределами темы…
                            • НЛО прилетело и опубликовало эту надпись здесь
                      0
                      Насчет того, что в сфере спец. софта аутсорс не самое лучшее решение — я согласен.
                      Насчет того, что вливание в проект долгое — НЕ согласен.

                      Все зависит от сложности софта и квалификации разработчика. Например на проект продаж через киоски был запущен в тестовом режиме (альфа) уже через 3 месяца после моего прихода в компанию.

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

                      Сейчас нам предстоит при помощи аутсорс-компании добавить в этот проект кусок функционала всего за месяц. Я склонен полагать, что все пройдет удачно.

                    0
                    У Кавасаки дан однозначный ответ на этот вопрос.

                    Все зависит от степени развития стартапа — бутстрепинг или уже взрослая компания с венчурными вложениями.
                    Если в Вашем продукте есть не то, чтобы изъян, просто что-то работает не так как у других, и Вы уже довольно уверенно стоите на ногах — то да, несомненно, отдавайте.
                    Если Вы только начали и находитесь еще в поиске — то нет, конечно. Забейте на этот момент — сейчас главное подчеркнуть достоинства, в не вечно ныть о недостатках.
                    Продавайте то что уже есть и оно работает. Если, конечно, то что вы хотели бы отдать на аутсорс не повредит клиентам в плане здоровья/финансов.
                    Время доделать все будет. Главное не затягивать с ним.
                    НО еще главное помнить — лучшее-враг хорошего.

                    А вообще рекомендую Гая Кавасаки — Стартап. Для общего развития не повредит.
                    • НЛО прилетело и опубликовало эту надпись здесь
                        0
                        Я был участником, точнее спасателем одного из таких проектов, хозяева которого не проработав детали и риски отдали разработку на аутсорс. Скажу сразу, что спасти ничего не удалось.

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

                        Моя задача состояла в том, чтобы контролировать разработку, которая велась командой фрилансеров в Кишиневе.

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

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

                        Все закончилось достаточно хорошо. Поняв, что ждать от такого проекта даже запуска — бесполезно, я просто ушел. Я теперь работаю с интересными людьми (включая автора статьи), а проект через 3 месяца был закрыт.
                        0
                        Сама идея аутсорсинга довольно хороша и заманчива, все плюсы явно перекрывают существующие минусы, но напрактике чащего всего получается все наооборот, потому как услуга сама по себе у нас неочень развита начинается полный вынос мозга — некомпетенция аутсорсера, временно фактор поиска надежного аутсорсера, наплевательское отношение не «на свой проект», цена вопроса очень часто не соттветствует требованиям. вот и имеем прекрасную идею реализованную непонятно как, нужно время что бы наладить процесс, прийти к пониманию. а время как известно деньги.
                          +2
                          У автора понятие аутсорсинга странное. То, о чём вы пишите — не аутсорсинг, а разовая услуга, например, разработать интернет-магазин. Аутсорсинг — понятие более растяжённое во времении, это разработка и дальнейшее ведение проекта (расширение функционала, различные доработки, возможно, даже наполнение ресурса).
                            +1
                            Конечно, собственная разработка всегда более привлекательна с точки зрения качества и продуманности результата, заточенности его под специфику фирмы, однако далеко не всегда можно себе позволить иметь полный диапазон необходимых специалистов. Пример интернет-магазина — очень хороший: можно полностью зааутсорсить все работы связанные с сайтом (не только разработку) воспользовавшись сервисом типа shopify, можно нанять компанию которая заточит существующее решение под специфику магазина, а можно быть полностью магазином с уникальным софтовым решением типа amazon :)

                            Поэтому я полностью согласен с критерием «влияния продукта на конкурентные преимущества компании». Я это сформулировал для себя как «чем ближе продукт к формированию unique selling proposition фирмы, тем более „внутренняя“ должна быть его разработка». В частности, поэтому, для меня достаточно безнадежно выглядит аутсорсинг разработки стартап-проектов (где собственно разрабатываемый продукт и должен стать USP стартапа).

                            Ну а с тем, что «Техническая поддержка решения должна производиться уже силами компании-заказчика» не согласен: по мне участие компаний должно быть приблизительно на одинаковом уровне, а уж никак — «они все сделают, а наши технари будут все поддерживать». Это должна быть совместная разработка с самого начала, где «наши технари» участвуют в разработке или должно быть долгосрочное сотрудничество включая поддержку (как пределный пример аутсорсинга всех технических вопросов см. модель shopify).
                              0
                              Не ту проблему рассматриваете товарищи, всё проще намного… Учитывая что вы рассматриваете аутсорс, значит вы не спецы, тогда…

                              Если надо сделать интернет магазин, то можно воспользоваться аутсорсом на составление грамотного ТЗ.

                              95% заказчиков с которыми имела дела одна компания в которой я работал (слава богу «работал» в прошедшем времени) всегда делали всё долго и дорого, их интересовало только одно, убедить заказчика (редко когда заказчик знал что ему надо, обычно консультировался уже «на месте») что ему нужно ВСЁ, от совместимости сайта с IE3 (за доп-плату причём огромную) до масштабируемости на 10 серверов в ближайшем будущем (при том что заказчик из Эстонии, а тут даже самый посещаемый магазин не имеет нагрузки более одного хита в секунду)

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

                              Так вот доверять простые сайты доверять аутсорсерам можно и даже нужно (причём лучше просто попросить фрилансера чтоб установил опенсорсный двиг и натянул дизайн) сложные же доверять нельзя никому, но это ОЧЕНЬ ДОРОГО, а заказывать у кого-бы то ни было из ценовой категории «чёрная дыра» (на хабре много писали, поиск в помощь) нельзя вообще никогда, это развод.

                              Так что вопрос скорее стоит так…
                              Вы хотите потратить более 20 000 зелени (нормальный аутсорс) или менее 2 000 зелени (фрилансер «Вася Школьников»)
                                0
                                Дык это я и пытаюсь сказать. Что заказывать надо либо мало, либо много. А деньги тут непоказательные. Например, в РБК СОФТ, где я работал с 2004 по 2008, нижний порог цены был от 10 (в ранние времена) до 25 тыс. (в более поздние). И это были очень несложные технически решения и проекты. Просто на них были довольно дорогие специалисты и очень отлаженный менеджмент — за это и брали деньги. А сами проекты были в подавляющем большинстве несложные. Были еще и сложные. Те стояли от $200 тыс. Но их было очень немного, зато они по характеру ближе к тому, что я называл «много».
                                0
                                По своему опыту скажу, что обойти проблему №1 можно написав свою библиотеку (CMF). Какой бы не был исполнитель, он дальше песочницы библиотеки, назовем ее API, не должен уходить. Такой проект и контролироваться можно и дописывать легко. Добавим сюда описание кода и мануал — вот вам и обучать никого не надо. Ну и главное, в этом API должна быть модульность, чтобы оторвав кусок (модуль) из общего кода, остальная модель не упала. Собирая по кирпичикам проект, можно отдавать разные задачи разным подрядчикам. Как вариантам можно воспользоваться готовым CMF, типа CakePHP, Zend Framework и т.д.

                                Главное, чтобы это API кроме вашей компании никто не менял, а то получится караул, описанный в примере поста. Архитектор должен быть 1, а прорабов много…

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое