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

Починаючи проєкт, можна сфокусуватися виключно на технічному боці та придумати геніальне рішення, найкраще на ринку. Ось тільки пізніше з’ясується, що загальна величина витрат на IT-інфраструктуру робить впровадження невигідним для бізнесу. Добре, якщо про це дізналися на етапі планування. 

І тут РМ або ВА дуже допомогли б замовнику, якби зробили попередній розрахунок вартості володіння (ТСО – 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. Ще один важливий момент, – на який термін розраховувати вартість володіння, ТСО (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 і database серверами, щоб вартість володіння й обслуговування була порівнянною з тією сумою, яку буде інвестовано в ПЗ.
• Розрахуйте вартість ліцензування засобів розробки платних бібліотек і фреймворків. Вони можуть коштувати грошей, але при цьому, скоротити час розробки і, відповідно, прискорити 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». 

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