Як правильно оцінити ІТ-проект? Розповідають експерти Lenal

СТОРОНА ЗАМОВНИКА

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

Ідеальний сценарій – створення робочої групи з різних відділів компаній. В цьому разі у вас буде повний опис продукту на всіх етапах виробництва, після чого у команди сформуються загальні бізнес-вимоги. Особливо важливий цей етап в електронній торгівлі, коли з оффлайн-рітейлу бізнес переходить в digital. Потрібно брати до уваги дуже багато деталей: синхронізацію процесів, специфіку товарів, оцифровану номенклатуру товарів, інтеграцію з ERP та CRM системами, спосіб оплати, доставки та багато іншого.

Опис продукту

Чудово, якщо у вас є певні технічні характеристики чи вимоги. Якщо ні – опишіть продукт й зазначте, які проблеми своїх клієнтів ви збираєтесь вирішити. На цьому етапі у вас повинні бути відповіді на наступні питання:

• Яке завдання проекту?
• Хто ваша аудиторія?
• Чи є будь-яка експертиза, документація  на майбутній проект?
• Які навантаження плануються?
• Як будуть користуватись проектом?
• Хто керує розробкою?
• Дедлайни і бюджет.

Шлях вашого клієнта (Customer journey)

Розуміння цільової аудиторії та її особливості допоможе технічному партнеру створити проект для кінцевого споживача, тому перед початком роботи над проектом потрібно детально опрацювати вашого цільового користувача:

• опис ідеального клієнта (звички, мотиви, проблеми);
• визначення каналів комунікації з клієнтом;
• основні точки взаємодії з вами (деталі навігації сайту, заповнення форми заявки, пошук сторінки контактів, ін.)
• модель поведінки клієнта, процес прийняття рішення та фактори, що на нього впливають;

Формат подачі бізнес-вимог не має значення. Це може бути презентація або просто список, відправлений електронною поштою.

Наприклад, якщо ваш продукт це парку вальний сервіс, то ви повинні розуміти, що головна проблема для ваших користувачів – пошук вільного паркомісця та розчарування в разі його відсутності. Ваш варіант вирішення проблеми – резервація місця заздалегідь з попередньою оплатою.

Точки взаємодії наступні (User case): користувач вводить заявку, обирає час та місце стоянки для паркування, сплачують за це. Таким чином, ви збережете нерви своїх клієнтів і заощадите їх час.

Ще раз, перш ніж почати свій проект – уявіть собі проблеми, які ви допомагаєте вирішити клієнту, та спосіб їхнього вирішення.

Монетизація моделі вашого проекту

Ми вже визначились, що саме робить замовник, чому та як йому допомогти. Наступний крок – визначити модель монетизації проекту. Що ти можеш заробити і як це зробити?

Іноді, особливо в електронній комерції, це можна продемонструвати, уникаючи складних таблиць. Ви можете просто пояснити, що витрати на залучення та продажі, здійснені в Інтернеті, в 3 рази дешевше, ніж в “оффлайн режимі”, тому маржа зросте з 30% до 45%, і цього буде достатньо, щоб зрозуміти, як це працює.

Цей етап також дуже важливий для розуміння того, який тип UX у вас буде в майбутньому, оскільки UX дизайн є потужним інструментом впливу на користувачів. Наприклад, якщо власник бізнесу зацікавлений у здійсненні покупок від $100 і більше, то саме правильний UX може спонукати клієнта до цього, пропонуючи додаткові товари, сервіси та послуги.

Загальні особливості та обмеження проекту

• Особливості інтеграції. Власник продукту описує, що має бути інтегроване з чим, технічні спеціалісти формують архітектуру проекту;
• Терміни доставки; обмеження у реальній роботі;
• Бюджетні обмеження (приблизна сума, запланована для інвестицій у проект);

Планування випуску версії

Версійність проекту – поширене явище за кордоном. Перша версія проекту запускається якомога швидше задля того, щоб протестувати свої гіпотези та почути відгуки користувачів, після чого доопрацювати продукт.

Українські замовники віддають перевагу «поліруванню» продукту аж доки той не виглядатиме бездоганно, перш ніж продемонструвати його світові. Тим не менш, було б розумніше почати роботу вже незабаром, щоб негайно отримати відгуки через взаємодію з користувачем.

Технічний партнер, зазвичай, вимагає інформацію про те, наскільки великий продукт, які функції він матиме і як власник продукту планує реалізовувати майбутні версії продукту.

Визначення пріоритетних задач

І ваша команда, і команда технічного партнера повинні знати, які задачі виконувати першими. Це допоможе вам сконцентруватися на найважливіших завданнях, та оптимально розподілити загрузку на весь час проекту.

СТОРОНА ТЕХНІЧНОГО ПАРТНЕРА

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

На що може очікувати власник продукту:

Детальний аналіз особливостей проекту

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

Ви також можете протестувати рівень залученості свого технічного партнера, провівши з ним онлайн- чи оффлайн-зустріч, під час якої попросити його описати ваш продукт. Таким чином, ви матимете уявлення про те, чи ваші погляди збігаються.

Схема реалізації

Після того, як ви зрозуміли, що ваші погляди співпадають, прийшов час для розробки схеми реалізації – чіткі дії, які приведуть до успішного проекту. Організувати роботу можна по-різному, але найчастіше ІТ-компанії ділять роботу на спрінти (певні відрізку часу), та складають список функцій над якими будуть працювати в цей період.

Визначення архітектури проекту

Враховуючи всі особливості проекту, – терміни доставки, бюджетні та інтеграційні специфіки, технічному партнеру потрібно розробити інфраструктуру та врахувати всі  бази даних проекту, на основі яких буде побудована архітектура проекту та її компонентна система (мікро-послуги та інше).

Детальна структура розбиття робіт

Досвідчений технічний партнер може зробити один крок вперед і запропонувати вам розбити роботу над проектом на модулі, кожен з яких матиме фіксовану ціну. Це дасть вам право керувати своїм проектом та витратами відповідно до вашого бюджету. Крім того, це може допомогти вам оцінити ризики та способи їх вирішення.

Чому б вам це потрібно? Ви матимете всю документацію, яка може бути реалізована будь-якою командою у випадку, якщо вас не задовольнить співпраця з поточним партнером.

А як щодо Agile?

Звичайно, є гнучкість. Але будь-який бізнес має певні обмеження як у бюджеті, так і в дедлайнах. Будь-який проект вимагає аналізу, а якщо ви вибираєте гнучкий спосіб, то місця для попередньої оцінки не залишається.

Якщо ви виберете ітераційний спосіб , вам просто потрібно знати рейт за годину роботи команди технічного партнера (time & material).

Але, якщо ви вирішите зробити дійсно хороший продукт, підготуйтеся до жорсткої гри. Не залишайте місця для непорозумінь. Чим детальніше ви обговорите всі деталі проекту, тим точніша буде оцінка.