Месеци безплатен труд и един урок, който промени всичко: как се роди HARDEN Method™
Моят първи голям проект за автоматизация беше онзи момент, в който разбрах колко критично важно е да се определи правилно обхватът на един проект още от самото начало.
Клиентът искаше “автоматизация за класифициране на тикети”.
Аз си помислих „лесна работа”, ще я направя за седмица-две.
Но след два дни работа разбрах, че:
- Няма правилно изградена база данни, с която да обуча LLM модел, който класифицира тикетите в Zendesk.
- Клиентът не предоставя никакви правила за работа и защо дадено действие се извършва по този начин.
- След това се оказа, че клиентът иска тази автоматизация да класифицира всички типове тикети, а не само един.
- При следващи срещи се оказа, че клиентът иска да се извършват и други действие след като един тикет е класифициран и т.н. Схванахте идеята.
Проектът стана 5 пъти по-голям от първоначалното задание.
Не защото клиентът лъжеше.
А защото нито аз попитах правилните въпроси, нито той знаеше какво е важно да каже. И ако трябва да сме честни тук, това не е негова работа.
За тази своя грешка платих с месеци безплатен труд.
Подчертавам, МЕСЕЦИ БЕЗПЛАТЕН труд.
Може би се питате защо продължих… Защото по-лошо от това да работиш “безплатно” е да не държиш на думата си и да не изпълниш това, за което си “стиснал” ръка с клиента.
Това преживяване в крайна сметка доведе до създаването на HARDEN Method™ (който с всеки един проект се допълва и развива с различни документации) – методология, която не просто описва стъпките при изграждането на едно решение, а гарантира предвидимост и стабилност на целия процес.
Защото в автоматизацията – както във всеки софтуерен проект – дяволът седи в детайлите.
И ако не го уловиш на етап Discovery, той ще те ухапе на етап Delivery!
🔍 Откъде започва всичко
Когато клиентът ви разкаже какво иска да автоматизира, естествената реакция на всеки ентусиазиран създател е веднага да скочи към решения:
- „Мога да го направя с n8n!”
- „Тук ще включа webhook!”
- „Данните ще ги пратим към Supabase!”
Познавате ли този импулс?
Той е добър – показва ентусиазъм, експертиза, желание да помогнем.
Но има един проблем.
Представете си, че отивате при лекар и той, без да ви е прегледал, веднага започва да предписва лечение.
- Не е питал какво точно ви боли.
- Не е попитал от колко време.
- Не е проверил има ли други симптоми.
- Не пуска никакви изследвания.
Резултатът?
Лечението може да е погрешно. Или непълно. Или твърде скъпо.
Същото важи и за автоматизацията.
Преди да проектираме решението, трябва да разберем реалността.
Не това, което клиентът мисли, че се случва.
А това, което наистина се случва.
Точно тук влизат в игра двата документа, които спасяват проектите от изненади и които са вече неизменна част от работата ни и срещата с клиенти:
📄 PDD (Process Design Document) – картата на реалността
Представете си PDD като рентгенова снимка на бизнес процеса.
Преди да оперирате, трябва да видите какво има вътре.
Къде са проблемите?
Какво работи?
Какво не работи?
PDD е документът, с който влизаме „зад кулисите” на бизнеса на клиента.
Той отговаря на въпросите, които никой не иска да си зададе (но всеки трябва):
Кой какво прави и кога?
→ Не „екипът обработва заявки”, а „Мария получава имейл в 9 сутринта, ръчно го копира в Excel, след това го изпраща на Иван за одобрение”.
Какви системи се използват?
→ Не „CRM и таблици”, а „Gmail, Google Sheets, стар Excel файл на desktop-а на Мария, понякога WhatsApp групата”.
Къде се губи време и какви са най-честите грешки?
→ Не „понякога има забавяния”, а „30% от имейлите не се обработват, защото попадат в спам, а Мария проверява само пощата си два пъти дневно”.
Кои са т.нар. ROI levers – точките, в които автоматизацията би донесла най-голяма възвръщаемост?
→ Не „ще спестим време”, а „ако автоматизираме извличането на данни от имейли, ще освободим 8 часа седмично, което е 32 часа месечно = половин човек”.
Това е фаза 1 – Discover в HARDEN Method™.
Моментът, в който картографираме реалността, ограниченията и възможностите.
Без добре изготвен PDD, всяка следваща стъпка ще бъде като стрелба в тъмното.
Примерен шаблон за PDD
| ПОЛЕ | ОПИСАНИЕ |
| Име на процеса | Пример: “Обработка на входящи имейли от клиенти” |
| Бизнес цел | Каква стойност носи този процес? |
| Текущи участници / роли | Кой е отговорен (човек, отдел, система) |
| Текущи инструменти / софтуер | Gmail, Notion, Google Sheets, CRM и др. |
| Входни данни | Какво задейства процеса (нов имейл, форма, заявка и т.н.) |
| Изходни данни | Какво е резултатът (нов запис, известие, файл и т.н.) |
| Основни стъпки | 1. Приема се имейл → 2. Извлича се съдържание → 3. Записва се в таблица |
| Болезнени точки | Какво не работи добре в момента |
| ROI Levers | Къде автоматизацията би спестила време/разходи |
⚙️ SDD (Solution Design Document) – архитектурата на бъдещето
Ако PDD е рентгеновата снимка, SDD е хирургическият план.
След като разберем процеса, идва ред да изградим решението – но не на случаен принцип, а с конкретна архитектура.
SDD описва как ще работи новата система.
Не на ниво „ще направим автоматизация”, а на ниво „ето какво точно ще се случва, стъпка по стъпка, данни по данни, грешка по грешка”.
SDD отговаря на въпросите:
Как ще бъдат структурирани данните?
→ Какви таблици ще използваме?
→ Как ще се свързват помежду си?
→ Какви ключове ще има всеки запис?
(Пример: Всеки имейл ще стане ред в Supabase таблица “Requests” със 7 колони: ID, sender_email, subject, body, status, created_at, assigned_to)
Кой какво може да прави?
→ Какви роли и права ще има всеки потребител или автоматизация?
(Пример: Мария вижда всички заявки. Иван вижда само тези, които са му assign-нати. Автоматизацията може да променя само статуса на заявка, не и нейното съдържание.)
Какво ще се случва при грешки?
→ Какво правим, ако имейлът е празен?
→ Ако дойдат два еднакви имейла?
→ Ако Supabase не отговори?
(Пример: Ако имейлът няма subject, автоматизацията ще го маркира като “needs_review” и ще изпрати известие до Мария.)
Как ще измерваме успеха?
→ Не „ще работи по-бързо”, а конкретни KPI.
(Пример: Време за обработка намалява от 15 минути на 30 секунди. Грешките падат под 2%. 95% от имейлите се обработват автоматично без човешка намеса.)
Това е фаза 2 – Design в HARDEN Method™.
Тук PDD се превръща в конкретна техническа рамка, по която се разработва решението.
Без SDD, имате идея.
Със SDD, имате план за действие.
Примерен шаблон за SDD
| ПОЛЕ | ОПИСАНИЕ |
| Име на решението | Пример: “Email-to-Supabase Automation” |
| Технология / Платформа | n8n, Supabase, Make, Custom Python Script и т.н. |
| Описание на решението | Какво точно ще прави автоматизацията |
| Архитектура / Диаграма | Кратко описание или линк към диаграма. За диаграма може да се използва платформата – mermaidchart.com |
| Входни данни (inputs) | Например: имейл, API payload, форма |
| Изходни данни (outputs) | Какво ще се създаде/актуализира (запис, отчет, файл) |
| Логика / Поток на стъпките | Node 1 → Node 2 → Node 3 → Error handling |
| Edge cases / Rollback | Какво се случва при грешка или дублиране |
| Тестови сценарии | Как ще проверим, че работи правилно |
| Очакван ROI / KPI | Метрики за успех (време, грешки, разходи) |
💡 PDD + SDD = стабилен проект
Много хора мислят, че автоматизацията „просто се прави” – натискаш няколко бутона, свързваш няколко приложения и готово.
Но нека да разбием този мит с един прост въпрос:
Бихте ли построили къща без план?
Вероятно не.
Ще наемете архитект, който да начертае къде ще бъдат стените, вратите, инсталациите.
След това ще дойде инженер, който да превърне тези планове в конкретни спецификации – колко тухли, каква дебелина на изолацията, къде точно минават тръбите.
Автоматизацията работи по същия начин.
Дори когато изглежда като „просто свързване на няколко инструмента”, всяка автоматизация е софтуер.
Има логики.
Има данни, които се движат от едно място на друго.
Има потенциални грешки.
Има зависимости между системи.
И точно както при къщата – ако не започнете с ясен план, рискувате да строите нещо, което изглежда готово отвън, но отвътре не работи както трябва.
Ето защо в софтуерните компании клиентите плащат десетки часове планиране, преди изобщо да се напише първият ред код.
Не защото искат да усложняват нещата.
А защото са научили от болезнения опит, че без ясна карта на реалността и конкретен технически план, проектите се провалят.
В този свят има две ключови роли:
Project Manager-ът – влиза в бизнеса, задава въпроси, картографира какво се случва в момента. Той създава PDD – документът, който казва „това е реалността днес”.
Product Owner-ът – взема тази карта и я превръща в конкретен план за действие. Той създава SDD – документът, който казва „ето как ще изглежда решението утре”.
PDD е фундаментът.
SDD е архитектурата.
Заедно те осигуряват, че проектът няма да се разпадне на първата промяна, няма да се окаже двойно по-скъп от предвиденото и няма да остави клиента разочарован.
Затова може и да звуча като счупена плоча (за което си има причина) – но точно този подход трябва да пренесем в света на автоматизациите.
Защото ако искаме проектите ни да бъдат стабилни, измерими и печеливши, трябва да спрем да се правим, че автоматизацията е нещо различно от софтуер.
Тя е софтуер. И заслужава същото ниво на професионализъм.
🧩 Когато обхватът е грешен
В практиката си съм виждала два основни сценария, когато обхватът не е бил правилно определен:
- Проектът еволюира и става многократно по-голям от първоначалното задание, защото в движение се появяват нови зависимости.
- Проектът напълно се променя, защото първоначалното разбиране на процеса е било повърхностно или неточно.
И в двата случая резултатът е един и същ – разходът се увеличава, а доверието намалява.
Първият ми урок за това колко скъпо може да струва една грешка в обхвата дойде именно от проекта, с който започнах тази история.
AI класификаторът за тикети в Zendesk.
Когато се върна назад, вече е очевидно: scope creep-ът започна още в първата среща.
Не защото клиентът беше неясен, а защото аз не бях подготвена да задам правилните въпроси.
Не разбрах, че зад изречението „искаме автоматизация, която класифицира тикети“ стои цяла гора от сценарии, зависимости, подтипове и “ако… тогава…” логики.
Първо беше един тип тикети. После станаха седем.
После се оказа, че всеки от тези седем има между шест и осем подтипа.
И че за всеки от тях трябва да се случва различно действие.
Накрая трябваше да се учи модел, да се правят ръчни класификации на десетки хиляди тикети, за да намерим закономерности.
Най-големият парадокс?
Никой не ме беше излъгал.
Просто никой (включително аз) не знаеше колко много неща има, които “все още не знаем”.
В крайна сметка автоматизацията беше изградена четири пъти от нулата.
Бюджетът – същият.
Времето – утроено.
Причината?
Липсата на рамка, липсата на процес, липсата на PDD и SDD.
📉 Какво наистина се обърка
- Нямаше Discovery рамка. Не бях изградила checklist, по който да вървя с клиента. Разчитах на “разговор”.
- Комуникацията беше грешна. Говорех не с ръководителя, а с оперативен служител, който просто показваше какво прави. Той не знаеше правилата – просто следваше навици.
- Имаше скрити зависимости. Зад Zendesk се криеше вътрешна база, няколко скрипта и набор от “ако това, тогава онова”, които никой не беше документирал.
- Нямаше управление на промени. Всеки нов детайл звучеше като малка добавка. Но малките добавки растат лавинообразно.
Резултатът?
Месеци безплатен труд.
Месеци, в които вместо да изграждам нови решения, изграждах отново и отново едно и също – просто защото не бях заложила правилните основи.
🧠 Как да го избегнем
След този проект въведох едно желязно правило: никога не започваме автоматизация без PDD и SDD.
Това не е бюрокрация.
Това е бронежилетката на всеки проект.
И дори днес, когато клиентът дойде с готова идея, пак започваме отначало.
Защото между “искам автоматизация” и “имам ясна картина какво прави бизнесът ми днес” има огромна пропаст.
А нашата работа е да я запълним.
🚩 Warning signs, че откривателската фаза е непълна
- Клиентът говори за резултат (“да се праща имейл”), но не за процеса (“кой го праща, кога, защо”).
- Не е ясно кой взема решенията в процеса.
- API достъпите и ограниченията не са проверени.
- Липсва човек, който разбира защо бизнесът работи по този начин, а не просто как.
- Клиентът казва “това е лесно” – без да е ясно на базата на какво го твърди.
🎯 Killer въпроси, които винаги извличат скритите рискове
- „Опишете ми подробно какво се случва от момента, в който пристигне заявката, до момента, в който е приключена.“
- „Какво се случва, ако нещо се обърка?“
- „Кой взема решението в тази стъпка – човек или система?“
- „Има ли изключения от това правило?“
- „Колко често тези правила се променят?“
- „Как изглежда успехът? Как ще разберем, че автоматизацията си върши работата?“
Тези въпроси рядко получават перфектен отговор.
Но винаги показват къде има риск и къде трябва да се задълбочи анализът.
⚙️ Какво се промени в Marinext AI
След онзи проект вече имаме вътрешен Discovery Чеклист, който всяка автоматизация минава.
PDD и SDD са задължителни документи.
Без тях не започваме Build фаза.
Те определят не само техническите изисквания, но и психологическия комфорт на двете страни – клиента и екипа.
Никой вече не гадае.
Всичко е ясно, подписано и проследимо.
🎯 Success Formula: HARDEN Method™
PDD и SDD стоят в основата на първите две фази на HARDEN Method™ – Discover и Design.
Това не е просто документация.
Това е механизъм за контрол, за предвидимост и за доверие.
| ФАЗА | ЦЕЛ | ДОКУМЕНТ |
| Step 1: Discover | Разкрий реалността, процесите, ограниченията, ROI точките | PDD |
| Step 2: Design | Проектира новото решение – логики, данни, роли, fallback сценарии | SDD |
HARDEN Method™ се роди от реална болка – от месеци изгубен труд и нощи, в които изграждаш нещо за четвърти път.
Днес тя е не просто процес, а гаранция за предсказуемост.
Няма да имаш перфектен проект.
Но ще имаш проект, който не се разпада.
