Откуда это все
Последние 6 лет я руковожу разработкой. Последние три года еще и консультирую. И, разумеется, постоянно сталкиваюсь с вопросами типа "на каком языке писать будем?" или "какую БД будем использовать?". Хорошо, когда ответы на такие вопросы продиктованы предметной областью проекта. Понятно, что PHP для драйвера не подходит, а С++ для бэкенда промо-лендинга — абсурд. Это сужает выбор. Но в оставшемся выборе часто громоздится целый "Ноев ковчег" языков, решений, фреймворков и платформ, где каждой твари далеко не по паре.
В прошлой жизни, когда я был простым линейным программистом или лидом, меня это не волновало. Вот это я знаю хорошо, и мне нравится на этом писать. Вот про это читал много хороших отзывов, и мне интересно. А вот это мы как-то пробовали, получилось ужасно, поэтому зарекся. В мою ответственность входило только качество кода, который я выдаю, и персональный дедлайн. С ростом зоны ответственности стали добавляться новые очаги головной боли: качество кода команды в целом, скорость накопления технического долга, пользовательские характеристики продукта и многое другое. Но в тот год, когда я впервые был назван СТО, появилось самое больное место — бюджет. Я внезапно осознал, что вся, повторю, вся без исключения разработка программных продуктов — она про деньги. Даже если ты в деревне у бабушки на старом ноуте по GPRS от скуки контрибьютишь в никому не нужный маргинальный проект очередного ЭЯП. Время — деньги, популярность — деньги, качество кода — деньги, способность укладываться в дедлайны — деньги, точность прогноза трудозатрат — деньги…
А про деньги человечество накопило немало знаний. Так отчего ими не пользоваться? Для меня этот поход был и остается совершенно логичным и естественным, но каждый раз я сталкиваюсь с разной степени удивлением как от менеджмента (в меньшей степени), так и от разработчиков при объяснении своего выбора.
Выбор это инвестиция
Не думаю, что стоит раскрывать аксиому подзаголовка подробно. От выбора технологии зависит бюджет, сроки и конечная себестоимость продукта. Этого достаточно.
Вся тонкость в термине "инвестиция".
Инвести́ции (англ. Investments) — размещение капитала с целью получения прибыли. Инвестиции являются неотъемлемой частью современной экономики. От кредитов инвестиции отличаются степенью риска для инвестора (кредитора) — кредит и проценты необходимо возвращать в оговорённые сроки независимо от прибыльности проекта, инвестиции (инвестированный капитал) возвращаются и приносят доход только в прибыльных проектах. Если проект убыточен — инвестиции могут быть утрачены полностью или частично. Википедия
Проштудировав горы литературы по инвестициям я понял одно — 99.9% этой информации самоочевидна и никакой rocket sciense тут нет. Но основная масса людей попросту игнорирует все эти самоочевидные и банальные вещи, и фокус не в том, чтобы знать это. Фокус в том, чтобы постоянно об этом помнить.
Суть инвестиций проста: вложить ресурсы (деньги, время, усилия) в проект, чтобы получить от проекта некоторую ценность. Ценностью может быть прибыль. Или знание. Или удовольствие. Главное правильно для себя эту ценность определить. В случае с коммерческой разработкой с определением ценности вопросов нет — это деньги. Поэтому ключевой вопрос ценности в определении инвестиционной привлекательности тут не стоит.
И да, жизненный цикл технологии в вашем замечательном проекте площадки по продаже ошейников ручной работы для хомячков — это проект внутри проекта. Со всеми вытекающими.
Прибыли и риски
Оценка инвестиционной привлекательности всегда сравнительна. Нет попугаев, в которых можно измерить сферический в вакууме проект с точки зрения инвестиций. Да, даже если проект всего один, и стоит выбор инвестировать или нет. Потому что в этой ситуации проектов на самом деле два, всегда есть проект "держать деньги под подушкой".
Любой проект имеет две составляющие с точки зрения инвестиций: размер вложений и прогнозируемый размер прибыли… с учетом рисков. Про риски часто или забывают полностью, или не сильно углубляются в их оценку. А зря. Потому что именно риски в первую очередь определяют инвестиционную привлекательность проекта.
В случае с выбором технологи все ровно точно так же. Поэтому выбор технологии, кроме осознания желаемой ценности, выливается в оценку рисков этого выбора. Ну хорошо, ладно, еще есть фактор размера вложений, да.
Оценка этих самых рисков
Вся трудность оценки инвестиционной привлекательности вообще и оценки рисков в частности заключается в приведении величин к единому базису(деньгам) с достаточной точностью. Большинство формул, используемых экономистами для этих оценок, лично меня как математика приводят в ужас. Взять тот же ROI, который с приемлемой точностью можно посчитать только постфактум. С другой стороны, точность сравнительной оценки двух величин зависит от близости значений этих двух величин, и далеко не всегда надо знать сколько километров до границы и сколько до ближайшего гастронома, чтобы сравнить эти расстояния.
Взять тот же С++ и PHP. Очевидно, что при одинаковом функционале продукт на первом будет производительнее продукта на втором. Но обойдется много дороже и по времени, и по зарплатам. И тут не надо считать до копейки, до дня и до уника в сутки насколько, чтобы понять: бэкенд промолендинга на С++ не интересен.
Но дело даже не в точности оценки конкретных характеристик. В приведенном примере вообще ни слова про риски. Дело в как можно более полном факторном анализе всех рисков. Для себя я составил довольно полный, на мой взгляд, но не исчерпывающий список.
Риски персонала
Сроки поиска — насколько рынок труда наполнен CV искомого уровня. Программиста на COBOL придется искать долго и дорого, и срок его поиска имеет огромную дисперсию. Можно найти за месяц, а можно не найти и за год. И каждый день просрочки в найме снижает возвратную ценность проекта.
Экспертиза найма — насколько адекватно наниматель в состоянии оценить кандидата. Это сложный риск, в него входит не только уровень экспертизы нанимателя в технологии по кандидату, но и сложившиеся в комьюнити этой технологии традиции (да, одни специалисты склонны к дезинформации более, чем другие), а так же размер этой технологии — "я хорошо знаю С++" и "я хорошо знаю PHP" два совершенно разных по силе утверждения. Этот риск влияет как на затраты по найму — отсев непригодных, составление оценочных схем и т.д. — так и на конечную ценность (наняли не того).
Дисциплина — не секрет, что в разных технологиях разный уровень дисциплины кода как продиктованный самой технологией (привет, JavaScript!), так и традициями профессионального сообщества. Обеспечение запланированного уровня дисциплины — это будущие затраты на менеджмент.
Владение кодом — насколько потенциально травматично для проекта внезапное исчезновение разработчика. Тут учитывается и наполненность рынка труда, и сложность восприятия кода (perl -e '$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|{;;y; -/:-@[-{-};`-{/" -;;s;;$_;see'), и многое другое.
Динамика сообщества — устойчивое или растущее сообщество подразумевает более-менее уверенность в состоянии рынка труда в будущем. Хотя, конечно, известны случаи, когда сообщества схлопывались в считанные месяцы.
Стратегические риски
Зрелость технологии — как правило(но не всегда) технология, существующая десятки лет и пробежавшая по множеству граблей, более устойчива, стабильна и надежна. И в этом смысле часто лучшее действительно враг хорошего.
Размер сообщества — перекликается с рисками персонала, но тут присутствует в другом аспекте: размер комьюнити, как правило, влияет на количество контрибьюторов. Чем больше контрибьюторов, тем больше труда потрачено на улучшение технологии.
Стабильность — состоит из стабильности технологии и стабильности комьюнити. Если в истории технологии было несколько "ересей Хоруса", то ожидать от такой технологии тихой гавани в будущем не приходится. Если комьюнити постоянно сегментируется, если новые версии не совместимы со старыми и по сути являются совсем другим продуктом, то такая технология интересна лишь на очень коротких отрезках.
Целостность — насколько целостна технология, насколько четко сформулированы основные концепции и насколько их разделяет и комьюнити, и комьюнити сателлитных технологий/подтехнологий. Насколько консистентна документация и база знаний. Если у фреймворка вместо документации — куцая вики на гитхабе с не всегда актуальными сведениями, а основное знание распределено по сотням роликов на ютубе, которые друг другу местами противоречат в описании подходов и смыслов, то о целостности тут говорить не приходится.
Порог вхождения — насколько человеку с нулевым уровнем владения данной технологии сложно и дорого выйти на приемлемое владение. Да, почти всегда риски персонала выливаются в потребность/целесообразность такого [пере]обучения.
Итого
Перечисленные риски присутствуют при выборе практически любого размера из значимости технологий, от языков программирования и фреймворков до библиотек и утилит. Разумеется, каждый из них в каждом отдельном случае имеет свою значимость, но учитывать их все стоит всегда. Разумеется список не полный, и я не претендую на абсолютную истину, но именно этот список помогает лично мне в непростом деле управления разработкой.
Автор: dualavatara
