Лекція 6. Структуризація проекту

Основою для планування і виконання всього проекту є ієрархічна структура робіт, що розробляється в ході уточнення змісту проекту (WBS). При цьому методи структуризації проекту зводяться до двох:

"зверху-вниз" (дедуктивний метод top-down approach) - визначаються загальні завдання, на основі яких далі здійснюється деталізація рівнів проекту;

"знизу-вгору" (індуктивний метод bottom-up approach) - визначаються приватні завдання, а потім відбувається їх узагальнення.

Для структуризації проекту використовують низку спеціальних моделей:

дерево цілей; дерево рішень; дерево робіт; організаційну структуру виконавців; матрицю відповідальності; мережеву модель; структуру споживаних ресурсів; структуру витрат. Дерево цілей (рис. 13) – це графи, схеми, показують, як генеральна мета проекту розбивається підцілі наступного рівня. Дерево - це пов'язаний граф, що виражає підпорядкування та взаємозв'язку елементів. В даному випадку такими елементами є цілі та підцілі.

Подання цілей починається з верхнього рівня, далі вони послідовно розукрупнюються. При цьому основним правилом розукрупнення цілей є повнота: кожна мета верхнього рівня повинна бути представлена ​​як підцілі наступного рівня вичерпним чином. Одночасно менеджери проектів та керівники середньої ланки представляють свої цілі та плани щодо досягнення цих цілей (знизу-вгору). Усі розбіжності у баченні цілей, завдань та способів їх досягнення мають бути вирішені у процесі обговорення та переговорів між керівниками вищої та середньої ланки.Відповідно до одного з найпоширеніших підходів до визначення цілей проекту (SMART), вони мають бути:

конкретними (Specific), тобто. е. визначальними, що має бути досягнуто і до якого терміну;

вимірними (Measurable) за допомогою ціни, якісних та кількісних параметрів;

досяжними (Attainable) у межах знань, досвіду, інтенсивності споживання ресурсів тощо;

реалістичними (Realistic), тобто. е. досяжними, але потребують зусиль;

контрольованими (Trackable), тобто. е. узгодженими за датами та методами виміру досягнутого успіху.

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

Ієрархічна структура розбиття (декомпозиції) робіт (WBS – Work Breakdown Structure) – ієрархічна структура послідовної декомпозиції проекту на підпроекти, пакети робіт різного рівня, пакети детальних робіт. WBS є базовим засобом створення системи управління проектом, т.к. до.дозволяє вирішувати проблеми організації робіт, розподілу відповідальності, оцінки вартості, створення системи звітності, ефективно підтримувати процедури збору інформації про виконання робіт та відображати результати в інформаційній управлінській системі для узагальнення графіків робіт, вартості, ресурсів та дат завершення.

Підставою декомпозиції WBS можуть бути:

компоненти товару (об'єкта, послуги, напрями діяльності), одержуваного внаслідок реалізації проекту;

процесні чи функціональні елементи діяльності організації, що реалізує проект;

етапи життєвого циклу проекту; основні фази;

підрозділи організаційної структури;

географічне розміщення просторово – розподілених проектів.

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

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

оцінка термінів, вартості та ризиків; елемент може бути розбитий більше логічно; елемент може бути виконаний відносно швидко (80 годин).

Для наочності та простоти автоматизації використання WBS кожному елементу декомпозиції надається унікальний ідентифікатор, що відповідає рівню і, наприклад, порядковому номеру на рівні з використанням роздільників типу табуляції, розділових знаків тощо (рис. 14).

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

Організаційна структура виконавців (OBS – Organization Breakdown Structure). Для забезпечення ефективного управління проектом необхідно знати, яка організація (виконавець) є відповідальною за кожен пакет або рівень дерева робіт. Це можна зробити з допомогою схеми організаційної структури проекту. У цій схемі керівник проекту знаходиться на її верхньому рівні, а на нижчих рівнях послідовно розташовуються відділи, необхідні для функціонального управління роботами,

або окремі виконавці, які залучаються до реалізації окремих пакетів робіт (рис. 15). Ці рівні іноді відповідають рівням WBS.

Мета OBS полягає у вказівці не тільки виконавців робіт для кожного пакету, а й у визначенні відділів організацій, відповідальних за виконання відповідних робіт.

Матриця відповідальності (Responsibility Matrix) пов'язує пакети робіт з організаціями-виконавцями на основі WBS та OBS. У матриці визначаються основні виконавці з пакетів робіт. Матриця відповідальності забезпечує опис та узгодження структури відповідальності за виконання пакетів робіт. Вона являє собою форму опису розподілу відповідальності за реалізацію робіт із проекту із зазначенням ролі кожного з підрозділів. Матриця містить список пакетів робіт WBS по одній осі, список підрозділів та виконавців, які беруть участь у виконанні робіт, за іншою (рис. 16). Елементами матриці є коди видів діяльності або відповідальності (з попередньо визначеного списку) та/або вартість робіт. Матриця також може відображати види відповідальності

конкретних керівників ті чи інші роботи.

Кількість видів відповідальності може бути різним залежно від специфіки проекту та його організації. Крім того, в матриці можуть бути відображені ролі людей, які не задіяні безпосередньо в проекті, але які можуть надавати підтримку в роботі команди. Рекомендується

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

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

Мережеві моделі (Project Network Diagram). Мережеві графіки (рис. 17) є втіленням плану дій проекту на робочий розклад. Вони є фундаментальною основою моніторингу та контролю робіт проекту.

Разом із планом та бюджетом вони є найголовнішим інструментом управління проектами.

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

Структура споживаних ресурсів (RBS – Resource Breakdown Structure). Для аналізу коштів, необхідні досягнення цілей і підцілей проекту, здійснюється структуризація ресурсів різних типів. Ієрархічно побудований граф (форма графа RBS схожа на форму графів WBS та ORG) фіксує необхідні на кожному рівні ресурси для реалізації проекту. Наприклад, на першому рівні визначаються матеріально-технічні, трудові та фінансові ресурси. Потім матеріально-

технічні ресурси диференціюються на будівельні матеріали, машини, устаткування; будівельні матеріали на складовані та нескладні тощо. буд. Фінансові ресурси утворюють структуру вартості (ABS – Account Breakdown Structure).

Особливу роль у досягненні цілей проекту відіграє наявність у замовника комплексу якісно-виконаної проектно-кошторисної документації (ПСД). Існують різні точки зору на місце проектування в

життєвий цикл проектів. Багато фахівців вважають його ключовим.

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

Порядок організації та проведення тендеру на проектні роботи визначається інвестором (замовником). Підготовка тендерної документації здійснюється організацією, яка має ліцензію. Для організації та проведення тендеру на проектні роботи створюється тимчасова комісія –

Тендерний комітет (ТК). До складу ТК входять представники замовника, а також експерти зі спеціальних питань.

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

економічні критерії та вимоги).Фінансування діяльності ТК та підготовки тендерної документації здійснюється за рахунок інвестора (замовника). Ці витрати можуть бути повністю або частково відшкодовані шляхом продажу тендерної документації претендентам. Тендер на проектування

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

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

Робоча документація для будівництва розробляється відповідно до державних стандартів СПДС (системи проектної документації будівництва) та уточнюється замовником та проектувальником у договорі (контракті) на проектування.

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

Разом із завданням на проектування замовник видає проектувальнику таку інформацію: обґрунтування інвестицій; рішення місцевого органу виконавчої влади про попереднє узгодження місця розміщення об'єкта; акт вибору земельної ділянки; архітектурно-планувальне завдання; технічні умови на приєднання проектованих об'єктів до джерел постачання, інженерних мереж та комунікацій; відомості про проведені з громадськістю обговорення рішень про

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

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

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

Держбуд Росії запровадив єдиний порядок проведення експертизи містобудівної документації та проектів будівництва, суть якого зводиться до наступного:

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

документація та проекти затверджуються тільки за наявності позитивного висновку органів державних експертиз (а в деяких випадках і за погодженням з органами державного нагляду);

Основною проектною стадією, яка підлягає експертизі, є ТЕО.

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

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

за фінансування з допомогою державних капітальних вкладень – Держбудом Росії чи зацікавленими міністерствами і;

при фінансуванні за рахунок капітальних вкладень з бюджетів суб'єктів Російської Федерації - відповідними органами державного управління або в установленому порядку;

при фінансуванні за рахунок власних фінансових ресурсів, позикових та залучених коштів інвесторів (включно з іноземними) затверджуються безпосередньо замовниками (інвесторами).

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

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

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

Запитання за матеріалами лекції:

1.Перерахуйте моделі, які використовуються для структуризації проекту.

2. Як визначається прийнятний рівень декомпозиції?

3. Що може бути основою декомпозиції WBS?

4. Вкажіть загальний порядок проведення тендерів на розробку проектно-кошторисної документації (ПСД).

5. Перерахуйте основні етапи розробки ПСД.

6. Перелічіть функції менеджера проекту під час проектування.

7. Наведіть порядок експертизи ПСД.

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

Ось притягли вам з полювання мамонта: вищий за вас на зріст, вгодований і на вигляд поки неїстівний. Що робити? Декомпозувати, звісно: лапи окремо, шкіру окремо. Але з чого розпочати? І коли хоч приблизно буде готова вечеря?

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

рівні декомпозиції

Здавалося б, простіше простого: ріжемо проект на великі частини, ці частини ще на частини, а ті частини знову на частини. Але чи справді все так просто?

1 рівень. Великі блоки чи компоненти

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

2 рівень. Сторінки сайту або екрани мобільного додатка

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

приклад

Для e-commerce основний сценарій - продавати, а шлях користувача в ньому має такий вигляд: каталог → список товарів → картка товару тощо.

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

Коли сценарій розкладається на екрани, шансів помилитися стає менше. Але пам'ятаєте, що кожен сценарій варто перевіряти на пов'язаність — чи вам достатньо цих екранів, щоб цей сценарій здійснився?

приклад

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

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

3 рівень. Зміст екранів

У випадку на екранах можуть бути якісь вкладки або якісь блоки - грубо, вкладені екрани. Наприклад, сторінка кошика/оформлення замовлення - тут завжди є блок товарів зі своїм сценарієм (додати-зменшити-очистити), а також блоки доставки, оплати, авторизації, бонусної системи тощо. Бувають ситуації, коли ці блоки також розбивають на екрани кроками. Залежить від рішення, прийнятого за підсумками аналітики, — буває, що зручніше їх все-таки «злити» докупи.

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

Коли ви добираєтеся до третього рівня, потрібно бути супер-уважними, тому що на сторінці можуть з'являтися різні речі. І важливо розуміти, звідки вони там узагалі беруться — від цього сильно залежатимуть ваші оцінки.

Звідки ця хрень на сторінці?

Отже, ви дісталися якогось блоку або сторінки. Саме час запитати себе «Звідки це на сторінці?!». Але проджекти, аналітики та аккаунт-менеджери (і навіть замовники) ось тут часто-густо лінуються — «подумаємо про це потім».

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

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

Якими можуть бути варіанти, звідки беруться дані на сторінці?

Варіант 1. Хардкод

Найпростіший у реалізації варіант відповіді на наше запитання – хардкод. Це означає, що програмісти сіли, прямо в коді зафігачили якусь штуку і тепер поміняти її можуть тільки вони. Найчастіші блоки, з якими так роблять - логотипи компаній, іноді посилання на соцмережі, іноді так роблять з меню (все рідше), телефонами (погано!), Декоративними елементами на верстці. Все це більш-менш розумні моменти. Нерозумно, це коли код зашиваються, наприклад, ВСІ сторінки чи SEO-тексти блоками.

Варіант 2. Включається область

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

Варіант 3. З адмінки (з бази даних)

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

Але чи достатньо буде розуміти, з якої сутності та з якого поля виводяться дані? Не зовсім.

Наприклад, це формула

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

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

Бачите формулу — копайте глибше. У неї всередині є коефіцієнти — а звідки беруться ці коефіцієнти?

Ось через це про формули ніхто не любить думати:)

Наприклад, це файл

Залежно від використовуваної технології буває, що частина даних зберігається у файлах.

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

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

- Володимир Завертайлов, CEO & Founder

Як дані потрапляють у базу даних?

Зазвичай адміністратор або контент-менеджер сідає та забиває дані ручками. Тоді тут має виникати питання, а чи вистачить йому стандартних компонентів адмінки для цього. Для цього ПМ повинен бути дуже добре знайомий із можливостями стандартної адміністративної панелі. А ще з ними має бути знайомий аналітик і тестувальник (про кодера, зрозуміло, мовчимо). У Сибірікс всі QA-фахівці проходять базовий курс контент-менеджера, щоб розуміти, на що здатна адмінка. Ну, а про те, що QA-спеці у нас зазвичай виростають у проджект-менеджерів, ми вже якось писали.

