Let’s talk

Проектування архітектури для SaaS сервісів, інтернет-магазинів

Проектування архітектури, створення технічного рішення, підбір компонентів і сервісів

15%вартості розробки продукту становить проектування

9ключових артефактів проектування використовуємо

200годин команди на середній проект

Зв'язатися

Детальніше

Нагороди 6 нагород 4 номінації в UI/UX

рейтинги

Всі

Суть проектування як послуги

Щоб почати розробку, потрібно спершу підготувати проектну документацію. У випадку з простими проектами, використовується прототип, коротка функціональна специфікація і user stories. У більшості випадків для рішень, що створюються на базі готових систем і не потрібно багато проектної документації, тому що вже є аналоги і в принципі зрозуміло що потрібно зробити і як воно повинно працювати, система, яка лягає в основу (cms, crm, lms, erp і т.п.) вже містить набір базових функцій і продумувати всі нюанси їх роботи не потрібно.

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

Давайте не будемо робити проектування?

Навіщо витрачати час на проектування, якщо є SCRUM (AGILE)?

"Не витрачаючи час ми швиденько почнемо розробку" або "Ерік Ріс в книзі Lean Startup каже що планувати не потрібно, потрібно швидше робити продукт". – Таке нам іноді говорять клієнти.

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

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

Ця аналогія справедлива і для ІТ. Є прості проекти, де все очевидно і які можна "просто зробити" маючи достатньо досвіду реалізації подібних рішень, але дійсно цікаві та незвичайні проекти вимагають уважного підходу і глибокого опрацювання до того як буде написана перша строчка коду. Більш того це ніяк не суперечить ітераційним і гнучкими методологіями розробки - SCRUM, Lean Startup і інші відомі методики ніяк не передбачають відмову від проектування. Скоріше мова йде про те що потрібно відмовитися від надмірної проектування там де це можливо і за рахунок цього заощадити бюджет і час. Але спроба відмовитися від проектування зовсім і почати реалізовувати незрозуміле і непродумане рішення може обернутися набагато більшими витратами.
Нам потрібно швидше почати, у нас немає на це часу!

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

Реальний приклад з життя:
Компанія F вклала близько $ 120 тисяч в розробку рішення по автоматизації процесів маркетингу і продажів на базі CRM системи іменитого міжнародного вендора. Розробка стартувала під гаслом "нам потрібно це за пів року" і на проект часу не знайшлося. В результаті вже ближче до запуску системи з'ясувалося що система дуже повільно працює, незручна в обслуговуванні і створює більше проблем ніж вирішує. У підсумку систему з горем навпіл впровадили в абонентський відділ, проект закрили і почали розробку нової системи. На цей раз вирішили писати свою з нуля. Але за цей час змінилася економічна ситуація і керівництво поставило задачу - написати своє дешево і за 3 місяці. Звичайно в таких умовах займатися проектуванням часу вже не було і мобілізувавши внутрішніх програмістів компанія відразу приступила до розробки. Як ви думаєте, чи отримала вона вирішення своїх проблем і о котрій годині це в підсумку обійшлося?

15% бюджету

– частка проектування в загальній вартості продукту

Проектування направлено на зменшення невизначеності

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

"Я не хочу заплатити за проект щоб дізнатися, що реалізація моєї ідеї коштує в 10 разів більше, ніж я думав!"

Розуміємо. Але ви ж напевно знаєте що 70% ІТ проектів в принципі не запускаються і заморожуються в процесі? Проектування позбавляє вас від дорогих ілюзій. Хороша новина в тому, що навіть дізнавшись про те що проект коштує дорожче або є більш технічно складним, ніж ви спочатку думали, ніщо не змушує вас його припиняти - завжди можна спростити, відмовитися від складних функцій і перевірити гіпотезу на мінімальній версії, як і пропонує Ерік Райс в Lean Startup, можна знайти інвестиції або спробувати поетапний запуск. Тут вирішувати вам який ступінь ризику і невизначеності ви хочете прийняти. Якщо ви готові до підвищеного ризику - тоді мінімізуйте витрати на проектування і шукайте того хто має схожий досвід, щоб хоч якось убезпечити проект від провалу.

