$ 64.1568.47$54.46
24 декабря 2015 года в 08:00

Екатерина Дмитриева. Кому доверить разработку мобильного приложения

Собственные разработчики или аутсорс

Екатерина Дмитриева. Кому доверить разработку мобильного приложения

Многие считают, что если уж делать мобильный сервис, то нанимать своих программистов, которые напишут так, что переписывать не придётся. Я считаю иначе. Первую версию сервиса нужно разрабатывать на аутсорсе. И переписывать всё равно придётся.

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

Если это не так, вот четыре аргумента в пользу работы с внешними специалистами.

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

2). Разработчики редко укладываются в сроки. Мне за всю мою практику попадался только один, который всегда успевал вовремя. Я, например, для каждого программиста, с которым работаю, знаю «коэффициент», на который нужно умножить его оценку, чтобы получить реалистичный дедлайн.

Когда программист — новый, вы ещё не знаете его «коэффициент» и поэтому рискуете вдвойне. Увеличение сроков влечёт увеличение стоимости (штатные программисты получают оклад), а значит, вы ошибётесь не только со временем, но и с бюджетом.

Аутсорс — другое дело: все риски берёт на себя разработчик. Правда, обычно он закладывает их уже в стоимость, но это даёт вам больше шансов на исполнение бюджета (а если сильно повезёт, то и сроков). Если сравнить стоимость аутсорса и внутренней разработки, то вполне может оказаться, что в вашем случае работать со своими специалистами будет выгоднее. Только не забудьте учесть риски, налоги и дополнительные затраты на штатного сотрудника.

Для иллюстрации возьму средние цифры. Допустим, мы говорим о приложении стоимостью 600 000 рублей.

В какую сумму может обойтись внутренняя разработка? Постоянные затраты (зарплата руководителя отдела или направления, налоги, аренда, бухгалтерия, маркетинг и тому подобное) — 250 000 рублей в месяц. Самое короткое время, за которое вы с нуля найдёте хорошего программиста, — два месяца. Стоимость своего специалиста высокого уровня — 165 000 рублей. 100 000 — на руки, 41 000 — налоговые отчисления, 9000 — отпускные, 15 000 — аренда (если сотрудник работает в офисе, ему нужно дополнительное место). Допустим, проект, рассчитанный на три месяца, затягивается ещё на один. Итого — более 2 млн рублей.

Теперь посчитаем, что будет, если выбрать аутсорс. Если мы потратим на поиск специалиста две недели, за четыре месяца все расходы (включая зарплату вашего сотрудника, контролирующего процесс) едва превысят 1,7 млн рублей.

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

4). Если первая версия взлетела, не спешите расслабляться. Вам ещё предстоит сильно её дорабатывать или даже перепридумывать — но всё-таки на основе старого кода и уже работающей механики. Когда вторую версию продукта готовит другая команда, это обычно идёт на пользу продукту. Новый взгляд, беспристрастная оценка эффективности предыдущей версии, новые идеи. Кроме того, это совершенно другая стадия для разработчиков, здесь уже нужно больше слушать и наблюдать за пользователями, чем строго следовать описанной задаче.

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

Личный опыт

Первая версия сервиса «БИТ.Лидер» разрабатывалась на аутсорсе. Когда проект заработал и доказал эффективность, я взяла сильных разработчиков. Проект развивался, пользователей становилось всё больше. Но какой бы идеальной не казалась идея сначала, она должна была измениться. Только в процессе работы пользователи понимают, что удобно, а что нет, какие функции незаменимы, а какие простаивают. Мы работали с пользователями, прислушивались к требованиям, старались предугадывать желания.

В какой-то момент стало ясно, что заложенная изначально структура сервиса уже не подходит проекту на его текущей стадии. Появился большой объём новых функций, не предусмотренных в первоначальной архитектуре. Кроме того, операционные системы не стояли на месте. В iOS, например, появился новый язык программирования Swift, отдельные функции которого позволили на порядок увеличить производительность. Изменилась мода на дизайн приложений.

В общем, «БИТ.Лидер» нужно было переписывать заново, и к этому времени у меня в штате уже были программисты. Они ранее реализовывали новые функции в версии 1.0, а поэтому, как никто другой, знали продукт и его «подводные камни», на 100% понимали логику системы.

Я рада, что выбрала именно такой путь. Если кто-то захочет его повторить, вот несколько главных советов.

1) Выбирая аутсорс, запросите до десяти предложений. Вероятнее всего, самое дорогое и самое дешёвое будут слишком сильно отличаться от реальности (бывает, что отличаются на порядок). К оставшимся приглядитесь более тщательно. Критериев несколько. Понимание исполнителями задачи, её детализация при оценке, имя и репутация компании, портфолио, гарантии результата. Обязательно запрашивайте портфолио конкретных разработчиков, которые будут работать над проектом, обращайте внимание на их роль в проектах. Бывает, что у компании портфолио прекрасное, только работали над проектами совсем другие спецы, а вам под шумок выделяют стажёров.

2) В договоре с аутсорсером в качестве критерия успешности результата пропишите не только работоспособность системы, но и качество кода. Это важно потому, что какое-то время именно первая версия будет развиваться, другим специалистам нужно будет её поддерживать. Для оценки качества кода имеет смысл привлечь стороннего эксперта, это вложение многократно окупится. Безусловно, не получится прописать все критерии идеального кода, но ряд требований зафиксировать необходимо. Это комментарии к коду, корректные названия функций и переменных, отсутствие «копипаста» (дублирования отдельных участков кода).

3) Ещё один важный пункт договора — запрет разработчикам упоминать проект в СМИ и портфолио. За нарушение предусмотрите санкции — настолько болезненные, чтобы разработчики всерьёз считались с требованием. Для нас, например, формальность данного пункта договора стала серьёзной ошибкой. Аутсорсер вовсю использовал наш проект в портфолио, из-за чего вложения в его продвижение работали в том числе и на аутсорсера. В поисках информации о вашем приложении поисковые системы будут ещё долго показывать как ваш сайт, так и сайт аутсорсера, даже если от изначального кода, который они написали для вас, совсем ничего не осталось.

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

5) В работе с аутсорсерами используйте те же навыки мотивации, что и со своей командой. Для лучшего результата не стоит ограничиваться формальными договорными отношениями и предоставленным ТЗ. Будьте готовы много говорить: объяснять, проверять, правильно ли поняли, ещё раз объяснять, ставить промежуточные контрольные точки.

Обсудить ()
Новости партнеров