Как выбрать разработчика или агентство для вашего бизнеса

Найм разработчика или агентства — одно из самых ответственных решений владельца бизнеса, и большинство людей подходят к нему практически без критериев оценки. Вы бы не наняли бухгалтера без проверки квалификации или подрядчика без просмотра предыдущих работ. Однако я регулярно встречаю владельцев бизнеса, которые наняли первого разработчика на Upwork, заплатили 50% предоплаты без договора и получили наполовину готовый продукт, который нельзя ни использовать, ни поддерживать.

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

Фрилансер vs. агентство vs. штатный сотрудник: компромиссы

Прежде чем оценивать конкретных кандидатов, нужно решить, какой тип сотрудничества подходит для вашего проекта.

Фрилансеры

Лучше всего для: Малых и средних проектов с четко определенным объемом работ, текущего обслуживания существующих продуктов, добавления конкретных функций в существующую кодовую базу.

Типичная стоимость: $50-$200/час в зависимости от опыта и локации, или $3,000-$30,000 за проект.

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

Недостатки: Единая точка отказа. Если фрилансер заболеет, уедет в отпуск или возьмет слишком много проектов — ваши сроки сдвинутся. Ограниченные мощности для больших проектов. Нет встроенных возможностей по дизайну, QA или DevOps — возможно, придется нанимать нескольких фрилансеров и координировать их самостоятельно.

Реальность: Диапазон качества среди фрилансеров огромен. Лучшие фрилансеры превосходят большинство агентских команд и берут соответственно. Худшие возьмут ваши деньги и выдадут непригодный код. Ваша задача — отличить первых от вторых (подробнее ниже).

Агентства

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

Типичная стоимость: $100-$300/час за команду, или $20,000-$200,000+ за проект.

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

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

Реальность: Качество агентств варьируется так же сильно, как и качество фрилансеров, только при более высоком ценнике. Лучшие агентства стабильно выдают отличную работу с профессиональным управлением проектами. Худшие берут агентские ставки, а затем аутсорсят фактическую разработку дешевым субподрядчикам за рубежом, не говоря вам об этом. Спросите, кто конкретно будет писать код.

Штатные разработчики

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

Типичная стоимость: $80,000-$180,000/год зарплата плюс соцпакет, офис, оборудование и управленческие накладные. Реальная стоимость обычно в 1.3-1.5 раза превышает зарплату.

Преимущества: Полная посвященность вашему проекту. Глубокое понимание бизнеса со временем. Никаких сюрпризов в счетах. Вы владеете отношениями и знаниями.

Недостатки: Найм занимает 2-4 месяца. Нужно разбираться в технологиях достаточно, чтобы оценивать кандидатов и управлять ими (или нанять того, кто это может). Вы отвечаете за их карьерное развитие, поддержание вовлеченности и замену при уходе. Один разработчик не покрывает все технологии — возможно, все равно понадобятся подрядчики для специализированной работы.

Реальность: Штатный разработчик имеет смысл только когда ваши постоянные потребности в разработке достаточно велики, чтобы полностью загрузить его. Если вам нужно 20 часов разработки в месяц, найм штатного разработчика за $150,000/год означает, что вы платите $625/час за его используемое время. Фрилансер по $150/час обошелся бы в разы дешевле.

Моя рекомендация

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

Если проект достаточно сложен, чтобы требовать команду (мобильное приложение + бэкенд + веб-панель, например), небольшое агентство (5-15 человек) обычно обеспечивает лучший баланс качества, координации и стоимости. Крупные агентства (50+ человек) лучше подходят для проектов корпоративного масштаба, где нужны глубокие компетенции в специализированных областях.

Как оценивать портфолио

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

Посетите живые сайты

Не просто смотрите скриншоты в презентации портфолио. Попросите URL и реально посетите сайты или скачайте приложения. Удивительно много "работ из портфолио" больше не доступны онлайн, что может значить: клиент закрылся (бывает), проект не был завершен (красный флаг), или качество ухудшилось после запуска из-за отсутствия поддержки (вопросы о долгосрочном качестве).

Когда посещаете живой сайт, обращайте внимание на:

• Скорость. Быстро ли он загружается на телефоне? Попробуйте на мобильном интернете, а не на офисном Wi-Fi. Если собственная работа из портфолио разработчика тормозит, что это говорит о стандартах, которые он применяет к клиентским проектам?
• Мобильный опыт. Откройте на телефоне. Удобно ли пользоваться? Можно ли найти информацию без затруднений? Легко ли нажимать кнопки?
• Отточенность. Правильно ли загружаются изображения? Есть ли битые ссылки? Хорошо ли отформатирован текст? Эти детали выдают уровень заботы разработчика о проекте.

Спросите об их роли

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

Ищите проекты, похожие на ваш

