Product Architecture Professium

Готуємо архітекторів продуктового дизайну. 1 рік, 2 рази на тиждень.

Про курс

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

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

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

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

На цьому курсі ми готуємо Архітекторів продуктового дизайну, які допоможуть динамічно розвивати продукти так, щоб ті існували довго й робили своїх користувачів щасливими.
60 000 грн/семестр

Оплата курсу здійснюється посеместрово, по 60 000 грн за семестр. Можлива оплата у розстрочку.

100+ занять

2 рази на тиждень — щосереди (19:30—22:30) та щосуботи (12:00—18:00).

16 вересня

Перше заняття на курсі відбудеться 16 вересня. Заявки приймаємо до 30 червня.

20 місць

Хто докладе зусилля, візьме для себе все. Інші швидко вилетять.


Яр Бірзул

Директор з продукту robota.ua. В минулому автор та куратор курсу UX Architecture, що є попередником та фундаментом цього професіуму.

Кому буде корисно

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

Мінімальні вимоги:
— 3-річний досвід роботи продуктовим дизайнером.
— Вміння ставити собі та іншим питання «ШОБШО?».
— Наявність мінімум 15 годин на тиждень, вміння викладатися на повну протягом тривалого часу.

Для проходження курсу вам знадобиться власний ноутбук. Протягом навчання будемо працювати з такими програмами: Miro, Slack, Axure, Figma, Jira, Confuence.

Програма курсу

70% практики, 30% теорії — вчимося в умовах, максимально наближених до бойових. Кожен студент спроектує 5 продуктів для реальних бізнес-клієнтів: всі необхідні адміністративні та клієнтські інтерфейси, підготує завдання для фронтенд- та бекенд-інженерів і захистить власні продуктові рішення перед клієнтами.

Деякі з курсових проектів, створені студентами на минулих курсах:
— Setapp for Teams для MacPaw;
— Система управління кіберспортивними аренами для WePlay;
— CRM для Robota.ua;
— ERP для Weblium.

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

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

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

Відповідно до цього, професіум складається з трьох взаємопов’язаних частин.
1. БІЗНЕС

Бізнес-процеси та логіка
На задоволенні яких потреб ми заробляємо? Як перетікають гроші з кишень клієнтів до наших? Як цей процес прискорити?

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

— Об’єктно-орієнтовне проектування.
— Сервіс-дизайн.
— BPML/N.
— Бізнес-логіка.
— Воронка конверсій.
— Flowchart.
— Retention.
— Churn.
— Фронт-офіс.
— Бек-офіс.

Економіка / Біздев
Що треба драйвити, щоб заробити? Чи життєздатна модель?

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

— Бізнес-модель.
— PNL.
— Юніт-Економіка.
— LTV / CAC.
— ARPU.
— AOV та інші цікаві аббревіатури.

Аналітика
Де наш наступний великий шанс? Де потенціал для зростання? Як прийняти правильне рішення?

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

— A/B та MVT-тестування.
— Google Analytics.
— BigQuery.
— Data Studio.
— SQL.

2. ПРОДУКТ

Збір та пріоритезація вимог. Проектування
Що наш продукт буде вміти? Чому саме це?

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

— Потреби.
— Вимоги.
— Обмеження.
— Модель Кано.
— RICE.

Безсердечна реальність
Як наш продукт буде взаємодіяти з користувачем? Як викликати «Ага!» момент? Де й чому користувачі спотикаються і лаються на нас?

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

— Rapid Prototyping.
— Високодеталізоване прототипування.
— Axure.
— Операційне тестування.
— Коридорне тестуваня.
— Eye-Tracking.

Візуальний дизайн
Як зекономити час на макетній рутині? Як викликати потрібні емоції?

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

— Емоційний дизайн.
— Дизайн-система.
— Система компонентів.
— Модульний дизайн.
— Атомарний дизайн.
— БЕМ.
— Figma.
— Підготовка макетів.

3. СИСТЕМА

Комп’ютерна наука
Як продукти влаштовані під капотом? Як спілкуватися з інженерами, щоб порозумітися? Де закінчується фронтенд і починається бекенд?

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

— Бекенд / Фронтенд.
— Фронтофіс / Бекофіс.
— Алгоритми.
— ООП, MVC, HTTP.
— SQL / noSQL бази даних.
— SOLID.
— KISS.
— DRY.
— Enteties Chart.
— Data Flow.
— Funcional.
— Unit.
— Integrational Tests.

Системна архітектура
Як побудувати продукт, який легко підтримувати та масштабувати? Як організувати ефективну взаємодію частин системи?

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

— MVC.
— API.
— GraphQL.
— Моноліт.
— Сервіси.
— Шина подій.
— Черги.
— Sequence Chart.

Специфікація
Як передавати та розповсюджувати знання?

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

— База знань.
— Jira.
— Confluence.
— JTBD.
— User Story.
— Use Cases.
— Блок-схеми логіки поведінки.

Місце проведення

Київ, Projector (вул. Кожум'яцька, 10), місце зустрічі і роботи дизайнерів різних напрямків і спеціалізацій.

[email protected]
097 015-92-72

Реєстрація

Набір на професіум 2021-2022 ще не розпочато. Але ви можете вже зараз залишити заявку, і при відкритті набору, ми одразу надішлемо вам листа з умовами вступу.