Как менеджеру оценить стоимость IT-решения

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

И здесь РМ или ВА очень помогли бы заказчику, если бы сделали предварительный расчет стоимости владения (ТCO — total cost of ownership). 

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

В статье собрали практические рекомендации из вебинаров наших спикеров, которые помогают РМ-ам, продактам и бизнес-аналитикам разбираться в архитектуре проекта на курсе ArchiTech.

Развитие облачных технологий предоставило компаниям фактически безграничные ресурсы для оценки и анализа. Рост сервисов на уровне 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-решения, посмотрите на отдельные составляющие:

1. Во сколько обойдется лицензирование компонентов. Обратите внимание, что коммерческий open source и его поддержка бывают платными, поэтому смотрите на типы лицензии. 
2. Какова стоимость и сроки внедрения (time to market). Это о том что, если мы вложим 100 тысяч, через какой период времени окупятся наши инвестиции. ROI нужно сопоставлять с time to market, потому что, если эти 100 тысяч будут реализованы через год, возможно, за год данный продукт или сервис потеряет актуальность. 
3. Какой будет поддержка. Если на уровне community, — нужно искать технический персонал соответствующей квалификации. Если при помощи платформы, — это может быть open source коммерческая поддержка. 
4. Отдельно просчитайте стоимость рейта внутреннего найма для специалистов на данной технологии и в нужном вам регионе. Делайте расчет не больше чем на три года.
5. Проработайте cloud configuration. Начинать можно с помощью калькулятора, который предоставлен провайдером. А затем дополнительно пообщайтесь с авторизированными партнерами на предмет тех или иных сервисов. Особенно если у вас стоят вопросы про миграцию из каких-то on premise систем в cloud. 
6. Hardware and/or Software configuration. При замкнутой микросистеме важно оптимально подобрать нужные Hardware и Software конфигурации, решить, какие сервера купить в data центр, на каких платформах, с какими application и data base серверами, чтобы стоимость владения и обслуживания, была соизмерима с той суммой, которая будет инвестирована в ПО.
7. Рассчитайте стоимость лицензирования средств разработки платных библиотек и фреймворков. Они могут стоить денег, но при этом, сократить время разработки и, соответственно, ускорить time to market.

Если все эти технические подробности выглядят слишком сложными, приходите разбираться на курс TechMind. За полтора месяца вы научитесь общаться с техническими специалистами на их языке и будете понимать, какой фреймворк и команду выбрать для проекта. А на ArchiTech объясним, как работать с архитектурой проекта и выбирать лучшее решение для бизнес-задачи.

Что такое фича?

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

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

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

Главные преимущества фич следующие:

• Разрабатываются с учетом потребностей и предпочтений конечных пользователей, что способствует повышению их удовлетворенности продуктом.
• Постоянное добавление новых фич помогает компаниям оставаться на переднем крае технологических инноваций и конкурентоспособности.
• Эффективные и привлекательные фичи могут привлечь новых пользователей и увеличить рыночную долю продукта.
• Хорошо спланированные нововведения позволяют продукту легко адаптироваться к изменяющимся требованиям рынка и технологий.
• Фичи могут значительно улучшить общее восприятие и удобство использования продукта.
• Уникальные или инновационные решения помогают продукту выделиться среди конкурентов.
• Непрерывное улучшение и добавление новых фич могут укрепить доверие и лояльность клиентов.
• Эффективно разработанные функции могут сократить затраты на поддержку и обслуживание продукта.
• Они обеспечивают возможность получения ценной обратной связи от пользователей, что способствует улучшению продукта.
• Разработка новых фич может стимулировать креативность и инновационный подход в команде.

Фичи являются неотъемлемой частью любого IT-продукта. Они обеспечивают его актуальность, удовлетворяют потребности пользователей и способствуют успеху продукта на рынке. Важно регулярно анализировать и обновлять фичи, чтобы соответствовать меняющимся трендам и потребностям пользователей.

Что такое фича в Scrum?

Фича в Scrum – это конкретная функция или улучшение продукта, которое должно быть реализовано в рамках спринта. Эти элементы часто формулируются как пользовательские истории, описывающие желаемый функционал с точки зрения пользователя.

В Scrum фичи служат основой для планирования спринтов и распределения работы в команде. Они помогают сфокусироваться на создании ценности для пользователя и поддерживают гибкость в процессе разработки.

Преимущества фич в Scrum следующие:

• Фокус на пользовательской ценности. Позволяет команде сосредоточиться на создании реальной ценности для пользователя.
• Гибкость и адаптивность. Фичи в Scrum легко адаптируются под изменяющиеся требования или обратную связь.
• Повышение прозрачности. Конкретные решения обеспечивают ясность в планировании и отслеживании прогресса.
• Улучшение коммуникации в команде. Ясное определение фич способствует эффективному взаимодействию в команде.
• Ускорение процесса доставки. Они способствуют более быстрой и четкой доставке продукта.

В Scrum фича является центральным элементом планирования и реализации работы. Она помогает команде оставаться сфокусированной на целях пользователя, обеспечивая при этом гибкость и эффективность в разработке.

Как реализовать фичу в Scrum

Реализация фичи в Scrum требует понимания принципов Agile разработки и эффективного взаимодействия в команде. Процесс реализации новой идеи или функции выглядит следующим образом:

1. Планирование фичи. Все начинается с идеи или требования, четко описываемого в виде пользовательской истории. Фича оценивается и приоритезируется в бэклоге продукта, учитывая ее ценность и сложность.
2. Разработка фичи. Команда выбирает новые идеи и решения из бэклога для реализации в следующем спринте.
3. Дизайн и реализация. Используются возможности команды, функция разрабатывается через итеративные циклы, включающие дизайн, кодирование и тестирование.
4. Ежедневные скрам-встречи. Команда обсуждает прогресс и решает возникающие проблемы.
5. Завершение работы над фичей. Новая функция демонстрируется заинтересованным сторонам для получения обратной связи. Проводится ретроспектива, команда анализирует процесс работы над фичей и ищет способы улучшения.

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

Чтобы успешно реализовывать фичи, необходима техническая грамотность. Для этого менеджеру поможет Techmind – курс для нетехнических специалистов в IT, который полностью раскроет все аспекты разработки для менеджера. Посмотрите программу курса на сайте и оставляйте заявку, чтобы узнать подробнее, как Techmind помогает решать проблемы менеджера.

Фичи — внедрять или лучше не надо

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

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

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

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

• Размер фичи, сколько времени пойдет на реализацию: день, неделя, месяц или фича такая большая, что трудно оценить размер и нужные ресурсы.
• Комплиментарность — улучшатся ли какие-то процессы, основной либо второстепенный сценарий. Возможно, в результате изменится существующий сценарий или откроется новый. 
• Новизна — есть ли что-то подобное у конкурентов или идея абсолютно новая, и появилась в процессе брейншторма. 
• Измеримость результата — как изменятся конкретные метрики. По измеримости может быть несколько вариантов: невозможно посчитать, сильно улучшит метрики, возможно улучшит либо посчитать результат можно, но непонятно влияние на основные показатели. 
• Источник — откуда пришла идея фичи: из best practice, от коллег, со стороны клиентов, «подсмотрели у конкурентов», возникла у самого менеджера, родилась в команде.
• Проработанность — насколько фича осознана, проработана и насколько мы готовы ее развивать. Проработанность бывает разных уровней: от «непонятно как это делать и кому нужно» до «есть ТЗ, план и таски в Jira». 

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