Първият ми голям проект за автоматизация беше моментът, в който осъзнах колко критично важно е да се дефинира обхватът на проекта правилно от самото начало.
Клиентът искаше “автоматизация за класифициране на тикети”.”
Мислех си: “Лесна работа, ще я свърша за седмица-две.”
Но след два дни работа, осъзнах, че:
- Нямаше правилно изградена база данни за обучение на LLM модел, който би могъл класифицирайте билетите в Zendesk.
- Клиентът не беше предоставил никакви работещи правила или обосновка защо определени действия са извършени по определен начин.
- Тогава се оказа, че клиентът иска тази автоматизация да класифицира all видове билети, не само един.
- На следващите срещи стана ясно, че те също искат да бъдат извършени допълнителни действия, след като даден билет бъде класифициран и т.н. Разбирате идеята.
Проектът стана пет пъти по-голям от първоначалната задача.
Не защото клиентът лъжеше — а защото нито аз зададох правилните въпроси, нито той знаеше какво е важно да сподели.
И, честно казано, това не е неговата работа.
За тази грешка платих с месеци неплатен труд.
Повтарям — месеци неплатена работа.
Може да се запитате защо продължих…
Защото по-лошо от работа без заплащане е да не си държиш на думата и да не доставиш това, за което си се съгласил.
Този опит в крайна сметка доведе до създаването на Метод HARDEN™ — методология, която не само описва стъпките за изграждане на решение, но и гарантира предвидимост и стабилност през целия процес.
Защото в автоматизацията — точно както във всеки софтуерен проект — дяволът е в детайлите.
И ако го пропуснете по време на фазата на откриване, той ще ви ухапе по време на доставка!
🔍 Където всичко започва
Когато клиент ви каже какво иска да автоматизира, естествената реакция на всеки развълнуван създател е да се втурне директно в решенията:
- “Мога да го направя в n8n!”
- “Ще добавим уебхук тук!”
- “Ще изпратим данните в Supabase!”
Звучи ли ви познато?
Този импулс е добър — показва ентусиазъм, експертиза и искрено желание да се помогне.
Но има проблем.
Представете си да отидете на лекар, който, без дори да ви прегледа, веднага започва да предписва лечение.
- Той не е попитал какво точно го боли.
- Той не е попитал откога се случва това.
- Той не е проверил за други симптоми.
- Той не поръчва никакви тестове.
Резултатът?
Лечението може да е грешно. Или непълно. Или ненужно скъпо.
Същото е и с автоматизацията.
Преди да проектирате решението, трябва да разбереш реалност.
Не това, което клиентът мисли се случва — но какво е всъщност случващо се.
Точно тук влизат в действие двата документа, които спасяват проектите от изненади — и те се превърнаха в неразделна част от начина, по който работим с клиентите днес.
📄 PDD (Документ за проектиране на процес) – Картата на реалността
Представете си PDD като рентгенов анализ на бизнес процеса.
Преди да започнете работа, трябва да проверите съдържанието.
- Къде са проблемите?
- Какво работи?
- Какво не?
PDD е документът, който дава представа за бизнес операциите на клиента.
Отговаря на въпросите, които никой не иска да зададе — но всички трябва:
Кой какво прави и кога?
Не “екипът обработва заявки”, а “Мария получава имейл в 9 сутринта, копира го ръчно в Excel, след което го изпраща на Иван за одобрение”.”
Какви системи се използват?
Не “CRM и електронни таблици”, а “Gmail, Google Sheets, стар Excel файл на работния плот на Мария и понякога WhatsApp групата”.”
Къде се губи време и какви са най-честите грешки?
Не “понякога има забавяния”, а “30% от имейлите не се обработват, защото попадат в спам, а Мария проверява входящата си поща само два пъти на ден.”
Какви са лостовете на възвръщаемост на инвестициите — точките, където автоматизацията би донесла най-голяма стойност?
Не “ще спестим време”, а “ако автоматизираме извличането на данни от имейли, ще освободим 8 часа на седмица = 32 часа на месец = половин човек”.”
Това е Фаза 1 – Откриване в Методът HARDEN™ — моментът, в който картографираме реалността, ограниченията и възможностите.
Без правилно изграден PDD, всяка следваща стъпка е като стрелба в тъмното.
⚙️ SDD (Документ за проектиране на решение) – Архитектурата на бъдещето
Ако PDD е рентгенът, SDD е хирургичният план.
След като разберем процеса, е време да проектираме решението — не на случаен принцип, а с ясна структура.
SDD описва как ще работи новата система.
Не “ще направим автоматизация”, а “ето точно какво ще се случи, стъпка по стъпка, данни по данни, грешка по грешка”.”
Отговаря на въпроси като:
- Как ще бъдат структурирани данните? Какви таблици ще използваме? Как ще бъдат свързани? Какви ключове ще има всеки запис? Пример: Всеки имейл става ред в таблица Supabase “Requests” със 7 колони: ID, sender_email, subject, body, status, created_at, assigned_to.
- Кой може какво? Какви роли и разрешения съществуват? Пример: Мария вижда всички заявки, Иван само тези, които са му възложени. Автоматизацията може само да променя статуса на заявката, а не нейното съдържание.
- Какво се случва в случай на грешки? Празен имейл? Дубликат? Supabase не отговаря? Пример: Ако имейлът няма тема, той се отбелязва като “needs_review” и се изпраща известие до Мария.
- Как ще се измерва успехът? Не “ще работи по-бързо”, а конкретни КПИ: Пример: Времето за обработка намалява от 15 минути на 30 секунди, грешките падат под 2%, 95% от имейлите се обработват автоматично без човешка намеса.
Това е Фаза 2 – Дизайн в метода HARDEN™.
Тук PDD става конкретна техническа рамка за развитие.
Без SSD, имате идея.
Със SSD имате план.
💡 PDD + SDD = Стабилен Проект
Много хора си мислят, че автоматизацията “просто се случва” — натискате няколко бутона, свързвате някои приложения и сте готови.
Но нека разбием този мит с един прост въпрос:
Ще построиш ли къща без план?
Вероятно не.
Ще наемете архитект да начертае къде ще бъдат стените, вратите и системите.
Тогава инженерът ще превърне тези чертежи в конкретни спецификации — колко тухли, колко дебела изолация, къде минават тръбите.
Автоматизацията работи по същия начин.
Дори когато изглежда, че е “просто свързване на инструменти”, всяка автоматизация е софтуер.
То има логика.
Има данни, които се движат между системите.
Има потенциални грешки и зависимости.
И точно като къща — Ако не започнете с ясен план, рискувате да изградите нещо, което изглежда готово отвън, но не работи отвътре.
Затова софтуерните компании прекарват десетки часове в планиране, преди да напишат и един ред код.
Не за да се усложняват нещата — а защото опитът ги е научил, че без ясна карта на реалността и солиден технически план, проектите се провалят.
В този свят две роли са ключови:
Ръководителят на проекта – навлиза в бизнеса, задава въпроси и картографира какво се случва в момента. Те създават ПДД, документът, който гласи “това е днешната реалност”.”
Продуктовият собственик – взема тази карта и я превръща в план за действие. Те създават SDD, документът, който гласи: “ThЕто как ще изглежда решението утре.”
PDD е основата.
SDD е архитектурата.
Заедно те гарантират, че проектът няма да се срине при първата промяна, няма да стане два пъти по-скъп и няма да разочарова клиента.
И така, да — може да звучи като зациклила плоча (с причина) — но точно този подход трябва да внесем в света на автоматизацията.
Защото ако искаме проектите ни да бъдат стабилни, измерими и печеливши, трябва да спрем да се преструваме, че автоматизацията е нещо различно от софтуер.
То е софтуер — и той заслужава същото ниво на професионализъм.
🧩 Когато обхватът е грешен
В моята практика съм виждал два основни сценария, когато обхватът на проекта не беше правилно дефиниран:
- Проектът се развива и става много по-голям от първоначалната задача, защото по пътя се появяват нови зависимости.
- Проектът претърпя значителни промени, защото първоначалното разбиране на процеса беше или повърхностно, или неточно.
И в двата случая резултатът е един и същ - разходите се увеличават, а доверието намалява.
Първият ми урок за това колко скъпа може да бъде грешката в обхвата дойде от самия проект, който започна тази история — класификаторът на билети на Zendesk.
Като се върна назад, очевидно е: обхватът започна още на първата среща.
Не защото клиентът беше неясен, а защото аз не бях готов да задам правилните въпроси.
Не осъзнавах, че зад фразата “искаме автоматизация, която класифицира тикети” се крие цяла гора от сценарии, зависимости, подтипове и правила “ако… тогава…”.
Първо, беше един вид билет. После седем.
Тогава всеки от тези седем имаше между шест и осем подтипа, всеки изискващ различно действие.
В крайна сметка трябваше ръчно да класифицирам десетки хиляди билети, за да обуча модела и да идентифицирам модели.
Най-големият парадокс?
Никой не беше излъгал.
Никой (включително аз) не знаеше колко много не знаехме.
В крайна сметка автоматизацията беше възстановена три пъти от нулата.
Бюджетът — непроменен.
Хронологията — утроен.
Причината?
Без рамка, без процес, без PDD или SDD.
📉 Какво наистина се обърка
- Нямаше рамка за откриване. Нямах контролен списък и разчитах само на “разговор”.”
- Комуникацията беше грешна. Говорих със служител, който показваше задачи, а не с човек, който взема решения.
- Скрити зависимости. Zendesk имаше вътрешни скриптове и бизнес правила, които бяха недокументирани.
- Няма управление на промените. Всяко “малко допълнение” прерасна в мащабно отклонение от обхвата.
Резултатът?
Месеци неплатен труд — възстановяване на едно и също нещо отново и отново, просто защото липсваха основите.
🧠 Как да избегнем това
След този проект въведох едно желязно правило:
Никога не започвайте автоматизация без PDD и SDD.
Това не е бюрокрация — това е бронежилетка за всеки проект.
Дори и клиентът да дойде с готова идея, ние винаги започваме отначало.
Защото между “Искам автоматизация” и “Знам точно как работи моят бизнес процес днес” има огромна пропаст.
И нашата работа е да го затворим.
🚩 Предупредителни знаци за непълно откритие
- Клиентът говори за резултат (“изпрати имейл”) но не и процес (“кой го изпраща, кога и защо”).
- Не е ясно кой взема решения в процеса.
- Достъпът до API и ограниченията не са тествани.
- Няма човек, който разбира защо бизнесът работи по определен начин, само как.
- Клиентът казва: “Това е лесно”, без доказателства.
🎯 Убийствени въпроси, които винаги разкриват скрити рискове
- “Опишете стъпка по стъпка какво се случва от момента, в който пристига заявка, докато не бъде завършена.”
- “Какво ще стане, ако нещо се обърка?”
- “Кой взема решението в тази стъпка — човек или система?”
- “Има ли изключения от това правило?”
- “Колко често се променят тези правила?”
- “Как изглежда успехът? Как ще разберем, че автоматизацията работи?”
Тези въпроси рядко дават перфектни отговори - но те винаги разкриват къде са рисковете и къде се изисква по-задълбочен анализ.
⚙️ Какво се промени в Marinext AI
След този проект въведохме вътрешен Контролен списък за откриване че всяка автоматизация трябва да премине през това.
PDD и SDD станаха задължителни.
Без тях не започваме фазата на изграждане.
Те не само определят техническите изисквания — те представляват психологическия комфорт и на двете страни.
Никой не гадае. Всичко е прозрачно, подписано и проследимо.
🎯 Формула за успех: Методът HARDEN™
PDD и SDD са в основата на първите два етапа на Метод HARDEN™ — Открийте и проектирайте.
Те не са само документи.
Те са механизми за контрол, предвидимост и доверие.
| ФАЗА | ЦЕЛ | ДОКУМЕНТ |
| Стъпка 1: Открийте | Разкрийте реалността, процесите, ограниченията, точките на възвръщаемост на инвестициите | ПДД |
| Стъпка 2: Дизайн | Дефинирайте новото решение — логика, данни, роли, резервни сценарии | SDD |
Методът HARDEN™ се роди от истинска болка — месеци загубена работа и нощи, прекарвайки в пресъздаване на едно и също нещо за трети път.
Днес не е просто процес — това е гаранция за предвидимост.
Може да нямате перфектен проект.
Но ще имаш един, който няма да се разпадне.
