Як уникнути багатьох проблем в розробці великого eCommerce проекту на Magento 2 — бачення керівника проектами

20 Травня 2024

наступна стаття
Яна Кравець

Project Manager

Яна  Кравець
Як уникнути багатьох проблем в розробці великого eCommerce проекту на Magento 2 — бачення керівника проектами

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


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

Все починається з контрактів

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

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

  2. Fixed Price — це фіксована ціна певного проекту або його частини. Цей тип контракту підходить проектам, що детально описані, погодженні і зміна функціоналу не передбачена до моменту здачі проекту;

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

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

Точки дотику команд

Давайте детально розглянемо проект, що може бути підпорядкований за типами контрактів Time and Material, або Fixed Price та проблеми, з якими стикаються багато компаній розробки. Головною проблемою є розуміння свого продукту, можливість інтерпретувати та донести ідею до команди розробників. Зараз я би хотіла зачепити тему менеджменту під час розробки будь-якого проекту.

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

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

  1. Я сам знаю що я хочу, я все розкажу і сам буду все приймати;

  2. Я прийшов до вас, я вам довіряю, зробіть нормально.

Б’юся об заклад, у 99% за першим типом проблем можуть виникати такі непорозуміння:

  • Команда розробників, особливо на початку, потребує великої кількості часу на збір всіх ваших потреб та бажань, стосовно проекту; 

  • після початку робіт, команді потрібні будуть часті запити, зустрічі, створення та погодження всіх user story за проектом. На це потрібен буде час та обов'язкове ваше занурення в саму розробку;

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

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

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

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

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

Довіра має бути виправданою

Давайте тепер розглянемо другий варіант, коли ви довіряєте професіоналам.

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

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

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

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


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

Baner articles 2023.png


Схожі статті
Записатись на консультацію

Ми зв'яжемось з Вами протягом 10 хвилин