Чому вам все-таки потрібно проектувати?

Все одно проектування не закриває 100% питань, навіщо його тоді робити?

Ви маєте рацію, проектування в ІТ це не зовсім те що можна зробити один раз і відпрацювати за цим проектом до самого кінця розробки. Цьому є навіть наукове пояснення з теорії системного аналізу. Справа в тому що все з чим ми працюємо потрапляє під поняття "складна система" а у складних систем є багато неприємних особливостей, що ускладнюють постановку вимог і прогнозування перебігу проекту. Тому потрібно тверезо оцінювати користь проекту і не робити занадто детальних і надлишкових проектів, зупиняючись по суті на мінімально необхідному для конкретного завдання рівні проектування. Тоді проект не буде аж надто дорогим і може знімати 70-80% невизначеності, що вже суттєво підвищує шанси на успіх. Тобто питання знову зводиться до прийнятної вами ступеня ризику. Чим менше ви хочете ризикувати своєю ідеєю і часом, тим точніше потрібно підходити до проектування.
     Я в цьому нічого не розумію, для мене проект не має цінності, по суті етап проектування потрібен вам самим для того щоб зробити те що мені потрібно, так навіщо ж я буду за це платити?

Якщо це якось резонує з вашими думками - це значить що ви бачили погані проекти і не бачили хороші. Скажіть, чи уявляєте ви гранично чисто і ясно в кожної деталі реалізацію вашої ідеї? 90% людей на це питання скажуть "так, уявляю, але є нюанси які мені не до кінця зрозумілі і вимагають уточнення" (10% скажуть "ні, я розумію в загальних рисах, мені не завадить ваша допомога, хлопці, щоб я краще зрозумів як це повинно працювати). Якщо ви ставитеся до першої групи, то скажіть, чи стикалися ви коли-небудь з тим, що в процесі з'ясування деталей, ви розвиваєте свою ідею аж до того що в підсумку вирішуєте зробити принципово іншим способом ніж вам здавалося правильним спочатку, при цьому ви дуже задоволені результатом?

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

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

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

Це екстремальний підхід до проектування. Evergreen солідарний з Міністерством охорони здоров'я що самолікування небезпечно для вашого (проектного) здоров'я. Звичайно в ІТ все набагато зрозуміліше і можна всьому навчитися, питання тільки швидкості цього навчання і ризиків. Проектування це процес спрямований на зниження ваших ризиків, а проект по шаблону це і є один великий ризик, тому що не містить в собі часто навіть половини необхідних для розробки вимог і даних.

Якщо ви все ж хочете ризикнути, використовуйте наш Чек-лист ТЗ

Артефакти проектування Evergreen

Гортайте, щоб побачити інші причини

Загальна концепція проекту включає в себе бачення проекту, аналіз конкурентного середовища, бізнес-потреба і бізнес-ідею проекту.
Межі продукту визначають собою то що повинно в підсумку вийти і що ми не плануємо перетинати (якщо ми перетнемо ці кордони, це буде вже інший продукт).
Приблизний розрахунок рентабельності і вибір методу реалізації на підставі можливої окупності.
UI прототип і детальні user stories створюємо для того щоб описати всі деталі взаємодії користувачів з нашою системою.
Аналіз і опис бізнес-процесів (БП) проектованої системи . Зазвичай вже є у наших клієнтів в якомусь вигляді, ми намагаємося отримати їх в якості вступних і почати розбирати їх на сутності і підпроцеси. В результаті аналізу створюємо такі документи, в залежності від проекту:
- user stories верхнього рівня абстракції
- use cases для опису сценаріїв взаємодії між декількома системами /персонами /сутностями
- user flow - сценарії роботи користувача з системою (об'єднують в собі ЮС і кейси, показують повний процес від початку до кінця)
Загальна технічна концепція проекту
- Вибір типу архітектури (монолітна або компонентна)
- Декомпозиція монолітної архітектури на компоненти (Наприклад: завантаження файлів, відправка пошти, робота з документами, чат).
- Загальна компонентна технічна схема проекту. Взаємодія компонентів між собою. (Наприклад, завантажувати можна і з галереї і з чату)
- Нефункціональні вимоги до системи: безпека, доступність (браузери і ОС), масштабованість, продуктивність (навантаження сервера), обмеження
Деталізована технічна схема компонентів
- Опис необхідних сервісів для роботи компонента. R & D і підбір сумісних сервісів. (Приклад для завантаження файлів необхідний сервіс APi через який будуть відправляти і отримувати файли).
- Розбивка на мікросервіси
- Схема взаємодії сервісів /мікросервісов
Схема стека технологій
- Підбір стека software реалізації під кожен компонент. Проведення R & D сумісності.
- Рішення tech cases.
- Підбір стека hardware реалізації якщо така має місце
- Підбір рекомендацій по налаштуванню і розміщення проекту на продакшені
- Аналіз сумісності UI інтерфейсів і сервісів
Проектування етапів розробки та впровадження проекту : схема етапів розробки розбита по етапах і з угрупованням по компонентам /сервісів.
Організація процесу і команда необхідна для реалізації проекту

Загальна концепція проекту включає в себе бачення проекту, аналіз конкурентного середовища, бізнес-потреба і бізнес-ідею проекту.
Межі продукту визначають собою то що повинно в підсумку вийти і що ми не плануємо перетинати (якщо ми перетнемо ці кордони, це буде вже інший продукт).
Приблизний розрахунок рентабельності і вибір методу реалізації на підставі можливої окупності.
UI прототип і детальні user stories створюємо для того щоб описати всі деталі взаємодії користувачів з нашою системою.
Аналіз і опис бізнес-процесів (БП) проектованої системи . Зазвичай вже є у наших клієнтів в якомусь вигляді, ми намагаємося отримати їх в якості вступних і почати розбирати їх на сутності і підпроцеси. В результаті аналізу створюємо такі документи, в залежності від проекту:
- user stories верхнього рівня абстракції
- use cases для опису сценаріїв взаємодії між декількома системами /персонами /сутностями
- user flow - сценарії роботи користувача з системою (об'єднують в собі ЮС і кейси, показують повний процес від початку до кінця)
Загальна технічна концепція проекту
- Вибір типу архітектури (монолітна або компонентна)
- Декомпозиція монолітної архітектури на компоненти (Наприклад: завантаження файлів, відправка пошти, робота з документами, чат).
- Загальна компонентна технічна схема проекту. Взаємодія компонентів між собою. (Наприклад, завантажувати можна і з галереї і з чату)
- Нефункціональні вимоги до системи: безпека, доступність (браузери і ОС), масштабованість, продуктивність (навантаження сервера), обмеження
Деталізована технічна схема компонентів
- Опис необхідних сервісів для роботи компонента. R & D і підбір сумісних сервісів. (Приклад для завантаження файлів необхідний сервіс APi через який будуть відправляти і отримувати файли).
- Розбивка на мікросервіси
- Схема взаємодії сервісів /мікросервісов
Схема стека технологій
- Підбір стека software реалізації під кожен компонент. Проведення R & D сумісності.
- Рішення tech cases.
- Підбір стека hardware реалізації якщо така має місце
- Підбір рекомендацій по налаштуванню і розміщення проекту на продакшені
- Аналіз сумісності UI інтерфейсів і сервісів
Проектування етапів розробки та впровадження проекту : схема етапів розробки розбита по етапах і з угрупованням по компонентам /сервісів.
Організація процесу і команда необхідна для реалізації проекту

Ви хочете спроектувати новий додаток або сервіс?

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

Наші контакти

Скачати бриф Он-лайн заява

Цей сайт є українською мовою. Ви можете переключити мову у меню, або зробити це зараз.

переключити