Почем инструментик?

Когда человек выбирает дрель, чтобы насверлить дырок в стенах и повесить полочки, один из первых вопросов - "сколько стоит?" Но когда выбираются инструменты под it-шный проект, об этом вопросе часто вообще забывают. А ориентируются на громкие слова (типа "enterprise - технология"), или на соседа, "у которого так работает, что прямо летает".

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

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

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

Выделим три категории. Первая - "свойства инструмента".

• Прозрачность.
• Надежность.
• Требования к ресурсам.

Вторая - "свойства проекта".

• Длительность проекта.
• Длительность сопровождения получившейся системы.
• Доля специфичных для проекта знаний. "Локальные компетенции".
• Изменчивость проекта.

Третья - пересечение первой и второй.

• "Паразитный функционал".

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

Начнем подробный разбор с последнего, именно потому, что он имеет отношение и к проекту и к инструменту.

Паразитный функционал

Существует мнение, что если взять большой, мощный и продвинутый инструмент (библиотеку, фреймворк), то в нем уже все есть, и разрабатывать потребуется очень мало или вовсе ничего. Так, доточить самую малость. В других областях бизнеса подобная "жадность" корректируется ценой. Но не в IT. Код, как известно, копируется. Копирование - дешевый процесс. В результате фирмы-производители тиражных инструментов могут очень гибко играть ценой. А еще есть сообщество freeware, где инструменты вообще бесплатны. Вот и возникает соблазн ухватить сразу "что потолще", на вырост. Только так ли уж бесплатны "бесплатные" инструменты?

Несколько составляющих цены любой может назвать сразу:

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

Уже, немало, но еще не все. Разработчикам придется еще потрудиться, чтобы отключить этот ненужный функционал. Как минимум, ставить заглушки. Достаточно неприятная работа, отрицательно влияющая на мотивацию. А если у инструмента еще и не все ладно с архитектурой, то в ходе проекта еще долго придется натыкаться на сюрпризы, когда без чего-то вам вовсе не нужного что-то "нужное" не работает.

Предположим вам надо 30 конкретных единиц функционала (дальше буду называть их "фичами") и есть две библиотеки программного кода. Первая содержит 20 фич и они все вам нужны, а вторая - 100, среди которых и 30 нужных в вашем проекте. Понятно, что в первом случае 10 недостающих фич вашим разработчикам придется дописать самим. Во втором - ничего дописывать не нужно, но вот разобраться придется со всей сотней и отключить 70 ненужных, чтобы не мешали. Что обойдется дешевле - вопрос.

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

Прозрачность

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

Если коэффициент прозрачности равен или меньше единицы, то мы имеем дело с "write only" инструментом. А по-русски: "проще выкинуть". Среди старых технологий такая ситуация вовсе не редка. Собственно, именно в росте этого коэффициента сильнее всего проявляется развитие IT-отрасли. Многие из созданных в последние годы инструментов дают коэффициент прозрачности около четырех, а грамотным документированием его можно еще повысить. (Правда, документирование тоже "стоит денег" так что тут надо искать разумный оптимум. Но этот вопрос относится больше к управлению проектом, а не к первоначальному выбору инструмента.)

Надежность

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

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

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

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

Требования к ресурсам

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

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

Мне приходилось встречать мнение, что за время разработки проекта техника шагнет вперед, границы раздвинутся, и на их нынешнее положение можно не обращать внимания. Сколько-то лет назад это было верно, но в нынешнее время ситуация изменилась. Например, скорость отдельного ядра процессора уже не растет так, раньше. А "многоядерность" надо еще уметь использовать, и ее не все инструменты поддерживают. Ориентация на "будущее железо" связана с большими рисками, и требует отдельного рассмотрения. Тогда как границу для существующего "железа" прикинуть достаточно просто - посмотреть приложения, сделанные с помощью интересующих вас инструментов. Тогда лучшие из них - то, чего вы можете достичь.

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

Длительность проекта и длительность сопровождения

Два параметра, про которые я не стану писать подробно. И так понятно, как они входят в стоимость. Замечу лишь, что "длительность проекта" еще будет упомянута в разделе про обучение разработчиков, а "длительность сопровождения" входит в стоимость аренды "железа" в облачных приложениях.

Локальные компетенции

Итак, новые инструменты обеспечивают хороший "коэффициент прозрачности" и использование особенностей современного "железа" (той же многоядерности)... Но сразу возникает вопрос: "Где взять программистов?" Для совсем новых и мало распространенных инструментов единственный реальный путь - учить. Дорого это или нет? Посчитаем.

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

Примечание: Библиотечки, которые можно изучить за день, я тут не рассматриваю, поскольку мы говорим о комплексных инструментах, достаточных для самостоятельного проекта. Что касается тех, что требуют годичного изучения, такое время связано прежде всего с количеством фич, включенных в них. Смотрим выше про "паразитный функционал"...

Кроме первичного обучения, есть еще одна составляющая. Предположим, у нас проект сроком в пару лет, и над ним уже ведется работа в течение года. Тогда при коэффициенте прозрачности "4", мы имеем три месяца на вхождение нового человека в проект, даже если он уже знает инструмент. Это "локальная компетенция" проекта.

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

Далее предположим, что мы взяли компактный, удобный и современный, но редко используемый инструмент со сроком обучения в три месяца. Но мы ведь можем учить его не на абстрактных примерах, а прямо на нашем конкретном проекте. Тогда сроки частично перекрываются и вместо трех месяцев на освоение инструмента плюс три месяца на вхождение в проект мы получим примерно четыре месяца на все. Итак, за использование "редкого и экзотичного" инструмента мы платим в этом случае дополнительным месяцем обучения. Если при этом удается, например, повысить коэффициент прозрачности вдвое, то этот месяц уже окупается.

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

Изменчивость проекта

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

Важно, насколько она меняется. Какая часть функционала будет переделываться ежемесячно? Может оказаться, что очень большая. Особенно значимо это для стартапов, где раз в несколько месяцев проект может полностью менять свои цели. В какие сроки, в какие деньги это выльется? Естественный вопрос инвестора и менеджера.

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

Троеточие

Я упомянул, естественно, далеко не все параметры, влияющие на выбор технологий в проекте. Но наиболее значимые из них на этапе выбора инструмента. (Напомню: в условиях разработки "с нуля".)

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