приклад

У вас на дизайні є слайдер, де розставлені точки, на кліку на які відкривається спливашка, в якій є фотографія, опис та посилання на кудись. Запитання: як розставляти ці точки? Як варіант – координати X та Y, але навряд чи контентник буде щасливий від такого функціоналу. А отже, доведеться щось вигадувати. І отже, в кошторис треба це закласти.

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

Варіант 4. Інтеграція зі стороннім ресурсом

Одне з джерел даних у базі — контент користувача. І тут важливо розуміти, як він потрапляє до бази.На цьому етапі часто втрачається один із великих сценаріїв: наприклад, як користувач вносить відгуки. У відгуків часто буває рейтинг - штука на вигляд проста, але всередині вона може бути досить складно організована. У чого більший рейтинг? Там, де поставили одну оцінку в 10 балів, чи десь 1000 оцінок, але різних? Середньоарифметичне тут працює погано. Але хитрі алгоритми є – привіт, ще один резерв у кошторисі.

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

Парсинг - не найприємніша тема. Коли вам кажуть «сходіть за цими даними на сторонній ресурс і акуратно все поцупіть», закінчується це найчастіше погано. А коли ще цих ресурсів 10-15-20, тоді взагалі смерть. Тому що дані або структура на них, як правило, можуть змінюватися, а ви про це дізнаєтеся в останню чергу, коли все вже відвалиться.

Інша проблема — адміни сайтів, з яким паряться дані, не надто щасливі, що ці дані хтось «краде», і всіляко захищатимуться. А це призводить до «падіння» парсингу та потрапляння до чорних списків. Ви спробуєте з цим боротися додаванням будь-яких платних proxy — коротше цілий квест. Є спеціальні послуги для організації парсингу - наприклад, Mozenda, Automation Anywhere, Beautiful Soup, WebHarvy або Content Grabber (повний список з 30 сервісів шукайте тут).

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

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

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

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

Як все це «подружити»

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

Як тільки ви чуєте слово "калькулятор" або "вважається", напружуйтеся :) Коли є інтеграція зі стороннім сервісом - теж.В іншому нічого страшного, і все досить прозоро :)

Коли це може не спрацювати

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

Успіхів у декомпозиції та частіше заглядайте до нас на YouTube-канал за новими корисними відео для проджектів (і не тільки)!

Декомпозиція: як спростити собі життя та досягти результатів

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

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

Що таке декомпозиція?

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

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

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

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

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

Наприклад, мета «більше заробити» дуже розмита. Мета: «заробляти за місяць $Х» точніша. Її легше розбити:

• «попросити підвищення на роботі»,
• «розглянути варіанти зміни роботи», або
• "Знайти додатковий заробіток".

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

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

Відмінності декомпозиції з інших видів планування

Декомпозиція здається дуже знайомим принципом: багатьом відома фраза «слона треба їсти частинами». Але чим декомпозиція відрізняється від інших принципів планування і чим добрий саме цей підхід?

• Логічність: декомпозиція має на увазі завжди єдину логіку в системі.
• Рівні рівні: розподіл мети на рівні завдання, однакові за часом або за кількістю ресурсів, що витрачаються, у своїй площині.
• Ієрархія: від складного до максимально простого і вирішуваного.
• Дрібні складові: що менше і зрозуміліше, то краще. Декомпозиція вважається зроблена, коли не залишилося що розбивати. Останні завдання можна виконати за обмежений час приблизно за пару годин.

Декомпозиція мети «організувати нараду»: на схемі видно, що прописана як мета, а й метод її здійснення (имейл, вручну тощо. буд.)

• Час: завдання мають чітке положення в часі. Тобто після закінчення декомпозиції можна спрогнозувати час виконання мети.
• Чіткість формулювань: все, що буде написано у вашому плані, має бути зрозумілим і вам, і іншим членам вашої команди. Крім формулювань завдань, краще використати ще й ознаки досягнення. Наприклад, запитати себе: «Які ознаки означатимуть те, що мети досягнуто чи завдання вирішено?».

Декомпозиція явно не завершена: адже незрозуміло, по-перше, як саме завдання виконуватимуться, а по-друге, не вказано ознак їх виконання

• Цілісність: при декомпозиції не можна включати ті завдання, які допомагають досягненню мети.

