В заказной веб-разработке часто возникают «плавающие» объемы загрузки, которые невозможно запланировать: они внезапно появляются и так же внезапно пропадают. В месяц таких задач может быть от 10% до 30% от общего количества. Нанимать каждый раз специалистов в команду и увольнять после спада нагрузки — не слишком правильное решение, сложное и затратное. Гораздо эффективнее использовать аутсорсинг.
3 причины агентству подключать аутсорсинговые команды
- Фиксированный бюджет по задаче, уже включающий в себя отладку и гарантийное сопровождение.
- Нет издержек на обеспечение условий работы сотрудников (рабочие места, отпуска, болезни и т. д.).
- Нет косвенных затрат (компьютеры, свет, вода и т.д.).
Наглядно в цифрах
- Средняя стоимость часа на аутсорсе — 1100 рублей.
- Средняя внутренняя ставка специалиста (даже включая косвенные затраты) значительно ниже — 850 рублей.
- При отработке 8000–10 000 часов в месяц всей компанией на аутсорс отдаётся из них 800–3000 часов.
Продвижение медцентров и клиник: три кейса о SEO, TikTok и Instagram*
Как получить измеримые результаты в фарммаркетинге.
Показываем на примерах →
Спецпроект
Затраты на аутсорс-команды при таком объеме часов — от 900 тысяч до 3,5 млн рублей. Тот же самый объем инхаус будет стоить от 700 до 2,5 млн рублей.
А теперь занимательная математика: 15% времени занимает отладка (а это 1200–1500 часов от общего времени отработки компании в месяц). На аутсорсе отладка не тарифицируется, а вот специалистам инхаус за нее придётся платить (в переводе на деньги выходит от 1 до 1,2 млн рублей).
Получается, что всё инхаус будет стоить от 1,7 до 3,7 млн рублей, то есть, почти в полтора раза дороже.
Проблемы аутсорсинга
Главная проблема аутсорса в веб-разработке — низкий порог входа на рынок и, как следствие, неудовлетворительное качество услуг подрядчиков. Этот минус может перекрыть агентству все сиюминутныке экономические выгоды, поскольку из-за него можно вообще остаться без заказов.
Аутсорс-компании появляются из маленьких региональных агентств: ресурсы в регионах дешевле, чем в Москве или Санкт-Петербурге, но даже при наличии мощной экспертизы заполучить крупного клиента региональной студии практически невозможно: на рынке уже устоялись агентства-лидеры, которые плотно сотрудничают с мировыми брендами, крупными клиентами из e-commerce, банками и другими популярными сервисами. Из-за этого у большинства новых команд отсутствует опыт разработки сложных и серьезных проектов, а соответственно и контроль качества выходящего продукта.
Хорошие команды в регионах вынуждены работать с представителями малого бизнеса, мизерными бюджетами и слабыми требованиями к качеству продукта. Некоторые разработчики настолько к этому привыкают, что даже при получении заказа от крупного клиента с приличным бюджетом уже не могут выдать качество соответствующего уровня.
Поэтому для себя мы решили: нужно развивать партнёрские аутсорс-компании, чтобы качество их услуг было на одном уровне с качеством нашей внутренней команды.
Мы разработали правила по работе с аутсорсом, которые используем уже на протяжении 8 лет. Эти правила позволяют партнерам наращивать компетенции и существенно облегчают работу нам. Партнеры обучаются стандартам и технологиям работы на подряде, качество их работы становится сравнимым с качеством нашего внутреннего продакшена. Всем тем, кто на рынке веб-разработки взаимодействует с аутсорсом, мы рекомендуем придерживаться этих восьми пунктов.
Правила работы с аутсорс-командами
- Давать максимальную обратную связь по коду и технологиям. Это нужно для объяснения преимуществ той или иной реализации или инструмента. Делать это лучше всего ежедневно: если упустить ошибку, ее исправление может занять неоправданно много времени. Самый оптимальный вариант — каждый день проводить 15-20-минутные обсуждения по результатам код-ревью, чтобы понять статус по плохим и хорошим приёмам в реализации. Без всего этого невозможно оперативно влиять на качество получаемого продукта от аутсорс-команд.
- Валидировать код. Код-ревью — обязательный этап для всех задач на проектах (). Без этого целостность кода и архитектуры могут пострадать, а требования к быстродействию и безопасности не будут удовлетворяться. Код сайта будет обрастать «костылями», и клиенту впоследствии потребуется рефакторинг. Чтобы этого не произошло, есть смысл проводить автоматическую проверку кода на соответствие требованиям безопасности TOP-10 OWASP. При событии push в системе контроля версий GIT начинается ряд автоматических процедур. Наш git-flow представлен на картинке.
- Внедрить стандарты PSR (это один из самых распространённых стандартов, именно его соблюдают большинство разработчиков фреймворков для php, такие как yii и symphony) и жестко их придерживаться. Это нужно для безболезненного масштабирования ресурсов и оперативного подключения или замены участников команд. Иначе при каждом изменении команды вы будете терять много времени, а, значит, и денег на введение новых разработчиков в курс дела.
У нас в AGIMA на серверной стороне всех проектов интегрирована автоматическая проверка соблюдения стандартов при помощи phpSniffer. - Распределять загрузку по задачам в зависимости от грейда аутсорс-компании. Одни команды хорошо показывают себя на промо-лендингах и отлично верстают, другие заточены под разработку магазинов на magento, третьи идеально интегрируются с 1С.
Сильные стороны команд мы узнаем на тестовом задании, в котором есть задачи на БД, ООП, архитектуру, инфраструктуру и многое другое. После успешного выполнения тестового задания проводится skype-собеседование со всеми сотрудниками аутсорс-компании. Если уровень компетенции одного из членов команды нас не устраивает, мы просим человека заменить. На основании собранной при тестировании информации тимлид уже при проектировании архитектуры проекта понимает, какой команде лучше отдать тот или иной кусок реализации. - Покрыть сеткой автотестов критический функционал на крупных проектах (это делается на стороне агентства, которое привлекает аутсорс, — так можно оптимизировать время на взаимодействие между аутсорс-разработчиками и внутренним отделом QA). Выделите самые важные продуктовые страницы и опишите пользовательские сценарии (например, набор действий для покупки того или иного товара). Автоматизировав эти сценарии, вы сможете быстро проверять (по расписанию ежедневно + при всех обновлениях системы), доступна ли основная функциональность. Так можно быть уверенным, что функциональных проблем нет.
- Применять подход разработки через тестирование (TDD). Суть подхода в том, что сначала на своей стороне пишется тест, покрывающий желаемое изменение, затем код, который позволит пройти этот тест, после чего проводится рефакторинг нового кода к соответствующим стандартам. Это позволяет экономить ресурсы тестировщиков и тимлидов, а также давать более оперативный ответ по приёмке работ.
- Вести разработку строго в соответствии с чек-листами (у нас такие). Это важно, чтобы не забыть и проверить самые «узкие» места проекта на всех этапах его создания. Ошибка, допущенная на этапе проектирования, может всплыть только при тестировании и внедрении, когда вся система уже разработана. Это риск потерять много денег и времени.
- И самое главное: делиться наработанным опытом. Это важно для развития нашего рынка и глобального улучшения рунета. Мы, например, пишем статьи об управлении (вот тут — про формирование команды и построение процессов в веб-разработке, а тут — про инструментарий для планирования разработки), выступаем на профильных конференциях и преподаем на курсах.
Наша партнерская сеть насчитывает около 40 аутсорс-команд, которых мы вырастили и можем полностью довериться их качеству выполнения работ (хотя правила контроля всё равно применяются ).
Кстати, если у вас есть команды с собственным штатов разработчиков на «1С Битрикс», вы хотите участвовать в разработке действительно крупного и серьезного проекта и вам нравится использовать MVC, миграции, ядро D7, ORM, Varnish, Docker, SOAP, xDebug, XHProf и другие технологии — пишите в комментарии и заполняйте форму на сайте, расскажем подробнее о работе с нами.
Партнерская публикация
Мнение редакции может не совпадать с мнением автора. Если у вас есть, что дополнить — будем рады вашим комментариям. Если вы хотите написать статью с вашей точкой зрения — прочитайте правила публикации на Cossa.
Источник:
