Підводні граблі при створенні інтернет-магазину

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

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

Помилка 0: Немає розуміння етапів розробки проекту

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

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

Розробка більш-менш стандартного магазину на CMS «1С-Бітрікс» складається з наступних стадій:

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

2. Розробка макетів дизайну. Якщо прототипів не було, функціонал сайту закладає дизайнер;

3. Коли макети дизайну прийняті, вони віддаються на верстку;

4. Після того, як верстка готова, бекенд-програміст «садить» її на динаміку.

5. Фінальне тестування, реліз.

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

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

Що сталося далі розробникам невідомо ... Та це й не їхня проблема.

Помилка 1: Немає технічного завдання, нерозуміння технології замовником

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

Був випадок, коли техзавдання немає, але є дизайн. Коли проект був готовий, з'ясувалося, що замовник хоче, щоб на сайті можна було оформити замовлення без попередньої його проплати. Відповідно, в CMS «1С-Бітрікс» сутність оплати повинна бути прив'язана до замовлення і не можна додавати оплату без замовлення. Програміст усіма силами намагається донести це до проектного менеджера, який це розуміє, але ніяк не може переконати замовника. Клієнт тупотить ногами і кричить, що не знає такого слова як «не можна». І взагалі, у всіх його друзів є «інтернет-магазини в Америці» і у всіх них замовлення не оформляється, поки не буде оплачене прямо там же на сайті ...

І дійсно: ось він показує інтернет-магазин на CMS Shopify, в якому третім етапом оформлення замовлення є оплата. І ніякої аргумент про особливості архітектури вже не існують. Замовник радіє, менеджер мовчить, програміст розуміє, що доведеться робити. Ненароком згадує, що для приймання платежів на сайті потрібен сертифікат PCI DSS і віддаляється винаходити той самий велосипед.

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

Висновок: вся специфіка проекту повинна бути формалізована і розписана до початку реалізації проекту. Тільки тоді можна дати оцінку можливості реалізування функціоналу і термінів.

Помилка 2: У замовника і виконавця різні техзавдання

Одного разу, надійшла задача реалізувати бекенд частину інтернет-магазину на підряді у іншої студії. Було техзавдання, був частково готовий фронтенд, був навіть старий магазин. Робота закипіла. Іноді в уже готовий функціонал вносилися зміни, але, як показує практика, це нормально. Складалося враження, що замовник стежить за проектом: в цілому його все влаштовує і, час від часу, з'являються невеликі «хотілки» з рідні: «А зробіть, щоб в попап картинка була зліва, а не згори».

Поки не прийшов час презентувати готовий проект.

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

Висновок: техзавдання має не просто «бути», а й дотримуватися всіма учасниками процесу.

Помилка 3: Чому ніхто не любить термінові замовлення?

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

Одного разу на розробку в останніх числах листопада надійшов проект, який вже першого грудня мав бути запущений (був потрібен п'яти сторінковий сайт, на який зав'язаний конкурс, під новорічну промоакцію).

Розробник був попереджений про необхідність овертайму і в суботній обід почався 48 годинний марафон «встигни до дедлайну».

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

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

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

Помилка 4: Найприкріше

Найприкріше для розробника — коли проект зроблений якісно і в терміни, в процесі розробки були реалізовані якісь нові для розробника технології, проект був терміновим і роботи велися з овертаймами (в тому числі у вихідні та святкові дні), а через рік, зайшовши увечері на сайт, видно таку картину:

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

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

Підбиваємо загальні підсумки

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