Как выбрать подрядчика для разработки веб-продукта: подробный гайд по всем аспектам работы

Сооснователи агентства веб-разработки DNA TeamDNA Team Дмитрий Забавин и Антон Тарасенко рассказали, как выбрать подрядчика под свою задачу, что делать, если не выполняются обязательства, и какие вопросы важно задать ему и себе перед началом сотрудничества.

«Зеленые флаги» у подрядчика

1. Рекомендация

Можно спросить у знакомых, с кем они уже работали и остались довольны. На этапе тендера подрядчики могут выглядеть очень похоже, суть проявляется в процессе работы, подчеркивает Антон.

2. Публичность

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

«Как правило, экспертность выливается в наличие телеграм-канала, сообщества, которое ведет либо компания, либо фаундеры от своего имени. В общем, что-то, что регулярно обновляется».

3. Рейтинги

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

4. Многообразие портфолио

Оно должно быть актуальным. Если исполнитель указал, что написал сайт, то на нем должны работать все элементы. И в «подвале» — нижней части сайта — должно быть написано, что разработано именно этой компанией.

Если это мобильные приложения, то они должны быть живые, в App Store, Google Play или в других магазинах приложений, чтобы можно было скачать, посмотреть, покликать лично.

5. Продуктовый подход

Глобально есть два типа компаний:

• Те, которые не могут и шагу ступить без развернутого технического задания;
• И те, кто у кого «бизнесовый» подход, а не чисто разработка и на этом все.

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

Есть те, кто не особо хочет разобраться в «бизнесовой» и аналитической частях, их по ощущениям около 80%, отмечает Антон. А есть другой пласт агентств, и вот они в первую очередь про бизнес.

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

6. Оперативность ответа на запрос

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

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

7. Открытое обсуждение проблем и возможность довести вопрос до начальства

Хорошо, если подрядчик сразу говорит о том, что в кризисной ситуации у вас будет контакт с гендиректором или сооснователем. Можно этим воспользоваться и привлечь руководство подрядчика к разрешению вопроса.

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

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

8. Возможность поэтапной оплаты

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

9. Насмотренность

Исполнитель должен видеть риски по исполнению конкретно вашего запроса, еще «на берегу» понимать, с чем можно столкнуться в работе. Если это, например, мобильное приложение, то в качестве основного риска будет выкладка в магазины приложений, особенно с учетом санкций. У Apple и у Google всегда были разные требования к приложениям и они постоянно меняются — риски по выкладыванию достаточно большие, отмечают эксперты.

«На месте заказчика я бы спросил исполнителя о сроке и о том, что можно сделать, чтобы минимизировать риски. Хороший подрядчик точно будет это знать».

Про ценообразование

Дешевле или дороже?

Когда заказчик получает десятки коммерческих предложений, разброс цены может быть от 100 тысяч до 10–20 миллионов и больше. И это за один и тот же проект.

«Я бы посоветовал так: мелких подрядчиков не стоит даже рассматривать. Потому что 80% исполнителей на рынке дают низкую цену просто для того, чтобы завести какой-то диалог с заказчиком, а когда стартует работа, начинают вить веревки: „А я учел одно, я имел в виду другое под этим, а здесь еще и дополнительные работы“.

Скупой платит дважды, но в нашем случае трижды, четырежды, а то и больше».

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

«Таких деталей может быть несколько и в итоге чек вырастает в разы, а качество такого продукта в 99% случаев не стоит потраченных денег. Дальше этот проект, скорее всего, не сможет масштабироваться, архитектура будет неудобной, что-то будет неправильно работать и так далее.

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

С теми, кто называет цену, например, в 20 миллионов, как раз стоит пообщаться, уверены эксперты. В личном разговоре сильные подрядчики начинают рассказывать интересные вещи, о которых другие могли не упоминать: продукт надо выкладывать на различные площадки, он должен поддерживать высокую нагруженность. То есть появляются нюансы, о которых даже заказчик не думал. И отсюда такое отличие в цене.

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

Из чего складывается цена

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

