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

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

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

Як ми вирішували проблему оптимізації архітектури проєктів

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

Наша роль у збереженні та оптимізації архітектури проєкту

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

Координація команди та забезпечення стійкості архітектури

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

Наслідки відсутності належної архітектури проєкту

Відсутність належної архітектури проекту може призвести до низки проблем:

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

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

Ефективна комунікація та розподіл завдань у команді

Для ефективної комунікації та розподілу завдань ми активно використовуємо Trello. Картки та списки в цьому інструменті дозволяють чітко структурувати роботу, забезпечуючи task control і прозорість процесів. 

Кожен член команди має доступ до актуальної інформації про завдання та їх виконання, що покращує team collaboration. Ми регулярно проводимо обов'язкові зустрічі раз на два тижні, де кожен має можливість представити свої завдання або підготуватися до нових. Ці зустрічі служать своєрідними чекпоінтами, які допомагають нам контролювати прогрес і актуалізувати завдання, що є важливою частиною project management.

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

Обов'язкові зустрічі – це ключовий елемент нашого підходу до управління проєктами. Вони дозволяють кожному члену команди детально описати свої завдання та оновити "лог задач", який відображає наш прогрес. Це забезпечує прозорість роботи і допомагає новим учасникам швидко включитися в процес, що сприяє ефективному task tracking. Наші внутрішні правила вимагають детального опису завдань, що сприяє кращому розумінню і координації роботи в команді, покращуючи team collaboration.

Комплексне рішення для управління проєктами

Управління low-code / no-code проектами вимагає забезпечення контролю і прозорості як для внутрішньої команди, так і для замовника. Ми розробили комплексне менеджментське рішення, яке поєднує технічні та організаційні засоби для підвищення ефективності та якості управління проєктами. Це рішення було створене не тільки для покращення наших власних процесів, але й для контролю архітектури та виконання реквестів для наших клієнтів. Використання SAAS tools дозволяє нам автоматизувати багато аспектів управління проєктами, що знижує ризики і забезпечує стабільність.

Інтеграція Trello з Google таблицями

Одним із ключових компонентів нашого рішення є інтеграція між платформами Trello і Google таблицями. Цей підхід дозволяє забезпечити прозорість у виконанні реквестів та їх зв'язок з архітектурою проєкту, що полегшує task control. Активне використання Make допомагає автоматизувати передачу інформації між різними сервісами, що значно спрощує процес workflow optimization і task tracking.

Переваги інтеграції для управління проєктами

Таке комплексне рішення поєднує в собі як менеджерські, так і технічні аспекти, забезпечуючи оптимальне виконання завдань, контроль над архітектурою та прозорість для замовника. Це дозволяє уникнути повторної роботи, знижує ризики і забезпечує ефективну team collaboration всіх учасників проєкту.

Детальніше про рішення і чому воно важливе

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

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

Перш за все, для контролю всіх реквестів ми завели Trello. Досить простий інструмент, який дозволяє будь-кому з команди замовника зрозуміти як створювати реквести (задачі). Ми маємо різні дошки для різних команд.

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

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

Цей процес автоматизовано за допомогою платформи Integromat, яка зараз відома як Make. Автоматизація запускається тоді, коли картка досягає певних етапів, зокрема статусу Done (виконано) або Launch (запущено).

Виконані картки (реквести) падають в таблицю протягом 14 днів, і тоді ми зустрічаємось, щоб описати більш детально: що було зроблено, для кого, і в якому асеті. Це вже більше менеджерська частина роботи. Двічі на місяць ми зустрічаємося з командою. Перший раз – для оновлення документа, який ми називаємо "Update Log". Усі задачі фіксуються в цьому документі. А другий раз – ми вносимо всі апдейти в архітектуру.

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

Причина виникнення цього рішення

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

Оптимізація витрат – одна з основних причин

Статистично, середні компанії використовують від 60 до 80 SAAS tools та інструментів, які потрібні для роботи в різних відділах. У нашому випадку, замовник має 56 платних інструментів, які забезпечують виконання всіх необхідних функцій компанії. Щоб ця цифра не збільшувалася, а відповідно не зростали витрати, ми слідкуємо за ними через технічну архітектуру.

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

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

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

В який момент виникла ідея щось таке створити?

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

Конфлікти у роботі – основна причина створення такої архітектури

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

Введення архітектури та таблиць з описами дозволило нам зберігати всю інформацію в одному місці. Це допомагає уникати повторної роботи та конфліктів між завданнями. Як координатори, ми можемо переглядати, що вже було зроблено, і які зміни можуть викликати конфлікти. Таким чином, ми забезпечуємо ефективну координацію роботи команди і оптимізуємо наші процеси, використовуючи SAAS tools для task tracking та workflow optimization.

Ризики та їх мінімізація в архітектурі проєктів

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

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

