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

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

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

И действительно, после аудита кода такого брошенного проекта открывается куча проблем:

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

Доработать можно, но это будет дорого и долго. В итоге основной бюджет уже потрачен, на доработку или новую разработку с нуля денег уже нет. Проект замораживается. Пока собираются или копятся деньги на повторную разработку на рынке уже появляются конкуренты. Стартап умер еще не родившись.  И кто виноват? Первый разработчик? Частично. Но на самом деле главная причина в том, что процесс подбора специалиста и контроль работы разработчика был выстроен неправильно. Поэтому я сейчас расскажу как надо делать по уму на основе опыта работы в успешных IT компаниях.

Для начала объективно оцените сложность проекта и на сколько он будет длительным. 

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

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

Поэтому я обычно рекомендую делать так:

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

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

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

2. Опубликовать объявления о поиске разработчика.

Тут в целом все просто, думаю справитесь :)

3. Отобрать несколько разработчиков, каждому дать небольшое ОПЛАЧИВАЕМОЕ ТЕСТОВОЕ задание.

Почему так? Исполнитель, который откликнулся на ваше объявление может хорошо и красиво говорить, но плохо делать. Для того, чтобы из нескольких выбрать самого качественного, предварительно нужно проверить как разработчик пишет код.

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

4. Выбираем исполнителя и начинаем с ним работу

После того, как выбрали исполнителя, договариваемся с ним об условиях работы.  Обычно я рекомендую работать недельными спринтами, где в конце неделе эксперт-разработчик проверяет работу исполнителя независимо от его уровня. ( Да, работу Senior специалистов тоже нужно контролировать иначе есть немалый риск, что разработчик будет работать спустя рукава )  Такая практика проверки кода называется code-review. 

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

Преимущества Code Review:

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

В итоге благодаря контролю качества кода проект легко поддерживать и развивать, а также передавать его другим разработчикам. Такая практика используется во многих компаниях, в том числе и крупных, что помогает поддерживать качество проекта. И даже если потом выбранный исполнитель по каким-то причинам покинет проект, другому разработчику будет легко разобраться в проекте и продолжить его разработку. Обычно для code-review используют Github.

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

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

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

Я возможно смогу сам взяться если ваш проект связан с веб-разработкой, либо посоветую кого-либо из своих знакомых, кто сможет вам помочь. Также могу помочь с выбором технологий или подробнее проконсультировать по процессу, для консультации пишите в телеграм https://t.me/alexbelousov92 Другие мои контакты можно найти в профиле :)