Разработчик, создавший пять интернет-магазинов, сделает лучший шестой, чем разработчик, который никогда не создавал ни одного. Опыт в предметной области важен — не потому что технология отличается, а потому что опытные разработчики уже совершили и усвоили ошибки, которые неопытные будут совершать на вашем проекте.

Это не значит, что нужно нанимать только того, кто создал точную копию того, что вы хотите. Но если ваш проект — система заказов для ресторана, разработчик с опытом в food-tech поймет граничные случаи (кастомизация меню, зоны доставки, кухонные процессы, разделение счета), которые разработчик, создававший только маркетинговые сайты, не учтет.

Проверьте даты

Спросите, когда были завершены проекты в портфолио. Веб-разработка меняется быстро. Портфолио, полное проектов 2019 года без обновлений, говорит кое-что об уровне текущей активности разработчика и долгосрочном качестве работы. Недавние проекты (за последние 12-18 месяцев) более релевантны для оценки текущих навыков.

Красные флаги, при которых стоит уходить

За годы работы в индустрии я видел все варианты провалившихся проектов. Вот предупреждающие знаки, которые, по моему опыту, стабильно предсказывают неудачу.

Подозрительно низкая цена

Если один разработчик предлагает $15,000, другой — $12,000, а третий — $2,000 за тот же проект, разработчик за $2,000 не более эффективен — он либо срезает углы, которые вы пока не видите, либо планирует догнать цену дополнительными заказами позже, либо просто не понимает объем того, о чем вы просите.

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

Нет процесса или методологии

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

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

Не упоминают тестирование

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

Хорошие разработчики пишут автоматические тесты, проверяющие корректность кода. Они тестируют на множестве браузеров и устройств. У них кто-то, кроме автора кода, проверяет его работу. Эти практики стоят времени, что является частью причины, почему качественная разработка дороже любительской.

Сопротивление контрактам или документации

Если разработчик противится письменному договору — это серьезный красный флаг. Профессионалы приветствуют контракты, потому что контракты защищают обе стороны. Договор должен покрывать: объем работ, сроки, график оплаты, права на интеллектуальную собственность, что происходит при изменении объема и как каждая сторона может прекратить сотрудничество.

Аналогично, если они отказываются документировать технические решения или создавать какую-либо документацию о том, как работает система — вы создаете зависимость от конкретного человека. Когда он будет недоступен (или вы захотите сменить разработчика), отсутствие документации означает, что следующему человеку придется реверс-инжинирить все с нуля.

Обещают нереалистичные сроки

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

Разработчик, обещающий агрессивные сроки, либо планирует срезать углы, либо не понимает объем, либо вернется на второй неделе со списком "усложнений", удлиняющих сроки (и бюджет).

Ключевые пункты контракта: что должно быть в соглашении

Нанимаете ли вы фрилансера или агентство, письменное соглашение должно покрывать следующие области.

Объем работ

Объем должен описывать, что будет создано, достаточно детально, чтобы обе стороны могли посмотреть на готовый продукт и согласиться, соответствует ли он обещанному. Не настолько детально, чтобы каждый пиксель был указан (такая жесткость губит проекты), но достаточно детально, чтобы "создать мне сайт" не превратилось в спор о том, была ли включена система бронирования.

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

Структура оплаты

Никогда не платите 100% предоплаты. Поэтапная оплата выравнивает стимулы и защищает обе стороны.

Распространенная и работающая структура:

• 20-30% предоплата для начала проекта (покрывает риск разработчика при начале работы)
• 30-40% на промежуточном этапе (обычно после утверждения дизайна или функционального прототипа)
• 30-40% при завершении (после финальной проверки и развертывания)

Для крупных проектов может быть 4-5 этапов. Ключ в том, что каждый платеж привязан к результату, который вы можете оценить. Если проект застопорится, вы заплатили только за выполненную работу.

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

Права на интеллектуальную собственность

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

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

Без четкого пункта об ИС разработчик технически владеет кодом и лицензирует его вам. Это создает зависимость: если отношения закончатся плохо, он может утверждать, что у вас нет права модифицировать или поддерживать код.

Соглашение о неразглашении (NDA)

Если проект включает проприетарную бизнес-логику, данные клиентов или действительно новую идею, NDA разумно. Большинство профессиональных разработчиков подпишут стандартное NDA без возражений.

Однако понимайте, что NDA защищает и чего не защищает. Оно защищает конфиденциальную информацию — не идеи. Если ваша бизнес-концепция — "Uber для выгула собак", NDA не помешает кому-то создать конкурирующий продукт. Оно помешает делиться конкретными деталями бизнеса, данными клиентов и проприетарными процессами, раскрытыми в ходе сотрудничества.

