Аутсорс - волшебная палочка выручалочка для компаний. Благодаря аутсорсу вы можете передать определенную часть задач другой команде. А как сделать это правильно и как происходит сейчас, давайте разберем.
Стоит начать с разбора ситуации, когда компании пользуются услугами внешних разработчиков. Они все достаточно разные, но давайте посмотрим на это в разрезе размера компаний.
Для кого?
Маленькие компании.
Тут все просто. У таких компаний отсутствует свой собственный IT отдел, поэтому все задачи по разработке любого рода софта уходят на внешние команды.
Средние компании.
В таких компаниях имеется свой отдел разработки, а потребность во внешних ресурсах появляется, когда необходимо создать продукт хорошего качества с учетом специфики рынка или нужно решить непрофильную задачу. Например, поступила задача разработать мобильное приложение, в то время как в штате есть только веб разработчики, занимающиеся развитием своего сайта.В данном случае формировать свою внутреннюю команду все-таки и долго, и дорого.
Крупные компании.
Компаний, имеющие огромный штат собственных разработчиков. Но даже таким компаниям тоже постоянно появляется необходимость в делегировании каких-то задач внешним командам. У крупных компаний как правило количество проектов в портфеле на много больше, чем внутренних ресурсов, даже с учетом постоянно найма в штат новых разработчиков.
Небольшое уточнение: крупные заказчики как правило используют модель аутсаффинга. Так как перед ними стоит задача не просто реализации продукта в установленные сроки, но также с минимизацией рисков. Соответственно для контроля процесса разработки такие компании берут управление проектами в собственные руки.
Итак, мы поняли, что подрядчики нужны всем. И если говорить о схемах поиска подходящего подрядчика, то у разных компаний они разные и нет единой идеальной формулы. Приведем несколько примеров:
- Через поисковые системы, но здесь нужно быть готовым к ряду рисков, ведь можно наткнуться на не проверенную команду.
- Поиск в различных рейтингах, где уже есть некий контроль и анализ присутствующих команд. Самыми основными на данный момент являются: Рейтинг Рунета, Tagline, Ruward.
- “Сарафанное радио” - обращение по рекомендациям (друзей, знакомых, знакомых друзей или друзей знакомых), что еще больше минимизирует вероятность нарваться на недобросовестную команду разработки.
- Еще один способ, которым пользуются крупные компании - тендерные площадки. При таком поиске, как мне кажется, подрядчик также заинтересован в выстраивании сотрудничества либо с топовыми компаниями, либо как минимум с проверенными в предыдущих проектах. Ведь все таки специфика тендеров несет за собой риски выигрывания тендера некомпетентной компанией, срыва сроков и неспособностью завершить взятые на себя обязательства по разработке выигранного тендера.
- Ну и не стоит забывать про работу отделов продаж IT компаний, которые также постоянно ищут (и находят) новые заказы и контракты.
Теперь мы подошли к очень важному моменту - передача задачи. Как говорилось выше мы разберем две ситуации: идеальный вариант и наиболее жизненный. Также рассмотрим для каждого плюсы и минусы.
Идеальный вариант
Если взять за эталон крупных заказчиков с выстроенными внутренними процессами разработки, то как правило, от заказчика приходит детализированное описание проекта в целом, описание функциональных и нефункциональных требований. Часто присутствует готовый укрупненный приватизированный бэклок, тайминг разработки, стабилизации и запуска проекта, актуальная документация всех зависимых внешних и внутренних сервисов, проработанный дизайн с картой экранов, проработанная архитектура и ряд других полезный артефактов.
Часть таких клиентов выстраивают развитие своих проектов с учетом обратной связи: от их клиентов, от поведения рынка, от конкурентов и ряда других факторов. Поэтому, даже при наличии у Заказчика большого сформированного бэклога, приоритезация и формирование ближайших спринтов идет с учетом постоянного анализа предыдущих релизов, актуальной ситуации на рынке и планов маркетинговых отделов, в результате чего многие, казалось бы важные задачи так и остаются в бэклоге с более низкими приоритетами. При таких подходах достаточно сложно спрогнозировать развитие продукта и архитектурно учесть его потенциала, в результате чего периодически приходится выполнять частичный или комплексных рефакторинг кода. Также отсутствует возможность спрогнозировать какую-то фиксированную стоимость всего проекта, так как фактически Заказчик не ставит четких конечных целей по функциональности. Из явных плюсов - разработка идет в очень интенсивном ритме, всегда актуальна, быстро реагирует на изменения рынка и потребности пользователей, что повышает популярность таких продуктов.
Жизненный вариант
Во всех остальных случаях, Заказчик редко ставит в явном виде низкоуровневые задачи, и в лучшем случае формирует верхнеуровневые задачи ожидаемого продукта с описанием общей ее функциональности и каких-то бизнес требований. Очень много клиентов описывают несколькими абзацами свое общее видение, либо прикрепляют ссылку на сторонних продукт в качестве примера с комментариями специфики их планируемого проекта.
Такие запросы приходят как от далеких от разработки Заказчиков, так и от более опытных Заказчиков, у которых просто либо нет достаточного времени описать задачу, а сроки выбора подрядчика горят, либо изначально задачу проектирования и детализации требований планируется передать на подрядчика.
Этого конечно же недостаточно для старта работ. Чем детальней описаны ожидаемые функциональности, тем точнее команда разработки может оценить трудозатраты, стоимость и сроки разработки данного проекта.
Но не все Заказчики имеют такую возможность, поэтому многие разработчики на этапе пресейла по поверхностному описанию дают примерную оценку. И только после этапа проектирования могут дать более точную, где в режиме обсуждения с Заказчиком собирают:
- все требования,
- ожидания клиента,
- прототипируют интерфейсы,
- разрабатывают концепции дизайна,
- делают при необходимости различного рода исследования,
- проектируют архитектуру с учетом ожидаемого роста и нагрузок,
- описывают различные документы (ТЗ, Бизнес требования, Функциональные/нефункциональные требования, Правила сдачи/приемки результата работ, тайминг разработки, бэклоги, тест кейсы, сопроводительная документация) и много чего другого.
Этап проектирования дает возможность погрузить команду разработки в проект, в результате чего можно достаточно точно оценить все трудозатраты, учесть все риски, подобрать лучшие решения и практики для реализации данного проекта. По этому, для качественной разработки, нужно полностью синхронизировать ожидание Заказчика с пониманием разработчиков, где необходимо исключить двоякую трактовку отдельной функциональности.
Но при данном формате работе по проекту, есть большой минус - сама разработка откладывается на значительный срок до момента завершения этапа проектирования.
Вторым большим минусом для самого проекта - это отсутствие гибкости в разработке проекта, так как есть четкие требования к проекту, описанные и оцененные в документации к проекту, все, появляющиеся в ходе разработки новые требования со стороны заказчика выносятся в бэклог и могут быть взяты в работу после завершения основных работ по отдельному заданию за отдельный бюджет.