Один нюанс при выборе технологического решения

– Запилим сервис сами или купим облачный?
– Построим платформенное решение на три команды или разрешим каждой делать своё?
– Напишем сервис на node.js или python?
– ...

Когда руководители принимают "большие" инженерные решения, велик риск построить обоснование только на инженерных аргументах.

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

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

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

Такой сервис, теоретически, возможно запилить за квартал, есть даже команда, которая такое смогла. Но насколько твоя команда похожа на неё?

Обобщенную библиотеку и правда можно написать. Но в каких отношениях находятся лиды, которые будут ее испольовать?

––

Серьезных инженерных решений, не накладывающих серьезных требований на команду, почти не бывает. Если подходящих у тебя нет и нет возможности быстро их собрать – незазорно выбрать решение не только на технологических аргументах (Инстаграм вот, например, долгое время был написан на Django – и ничего :)).

// ровно по этой причине я, при запросе на аудит, обычно стараюсь глубоко поковырять как в tech, так и в людях в компании