Выбор разработчика похож на наём человека, которому вы доверяете важную часть своего дела, толком не умея проверить, хорош ли он. Заказчик чаще всего не программист, кода читать не умеет, а отличить настоящего профессионала от уверенного новичка на словах почти невозможно — оба говорят гладко и обещают сделать. И вот человек выбирает по интуиции или по самой низкой цене, а через месяц получает то, что приходится переделывать у другого, заплатив дважды.
Хорошая новость в том, что выбрать надёжного исполнителя можно и не разбираясь в технике. Качество разработчика проявляется задолго до первой строчки кода — в том, как он понимает задачу, какие вопросы задаёт, что обещает и как ведёт переговоры. Эти сигналы видны любому внимательному заказчику. Разберём, на что смотреть в портфолио, какие вопросы задать до старта и по каким красным флагам распознать того, с кем лучше не связываться.
Эта статья — опорная в разделе про разработку. Смежные темы: как составить ТЗ, из чего складывается цена, кто нужен в команде разработки.
Что вы узнаете из статьи
- На что реально смотреть в портфолио, а что не значит ничего
- Какие вопросы до старта показывают профессионала
- По каким красным флагам видно ненадёжного исполнителя
- Почему самая низкая цена — плохой критерий выбора
- Как оценить разработчика, не разбираясь в технике
Что смотреть в портфолио и отзывах
Портфолио — первое, на что смотрит заказчик, и здесь легко обмануться. Красивые картинки и громкие названия проектов сами по себе не значат почти ничего: непонятно, что именно человек в этих проектах делал и делал ли вообще. Поэтому смотреть нужно не на эффектность, а на близость к вашей задаче. Делал ли разработчик что-то похожее на то, что нужно вам? Опыт с родственными задачами стоит дороже, чем десяток красивых, но чужих по типу работ.
Куда важнее портфолио — отзывы прошлых заказчиков, потому что они показывают то, чего не видно в картинках: каково с человеком работать на самом деле. Соблюдает ли сроки, как общается, доводит ли до конца, не было ли историй с переделками и пропажами на полпути. Один честный отзыв вроде «сделал в срок, на правки реагировал спокойно, код потом легко подхватил другой» стоит десятка строчек самопрезентации.
Если проект большой и одному человеку не по силам, оценивать нужно уже не отдельного исполнителя, а команду под проект целиком — кто в неё входит, кто за что отвечает, есть ли у них опыт совместной работы. Команда без слаженности часто хуже одного толкового специалиста.
Какие вопросы задать до старта
Разговор до начала работы говорит о разработчике больше, чем любое портфолио. Есть несколько вопросов, ответы на которые сразу проявляют профессионала.
«Перескажите, как вы поняли задачу». Самый показательный вопрос. Профессионал перескажет своими словами, уточнит непонятные места, задаст встречные вопросы — потому что он действительно вникает. Тот, кто просто кивает «всё понятно, сделаем» и не спрашивает ничего, скорее всего, понял по-своему, и это аукнется переделкой. Хороший разработчик сам тянется к тому, чтобы ТЗ на проект было чётким, а не «как пойдёт».
«Делали ли вы похожее и можно ли посмотреть?» Конкретный опыт важнее общих заявлений «я могу всё». Универсал, который берётся за любую задачу, часто слабее того, кто специализируется на близких к вашей.
«Как вы оцениваете сроки и из чего цена?» Профессионал объяснит логику оценки и разложит, за что вы платите. Тот, кто называет цифру с потолка и не может её обосновать, либо не подумал, либо скрывает.
«Что будет, если задача изменится или что-то пойдёт не так?» Ответ показывает, как человек работает с реальностью, в которой планы редко сбываются идеально. Зрелый исполнитель спокойно расскажет про процесс изменений, незрелый отмахнётся «да всё будет нормально».
Красные флаги: когда стоит насторожиться
Есть набор признаков, каждый из которых — повод как минимум насторожиться, а в сумме — почти гарантия проблем.
Соглашается на всё, не задавая вопросов. Кажется удобным — не мучает уточнениями. На деле это значит, что человек не вникает в задачу, и сделает он то, что сам додумал. Хороший разработчик всегда задаёт вопросы, потому что без них нельзя сделать правильно.
Подозрительно низкая цена и нереальный срок. Если все называют срок в месяц и цену в районе определённой суммы, а один обещает за неделю и втрое дешевле, это не выгодная находка, а тревожный сигнал. Либо он не понял объём, либо срежет половину работы, либо пропадёт. Понимание того, из чего складывается цена, помогает отличить честное предложение от подозрительного.
Уход от конкретики. На вопросы про объём, формат сдачи, что входит, а что нет, отвечает общими словами «да там всё стандартно, не переживайте». За этим обычно прячется либо нежелание брать обязательства, либо непонимание собственного объёма работы.
Не хочет работать по ТЗ и фиксировать договорённости. «Зачем нам бумаги, мы же друг друга поняли» — фраза, после которой стоит попрощаться. Отказ фиксировать — это отказ от ответственности.
Требует всю оплату вперёд. Адекватная схема — оплата по этапам или по факту. Требование всей суммы до начала работы — серьёзный риск.
Почему низкая цена — плохой критерий
Соблазн выбрать самого дешёвого понятен, особенно когда заказчик не видит разницы между предложениями. Но низкая цена в разработке почти никогда не бывает подарком — за ней стоит либо срезанный объём, либо неопытность, либо намерение сделать абы как и исчезнуть. И то, что сэкономлено на старте, с лихвой возвращается на этапе переделок.
Логика тут простая, как с любой работой, которую делают руками и головой. Хороший специалист знает себе цену и не работает в убыток, поэтому его предложение не будет самым низким. Самое дешёвое предложение почти всегда исходит либо от того, кто не понимает реального объёма, либо от того, кто понимает, но собирается часть работы тихо не сделать. В обоих случаях заказчик платит дважды.
Это не значит, что нужно хватать самое дорогое — переплата за громкое имя так же бессмысленна. Здоровый ориентир — соотношение цены и подтверждённого качества: отзывы, история сданных проектов, адекватность в разговоре. Чуть дороже, но один раз и хорошо — почти всегда выгоднее, чем дёшево и потом ещё раз за переделку.
Как вести себя на этапе переговоров
Сам процесс переговоров до сделки — это уже проверка, и вести его стоит так, чтобы он работал на вас. Несколько простых принципов помогают отсеять неподходящих ещё до старта.
Не торопитесь и не хватайтесь за первого согласившегося. Поговорите с несколькими кандидатами — не ради того, чтобы выбить цену пониже, а чтобы увидеть разницу в подходе. Один задаёт пять уточняющих вопросов, другой не задаёт ни одного — эта разница скажет о них больше, чем любые слова о себе. Сравнение нескольких подходов само вытаскивает наружу и красные флаги, и сильные стороны.
Описывайте задачу честно и полно, не приукрашивая и не упрощая. Соблазн «продать» проект покрасивее, чтобы заинтересовать, оборачивается тем, что исполнитель оценивает не ту работу, которая есть на самом деле. Чем точнее вы опишете задачу на входе, тем точнее будет оценка и тем меньше неприятных сюрпризов по ходу. Хороший разработчик ценит честное описание выше красивого.
Обращайте внимание не только на что человек говорит, но и как. Внятно ли объясняет сложное простыми словами или прячется за терминами, чтобы казаться умнее. Спокойно ли реагирует на ваши вопросы или раздражается. Отвечает ли по существу или общими фразами. Манера общения на переговорах почти всегда сохраняется и в работе — тот, кто на старте уходит от конкретики, и в проекте будет уходить от ответственности.
И последнее: доверяйте смешанному впечатлению. Если формально всё хорошо, но что-то смущает — медлительность с ответами, уклончивость, нежелание фиксировать договорённости, — это не паранойя, а сигнал. Лучше потратить лишний день на поиск, чем месяц на переделку у того, кто сразу вызывал сомнения.
Как платформа помогает выбрать надёжного исполнителя
На Где.Эксперт разработчиков выбирают не по громкой самопрезентации, а по реальным отзывам и истории выполненных заказов. Видно, кто уже делал похожие проекты, как заказчики оценили результат, соблюдались ли сроки, не было ли историй с переделками и пропажами. Это сразу отсекает большинство красных флагов ещё до начала разговора.
Задачу можно обсудить до старта и по тому, как исполнитель отвечает, понять, вникает ли он и стоит ли с ним работать. Оплата идёт по факту выполнения этапов, а отзывы прошлых заказчиков работают страховкой от главного риска — выбрать по красивым словам того, кто потом не справится.
Часто задаваемые вопросы
На что в первую очередь смотреть?
На реальный опыт с похожими задачами и отзывы прошлых заказчиков. Портфолио показывает, что человек делал близкое, отзывы — каково с ним работать. Это важнее красивой самопрезентации.
Какие вопросы задать до старта?
Как понял задачу (пусть перескажет), делал ли похожее, как оценивает сроки и цену, что будет при изменениях, в каком виде результат и есть ли поддержка. Ответы важнее портфолио.
Какие красные флаги главные?
Соглашается на всё без вопросов, подозрительно низкая цена и срок, уход от конкретики, нежелание работать по ТЗ, требование всей оплаты вперёд, отсутствие реальных примеров.
Стоит ли выбирать по самой низкой цене?
Нет. Низкая цена означает срезанный объём или неопытность, и экономия оборачивается переделками. Ориентируйтесь на соотношение цены и подтверждённого качества.
Как проверить, не разбираясь в технике?
По косвенным признакам: задаёт ли вопросы, внятно ли объясняет, есть ли отзывы, соблюдал ли сроки, готов ли работать по ТЗ с оплатой по этапам. Адекватность видна по общению.
Заключение
Выбрать надёжного разработчика можно и не умея читать код — качество исполнителя проявляется задолго до первой строчки, в том, как он понимает задачу, какие вопросы задаёт и что обещает. Профессионал вникает, уточняет, обосновывает цену и сроки, готов работать по ТЗ и фиксировать договорённости. Ненадёжный соглашается на всё не глядя, манит подозрительно низкой ценой, уходит от конкретики и не хочет ничего записывать.
Грамотный заказчик не хватает самое дешёвое и не ведётся на громкие слова, а смотрит на реальный опыт с похожими задачами, отзывы прошлых клиентов и адекватность в разговоре. Чуть дороже, но один раз и хорошо — выгоднее, чем дёшево и потом ещё раз за переделку. А когда хочется выбирать из проверенных, а не наугад, проще ориентироваться на отзывы и историю сданных проектов.
Найдите разработчика на Где.Эксперт — выбирайте по реальным отзывам, обсуждайте задачу до старта и платите по факту выполнения.