Навіщо потрібна декомпозиція?

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

Оцінити реалістичність проекту та цілі

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

Усвідомити всі завдання на етапах

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

Ви не помітили цього спочатку або не думали, що це допоможе досягненню мети. А декомпозиція вам у цьому допомогла.

Поставити здійсненні завдання

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

Розставити пріоритети

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

Зрозуміти порядок завдань

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

Побачити всі кроки

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

Оцінити терміни

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

Сформувати ресурси

Для кожного завдання стає зрозуміло, скільки часу, сил і уваги потрібно виділити на її виконання або кому її делегувати. Тоді ви мобілізуєте ресурси для всієї команди та можете підрахувати витрати.

Оцінити досягнення

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

Провести більш точну оцінку

Декомпозицію можна застосовувати й у опитуваннях. Наприклад, якщо ви хочете дізнатися рівень задоволеності покупців вашим продуктом, ви можете так і запитати «Оцініть від 1 до 10, наскільки вам подобається наш продукт».

Декомпозиція ж передбачатиме розбивку на кілька питань:

• «Оцініть, наскільки продукт простий у освоєнні»,
• «Оцініть, наскільки продукт візуально привабливий», та
• "Оцініть привабливість ціни товару".

За допомогою декомпозиції ви отримаєте точніші та надійніші відповіді.

Як зробити декомпозицію?

Застосовувати принцип практично можна, запам'ятавши принципи.

1. Ставте чітку сформульовану мету. Чим зрозуміліше формулювання, тим простіше вам до нього йти. Не забувайте прописати критерії досягнення. Наприклад, "збільшити кількість продажів на 100".
2. Виявляєте основні завдання досягнення. Не завжди ця мета міститиме десяток дрібних завдань, можна обмежитися одним етапом. Наприклад, "збільшити конверсію", "запустити рекламу", "провести акцію", "оновити дизайн на сайті".
3. Перевіряєте, чи є в поставлених завданнях зайві або такі, що не належать до мети. У прикладі вище це пункт «оновити дизайн сайту». Він безпосередньо не відноситься до збільшення продажів.
4. Далі розбиваєте великі завдання на дрібні. Найкраще кожну з них поділяти окремо, щоб не заплутатися. Наприклад, під "запуском реклами" ми пишемо: "придумати слоган і текст", "створити ілюстрацію для банера з нашим лого", "створити банери" та інші завдання.
5. Наступним етапом перевіряєте підзавдання, які написали. Якісь із них повторюватимуться або стануть зайвими, тобто не ведуть до досягнення мети. Тоді їх слід забрати.
6. Якщо ж завдання потрібно розділити на ще дрібніші, діліть та перевіряйте їх.

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

Як використовувати декомпозицію?

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

Є кілька варіантів декомпозиції у бізнесі, про них і поговоримо.

S.M.A.R.T.

Це концепція, яка допомагає опрацювати саму мету, перш ніж ви почнете ділити її на завдання. S.M.A.R.T. розшифровується: Specific, Measurable, Attainable, Relevant, Time-bound.

Від вас вимагається уточнення мети за п'ятьма параметрами:

• S - Конкретність. Результат буде конкретним, зрозумілим і чітким.
• M - Вимірюваність. Результат змінюється у кількості чогось чи інших показниках.
• A - Досяжність. Мета здійсненна фізично.
• R - Актуальність. Ваша це мета чи нав'язана? Допоможе вона бізнесу чи ні?
• T - Обмеженість за часом. Якщо ви пропрацювали усі попередні пункти, тоді ви готові поставити мету та визначити її чіткий дедлайн.

Перевірка мети після її постановки за концепцією S.M.A.R.T.

Покрокова декомпозиція

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

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

Декомпозиція у вигляді Mind map

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

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

Інтелект-карта для планування відпустки Тоні Бьюзена (з книги Інтелект-карти.
Повний посібник з потужного інструменту мислення» видавництва МІФ)

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

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

Висновок

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

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

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

Сервіс Vitamin tools теж показує вам загальну картину: ви розбиваєте рекламний бюджет на кілька облікових записів (TikTok, Яндекс Директ, Facebook та інші) і бачите їх усіх в одному вікні. Така розбивка дозволяє контролювати ваші кошти, бачити, куди саме ви їх направляєте і який ви з цього отримуєте фідбек.