«Если техническое задание абстрактное, один подрядчик подумает: „Это ерунда какая-то, легко справимся и с крупным брендом поработаем, поставим цену в миллион рублей“, а другой скажет: „Я уже делал такие проекты, я знаю, что там много подводных камней, 100% будут проблемы в работе, заложу рисков 300%“. И вот у тебя от миллиона до 10 разбег.

А все почему? Потому что из тех вводных, с которыми пришел заказчик, нельзя понять ничего конкретного».

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

• Разбираться самому;
• Заказывать аналитику у подрядчика.

Без четких данных ни один исполнитель не назовет точную цену, даже если она «нужна была еще вчера».

«Бывает, что у клиента нет образа конечного результата. Есть просто некое видение, за которое нужно назначить цену.

Это одна из главных проблем современного российского клиента, когда он приходит и говорит: „Нам нужно вот такое приложение, скажите сколько это будет стоить и чтобы цена не поменялась никогда“. А техническое задание при этом расписано на несколько строк».

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

Этапы работы над IT-проектом

По мнению основателей DNА Team, оптимальная этапность работы выглядит так:

1. Аналитика

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

«Были такие случаи, что заказчик приходил с одной историей, а в после аналитики он понимал, что ему нужно абсолютно другое. Может понадобиться две—четыре встречи для того, чтобы очертить рамки и разбить проект на этапы выполнения.

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

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

2. Дизайн

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

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

«Важный момент — мы на этом этапе дополнительно подключаем тестировщика. Он смотрит соответствие макетов и технического задания, которое аналитик проработал: все ли на месте и не забыли ли что.

Нельзя исключать человеческий фактор, всегда что-то можно упустить: уйти в историю с дизайном и забыть отрисовать какие-то элементы, например. Лучше отслеживать это сразу, потому что потом править будет сложнее».

В результате этого этапа появляется дизайн-проект, где четко прописано, по аналогии с ремонтом, «какими цветами и что за мебель будет в проекте».

3. Разработка

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

• Проджект-менеджер

Это человек, который координирует работу команды и взаимодействует с заказчиком. Он «переводит» задачи с языка клиента на язык программистов и наоборот — своего рода мост между сторонами.

Его задачи:

— Составление плана проекта (например, диаграммы Ганта);

— Планирование, создание и ведение задач с командой;

— Определение целей на ближайшие недели работы.

Проджект-менеджер не обязательно должен быть задействован на 100%, обычно достаточно 30% его времени, так как его роль — координационная.

• Разработчики

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

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

• Тестировщик (QA)

Отвечает за проверку качества разработки. Обычно он загружен на 30% от времени проекта, пик работы приходится на финальные этапы, когда нужно тестировать почти готовый продукт.

• DevOps-инженер

Этот специалист настраивает техническую инфраструктуру:

— Серверы для разработки и тестирования;

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

4. Запуск

Набор процессов для запуска продукта на рынок.

5. Техническая поддержка

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

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

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

Как снизить риск неожиданностей в работе и после нее

1. Внимательно составить договор

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

2. Заранее договориться о технической поддержке

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

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

«Мы часто сами напоминаем клиенту: „Давайте поддержку, давайте, давайте“. Около 80% не хотят думать об этом сразу, их тоже можно понять. Но потом возникают проблемы, которых можно было избежать».

Коммуникация с подрядчиком

В общении с исполнителем главное — не верить словам, потому что говорить можно что угодно: «Все работает», «Все сделано», «Все готово», но ничего не показывать. Любой результат можно увидеть и «пощупать», заказчик не должен стесняться спрашивать, как продвигается проект, уверены эксперты.

«Мы, например, назначаем еженедельные созвоны с клиентом, где показываем живой результат. Клиент видит, в каком состоянии проект, если что-то не сделано, мы объясняем, почему. Это нормальная практика, когда в разработке что-то съезжает.

Через какое-то время, если речь о приложении, мы клиента добавляем в качестве тестировщика — ему прямо на телефон приходят обновления приложений. То есть наш тестировщик улучшает приложение и клиент независимо от нас может посмотреть, как оно работает».

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

Поменять текст — пустяк, но если клиент говорит о новом функционале, даже незначительном с его точки зрения, это может потребовать большей «грузоподъемности», которая изначально заложена в «скелет» IT-продукта.

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

