Створення інтернет-магазину: ефективні підходи та методи

Створити інтернет-магазин так само просто, як вибрати спосіб управління проектом і слідувати йому. Щоправда, простого в цій задачі немає практично нічого.

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

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

Перший варіант зараз став простим як ніколи. Можна навіть не знати HTML і тим більше нічого складнішого за нього:

• заходите на сайт компанії, яка пропонує зібрати інтернет-магазин як конструктор;
• використовуєте шаблонні блоки з різними функціями, щоб створити структуру сторінок;
• вибираєте платні або безкоштовні варіанти дизайну та завантажуєте свій контент;
• оплачуєте передплату;
• profit!

Якщо ви збираєтеся, наприклад, продавати свій hand-made, у магазині буде +/- 50 товарів, а залучати користувачів плануєте через соціальні мережі — сміливо обирайте цей варіант. Це дешево, зручно та навіть захоплююче на етапі збирання. А якщо «щось зламається», то до вартості підписки належить не лише хостинг, а й техпідтримка. Якщо ви, звичайно, вибрали нормальну платформу.

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

Тут ми писали про те, що краще для інтернет-магазину: CMS або фреймворк, але ця стаття взагалі не про це. Вона про методи управління проектами, один з яких вам доведеться застосувати для розробки у будь-якому випадку.

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

• укладатися в стислі дедлайни;
• економно використовувати ресурси;
• дотримуватися процесу;
• все відразу.

Майже у всіх статтях про проектне управління є згадки про NASA, яким довелося вигадати не тільки як відправити людину на місяць, а ще й як організувати підготовку до цього надзавдання. Згадують тому, що головному «менеджеру» програми «Аполон», доктору Джорджу Мюллеру, вдалося створити систему управління та вмовити всіх їй слідувати настільки добре, що вони перевиконали всі плани та повірили в проектне управління.

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

Класичне проектне управління

У класичному проектному управлінні процес виконання задач розбивається на послідовні етапи. Його ще часто називають waterfall (водоспад) чи каскадний цикл. Це лінійна структура, де починати виконувати кожен наступний етап можна лише після завершення попереднього.

У класичному підході до управління проект розбивається на 5 етапів:

1. Ініціація. Власне початок роботи. Наприклад, коли ви приходите з ідеєю створення інтернет-магазину до веб-студії та починаєте обговорювати її з виконавцями. Щоб визначити, яким має бути результат, потрібно не лише розповісти, що вам хочеться, та вислухати, як це можна зробити, але також провести аналітику, врахувати багато нюансів та, зрозуміло, брати участь у мозкових штурмах та нарадах.
2. Планування. Коли стає зрозуміло, який результат потрібен, починається розробка ТЗ настільки докладно, наскільки це потрібно, щоб розпочати роботу. Тут уже не обійтися без консультації фахівців, які займатимуться проектом, складання планів роботи, обчислення потрібної кількості часу на кожен етап, оцінки ризиків тощо.
3. Розробка. Це ще не написання коду в прямому сенсі, а частина планування, коли вибираються технології для реалізації функціоналу, визначається конфігурація проекту та інші технічні нюанси, які не такі важливі для замовника, як результат, який вже затвердили на попередньому етапі.
4. Реалізація та тестування. Ось тут уже справжня робота — спочатку робимо все, про що домовилися, потім перевіряємо, як працює. Якщо тести показали, що щось не так, виправляємо.
5. Моніторинг. Показуємо клієнту, що вийшло в результаті, і закінчуємо роботу. Або, якщо потрібно, з'ясовуємо, що йому хочеться, та починаємо все спочатку.

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

Каскадні цикли — ідеальні методи управління для розробки продуктів, де всі роботи потрібно виконувати поетапно. Наприклад, у будівництві чи випуску техніки. Для створення інтернет-магазинів та будь-якого програмного забезпечення логічніше застосовувати різні рішення, засновані на Agile-методології.

Agile

Agile — сімейство гнучких ітеративно-інкрементальних методів управління проектами. Усі «модні» Scrum, Lean, Kanban — методи чи фреймворки з урахуванням принципів Аджайл.

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

Agile — це про ітеративну розробку. Перші два етапи залишаються як у класичному управлінні для всього проекту, а наступні вже поділяються на підпроекти-ітерації. Всередині кожної такої частини проводиться планування, розробка, тестування тощо. Коли ітерація завершена, її можна додавати до проекту та, що навіть більш важливо, змінювати, якщо це потрібно, без впливу на проект в цілому.

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

Топ-3 Agile методи

Agile — метод управління проектами «у вакуумі». Це не конкретна структура, як у її класичному варіанті, а набір принципів та цінностей гнучкої розробки. У 2001 був опублікований Agile Manifesto, а далі, на його основі, почали створюватися «реальні» методи управління, різні, але об’єднані загальними принципами.

Scrum

Скрам — найпопулярніший і найбільш структурований з Agile фреймворків, що вдало поєднує в собі елементи класичного та Аджайл підходів.

Фішка Scrum —  постійно показувати замовнику результати. Постійно, в даному випадку, означає, що раз на 1-4 тижні протягом усієї роботи над проектом розробники з кожної команди будуть показувати вам повністю готову функціональність або інше виконане відносно невелике завдання.

Сам проект спочатку розбивається на функціональні частини, product backlog — елементи, з яких потім збиратиметься повноцінна програма. Цим частинам призначаються пріоритети та виділяються команди по 5 осіб у середньому, які займатимуться розробкою. Усі команди працюють по спринтах.

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

