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

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

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

Вот полный подход, который, по моему мнению, работает лучше всего…

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

Вот несколько вопросов, которые откроют диалог:

  1. Как вы структурировали свои контракты с бывшими клиентами? Это может многое рассказать вам о том, как разработчик думает о своих рабочих отношениях с вами. Быть консультантом — это не просто быть разработчиком. Это требует глубокого внимания и понимания потребностей клиента, а не только создания наиболее технологически продвинутых приложений. Если подрядчик не сосредоточился на соображениях клиента о неприятии риска при составлении контракта, то почему бы и нет? Если у разработчика в прошлом не было структурированных контрактов или если идея ему чужда, это намек на то, что для него это несерьезный бизнес, а скорее хобби или побочный проект. Быть таковым не является хорошим признаком того, что человек будет предан завершению вашего проекта, создавая его с помощью отличных концепций разработки, выбирая лучшие технологические решения, основанные на ВАШИХ потребностях, а не на своем собственном желании поиграть с новыми технологиями, или ясно общаться. с вами в прогрессе.
  2. Поговорите со мной о структуре общения, которая у вас была в прошлом с вашими клиентами, и о структуре, которую вы хотели бы иметь. Это отличный показатель того, понимает ли человек, что проект касается вас, и создает ли он технологию в соответствии с вашими конкретными пожеланиями, а не берет проект и принимает собственные решения, не учитывая ваши потребности. Разработчик много раз полагал, что сама технология - единственная работа. Такого никогда не бывает. Подробнее об этом я рассказываю в своей статье Где бизнес встречается с технологиями. Без четкой коммуникационной структуры время разработки может начать увеличиваться, поскольку разработчик встраивает ненужный код, создает функции, о которых вы не просили, создает функции в соответствии с предполагаемыми спецификациями, которые необходимо переработать, и многое другое.
  3. Вы работали по установленному списку подробных задач, которые нужно выполнить? Это еще один отличный способ увидеть, на что будет похожа работа с этим разработчиком. Если разработчик говорит вам, что ему не нужно много деталей, это, как правило, признак того, что он либо раньше не занимался внештатным проектом, либо не понимает, что самый важный человек, управляющий функциями вашего приложения, — это вы. Всем разработчикам необходимо задавать множество вопросов по множеству различных деталей, чтобы иметь возможность знать, что включить в свое приложение, а на что не тратить время. Нет одинаковых приложений. Например, если разработчик создал приложение для электронной коммерции, это не означает, что все функции и детали другого приложения для электронной коммерции будут такими же или даже необходимыми. Все зависит от конкретной потребности бизнеса.
  4. Какую технологию вы бы выбрали для проекта? Остерегайтесь быстрых ответов на этот вопрос. Многие разработчики просто рекомендуют технологию, с которой они работали в прошлом, так как с ней будет проще всего работать. И, по статистике, это будет не лучшая технология для того, что нужно вашему проекту. Ищите здесь обсуждение, в котором сравниваются различные языки, фреймворки и т. д. и выясняется, почему выбранный из них лучше всего подходит для вашего бизнеса. Это также отличный знак, если разработчик говорит, что свяжется с вами по этому поводу, поскольку это решение не простое и гораздо лучше руководствоваться предварительными исследованиями и размышлениями.
  5. Если вы раньше не работали с этой технологией, беспокоитесь ли вы о том, что она может повлиять на проект, и как вы подойдете к кривой обучения? Это один из моих любимых вопросов. Там витает идея, что изучение языка программирования похоже на изучение такого языка, как испанский. На самом деле различий гораздо больше, чем сходств. Чтобы объяснить это, потребовалось бы гораздо больше, чем простое сравнение. Однако самый важный вывод заключается в том, что опытному разработчику, владеющему более чем тремя языками в своем арсенале, потребуется довольно короткое время, чтобы освоить новый язык. Между языками программирования есть много общего, и после того, как вы выучите несколько, вам будет намного легче освоить другой. У нового же разработчика просто не будет опыта, чтобы быстро и успешно освоить новый язык. Прислушайтесь к уверенности, когда ваш потенциальный фрилансер ответит на этот вопрос. Прислушивайтесь к тому, делали ли они это в прошлом, и абсолютно не беспокойтесь о приобретении нового опыта. Прислушивайтесь к структурированному подходу и к изучению нового языка. Если они успешно делали это много раз в прошлом, у них определенно есть структура, в которой они уверены.
  6. Хотели бы вы сделать небольшой проект? Что приводит нас к следующему разделу.

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

3) Работая с потенциальным разработчиком над этим небольшим проектом, используйте это время, чтобы оценить рабочие отношения. Измерьте коммуникативные навыки, которые включают в себя то, насколько хорошо консультант объясняет проблемы проекта, сроки, достигнутые вехи и т. д. Ваш разработчик должен быть готов объяснить все, о чем вы просите, потому что он будет единственным контактным лицом для вашей технологии. Эти предварительные беседы станут хорошим предзнаменованием того, как будет развиваться ваша структура общения. Захотят ли они описать вам технологию на каждом шагу? Будут ли они открыты и готовы обсудить препятствия, статус вашего проекта, сроки и т. д.

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

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