Стандартный список:

• Техническое задание

Если оно разрабатывалось вместе с подрядчиком.

• Исходный код IT-продукта

Это может быть отдельно исходный код приложения, отдельно код сервера. То есть это не один файл, а набор исходных кодов всех компонентов, которые нужны в проекте.

• Инструкция по запуску продукта

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

• Дополнительная документация

Иногда на проекте бывает дополнительная документация — например, описание API. Это, условно говоря, «рычаги» сервера, с помощью которых клиент получает желаемые данные. Обычно есть отдельный документ, в котором объясняется, как это работает.

• Дизайн-проект с исходниками экрана

Чаще — в формате Figma.

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

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

«Бывает, что заказчик заплатил, но акт не подписал и уже требует передачи данных. Это риск для подрядчика: пока акт не подписан, деньги формально не принадлежат ему. Заказчик может сказать: „Я же оплатил, давай материалы“, подрядчик передаст их, а потом заказчик предъявит претензию, что работа не принята. То есть код забрал, а деньги попытается вернуть через претензию. Это лишние риски».

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

В таких случаях доказать свою правоту сложно — суды по вопросам IT-разработки часто непредсказуемы: вероятность выиграть дело примерно 50 на 50. Трудно доказать, что работа выполнена полностью и соответствует договору, потому что в процессе всегда появляются нюансы.

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

Подрядчик не справляется с работой. Что делать?

Точно не стоит при первых проблемах говорить: «Мне все не нравится, я меняю подрядчика».

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

1. Провести ревью, чтобы подрядчик объяснил, что происходит;
2. Сформировать стратегию выхода из ситуации;
3. Возможно, привлечь к решению руководство исполнителя.

Если конфликт неизбежен, вот примеры выхода из него.

Ситуация 1:
Вы оплатили сразу всю сумму работы или внесли крупный аванс

Это самый сложный вариант.

Например, у вас разработка на 20 миллионов, вы оплатили 10 миллионов авансом и пытаетесь вытягивать этот проект. «Что-то» делается, но далеко от того, что вы хотели. Если дойдет до суда, все затянется, как и когда вы получите назад эти деньги — непонятно.

В таком случае стоит запросить у подрядчика все, что уже сделано, и оценить результат. Для этого можно нанять стороннюю организацию — она проверит код, документацию и качество работы, а после оценки сделает выводы о том, насколько с кодом можно работать. Тогда заказчик оплачивает названную сумму и расходится с исполнителем.

Ситуация 2
Вы оплачиваете работу по этапам, но что-то идет не так

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

«Бывает, заказчик обращается к нам с просьбой обсудить ситуацию: „Что-то не так, работа идет медленно“ или „Команда нас не слышит“. Мы подключаемся, разбираемся. Иногда проблема на нашей стороне — команда застопорилась, тогда перераспределяем ресурсы. Менеджер сам такие решения не может принимать, это всегда согласуется с нами.

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

Незапланированные нововведения могут вызвать сбои в работе приложения, потому что команда не успевает одновременно вносить изменения и стабилизировать продукт. Клиент не всегда понимает, что его правки влияют на сроки. Хороший проектный менеджер управляет ожиданиями и предупреждает: «Если добавляем это изменение, сроки сдвинутся».

Но заказчик может вносить новые пожелания и думать, что ни сроки, ни стоимость не изменятся и все будет отлично. А потом, когда возникает не «отлично», у него, естественно, появляется негатив.

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

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

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

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

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

Минимум раз в неделю стоит проверять результаты и давать обратную связь, иначе велик риск провала проекта».

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

Желательно, чтобы в команде заказчика был человек с опытом работы в IT-проектах. Он сможет контролировать подрядчика и объективно воспринимать его обратную связь.

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

«Бывает, что заказчик уверен в своих технических знаниях, но на самом деле их у него нет. Он спорит, говорит, что работа занимает час, хотя на нее нужно два дня, и это демотивирует команду.

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

Если заказчик это понимает, значит, он готов к работе с подрядчиком.

Что в итоге

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

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