7 страхов IT-аутсорсинга: почему компании его боятся?

Многие бизнесы нуждаются в разработке IT-продуктов – от мобильных приложений до CRM-систем для управления продажами. Однако, компании без собственного штата разработчиков часто настороженно относятся к аутсорсингу – например, боятся за конфиденциальность информации или сомневаются в качестве или рентабельности разработки. Предлагаем разобраться, какие страхи связаны с аутсорсингом и как обезопасить свой бизнес, на конкретных примерах из практики SimbirSoft.

Страх #1. «Я не смогу контролировать разработчика»

Благодаря накопленному опыту, IT-аутсорсер помогает выстроить процессы гибко и понятно даже для тех, кто раньше никогда не заказывал программное обеспечение (ПО). Мы обычно начинаем работу над продуктом с выезда “в поля”, в офис предприятия, чтобы лучше погрузиться в бизнес-задачи и оптимизировать процессы. Для каждого проекта составляется дорожная карта – RoadMap – со всеми задачами, этапами и дедлайнами, и наш партнер может в любое удобное время отслеживать их выполнение в Redmine, Confluence и других распространенных системах.

Работу мы зачастую строим на основе Scrum, итеративных методологий, давно доказавших свою эффективность. Задачи – к примеру, создание экранов мобильного приложения – распределяем по коротким 2-4-недельным отрезкам времени. При этом ежедневные митапы с вовлеченными в проект экспертами, помогают контролировать результаты, а в случае появления проблем – ускорить их решение (например, получить дополнительные бизнес-данные).

Такой подход помогает вывести продукт на рынок в короткие сроки, естественно, без потери качества. Например, всего за 100 дней удалось выпустить мобильный банк СКБ – и это с учетом всех строгих требований финтеха. Банку требовалось сделать приложение более удобным для пользователей, чтобы получить конкурентное преимущество на рынке, а также повысить свои позиции в отраслевом рейтинге Markswebb. Следуя дорожной карте, мы сфокусировались на наиболее важных для пользователей функциях (в частности, реализовали автоматическое распознавание данных финансовых документов) и сократили Time to Market – время вывода продукта на рынок. В результате мобильный банк СКБ вошел в ТОП5 по версии Markswebb, заняв 4 место среди лучших банков для малого бизнеса (2017 год).

<i> Мобильный банк СКБ, разработанный за 100 дней </i>
Мобильный банк СКБ, разработанный за 100 дней

За счет четкого распределения обязанностей в команде на каждом этапе создания продукта есть ответственный эксперт, а вам проще контролировать сотрудничество. В зависимости от поставленных задач, в проектную команду обычно входят несколько специалистов, имеющих соответствующий опыт: проджект-менеджер (PM), аккаунт-менеджер (AM), специалист по оценке качества (QA), team-leader (TL), разработчики, аналитики.

Страх #2. «Разработчики не сделают то, чего я хочу»

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

Из практики:

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

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

Страх #3. «Разработчик не задумывается о потребностях моего бизнеса»

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

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

Страх #4. «Мне придется отвечать за аутсорсера перед руководством, инвесторами»

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

Из практики:

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

Страх #5. «А вдруг меня обманут, украдут исходники и код?»

Бизнес всегда юридически защищен, поскольку аутсорсер подписывает NDA – договор о неразглашении – и несет полную ответственность. Это обычная практика. Кроме того, как правило, на аутсорсинг отдается разработка программного обеспечения без доступа к реальным данным. Например, мы создаем приложение для дистанционного банковского обслуживания (ДБО), но не имеем доступа к реальным банковским данным. Создание программ чаще всего заказывает средний и крупный бизнес, который имеет собственную службу поддержки или разработки, а также собственную IT-инфраструктуру и базу знаний. Удобнее всего, когда IT-компания приходит в вашу корпоративную инфраструктуру и программирует или тестирует строго в рамках своей задачи. При этом вы контролируете все процессы и располагаете исходными данными, даже в том случае, если в течение нескольких лет перестанете сотрудничать с тем или иным подрядчиком.

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

Страх #6. «Мы будем общаться на разных языках»

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

Страх #7. «Как только проект будет сдан, некому будет позаботиться о его развитии»

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

По завершении проекта многие клиенты обращаются к нам с новыми идеями. Например, с 2017 года мы сотрудничаем с инхаус-командой платежной системы QIWI над нишевыми продуктами, которые требуют быстрого старта. Вместе мы реализовали более 10 продуктов, в том числе благотворительную программу «Помочь всем», стратегическую игру «Финансовый абсолют», стриминг-платформу QIWI Donate, образовательный портал QAMPUS и инструмент управления задолженностью, модернизировали раздел «Помощь» для пользователей QIWI Кошелька. В основе нашего многолетнего сотрудничества – гибкость и работа на технологическом стеке QIWI, что позволяет компании сразу запустить разработанные продукты в эксплуатацию и свободно интегрировать их.

<i> Подарки в честь очередного релиза </i>
Подарки в честь очередного релиза

Как проконтролировать качество разработки?

Говоря о контроле качества информационного продукта, важно понимать, что это понятие включает в себя множество факторов, для каждого из которых существуют свои методы проверки. Например, для проверки качества кода или архитектуры вы можете заказать услуги аудита – Code Review – у внешних экспертов. Качество процессов разработки оценивают с учетом жизненного цикла задач и планирования итераций, а качество коммуникаций – на основе регламентов взаимодействия бизнеса и аккаунт-менеджера со стороны IT-компании. Какой из факторов качества вы поставите на первое место – зависит от специфики ваших задач. В любом случае, аутсорсер может уже на старте проекта предоставить вам критерии контроля качества.

33
1 комментарий

Подпишусь под каждым словом.
Вот инструкция для заказчиков, которые боятся аутсорсить разработку: https://book.beztz.net/

Ответить