💡 Risk mitigation або зменшення ризиків – це зниження ймовірності настання ризикової події та мінімізація наслідків її можливого настання.

Наша задача – контролювати цей процес

Якщо вчорашній випадок ми тримали у голові, то у випадку з текмайндером все тримається на папері. Є таблиця, яка описує архітектуру проєктів, яка оновлюється командою. Головне – робота команди. Ми допомагаємо організувати зустрічі та процеси, щоб все працювало відповідно. Це дозволяє уникнути конфліктів і забезпечити workflow optimization.

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

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

Щоб пояснити, як працює наша система, розглянемо кілька практичних прикладів. У нашій команді є 5 дошок для управління завданнями. Кожна з цих дошок структурована за певними категоріями, наприклад, SITE або CRM. На кожній дошці щодня виконується робота, яка включає обробку запитів від замовника або команди замовника, таких як: "Виправте кнопку", "Зробіть це", "Щось не працює". Щодня наша команда працює над такими запитами, забезпечуючи ефективне task tracking.

Управління завданнями за допомогою таблиць

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

1. Bug – помилки, які потребують виправлення.
2. Fix Change Request – запити на виправлення змін.
3. Change Request – запити на зміну, наприклад, змінити кнопку на сайті.
4. Feature Request – запити на додавання нової функції, наприклад, додати нову кнопку на сайт.
5. Epic – великі завдання, які виконуються протягом тривалого часу, наприклад, впровадження нового функціоналу.

Приклад роботи з великими завданнями (Epic)

Розглянемо приклад Epic: команда працює над проєктом "Event tracker", який представляє собою абсолютно новий функціонал. Цей епік розширює нашу архітектуру так само, як, наприклад, перехід компанії з Google Meet на Zoom. Підключення та налаштування Zoom згідно з потребами компанії, з необхідними автоматизаціями – це великий епік.

Наш процес побудований таким чином: кожні два тижні команда збирає виконані завдання в таблицю списком. Потім раз на два тижні ми зустрічаємося, обговорюємо найважливіші запити, кожен член команди пояснює, що було зроблено. Ініціатор зустрічей переглядає виконану роботу, щоб бути в курсі справ, і задає додаткові питання для кращого розуміння ситуації. Це допомагає забезпечити ефективне project tracking та task control.

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

Забезпечення відповідності нових запитів архітектурі

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

Таким чином, команда забезпечує стабільну роботу і уникнення конфліктів у проєкті, гарантуючи workflow optimization та ефективну team collaboration.

Що працює автоматично, а що потрібно робити вручну?

Одна з корисних функцій, яку ми використовуємо – витяг інформації в таблиці. Спочатку Make витягує дані з Trello, а потім Google Script, прив'язаний до таблиці, робить додатковий запит і витягує додаткову інформацію по картках, зокрема, хто створив картку і коли. Це дозволяє нам прорахувати швидкість закриття карток. Ця функція працює автоматично, не потребує додаткових ресурсів і надає багато корисної інформації.

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

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

Щодо архітектури в Miro, то ми переносимо інформацію вручну. Ми пробували автоматизувати процес, щоб дані з таблиць автоматично потрапляли в Miro, але це виявилося незручним. Тому працюємо за принципом culture first, automation second – тобто вдумливо самостійно все описуємо, а у майбутньому автоматизуємо процес, коли побачимо, що автоматизація відповідає нашим вимогам.

Навички та знання, використані під час створення проєкту

Створення ефективної системи управління завданнями вимагає широкого спектру навичок і знань. Ось які саме навички та знання були застосовані під час реалізації проєкту:

Управління проєктами та координація

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

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

Технічні навички та автоматизація

З технічних знань використовувалися наступні:

• Автоматизація процесів. Навички автоматизації у Make дозволили створити зручну інтеграцію між Trello та Google Таблицями. Це забезпечило зручний спосіб контролю та моніторингу завдань.
• Створення дашбордів. Дашборди на основі Google Таблиць дозволили візуалізувати дані про виконані завдання, що покращує data visualization і надає командам чітке розуміння поточної ситуації.
• Productivity tools. Використання продуктивних інструментів допомогло створити зручний дашборд, де можна наочно бачити, що відбувається, а також оцінювати вклад кожного учасника команди в проєкт.

Аналіз типів завдань і внесок команди

Особливу увагу було приділено кількості завдань за різними типами, такими як баги, фічі, change request тощо. Наприклад, в одному випадку здавалося, що працює тільки одна людина, тоді як в реальності – ні. Аналіз показав, що один з учасників отримував усі операційні запити, тоді як інші працювали над великими задачами. Це допомогло зрозуміти реальний внесок кожного члена команди.

Ефективне проведення мітингів

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

Опис архітектури з нуля

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

Використані навички та знання

