Почему именно этот инструмент
Это первое и самое главное, с чего нужно начать - определить свои мотивы. Вам хочется попробовать новые технологии? Сделать свою команду более привлекательной на рынке труда? Или вы считаете, что именно это решение поможет проекту быстро стартовать и без проблем удовлетворить выставленные нефункциональные требования?
Я стараюсь посмотреть на ситуацию с двух сторон: со стороны своей команды (и своих интересов, в том числе) и со стороны заказчика (и текущего проекта). Если новый инструмент будет полезен и тем и другим - это хороший знак и можно переходить к следующему вопросу.
Если инструмент удовлетворяет интересам только одной из сторон, нужно аккуратно расставить приоритеты, исходя из требований бизнеса. Оценить возможные риски, рассмотреть доступные компромиссные решения - и только после этого двигаться дальше.
Насколько зрелый сам инструмент. Кто и как его разрабатывает
Начав использовать самый свежий, динамично развивающийся фреймворк, можно стать заложником частых изменений, критичных багов и нарушений обратной совместимости.
С другой стороны: выбор библиотеки, которая развивается на энтузиазме пары добровольцев - тоже опасная затея. Высока вероятность попасть в ситуацию, когда в продукте обнаружена критическая уязвимость, а патч приходится ждать несколько месяцев или вообще писать самостоятельно.
Фреймворк или язык программирования, который развивается и поддерживается крупной компанией - тоже не панацея от всех проблем. Часто в общий доступ выкладывают инструменты, которые используются для внутренних нужд. В этом случае в роудмапе развития продукта приоритет будет отдаваться фичам, необходимым самой компании, а не сообществу пользователей.
Чтобы ответить на этот вопрос, я собираю максимум сведений по рассматриваемому инструменту. Помимо поиска информации в сети, полезно пообщаться с людьми, которые использовали его на реальных проектах, внимательно изучить репозиторий на github, если он есть - посмотреть статистику, скорость закрытия багов, список коммитеров. Необходимо также оценить качество и доступность документации.
Кто внутри компании будет заниматься разработкой
Прежде чем сделать выбор, нужно оценить, есть ли сейчас в компании все необходимые компетенции, чтобы решать реальные задачи используя этот инструмент.
В процессе разработки сайта периодически будут возникать проблемы, с которыми вы еще не сталкивались. Если ни один инженер компании не использовал ранее этот инструмент в продакшене, то велика вероятность, что сроки проекта затянутся. А решения могут не удовлетворять выставленным заказчиком нефункциональным требованиям. Поэтому нужно четко понимать, кто будет решать технические проблемы на проекте.
Какова ситуация на рынке труда
Очень важный вопрос, о котором часто забывают при выборе инструмента. Фактически он является продолжением предыдущего. В процессе разработки может возникнуть потребность быстро масштабировать команду. Если на рынке нет подходящих специалистов или они слишком дорогие - сделать это будет непросто. Стоимость разработки будет расти, что негативно скажется на показателях бизнеса.
Отвечая на этот вопрос, я стараюсь проанализировать состояние рынка труда по основным показателям:
- стоимость специалистов;
- баланс спроса и предложения;
- динамика роста количества вакансий и соискателей на них.
Собрав эту информацию, будет проще понять, во сколько обойдется масштабирование команды, и оценить целесообразность выбора того или иного инструмента.
Как заказчик будет поддерживать готовый продукт?
Если у заказчика есть inHouse-команда разработки, необходимо подумать от том, кто и как будет поддерживать разработанный продукт: какой стек они используют, какой у них состав команды и т.д.
На первый взгляд это может показаться неважным. Продукт уже разработан, а что будет дальше - проблемы заказчика. Но успех заказчика, это и ваш успех тоже. Если он сможет без лишних затрат поддерживать разработанное вами решение, то наверняка вновь обратится к вам с новым проектом и порекомендует коллегам.
Мы всегда ставим в приоритет долгосрочное сотрудничество, а не сиюминутную выгоду - и такой подход дает хорошие результаты.
Заключение
Отвечая на эти вопросы, важно избегать соблазна принять желаемое за действительное. Нужно быть честным перед собой и руководствоваться только объективными данными.
Разумеется, это относится в основном к критичным архитектурным решениям в рамках проекта. Проводить подобное исследование, чтобы выбрать библиотеку для форматирования строк будет дорого и нецелесообразно (если, конечно, вы не пишете свой текстовый редактор).
А вообще, лучший способ попробовать новый язык программирования или фреймворк - реализовать какой-нибудь Proof of Concept или Pet Project (как свой личный, так и в рамках компании). Здесь критерии для выбора инструментария будут менее жесткими, а цена ошибки не так высока.