Друга особливість структури Scrum — 5 типів зустрічей, нарад чи мітингів, можна називати їх як завгодно, які потрібні для контролю виконання завдань:

• Backlog Grooming. Перша зустріч у спринті для класичного планування. Учасники, на чолі з продукт оунером, дивляться, що вже зроблено і що ще потрібно зробити для проекту, а потім призначають задачі на цей спринт. Мета зустрічі — визначити, що отримає замовник наприкінці спринту.
• Sprint Planning. Друга частина першої зустрічі, де вже фахівці вирішують, як краще досягти поставленої мети: хто, що, як і коли робитиме.
• Daily standup. Щоденна коротка зустріч, де в середньому за 15 хвилин учасники команди розповідають, що зробили за вчора чи не зробили, бо зіткнулися із труднощами, та як збираються їх вирішувати.
• Підбиття підсумків. Мітинг наприкінці спринту, коли команда, а найчастіше її тимлід, показує власнику продукту результат.
• Ретроспектива. Остання зустріч, яку проводять одразу після підбиття підсумків, щоб обговорити, як загалом пройшов спринт. Тут обговорюються як робочі завдання, так і складності у взаємодії, якщо вони були, щоб до наступного спринту збільшити ефективність роботи.

Плюси та мінуси Scrum:

1. Гнучкість та видимі результати. Регулярні звіти не лише допомагають бачити вам як замовнику що робота рухається в потрібному напрямку, а й добре впливає на мотивацію розробників. Кому не хочеться поставити «галочку» навпроти чергового пункту плану роботи над проектом? Тим самим людям, що не хочуть даремно робити складну роботу, якщо вони вже зараз бачать, що як мінімум її, а може й багато іншого, доведеться переробляти. А в класичній моделі їм довелося б витрачати на це час, а вам ще й гроші — адже ви погодилися спочатку, що вам потрібен саме такий результат. Scrum дає можливість швидко підлаштовуватися під нові вимоги.
2. Можливість навчання. Scrum ідеальний для підготовки спеціалістів. Коли 4 з 5 учасників — майстри у своїй справі, а наради, де діляться досвідом, обов'язково проводяться щодня, новачкові завжди буде до кого звернутися за порадою та, загалом, легше навчитися роботі як самостійної, так і в команді. До того ж, колективна відповідальність команди за кожен спринт гарантує, що ніхто не залишить новачка віч-на-віч зі складним завданням і не дасть йому вирішити його якимось витонченим способом, що може в результаті нашкодити проекту.
3. Чудове рішення для розвитку продукту. Scrum хороший для розробки з нуля, але ще кращий для постійного оновлення. Спринти оптимально підходять для оцінки стану різних частин проекту, їхнього доопрацювання, тестування нової функціональності тощо. А якщо тестування показало не такі результати, як планувалося, все легко виправити буквально в наступному спринті. Тобто, замість глобального оновлення, умовно раз на рік, ви зможете вдосконалювати проект поступово, хоч щотижня.
4. Високі вимоги до команди. Так, Scrum хороший для навчання новачків, тому що від фахівців у таких проектах потрібно більше, ніж просто робити свою роботу. Часто потрібно виконати суміжні задачі, щоб укластися в строки та, як мінімум, розуміти, чому на конкретний таск потрібно стільки часу. Плюс потрібно постійно взаємодіяти з колегами по команді та брати відповідальність не лише за себе, а й за них також. Самоорганізованість — сама по собі рідкісний скіл, а зібрати 5 людей з такими навичками та досягти від них злагодженої роботи дуже складно.

Lean

Lean — одна з методологій Agile, яка теж не пропонує чіткої структури «роби так». Вона просто додає до концепції поділу проекту на невеликі підзадачі workflow — схему потоку операцій.

З Lean кожна підзадача буде мати свій порядок дій, від старту до результату. Простіше кажучи, поки в Scrum всередині спринту можна «розважатися» як завгодно, головне, щоб до кінця було все готово, Lean не встановлює чітких часових рамок. Натомість каже, у якій послідовності потрібно виконувати етапи підзавдань. І дуже докладно.

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

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

Kanban

Kanban — Agile-методологія від Toyota, яка перетворює абстрактний Lean на систему з наочним робочим процесом (workflow). Її однаково просто застосувати як до виробництва деталей для машини, так і до розробки сайтів або ПЗ.

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

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

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

4 фішки Kanban:

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

Що ще?

До Agile методів належить також вигаданий компанією Motorola Six Sigma. Це варіант Lean, де найважливішим фактором стає вимірювання та контроль усіх показників проекту. Його обирають, коли проект складний і найважливіше завдання — максимально заощадити ресурси та зібрати якнайбільше інформації для подальшого розвитку. Якщо ви не збираєтеся безупинно розвивати проект до нескінченності та не готові прийняти, що ваша думка не буде вирішальною, від нього краще відмовитись. Цей метод управління підходить стартапам зі складною бізнес-логікою та лише ускладнить розробку інтернет-магазину.

А ще є така система управління проектами, як PRINCE2, яка більше орієнтована на розподіл ролей. Хто, кому і за що повинен звітувати. Про безпосередню роботу виконавців там йдеться дуже мало, тому що створено цю систему для організації роботи керуючого складу великих корпорацій. І, що зовсім не дивно, PRINCE2 «вгорі» добре поєднується з будь-яким з Agile-методів у розробці кінцевих продуктів.

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

Якщо збираєтеся робити інтернет-магазин самі, створіть собі канбан-дошку в будь-якій зручній програмі або навіть у табличці Excel, щоб нічого не проґавити.

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

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