[Из песочницы] Выбор технологии как инвестиция

habralogo.jpg

Откуда это все


Последние 6 лет я руковожу разработкой. Последние три года еще и консультирую. И, разумеется, постоянно сталкиваюсь с вопросами типа «на каком языке писать будем?» или «какую БД будем использовать?». Хорошо, когда ответы на такие вопросы продиктованы предметной областью проекта. Понятно, что PHP для драйвера не подходит, а С++ для бэкенда промо-лендинга — абсурд. Это сужает выбор. Но в оставшемся выборе часто громоздится целый «Ноев ковчег» языков, решений, фреймворков и платформ, где каждой твари далеко не по паре.


В прошлой жизни, когда я был простым линейным программистом или лидом, меня это не волновало. Вот это я знаю хорошо, и мне нравится на этом писать. Вот про это читал много хороших отзывов, и мне интересно. А вот это мы как-то пробовали, получилось ужасно, поэтому зарекся. В мою ответственность входило только качество кода, который я выдаю, и персональный дедлайн. С ростом зоны ответственности стали добавляться новые очаги головной боли: качество кода команды в целом, скорость накопления технического долга, пользовательские характеристики продукта и многое другое. Но в тот год, когда я впервые был назван СТО, появилось самое больное место — бюджет. Я внезапно осознал, что вся, повторю, вся без исключения разработка программных продуктов — она про деньги. Даже если ты в деревне у бабушки на старом ноуте по GPRS от скуки контрибьютишь в никому не нужный маргинальный проект очередного ЭЯП. Время — деньги, популярность — деньги, качество кода — деньги, способность укладываться в дедлайны — деньги, точность прогноза трудозатрат — деньги…


А про деньги человечество накопило немало знаний. Так отчего ими не пользоваться? Для меня этот поход был и остается совершенно логичным и естественным, но каждый раз я сталкиваюсь с разной степени удивлением как от менеджмента (в меньшей степени), так и от разработчиков при объяснении своего выбора.


Выбор это инвестиция


Не думаю, что стоит раскрывать аксиому подзаголовка подробно. От выбора технологии зависит бюджет, сроки и конечная себестоимость продукта. Этого достаточно.
Вся тонкость в термине «инвестиция».


Инвести́ции (англ. Investments) — размещение капитала с целью получения прибыли. Инвестиции являются неотъемлемой частью современной экономики. От кредитов инвестиции отличаются степенью риска для инвестора (кредитора) — кредит и проценты необходимо возвращать в оговорённые сроки независимо от прибыльности проекта, инвестиции (инвестированный капитал) возвращаются и приносят доход только в прибыльных проектах. Если проект убыточен — инвестиции могут быть утрачены полностью или частично. Википедия

Проштудировав горы литературы по инвестициям я понял одно — 99.9% этой информации самоочевидна и никакой rocket sciense тут нет. Но основная масса людей попросту игнорирует все эти самоочевидные и банальные вещи, и фокус не в том, чтобы знать это. Фокус в том, чтобы постоянно об этом помнить.


Суть инвестиций проста: вложить ресурсы (деньги, время, усилия) в проект, чтобы получить от проекта некоторую ценность. Ценностью может быть прибыль. Или знание. Или удовольствие. Главное правильно для себя эту ценность определить. В случае с коммерческой разработкой с определением ценности вопросов нет — это деньги. Поэтому ключевой вопрос ценности в определении инвестиционной привлекательности тут не стоит.


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


Прибыли и риски


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


Любой проект имеет две составляющие с точки зрения инвестиций: размер вложений и прогнозируемый размер прибыли… с учетом рисков. Про риски часто или забывают полностью, или не сильно углубляются в их оценку. А зря. Потому что именно риски в первую очередь определяют инвестиционную привлекательность проекта.


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


Оценка этих самых рисков


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


Взять тот же С++ и PHP. Очевидно, что при одинаковом функционале продукт на первом будет производительнее продукта на втором. Но обойдется много дороже и по времени, и по зарплатам. И тут не надо считать до копейки, до дня и до уника в сутки насколько, чтобы понять: бэкенд промолендинга на С++ не интересен.


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


Риски персонала


Сроки поиска — насколько рынок труда наполнен CV искомого уровня. Программиста на COBOL придется искать долго и дорого, и срок его поиска имеет огромную дисперсию. Можно найти за месяц, а можно не найти и за год. И каждый день просрочки в найме снижает возвратную ценность проекта.


Экспертиза найма — насколько адекватно наниматель в состоянии оценить кандидата. Это сложный риск, в него входит не только уровень экспертизы нанимателя в технологии по кандидату, но и сложившиеся в комьюнити этой технологии традиции (да, одни специалисты склонны к дезинформации более, чем другие), а так же размер этой технологии — «я хорошо знаю С++» и «я хорошо знаю PHP» два совершенно разных по силе утверждения. Этот риск влияет как на затраты по найму — отсев непригодных, составление оценочных схем и т.д. — так и на конечную ценность (наняли не того).


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


Владение кодом — насколько потенциально травматично для проекта внезапное исчезновение разработчика. Тут учитывается и наполненность рынка труда, и сложность восприятия кода (perl -e '$? s:; s: s;;$?:: s;;=]=>%-{<-|}<&|{;; y; -/:-@[-{-};`-{/» -;; s;;$_; see'), и многое другое.


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


Стратегические риски


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


Размер сообщества — перекликается с рисками персонала, но тут присутствует в другом аспекте: размер комьюнити, как правило, влияет на количество контрибьюторов. Чем больше контрибьюторов, тем больше труда потрачено на улучшение технологии.


Стабильность — состоит из стабильности технологии и стабильности комьюнити. Если в истории технологии было несколько «ересей Хоруса», то ожидать от такой технологии тихой гавани в будущем не приходится. Если комьюнити постоянно сегментируется, если новые версии не совместимы со старыми и по сути являются совсем другим продуктом, то такая технология интересна лишь на очень коротких отрезках.


Целостность — насколько целостна технология, насколько четко сформулированы основные концепции и насколько их разделяет и комьюнити, и комьюнити сателлитных технологий/подтехнологий. Насколько консистентна документация и база знаний. Если у фреймворка вместо документации — куцая вики на гитхабе с не всегда актуальными сведениями, а основное знание распределено по сотням роликов на ютубе, которые друг другу местами противоречат в описании подходов и смыслов, то о целостности тут говорить не приходится.


Порог вхождения — насколько человеку с нулевым уровнем владения данной технологии сложно и дорого выйти на приемлемое владение. Да, почти всегда риски персонала выливаются в потребность/целесообразность такого [пере]обучения.


Итого


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

Комментарии (0)

© Habrahabr.ru