Делайте NDA разумным по охвату и сроку. 2-летнее NDA, покрывающее информацию, переданную во время проекта — стандарт. 10-летнее NDA, запрещающее разработчику работать во всей вашей индустрии — неразумно, и хороший разработчик (справедливо) будет возражать.

Техническая оценка для нетехнических основателей

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

Спросите о выборе технологий

Хороший разработчик объяснит рекомендации по технологиям на понятном языке и обоснует их потребностями вашего проекта — а не личными предпочтениями. Спросите: "Почему вы рекомендуете эту технологию для моего проекта?" Ответ должен ссылаться на ваши конкретные требования, сроки и бюджет.

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

Спросите о хостинге и развертывании

Где будет жить ваш сайт или приложение? Кто управляет серверами? Что произойдет, если сайт упадет в 2 часа ночи? Как разворачиваются обновления?

Вы должны понимать хостинг-схему достаточно, чтобы знать: кто отвечает за работоспособность, какова ежемесячная стоимость и можете ли вы перейти к другому провайдеру при необходимости. Если разработчик хостит все на своем личном сервере и у вас нет доступа — вы привязаны к этим отношениям и отрезаны от собственного продукта.

Спросите о безопасности

Для любого проекта с данными клиентов или платежами спросите, как обеспечивается безопасность. Ответ не должен быть глубоко техническим, но должен покрывать: как хранятся и защищаются данные клиентов, как обрабатываются платежи (они должны использовать проверенные процессоры вроде Stripe, а не обрабатывать номера карт напрямую), использует ли сайт HTTPS и как управляются учетные данные доступа.

Если они отмахиваются от вопросов безопасности как неважных для вашего проекта — это красный флаг. Безопасность важна для каждого проекта с пользователями.

Попросите рекомендации

Это самый недооцененный инструмент оценки. Попросите 2-3 рекомендации от прошлых клиентов — желательно с проектами, похожими по размеру и типу на ваш. Затем действительно позвоните им.

Вопросы для рекомендателей:

• Проект завершился в срок и в бюджет?
• Как была коммуникация во время проекта?
• Были ли сюрпризы или неожиданные расходы?
• Наняли бы вы их снова?
• Как они справляются с проблемами или разногласиями?

Ответы расскажут больше, чем любой обзор портфолио или продающий звонок.

Управление отношениями для успеха проекта

Нанять правильного разработчика — половина дела. Эффективно управлять сотрудничеством — вторая.

Установите ожидания по коммуникации с самого начала

До начала работы договоритесь о:

• Как часто вы будете общаться (минимум еженедельные обновления)
• По какому каналу (email, Slack, инструмент управления проектами)
• Ожидания по времени ответа (24 часа для несрочных вопросов, в тот же день для блокирующих)
• Регулярные созвоны (еженедельный 30-минутный видеозвонок для обзора прогресса)

Большинство провалов проектов, которые я видел, были вызваны не плохой разработкой — а сбоями в коммуникации. Разработчик создал нечто отличное от того, что хотел клиент, потому что ни одна сторона не проверила согласованность, пока не стало слишком поздно.

Давайте четкую, письменную обратную связь

При проверке работы в процессе записывайте отзыв. "Мне не нравится дизайн" — бесполезно. "Шрифт заголовка кажется слишком неформальным для нашего бренда — можно использовать что-то более профессиональное, похожее на то, что мы видим на [конкретный пример]?" — дает разработчику конкретику для действий.

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

Управляйте изменениями объема осознанно

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

Когда хотите что-то добавить или изменить, формулируйте так: "Я хотел бы добавить X. Как это повлияет на сроки и стоимость?" Это вынуждает к явному разговору о компромиссах. Разработчик может сказать, что это добавит две недели и $3,000, и вы решите, стоит ли оно того. Или предложит более простую версию функции, укладывающуюся в текущий объем. Ключ — делать изменения объема осознанными, а не случайными.

Определите "готово" до начала работы

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

До начала работы создайте документ с критериями приемки, описывающий простым языком, что будет делать готовый продукт и как вы это проверите. "Процесс оформления заказа работает корректно" — расплывчато. "Клиент может добавить товары в корзину, ввести адрес доставки, оплатить банковской картой и получить email с подтверждением заказа" — проверяемо.

Когда результат соответствует критериям приемки — проект завершен. Дополнительные изменения за рамками этих критериев — новый объем работ со своими сроками и бюджетом.

После проекта: что дальше

Передача по завершении проекта так же важна, как старт.

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

Получите документацию. Минимум нужен документ, объясняющий: как обновлять контент, где хранится код, как развертывать изменения, какие сторонние сервисы использует продукт и какие задачи текущего обслуживания необходимы (обновление SSL-сертификатов, обновление зависимостей).

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

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

Инвестиционное мышление

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

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

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

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