IT рекрутинг

Выбираем инструментарий для проекта. 5 вопросов, которые следует себе задать

Почему именно этот инструмент

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

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

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

Насколько зрелый сам инструмент. Кто и как его разрабатывает

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

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

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

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

Кто внутри компании будет заниматься разработкой

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

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

Какова ситуация на рынке труда

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

Отвечая на этот вопрос, я стараюсь проанализировать состояние рынка труда по основным показателям:  

  • стоимость специалистов;

  • баланс спроса и предложения;

  • динамика роста количества вакансий и соискателей на них.

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

Как заказчик будет поддерживать готовый продукт?

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

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

Мы всегда ставим в приоритет долгосрочное сотрудничество, а не сиюминутную выгоду - и такой подход дает хорошие результаты.

Заключение

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

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

А вообще, лучший способ попробовать новый язык программирования или фреймворк - реализовать какой-нибудь Proof of Concept или Pet Project (как свой личный, так и в рамках компании). Здесь критерии для выбора инструментария будут менее жесткими, а цена ошибки не так высока.