Од разговор со клиент до јасно дефиниран производ

Пред да изградиме решение, мора да бидеме сигурни дека го разбираме вистинскиот проблем.

Пред да напишеме и една линија код

Замисли дека денес започнуваме нов проект со клиент што сака платформа за управување со настани.

На првиот состанок лесно е разговорот веднаш да отиде кон решенија.

Дали ќе користиме Laravel?

Како ќе изгледа базата?

Ќе има ли мобилна апликација?

Каде ќе влезе AI?

Но ниту едно од овие прашања не е прво.

Првото прашање е многу поедноставно:

Ако немаме јасен одговор на тоа прашање, секоја техничка одлука што ќе ја донесеме подоцна ќе биде изградена врз претпоставка.

Затоа професионалниот SaaS проект не започнува со развој.

Започнува со откривање.

Што е Discovery Workshop?

Discovery Workshop е структурирана работна сесија во која клиентот и проектниот тим заедно го анализираат бизнисот, тековните процеси, корисниците, проблемите, ограничувањата и очекуваните резултати.

Целта не е клиентот да ни диктира список на функционалности.

Целта е да откриеме што навистина се случува во неговата работа.

Во оваа фаза не се обидуваме да докажеме колку технологии знаеме.

Не започнуваме со Laravel.

Не започнуваме со Vue.

Не започнуваме со AI.

Започнуваме со луѓето што секој ден го живеат проблемот.

Што мора да знаеме пред да продолжиме?

До крајот на Discovery Workshop треба да можеме јасно да одговориме на неколку основни прашања.

• Кој е реалниот деловен проблем?
• Кои корисници најмногу го чувствуваат?
• Како проблемот се решава денес?
• Каде во постојниот процес се губат време и пари?
• Каде најчесто се случуваат грешки?
• Што сака клиентот да постигне со новиот систем?
• Кои резултати ќе покажат дека проектот е успешен?

Кој треба да биде вклучен?

Discovery не треба да биде разговор помеѓу еден програмер и еден клиент. Колку е посериозен производот, толку е поважно на масата да бидат присутни луѓе што гледаат на проблемот од различни перспективи.

Првата сесија: ја разбираме деловната визија

Првиот дел од работилницата не е технички.

Нè интересира зошто воопшто постои идејата за Evento.

Наместо веднаш да прашаме кои функции ги сака клиентот, поставуваме прашања што ја откриваат причината зад проектот.

• Зошто сакате да го создадете овој производ?
• Кој проблем го гледате на пазарот?
• Кој најмногу страда од тој проблем?
• Како организаторите го решаваат денес?
• Што ќе се случи ако не изградиме ништо?
• Како би изгледал успешен резултат по една година?

Овие прашања изгледаат едноставно, но токму од нив почнува да се формира вистинската визија на производот.

Втората сесија: го набљудуваме сегашниот процес

Во оваа фаза намерно не разговараме за новиот систем.

Сакаме прво да видиме како организаторот работи денес.

На пример, за еден настан процесот може да изгледа вака:

Кога процесот ќе го видиме како целина, проблемите почнуваат сами да се појавуваат.

Каде реално боли?

Не секоја непријатност е доволно голем проблем за да оправда развој на нов производ.

Затоа секоја болна точка ја анализираме според три прашања:

• Колку често се случува?
• Колку време или пари губи организацијата?
• Колку е сериозно влијанието врз корисникот?

Проблем 1 — Пријавите доаѓаат од повеќе канали

Дел од корисниците пополнуваат форма, други испраќаат порака, трети се јавуваат по телефон, а некои плаќаат без претходно да бидат заведени.

Последиците се предвидливи: дупликати, изгубени регистрации, неточни списоци и дополнителна рачна проверка.

Проблем 2 — Плаќањата се проверуваат рачно

Организаторот мора рачно да споредува уплати со пријави и да потврдува кој учесник навистина платил.

Тоа создава одложувања, административен товар и ризик од грешки.

