Чому так важливо швидше запустити інтернет-магазин?

Ідея відкрити інтернет-магазин приходить у голову, ймовірно, більшості власників, і рішення зазвичай приймається одним із двох шляхів:

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

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

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

Незалежно від того, чи це ваш перший чи навіть другий інтернет-магазин, часто важко знайти пріоритетні завдання. Це ще складніше, коли є великий тиск з боку «Великих хлопців» — великих конкурентів із їхніми сотнями тисяч клієнтів у базі даних, великими даними, повною автоматизацією та іншими складними речами. Зайве говорити, що зібрати таку велику клієнтську базу та мати весь цей функціонал коштує великих грошей.

Однак найголовніше при створенні інтернет-магазину — запустити його швидко, без зволікань. У той же час, важливо тримати витрати під контролем і в рамках визначеного бюджету, щоб вийти на беззбитковість і отримати прибуток за короткий час, тому що, врешті-решт, мета бізнесу і магазину - отримувати прибуток.

Чому важливий швидкий старт?

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

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

Що таке MVP і як він використовується для малих і середніх магазинів?

Раніше ми вже з'ясували, що чим раніше ми запустимо магазин, тим швидше ми потенційно зможемо почати отримувати прибуток. Але як побудувати структуру магазину, яка б допомагала заробляти гроші, а не заважала процесу продажів?

Для цього нам потрібно визначити перелік функцій, яких буде достатньо для запуску магазину, який, у свою чергу, може почати генерувати продажі та забезпечувати ефективне обслуговування клієнтів. Тобто MVP (Minimum Viable Product) вашого інтернет-магазину.

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

Ще один важливий момент: який магазин вважається малим, а який середнім?

У цій статті для зручності передбачається, що:

• невеликий магазин можуть обслуговувати лише кілька людей. Зазвичай такий магазин генерує не більше 15 замовлень на день. У маленькому магазині важливо не пропустити жодного покупця; можлива повна автоматизація процесів, але ручні більш вигідні;
• у магазині середнього розміру кількість замовлень обчислюється десятками на день і зазвичай вимагає більшої команди для обслуговування клієнтів, часто в кілька змін. У такому магазині стає важливішим максимально автоматизувати всі рутинні функції, поступово виключаючи ймовірність помилок, пов’язаних з людським фактором і ручними процесами.

Начебто вдалось починати треба з великого. Перед очима ті гігантські інтернет-магазини, де все складно: особисті рекомендації, складні особисті кабінети для різного типу покупців, низка різноманітних акцій та маркетингових кампаній, бонусні програми та кешбек, автоматизація та інші додаткові можливості. Складається враження, що без усього цього абсолютно неможливо обійтися, а розробка всіх цих функцій коштує великих грошей і значного часу. Але варто пам’ятати, що сучасний гігант Amazon був заснований у гаражі лише з невеликою командою, яка піклується про обслуговування клієнтів!

І на етапі запуску не зайвим буде нагадати, що головна мета магазину – продавати.

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

Процес запуску проекту

Класичний процес розробки передбачає, що власник витрачає час на те, щоб продумати всю структуру магазину, до найдрібніших деталей, а потім перенести це у комплексні Специфікації вимог до програмного забезпечення. Цей документ (SRS) є відправною точкою та керівною картою для розробників, по-перше, для оцінки проекту, а по-друге, для дотримання під час процесу розробки. Процес розробки та планування можна описати за допомогою різних методологій, але це не тема цієї статті.

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

• іноді під час процесу планування деякі деталі не враховувалися або пропускалися, що на той момент здавалося неважливим. Можливо, якісь завдання не були враховані і спливли на стадії розробки. Все це вплине на структуру всього проекту. Мабуть, такі ситуації є радше правилами, ніж винятками, і трапляються майже напевно на кожному проекті. Навряд чи можливо спроектувати та заморозити структуру проекту без попереднього обговорення з командою розробників;
• Можливо, ситуація на ринку змінюється, і виникає необхідність змінити функціональність або запровадити функціональність, відмінну від тієї, яку ми вже обговорювали. І це також досить поширена ситуація;
• нерозуміння або відмінності в техніках виконання проекту між власником і командою розробників також є досить поширеною проблемою. Власник повинен контролювати та порівнювати проект на кожному етапі, підтверджувати, чи правильно зрозуміла функціональність, описана в SRS. Навіть люди, які говорять однією мовою, можуть розуміти речі по-різному, залежно від середовища, культури, очікувань та інших причин, і це ще більше стосується складних проектів, де ідеї потрібно втілювати в життя командою розробників. Якщо ваші очікування не збігаються з реальністю, проект провалиться.

Lean-метод розробки (і, зокрема, його варіант під назвою Agile method) може допомогти оптимізувати процес. У випадку з невеликим магазином має сенс спочатку домовитися з забудовником про те, що:

• Існує конкретна оцінка вартості проекту, і розробка має бути в межах цього бюджету;
• є мінімальний набір модулів, який повинен бути присутнім на сайті - і цей набір також повинен вкладатися в бюджет. Методи впровадження цих модулів обговорюються з розробником;
• Чітко визначена послідовність розробки модулів. Загалом, проект починається з чітко визначених модулів і послідовності розробки (наприклад, якщо модуль каталогу повинен бути перед модулем замовлення, тому що без списку товарів порядок неможливий). Однак це також слід обговорити з розробником.

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

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

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

Як уникнути затримок у розробці

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

Головна помилка, яку часто роблять початківці, це бажання зробити все ідеально, забуваючи при цьому стару мудрість «Ідеальне — ворог добра». Це часто призводить до таких проблем:

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

... І раптом ...розробник припускає, що базу даних можна оптимізувати, речі можна покращити, і в будь-якому випадку можна розробити, здавалося б, робочий модуль, покращуючи зручність використання та, можливо, додаючи функціональність, яка може (або не може) бути необхідні в майбутньому. На даний момент це не обов’язково, просто добре мати!

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

У більшості ситуацій правильним рішенням було б відкласти такі вдосконалення, можливо, на пізніший етап. Пам’ятаєте, ми говорили про MVP? Справа в тому, що проект майже готовий. Ідеальний чи ні, принаймні він працює та готовий приносити продажі та дохід. Почати переробку прямо зараз означає втрачену вигоду і початок довгострокового розвитку, а це може стати нескінченною історією.

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

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

Але при цьому ваш неідеальний сайт вже буде працювати і приносити вам дохід!