Выбор разработчика сайта - это сложный ответственный и стрессовый процесс. Даже для специалиста, который может определить уровень компетенций кандидата, выбор разработчика порой заканчивается ошибкой.
Разумеется, нет универсальной методики, которая позволит безошибочно выбирать лучшего кандидата, но вы можете значительно минимизировать риск выбора неподходящего разработчика.
Методика создания сайта
Для начала, нужно определиться с типом проекта и необходимой для него технической базы. Соответственно, разработчика нужно выбирать для работы именно в выбранном сегменте.
Можем выделить 4 методики создания сайта:
- SaaS-конструкторы.
Это система, которую вы можете получить в аренду по подписке. К недостаткам таких движков можем отнести то, что система не становится вашей и вы не можете ее дорабатывать.
К преимуществам отнесем возможность очень быстрого старта, готовый и качественный базовый функционал, в краткосрочной перспективе экономически выгодно.
Такая методика подойдет для краткосрочных проектов и для временного быстрого решения, пока реализуется более сложный вариант. - Конструкторы на базе коробочных CMS + плагины и шаблоны.
Суть этой методики заключается в сборке сайта из готовых частей на базе полноценной CMS.
К преимуществам можно отнести относительно невысокую стоимость и сроки реализации, хотя, порой можно встретить непомерно высокие цены такой реализации. К недостаткам отнесем крайне низкое техническое качество, детально мы писали об этом в статье “Шаблонный дизайн сайта. Что это такое и стоит ли использовать?”.
Такая методика используется чаще всего. Есть иллюзия того, что это золотая середина межды первым и третьим пунктом. Но это не так. Эту методику я бы не советовал использовать любому типу проекта. - Разработка на базе коробочных CMS.
Суть этой методики заключается в использовании готовой CMS как базы и индивидуальная доработка системы под требования проекта.
К преимуществам отнесем широкие возможности кастомизации и затачивания функционала под потребности проекта. К недостаткам относится ограниченность масштабирования, поскольку коробочные CMS приспособлены под большие нагрузки.
Такая методика подойдет для подавляющего большинства проектов. - “Самописная” (уникальная) система.
Такие системы создаются специально под проект с учетом индивидуальных особенностей и потребностей.
Список преимуществ таких систем можно описывать бесконечно, или можно сказать, что система именно такая как вам нужно, она максимально удобна и в ней нет ничего лишнего. К минусам отнесем стоимость индивидуальной разработки CMS и срок реализации проекта.
Разрабатывать свою CMS стоит проектам, которые готовятся под большие нагрузки или в них планируется большой процент уникального функционала.
С каждой методикой работают разработчики разного уровня квалификации. Также сильно отличается степень ответственности, которую может взять на себя разработчик. Например, если у вас методика второго типа и вы платите своему разработчику за установку какого-то плагина, то он может отвечать только за правильность установки. Если плагин работает не правильно, то ответственность за это лежит на авторе плагина, а не на установщике.
У сайтов построенных на разных методиках разный срок жизни.
С SaaS-конструкторами об этом можно не думать, поскольку все технические проблемы лежат на авторах и вы своей абонплатой оплачиваете поддержание системы в актуальном состоянии.
Средний срок жизни коробочных движков составляет 3-5 лет. Дальше система устаревает как морально так и технически и становится уязвимой. А учитывая популярность коробочных систем и активность попыток их взлома, держать проект на уязвимой системе может быть крайне рискованно.
У самописных движков срок жизни может составлять 10-15 лет, при условии проведения плановых модернизаций.
Выбор типа движка и методики разработки является долгосрочным и стратегическим решением. И понимание разницы разных методик уже упрощают нам выбор. Очевидно, что нам не нужен хороший программист для работы с конструкторами, и также очевидно, что ни один крупный проект не может быть реализован на не специализированной системе людьми, которые не понимают технические тонкости работы разных узлов системы.
Студия или фриланс?
Между студиями и фрилансерами может быть множество отличий. Рассмотрим некоторые из них.
При выборе между фрилансером и студией важно учесть свои конкретные потребности, цели и бюджет.
Анализ портфолио разработчика
Какие выводы можно сделать просматривая портфолио разработчика? Вы можете определить нравится ли вам конкретный сайт, но это не многое говорит о самом разработчике. Не зная какая была поставлена задача и какой был бюджет, нельзя сказать, хорошо ли разработчик справился с задачей.
Заказчики вносят свои пожелания и правки в сайт. Они могут сделать сайт хуже, а могут и лучше. И если вам понравился какой-то сайт, то может оказаться, что вам понравились именно идеи заказчика, а не разработчика.
Также не стоит забывать, что не обязательно всю работу делает один разработчик. Иногда, дизайн заказывают в одном месте, а техническую работу в другом. В итоге, сайт в портфолио может иметь частичное отношение к разработчику.
Технический уровень разработчика вы в принципе не сможете определить по портфолио, если вы сами не специалист.
Если вам в портфолио понравился какой-то сайт и хотите, чтобы над вашим проектом работал тот же автор, то поинтересуйтесь у разработчика, работает ли еще в команде автор понравившейся вам работы и может ли именно он заняться вашим проектом.
Не будет лишним попробовать связаться с владельцами сайтов из портфолио, чтобы попросить отзыв о разработчике.
Выбор разработчика по стоимости
Вероятно, это самый сложный и противоречивый критерий оценки разработчика сайта.
Вряд ли кто-то хочет, чтобы над его проектом работал самый дешевый разработчик. Тем не менее, у любого проекта есть бюджетные ограничения и их нельзя игнорировать.
Проблема в том, что для того, чтобы получить адекватную оценку работ от разных разработчиков, каждому из них необходимо предоставить на оценку детально описанное задание. В противном случае, при оценке, каждый разработчик будет додумывать задачу. В результате, вы получите оценки абсолютно разных проектов.
Потому, вариантов тут не много, нужно либо детально прорабатывать задачу до оценки либо изначально сообщать разработчику желаемый бюджет и просить детально расписать то, что он в рамках этого бюджета сможет предложить.
Как определить технический уровень разработчика?
К сожалению, быстро определить технический уровень разработчика сложно даже для специалиста.
Но вы можете обратить внимание на несколько нюансов, которые косвенно намекают на то, что разработчик не совсем новичок.
Спросите, могут ли вам написать функционал на заказ. Например, фильтр товаров. Если разработчик может сделать это без проблем, это свидетельствует о его способности работать с кодом, а не только устанавливать готовые модули. А фильтр - это один из сложнейших элементов интернет-магазина, для того чтобы написать даже плохой фильтр нужны навыки немного выше нуля.
Спросите, работает ли разработчик с чужим кодом. Доработка сайтов других авторов составляет не менее половины всех работ опытных разработчиков. Если для кого-то работа с чужим кодом составляет проблему, то это намекает на низкую квалификацию такого разработчика. Конечно, это не касается отказов работать с экзотическим кодом конкретного сайта.
Спросите, занимается ли разработчик созданием “самописных” сайтов. Для того, чтобы написать свой движок, необходим уровень разработчика выше среднего.
А еще можете поинтересоваться, какой средний срок сотрудничества с клиентами. Если этот срок измеряется годами, то это может говорить о том, что текущие клиенты довольны сотрудничеством.
Таким образом, обратив внимание на эти аспекты, вы можете более точно оценить технический уровень разработчика.