Проблем 3 — Комуникацијата е рачна

Потврди, потсетници, промени во програмата и информации за локацијата често се испраќаат рачно.

Колку повеќе учесници има, толку поголема е веројатноста некоја порака да биде испратена до погрешна личност или воопшто да не биде испратена.

Проблем 4 — Недостасува аналитика

Организаторот може да знае колку билети продал, но често не знае:

• кој канал носи најмногу регистрации;
• во кој период најмногу се купуваат билети;
• кои категории на настани се најуспешни;
• колкав процент од регистрираните навистина присуствуваат;
• кои кампањи создаваат најголема вредност.

Не разговараме само со сопственикот

Една од најопасните претпоставки е дека сопственикот на бизнисот секогаш точно знае како изгледа секојдневната работа на корисниците.

Затоа интервјуираме повеќе засегнати страни.

Интервју со организатор

• Колку настани организирате годишно?
• Колку луѓе учествуваат во организацијата?
• Колку време просечно трае подготовката?
• Кој процес одзема најмногу време?
• Каде најчесто се случуваат грешки?
• Кои задачи постојано се повторуваат?
• Што најмногу ги фрустрира вашите учесници?
• Кои информации секогаш ви недостасуваат по завршувањето на настанот?
• Што би сакале никогаш повеќе да не го правите рачно?

Интервју со учесник

• Колку лесно го пронајдовте настанот?
• Колку беше јасен процесот на регистрација?
• Колку лесно беше плаќањето?
• Дали навреме ги добивте сите потребни информации?
• Какво беше искуството при влез на настанот?
• Што би промениле ако можете да смените само една работа?

Од проблеми кон функционални области

Дури кога ќе го разбереме процесот, започнуваме да размислуваме кои функционални области може да бидат потребни.

Важно е да не ги третираме како конечен список. Во оваа фаза тие се кандидати што подоцна ќе бидат приоритизирани во BRD и PRD.

Управување со настани

• Креирање и уредување настани.
• Архивирање.
• Категории.
• Локации.
• Организатори.
• Распоред и програма.

Регистрација и учесници

• Регистрација преку интернет.
• Рачно додавање учесник од страна на организатор.
• QR-карти.
• Листа на чекање.
• Пријавување на влез.

Плаќања

• Онлајн плаќање со картичка.
• PayPal.
• Банкарска уплата.
• Бесплатни настани.
• Рефундации.
• Фактури и потврди за плаќање.

Комуникација

• Е-пошта.
• SMS известувања.
• Push известувања.
• Автоматски потсетници.
• Известувања за промена на програмата.

Аналитика

• Број на регистрации.
• Продажба.
• Посетеност.
• Стапка на конверзија.
• Извори на регистрации.
• Извештаи по настан и организација.

Каде AI навистина создава вредност?

Во оваа книга нема автоматски да додаваме AI во секој модул само затоа што можеме.

За секоја потенцијална AI функционалност ќе поставиме едно прашање:

За Evento, во Discovery фазата идентификуваме неколку области што вреди понатаму да се истражат.

Ова сè уште не значи дека сите овие функции ќе влезат во производот.

Discovery ја идентификува можноста.

Подоцнежните фази ќе одлучат дали таа можност е доволно вредна, безбедна и економски оправдана.

Ризиците ги разгледуваме пред да станат проблем

Професионалниот тим не го документира само она што сака да успее.

Го документира и она што може да тргне наопаку.

Што мора да излезе од Discovery?

Работилницата не завршува со „добар разговор“.

Таа мора да создаде конкретни работни материјали што ќе станат основа за следната фаза.

Од работната маса на авторот

Практична задача

Следниот чекор

Сега веќе знаеме зошто Evento треба да постои, кој проблем го решава и што треба дополнително да се потврди.

Но сè уште немаме формален договор за тоа што бизнисот очекува од производот.

Следниот чекор е да го претвориме сето она што го откривме во јасен, структуриран и проверлив документ.

Тој документ е BRD — документот со деловните барања.