Проблеми та рішення раннього тестування інтернет-магазину чи іншого IT-продукту

       Раннє тестування знімає проблеми накопичення ризиків і подальшої витрати часу і грошей на виправлення помилок. Якщо мова заходить про розробку інтернет-магазину (або будь-якого іншого IT-продукту), то з самого початку роботи команда повинна ставитися до його створення як до тестування гіпотези. Гіпотезою в цьому випадку буде припущення «наше технічне завдання відповідає глобальним завданням проекту». Необхідно зрозуміти, чи зможе задумана функціональність інтернет-магазину забезпечити його планову прибутковість.

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


1. Упередженість правильності власних ідей


     Найчастіше в технічне завдання потрапляє суб'єктивний досвід представника замовника або агентства, що може негативно відбитися на ефективності технічного завдання (ТЗ).
     Проблема в тому, що порушений системний підхід в аналітиці: не вивчена цільова аудиторія, не сформовану ціннісну пропозицію для неї. Для перевірки краще зробити крок назад і зібрати дані щодо сегментів цільової аудиторії:

  • які потреби і проблеми не закриті? 
  • яку ціннісну пропозицію може дати компанія клієнтам в цьому випадку?

     Формувати ТЗ, а вже тим більше, починати розробку сайту буде набагато розумніше саме після такої найпростішої аналітики. Далі - складніше. Потрібно знайти перетин цінностей аудиторії з вашою пропозицією і зняти бар'єри на шляху до покупки.
     Під час реалізації продукту (в нашому випадку сайту) початкові припущення можуть не дати запланованого результату, в цьому випадку важливо спиратися не на інтуїцію, а точні дані тестування. Для об'єктивної оцінки результатів потрібно обов'язково мати бізнес-план по середньостроковому і довгостроковому розвитку проекту і KPI для оцінки його ефективності.
Вирішенням проблеми служать наявні на ринку технології вивчення цільової аудиторії та базові принципи формування бізнес-моделей і ціннісних пропозицій.
     Для більш точного попадання гіпотез в інтереси ЦА рекомендую використовувати схему Остервальдер, основна ідея якої полягає в тому, щоб знайти головні мотиви здійснення покупки і сформувати позиціонування, яке було б зрозуміло й цікаво аудиторії.


2. Психологічні аспекти


     Коли тестування показує неспроможність первісних гіпотез, важко прийняти результат і відмовитися від частини функціоналу або перейти до значної його переробці.
     Ця проблема носить чисто психологічний характер. Виконавець переконаний у правильності власних припущень, негативний результат руйнує його картину світу і уявлення про себе як про фахівця (особливо якщо у нього мало досвіду). У замовника (або інвестора), зі свого боку, вже сформовані певні очікування, і відкат змін сприймається як провал.
     Домовленості про ранній тестуванні допомагають зняти подібні проблеми ще до початку робіт. Замовник отримує обґрунтовані ризики, а виконавець закладає право на помилку. Дати однозначну оцінку результатам дозволяє План Вимірів, який містить у собі головні KPI і бізнес-цілі.


3. Порядок тестування


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