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

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

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

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

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

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

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

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

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

Основная задача проджект-менеджера  — сдать качественный проект, соблюдая отведенные сроки и бюджет, на особо крупных проектах он может управлять несколькими командами. Аккаунт-менеджер выстраивает отношения с клиентом, он может поддерживать беседу на “нормальном человеческом” языке и разбирается в продуктах. Аккаунт транслирует стратегические приоритеты клиента проджект-менеджеру, а тот формулирует задачи команде, которой руководит технический специалист  — team-лидер. Аналитики понимают специфику разных индустрий и прорабатывают бизнес-требования. А разработчики на основе этих требований реализуют уникальные технически сложные задачи.

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

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

Из практики:

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

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

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

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

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

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

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

Из практики:

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

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

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

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

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

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

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

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

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

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

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

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

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