Проектування великого проекту на прикладі аналога Alibaba.com

Багато розповідаю про проектування: як користуватися Axure або Sketch, які функції повинен містити сайт, як правильно спроектувати сторінку товару. Це все, безумовно, дуже корисно, але не показує повну картину того, що відбувається в проектуванні. В інтернеті навіть немає жодного повного прикладу технічного завдання на проекти такого рівня. Насправді, щоб створити великий сайт, потрібно витратити сотні годин на дослідження, прототипування і розробку детального ТЗ. У цій статті я вперше в рунеті покажу всі етапи проектування та результати по них, повний динамічний прототип (більше 150 прототипів) і велика ТЗ (більше 200 сторінок опису). Все це ми будемо робити на прикладі проектування аналога найбільшої в світі E-commerce майданчика «Alibaba.com».

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

Саму технологію проектування я вже раніше описував у популярної на Хабре статті «Серйозне проектування серйозних сайтів: частина 1 і частина 2» — більше 170 тис. переглядів. Так як ми робимо аналог вже працюючого і успішного сайту, то у нас не буде ряду етапів, або вони будуть мінімальними. Зокрема, збір вимог, мети проекту і клієнта, ЦА і персонажі, дослідження конкурентів, задачі-проблеми-рішення, Mind map і структури сайти. Нам потрібно тільки добре вивчити аналог. В принципі, для зручності, можна зробити собі Mind map і структуру сайту, але це швидше за бажанням, без них, в даному випадку, можна обійтися.

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

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

Динамічний прототип
Після вивчення аналога ми можемо приступити до макетування та створення динамічного прототипу. Проектувати можна прямо за розділами і зазвичай воно починається з картки товару, як найважливішої сторінки з великою кількістю зв'язків (якщо мова про E-commerce, в інших типах проектів потрібно починати з інших сторінок). Для цього ми використовували спеціальну програму Axure, яка дозволяє не тільки проектувати інтерфейси, але і створювати динамічний прототип, без чого проектування буде незавершеним. Так як проект дуже великий, все прототипи ми пронумерували і зробили вкладеності. Коли в проекті десятки і сотні макетів, без такої вкладеності можна дуже легко загубитися. Сам вихідний файл вийшов дуже великим, тому, ми розділили вихідний файл на декілька частин, при цьому зберігши нумерацію, так що перейшовши в динамічний прототип, нехай вас не бентежить неповний список сторінок зліва, таких файлів 4 штуки.

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

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

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

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

Метод контролю якості досить простий: QA Engineer, з великим користувача досвідом і знаннями предметної області, переглядає всі розроблені макети, натискає на кожну посилання, відстежує всі елементи. Якщо щось незрозуміло — задає питання проектувальнику. Якщо щось пропущено або нелогічно — ставить завдання на доопрацювання / перепроектування. Якщо не дотримані внутрішні стандарти якості проектування інтерфейсів — теж ставить завдання на доопрацювання. Саме цей спеціаліст не дозволяє пройти помилок далі. Для того, щоб нічого не упустити і домогтися інтуїтивно зрозумілого інтерфейсу тут ми застосовуємо ті самі користувальницькі сценарії розроблені раніше.

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

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

Особливі вимоги ТЗ:

  • Архітектура сайту — опрацьовує архітектор
  • Вимоги щодо навантажень — опрацьовує архітектор і тім лід
  • Сервера та інфраструктура — опрацьовує системний адміністратор, архітектор і тім лід
  • Вимоги безпеки опрацьовує фахівець з безпеки і тім лід
  • Вимоги по SEO — опрацьовує SEO-шник і інтернет-маркетолог
  • Вимоги до дизайну — опрацьовує дизайнер
  • Вимоги до верстання — опрацьовує верстальник
  • Микроразметка — опрацьовує верстальник
  • UML діаграми робастності — опрацьовує проектувальник і програміст
  • Розмежування прав доступу опрацьовує проектувальник
Приклад таблиці з правами доступу в проекті:



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

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

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

Приклад спроектованого аналога Alibaba.com (основні сторінки):
Хабр обрізає довгі картинки, тому дивіться в динаміці.