• Проєктний менеджмент: планування і проведення регулярних зустрічей.
• Автоматизація процесів: інтеграція інструментів для ефективного керування завданнями.
• Створення дашбордів: візуалізація даних та контроль виконання завдань.
• Моніторинг виконання завдань: контроль над прогресом і оцінка внеску кожного учасника.
• Керування ресурсами: оптимальне розподілення завдань і уникнення дублювання роботи.
• Technical solutions development: розробка і впровадження технічних рішень для підтримки архітектури проєкту.
• Data visualization: створення зручних і зрозумілих дашбордів для візуалізації даних.

Як тестували помилки?

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

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

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

Make повністю задовольняє всі потреби з переносу інформації з Trello в таблиці

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

Додаткові рішення та етапи для реалізації в майбутньому

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

Розуміння та контроль контекстних конфліктів

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

Використання нових інструментів та методів

Для подальшого вдосконалення процесу управління проєктами, ми розглядаємо можливість впровадження додаткових productivity tools і technical solutions. Це дозволить не тільки підвищити ефективність роботи, але й забезпечити кращий моніторинг виконання завдань і керування ресурсами. Також, нові інструменти допоможуть нам краще візуалізувати дані і полегшити прийняття рішень на основі чіткої та зрозумілої інформації.

Постійне вдосконалення архітектури

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

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

Як адаптувати рішення для вашого бізнесу

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

Ось план дій для початку процесу:

1. Зібрати список інструментів:
   • Створіть таблицю для списку інструментів, які використовуються в різних відділах, із зазначенням цілей їх використання.
   • Попросіть відділ фінансів надати інформацію про вартість використання цих інструментів.
2. Створити архітектуру інструментів та їх взаємодію в контексті різних команд та задач:
   • Зареєструйтеся в Miro або використовуйте інший інструмент для створення дошки.
   • Продумайте та створіть mindmap або аналогічну структуру для візуалізації архітектури.
   • Додайте інструменти та встановіть логічні зв'язки між ними.
3. Створити таблицю upd_log:
   • Додати в неї необхідні заголовки для ведення журналу оновлень.
4. Інтегрувати в таблицю task manager:
   • Приєднайте таблицю upd_log до task manager, що використовується в компанії, через коннектор.
   • Задачі мають автоматично потрапляти до таблиці на основі критерію "завершені / done".
5. Організувати командні зустрічі:
   • Проводьте командні зустрічі кожні два тижні
   • На першому – опишіть важливі задачі, які вже попали в таблицю upd_log.
   • На другому – опишіть і задачі і нові сутності, та взаємозв’язки, що вносяться у візуалізацію архітектури.

Цей план має на меті створення ефективної системи управління архітектурою технічних рішень у вашій компанії.

Чи можливо застосувати цю систему великим компаніям, як, наприклад, Нова Пошта?

Ця система може бути застосована великими компаніями, такими, як Нова Пошта, але потребуватиме адаптації.

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

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

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

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

Скільки часу зайняло впровадження цього рішення? Які були основні етапи в реалізації, і скільки часу вони зайняли?

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

Основні етапи включали в себе:

1. Підготовка дошки на Trello.
2. Опис правил і процедур для команди.
3. Призначення зустрічі з регулярним плануванням завдань.
4. Створення "логу завдань" для відстеження прогресу.
5. Оновлення архітектури для відображення нового процесу.

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

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

Для кого це може бути цікаво і як заохотити до реалізації архітектури?

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

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

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

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

Економія ресурсів та уникнення зайвих витрат

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

Переваги розуміння та управління архітектурою

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

Як заохотити людей до реалізації архітектури

Для заохочення до реалізації архітектури важливо показати її переваги:

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

Приклад реалізації архітектури для інтернет-магазину жіночого одягу

Розглянемо, як можна реалізувати технічну архітектуру для інтернет-магазину, де 90% асортименту складає жіночий одяг, а 80% з нього — це сукні. Такий бізнес має певні унікальні вимоги, які слід врахувати при побудові та управлінні його технічною архітектурою.

Структура сайту та функціональні можливості

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

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

Автоматизація бізнес-процесів

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

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

Управління ризиками та моніторинг виконання завдань

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

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

Оптимізація роботи з даними та автоматизація

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

Оцінка ефективності команди та управління ресурсами

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

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

Корисна порада від тих, хто вже впровадив рішення для тих, хто ще не наважився

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

💡 IAMPM — єдина онлайн-школа в Україні, що спеціалізується на навчанні нетехнічних IT-спеціальностей (product та project managers, business аналітиків, sales-менеджерів та ін.). Школа оновлює програми відповідно до останніх трендів, проводить практичні заняття з реальними кейсами та допомагає студентам з працевлаштуванням у провідні компанії.

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

Короткий висновок

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

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