Начиная проект, можно сфокусироваться исключительно на технической стороне и придумать гениальное решение, лучшее на рынке. Вот только позже выяснится, что общая величина затрат на IT-инфраструктуру, делает внедрение невыгодным для бизнеса. Хорошо, если об этом узнали на этапе планирования.
И здесь РМ или ВА очень помогли бы заказчику, если бы сделали предварительный расчет стоимости владения (ТCO — total cost of ownership).
Техническая экспертиза пригодится менеджеру не только для расчета TCO. Понимание архитектуры проекта позволит избежать лишних расходов на этапе планирования, поможет принять решение о внедрении новых фич.
В статье собрали практические рекомендации из вебинаров наших спикеров, которые помогают РМ-ам, продактам и бизнес-аналитикам разбираться в архитектуре проекта на курсе Delivery Mind.
Развитие облачных технологий предоставило компаниям фактически безграничные ресурсы для оценки и анализа. Рост сервисов на уровне cloud computing от таких глобальных игроков как Amazon, Google, IBM, Oracle, помогает провести оценку с высоконагруженными параметрами и конфигурациями.
И тут появляется проблема: когда ресурсы не ограничены, мало кто задумывается об эффективности их использования. Услуги облачных технологий впоследствии отразятся на операционной модели, потому что через полгода ежемесячные платежи за пользование сервисом могут значительно вырасти.
Не переплачивайте за cloud сервисы
Облачные платформы дают массу преимуществ при запуске нового продукта. В течении 15 минут можно развернуть любой environment в любой точке, сразу начать свой проект и получать прибыль. Это большой плюс, но чтобы и дальше оставаться в выигрыше, нужно правильно рассчитать стоимость владения — Total cost of ownership.
Посчитайте все. Cloud провайдеры дают свои калькуляторы, но их нужно перепроверять. Иногда вы можете забыть о важном сервисе, который впоследствии скажется на производительности. В других случаях, особенно для микросервисов, запросов высоконагруженных систем, понадобятся дополнительные компоненты. Оценивайте будущую software конфигурацию на cloud ресурсах — cloud конфигурация плюс software конфигурация.
Не бойтесь находить специалистов конкретного cloud-провайдера и задавать им дополнительные вопросы. Это поможет в будущем отстоять бюджеты на поддержку и развитие данного решения в ближайшие 2-3 года.
Рассчитайте TCO. Еще один важный момент, — на какой срок рассчитывать стоимость владения, ТCO (total cost of ownership). Сегодня нет необходимости считать TCO на 5 лет, как было еще до 2010 года. Смотрите в горизонт не более 3 лет, а лучше — 1-2 года. Сейчас все меняется очень стремительно: инструменты, фреймворки, тулы, фичи. Сервисы подобные data quality и data profality в Azure, позволяют реализовывать проекты, на которые раньше уходил год, за 4 месяца.
Учитывайте ROI. Иногда при подсчете стоимости владения, придется учитывать ROI (return of investment). Например, если компания готова инвестировать в новое решение условную сумму в 100 тысяч, то каким образом и в течение какого срока эти финансы окупятся.
Облачные технологии однозначно помогают зарабатывать, но всегда нужно рассчитывать, как эффективно управлять этим инструментом с финансовой точки зрения. Иначе стоимость владения станет настолько высокой, что придется «порезать» какие-то cloud configuration. Две возможности, чтобы сэкономить на облачных сервисах, — это резервирование мощностей (reserved instance) или переход на споты.
Рассчитайте стоимость отдельных компонентов
Чтобы правильно оценить общую предварительную стоимость IT-решения, посмотрите на отдельные составляющие:
- Во сколько обойдется лицензирование компонентов. Обратите внимание, что коммерческий open source и его поддержка бывают платными, поэтому смотрите на типы лицензии.
- Какова стоимость и сроки внедрения (time to market). Это о том что, если мы вложим 100 тысяч, через какой период времени окупятся наши инвестиции. ROI нужно сопоставлять с time to market, потому что, если эти 100 тысяч будут реализованы через год, возможно, за год данный продукт или сервис потеряет актуальность.
- Какой будет поддержка. Если на уровне community, — нужно искать технический персонал соответствующей квалификации. Если при помощи платформы, — это может быть open source коммерческая поддержка.
- Отдельно просчитайте стоимость рейта внутреннего найма для специалистов на данной технологии и в нужном вам регионе. Делайте расчет не больше чем на три года.
- Проработайте cloud configuration. Начинать можно с помощью калькулятора, который предоставлен провайдером. А затем дополнительно пообщайтесь с авторизированными партнерами на предмет тех или иных сервисов. Особенно если у вас стоят вопросы про миграцию из каких-то on premise систем в cloud.
- Hardware and/or Software configuration. При замкнутой микросистеме важно оптимально подобрать нужные Hardware и Software конфигурации, решить, какие сервера купить в data центр, на каких платформах, с какими application и data base серверами, чтобы стоимость владения и обслуживания, была соизмерима с той суммой, которая будет инвестирована в ПО.
- Рассчитайте стоимость лицензирования средств разработки платных библиотек и фреймворков. Они могут стоить денег, но при этом, сократить время разработки и, соответственно, ускорить time to market.
Если все эти технические подробности выглядят слишком сложными, приходите разбираться на курс TechMind. За полтора месяца вы научитесь общаться с техническими специалистами на их языке и будете понимать, какой фреймворк и команду выбрать для проекта. А на Delivery Mind объясним, как работать с архитектурой проекта и выбирать лучшее решение для бизнес-задачи.
Фичи — внедрять или лучше не надо
Иногда менеджеры сталкиваются с соблазном внедрить набор фич или заделиверить новые, просто потому что это must, и много фич — значит больше value. Не всегда нужно следовать такому подходу, особенно, если нет целостного понимания, как должен эволюционировать продукт. Правда бывает и другая крайность: видение продукта, «вырубленное в камне», — мы должны делать только это и ничего больше.
Еще две крайности по внедрению нового функционала связаны с потребностями клиентов. В одном случае, менеджеры слишком долго анализируют рынок и упускают момент, в другом — менеджер уверен, что знает о потребностях лучше самого клиента.
Любая категоричность в вопросах внедрения фич только повредит. Поэтому проявляйте гибкость, рассматривайте вопрос с разных точек зрения. Иногда есть смысл действительно просто посмотреть со стороны: например, как человек совершает покупки.
Не ошибиться с выбором, что и когда внедрять, помогает предварительная оценка. Аналитику перед фичей можно разделить на определенные категории:
- Размер фичи, сколько времени пойдет на реализацию: день, неделя, месяц или фича такая большая, что трудно оценить размер и нужные ресурсы.
- Комплиментарность — улучшатся ли какие-то процессы, основной либо второстепенный сценарий. Возможно, в результате изменится существующий сценарий или откроется новый.
- Новизна — есть ли что-то подобное у конкурентов или идея абсолютно новая, и появилась в процессе брейншторма.
- Измеримость результата — как изменятся конкретные метрики. По измеримости может быть несколько вариантов: невозможно посчитать, сильно улучшит метрики, возможно улучшит либо посчитать результат можно, но непонятно влияние на основные показатели.
- Источник — откуда пришла идея фичи: из best practice, от коллег, со стороны клиентов, «подсмотрели у конкурентов», возникла у самого менеджера, родилась в команде.
- Проработанность — насколько фича осознана, проработана и насколько мы готовы ее развивать. Проработанность бывает разных уровней: от «непонятно как это делать и кому нужно» до «есть ТЗ, план и таски в Jira».
Понимая процесс разработки в целом, менеджер может выяснить ограничения или убедить заказчика выделить бюджет на важную функциональность. Архитектурные решения, заложенные в самом начале работ, обязательно отразятся в итоговом продукте. Так что, если РМ действительно хочет влиять на качество, без понимания технических вопросов не обойтись.