Сторінка: Картка товару
» Макет: http://wt9kcs.axshare.com/#g=1&p=1_0_0_0_items_card



Сторінка: Картка послуги
» Макет: http://wt9kcs.axshare.com/#g=1&p=2_0_0_0_service_card



Сторінка: Оголошення
» Макет: http://wt9kcs.axshare.com/#g=1&p=3_0_0_0_obyavleniye_card_item



Сторінка: Головна
» Макет: http://wt9kcs.axshare.com/#g=1&p=9_0_0_0_glavnayam



Сторінка: Магазин
» Макет: http://wt9kcs.axshare.com/#g=1&p=10_0_0_0_magazin



Сторінка: Пошук товару
» Макет: http://wt9kcs.axshare.com/#g=1&p=13_0_0_0_serach_tovar



Сторінка: Каталог. 3й рівень
» Макет: http://dn4p5z.axshare.com/#g=1&p=2_0_0_0_catalog_3uroven_items



Сторінка: Каталог. 2й рівень
» Макет: http://dn4p5z.axshare.com/#g=1&p=3_0_0_0_catalog_2uroven_item



Сторінка: Каталог. 1й рівень
» Макет: http://dn4p5z.axshare.com/#g=1&p=3_0_0_0_catalog_1uroven_item



Сторінка: Каталог. Всі категорії
» Макет: http://dn4p5z.axshare.com/#g=1&p=3_0_0_0_catalog_all_item



Сторінка: Центр допомоги
» Макет: http://dn4p5z.axshare.com/#g=1&p=6_0_0_0_help_center



Сторінка: Реєстрація. Крок 1
» Макет: http://dn4p5z.axshare.com/#g=1&p=8_0_0_0_reg_step_1



Сторінка: Покупець
» Макет: http://l9d2yk.axshare.com/#g=1&p=13_0_0_0_pokupatel



Сторінка: Запити на купівлю
» Макет: http://l9d2yk.axshare.com/#g=1&p=13_1_0_0_zaprosu_na_pokupku



Сторінка: Оформлення замовлення
» Макет: http://l9d2yk.axshare.com/#g=1&p=13_2_0_0_oformleniya_zakaza



Сторінка: Повідомлення
» Макет: http://l9d2yk.axshare.com/#g=1&p=13_3_0_0_soobscheniya



Сторінка: Порівняння товарів
» Макет: http://l9d2yk.axshare.com/#g=1&p=15_0_0_0_comparison



Сторінка: Вибране
» Макет: http://l9d2yk.axshare.com/#g=1&p=14_0_0_0_featured



Сторінка: Постачальник
» Макет: http://sklpox.axshare.com/#g=1&p=13_1_0_0_postavschik



Сторінка: Мої товари
» Макет: http://sklpox.axshare.com/#g=1&p=13_3_1_0_moi_produktu_tovaru



Сторінка: Операції
» Макет: http://sklpox.axshare.com/#g=1&p=13_4_2_0_zakazu_sdelka



Сторінка: Контакти постачальників
» Макет: http://sklpox.axshare.com/#g=1&p=13_6_0_0_kontaktu



Сторінка: Мій профіль
» Макет: http://sklpox.axshare.com/#g=1&p=13_7_0_0_akkaunt



Підводячи підсумок
Людини не в темі даний обсяг виконаної роботи може налякати, проте досвідчені проектувальники, які хоч раз проектували маркетплейс або великий інтернет-магазин помітять, що тут далеко не все. У цьому проекті ми не показали адмінку, яка не менш складна, ніж зовнішній сайт і не показаний адаптив, який потрібно проектувати окремо (рідше, в цілях економії, адаптив робить верстальник на свій розсуд, але це не дуже правильно). Конкретно цей маркетплейс робив фахівець, який спроектував понад 30 різних маркетплейсов і інтернет-магазинів, тому, тут добре опрацьовані зв'язку, спливаючі вікна, логіка та інші елементи. Але по хорошому, не дивлячись на величезний обсяг робіт показаного, там ще потрібно проектувати і проектувати. Тобто цей прототип взяти і використовувати «як є» буде не дуже правильно.

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

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.