Не размерът прави софтуерната фирма силна
Петьо Стоянов · 7 април 2026
Днес малката софтуерна фирма може повече от всякога. Не размерът я прави силна, а начинът, по който работи.
Силата вече не се мери по същия начин
Изкуственият интелект промени изцяло процеса по създаване на софтуер.
Промяната не е, че вече има AI инструменти, които ти помагат да работиш по-продуктивно и по-бързо. И това е полезно, но не това за мен е голямата промяна.
Голямата промяна е, че вече съществува капацитет чрез AI, с който малките софтуерни фирми могат да изградят съвсем различен оперативен модел на работа.
Да, вече екипите са съставени от хора и виртуални служители.
Доскоро мярката за сила на фирмата беше колко хора има и съответно капацитетът беше линейна функция на големината на екипа. Днес някои дейности могат да бъдат поемани от виртуални служители.
Ключовото за мен е да изградя система, в която виртуалните служители са част от начина, по който работи фирмата.
AI като помощник или AI като система
И тук идва ролята на човека. За мен при работа с виртуални служители, движени от AI, човекът има все по-важна роля, що се касае до капацитета на фирмата. И не само по отношение на капацитета, а и в други аспекти, за които ще спомена след малко.
Основателите на малки софтуерни фирми имат възможност, която не съществуваше до момента.
Представете си двама основатели на малки софтуерни фирми. Първият използва отделни AI инструменти от време на време и AI при него е по-скоро хаотичен помощник. Вторият е изградил цял екип от виртуални служители, които го подпомагат, но не хаотично, а като структура, по начина, по който би изглеждала, ако тези роли ги изпълняваха реални хора. Например главен архитект и разработчик могат да са виртуални служители, правен консултант по проект също.
При първия AI е инструмент, който му помага да повиши личния си капацитет. При втория AI вече е част от система, в която различни роли поемат различни части от работата – ефектът не е просто увеличаване на капацитета, а умножаване на капацитета.
Затова към ден днешен аз гледам на AI не като помощник, а като цял слой, върху който мога да подредя начина, по който работи фирмата ми, така както я виждам.
Когато мисля как да подредя оперативния модел, не тръгвам от това къде да вкарам AI. Първо мисля от какви служители и роли се нуждае бизнесът ми днес. След това преценявам кои от тези роли, услуги или функции могат да бъдат поети от виртуални служители, но само ако това ми носи реална стойност, а не е самоцелно. Съответно поддържам структура от виртуални служители, която изглежда така, както би изглеждала, ако тези роли се изпълняваха от реални хора.
Екипът вече не е само от хора
Как “назначавам” виртуален служител?
Въпреки че досега обяснявах за ползите от виртуалните служители, искам да отбележа, че целта ми е да имам оптимален, а не максимален брой служители в екипа. Като казвам екип, визирам хора + виртуални служители. За мен отиването в крайности ще ми създаде шум и вместо да започне да помага, ще започне да пречи и да взема от фокуса ми.
Към момента имаме следните виртуални служители в екипа:
Mentor – стратегически съветник за бизнеса ми. С него обсъждам идеи, изчиствам послания и мисля по стратегическото развитие.
Това е „човекът“, с който първо сядам да мисля по дадена тема, свързана с бизнеса ми.
Ползвам го и отвъд чисто стратегически въпроси – например за обсъждане на нови функционалности на платформата ни. Да, бих могъл да дефинирам отделна роля Product Lead или подобна, но на сегашния етап на фирмата това би било по-скоро изкуствено, отколкото полезно. По-важно ми е да стъпя на реално работещ вариант, отколкото да симулирам по-детайлна структура от роли, която още не е необходима.
В екипа изключително важна роля имат виртуалните консултанти по конкретните проекти.
Project consultants – ако беше човек, това щеше да е онзи човек от екипа, който знае проекта отвътре в дълбочина – договори, регулации, архитектурни решения, историята на отношенията с партньора. Ролята му не е да е общ съветник по всичко, а за конкретния проект. В моя екип, за всеки проект, по който работим, има такъв консултант. Много са полезни.
Следващият виртуален служител в екипа е:
Finance & Accounting Employee (FAE) – това не е счетоводител в класическия смисъл и не замества външната счетоводна фирма, с която работим. По-скоро това е оперативен асистент, който ми помага при месечното фактуриране. Например при извличане на данни от фактури от cloud доставчици и префактуриране към партньори по конкретна логика, така че всичко нужно да бъде подготвено за счетоводната фирма, която ни движи счетоводството.
Виртуалните служители в екипа условно ги деля на нетехнически и технически. Дотук разказах за нетехническите. На мен, като tech човек, много по-интересни са ми техническите.
Chief Architect & Engineer (CAE) – сега сме април 2026 и да, той вече програмира вместо мен.
Бих казал, че това е една от най-важните роли в модела ни. Ако беше човек, в главата ми той би стоял като главния архитект и инженер на екипа – с експертиза на “доктор”, който познава системата и проектите в дълбочина. Когато е добре навигиран и вкаран в контекст, той може да създава качествен софтуер, стъпил върху принципите, които следваме в екипа.
Виртуалните служители работят чрез контекст. Без него са просто добре звучащи помощници, но не и реален работен капацитет. Затова е ключово контекстът да се управлява и поддържа централизирано.
Какво имам предвид?
Всяка малка софтуерна фирма поддържа на едно място важните си документи – бизнес план, стратегии, bio, идентичност, договори, маркетинг план и т.н. Било то в cloud или по друг удобен за основателя начин.
При нас към тези ресурси има още една важна част – виртуалните служители, заедно с необходимия им контекст, prompt-ове и инструкции.
Когато назначаваш реален служител, първо го въвеждаш в контекста – даваш му фирмените документи, с които е нужно да започне според ролята му, идентичността на фирмата и конкретни ресурси, които са специфични за тази роля. При виртуалния служител е много близко като аналогия – в неговата папка са същите фирмени документи и специфичните материали за неговата роля.
Ние приемаме принципа за single source of truth, т.е. оригиналът на всеки документ да живее на едно място. Това е важно, защото така и хората, и виртуалните служители стъпват върху една и съща актуална версия, а не върху различни копия. При нас в момента това е подредено в Google Drive чрез shortcuts към оригиналните документи. Но това е просто начинът, по който ние сме го организирали в момента. Всеки може да го направи с инструментите, които предпочита. Важното е контекстът да остане централизиран и управляем.
Друг принцип, който спазваме, е, че оперативният модел, който строим с виртуалните служители, не е зависим от конкретен AI инструмент или доставчик. AI моделите са изпълнители върху рамката, която сме заложили за конкретния служител. Всеки един от тях може да “заживее” в различна AI среда. Към момента (но това не значи, че и за бъдеще ще е така) за нетехническите виртуални служители използваме ChatGPT, а за техническите използваме Claude Code като основен и Codex като допълнителен.
Гледам на виртуалните служители като на истински хора в екипа. Те участват в процесите така, както биха участвали и останалите в него, със съвсем ясното съзнание за ограниченията, които имат (поне засега).
Как този модел работи при нас
Дотук описах модела. Сега ще покажа как той работи при нас чрез последната функционалност, която пуснахме в BoroBit App преди няколко дни. Това е функционалност, която позволява на човека да вижда стойността на парите си в приложението не само в лева, евро и други валути, а и в различни ориентири като злато, 1 кг бял хляб, 1 час труд, биткойн и други. Повече за самата функционалност сме разказали тук.
Започнахме с етапа, в който обсъждахме как тази функционалност трябва да се появи при хората. Основната ми работа в този етап беше с Mentor-a. В процеса на обсъждане идеята се разви още и от ориентир от лева към евро порасна до съвсем човешки ориентири – както споменах, хляб, час труд и т.н.
Целта на този първи етап беше идеята да мине от концепция към конкретика – какво решава, къде ще живее в продукта, какво трябва да прави и какво не трябва да прави. Тук пак ще спомена, че Mentor-ът е захранен със солиден контекст за фирмата, за системата, за бизнеса и конкретно за BoroBit App. Той знае всички екрани, знае структурата на интерфейса, текущите функционалности и познава продукта отлично, което го прави много полезен консултант за това как точно идеята, която имаме, да заживее в приложението, съобразена и с неговия контекст, и с последните UX и UI тенденции.
Работата с Mentor-а не е автоматизирана фабрика, в която ние го питаме, а той просто ни отговаря. По-скоро е обсъждане като с истински колега в работна среда – итеративен процес, в който избираме между варианти и гледаме темата от различни ъгли. Водещ не е Mentor-ът, а човекът. Човекът насочва, преценява, пази връзката между продукта и крайния резултат и движи процеса.
Като резултат от етапа вече знаем какво точно искаме да се разработи в конкретика – къде ще живее в продукта, кои екрани и функционалности засяга и всички детайли, нужни на разработчика, за да го разработи.
Процесът завършва с документ, който ние сме нарекли feature brief. Той е мостът между етапа на обсъждане и следващия етап – този по разработката.
Feature brief документът съдържа структурирана информация, нужна на разработчика – цел, продуктов принцип, кое е в обхвата (кои екрани, секции), кое е извън обхвата, основни UX правила и детайлни инструкции за всеки екран или секция, които ще се променят или разработват. Документът е създаден така, че да е полезен за виртуален разработчик да имплементира функционалността. Затова в него има една ключова част – разработката е разбита на отделни фази, така че функционалността да може да се имплементира фаза по фаза от виртуалния разработчик.
В етапа на разработка в екипа работим с Chief Architect & Engineer (CAE). Той взема feature brief-a и го превръща във функционалност.
CAE не е просто виртуален разработчик, който пише код. Той е захранен с толкова технически и фирмен контекст, че познава добре средата, в която работи. Разбира продукта и системата в дълбочина и не пише код на парче, а го прави съобразено с архитектурата на системата, спазвайки принципи за дългосрочно развитие на кода, минимален обхват и безопасни промени (не като случаен tool, а като разработчик). Затова за мен стойността му не е само в това, че ми спестява време в писането на код, а в това, че в екипа реално се появява още един, който работи.
Разработката също е итеративен процес, който се случва на фази, заложени във feature brief документа – както се казва, „разделяй и владей“.
За конкретната функционалност бяхме разделили разработката на пет фази – една предварителна фаза, в която подготвихме вътрешната структура, върху която стъпва функционалността, след това по една фаза за всеки от трите панела – Портфейл, Парични потоци и Настройки – и пета, последна фаза за polish.
Въпреки че CAE пише кода сам, самата разработка не се случва с магическа пръчка. Аз водя процеса, а CAE е изпълнителят, който разработва. На всяка фаза валидирам промените, които той е направил – дали отговарят на изискванията за качество на кода, на добрите практики и дали изпълняват целите на фазата.
Вътрешното ми мерило за това дали CAE се е справил е дали кодът, който е променил или написал, мога да го припозная като свой. В повечето случаи се справя от първия път, но много често се налага да го насочвам, да доуточняваме (понякога и директно в кода) още неща и да го захраня с още контекст, за да покрие изискванията ми.
По време на разработка, ако усетя, че на CAE му липсва конкретен контекст, с който не е бил захранен, спираме за момент разработката и добавям нужната информация в контекста му, но така, че да е налична и за бъдещи разработки с него. Това на пръв поглед леко те забавя в текущата разработка, но според мен точно това е ключово за увеличаването на капацитета на виртуалните служители – обогатяването на техния контекст да е част от работата, а не еднократно действие.
Така тази функционалност мина от идея до разработка през процес с участието на двама виртуални служители, а аз водех процеса, насочвах работата и валидирах всяка стъпка.
Днес във фирмата вече имаме процеси, в които в различни етапи участват хора, виртуални служители, външни и вътрешни системи. Следващото ниво за мен е самите процеси между всички тях да започнат все повече да се автоматизират.
Сигурността става още по-важна
Този модел ни дава много повече капацитет, но с него идва и много по-голяма грижа за сигурността на цялата среда около виртуалните служители. Говоря за това какъв контекст виждат, как са настроени самите модели, чувствителните данни да бъдат изолирани и изобщо всичко около тях да е подредено както трябва.
И тук аналогията с реален служител е много точна – когато даден нов колега влезе в екипа и започне да работи по кода, той не получава достъп до ключове, сертификати и всичко останало. По същия начин трябва да се мисли и за AI.
Отделяме време да подредим работата с AI така, че тя да стъпи на ясни принципи – минимално необходими права, изолирани чувствителни данни, добре подреден контекст, правилно настроена среда, спазени изисквания за сигурна работа на конкретния AI инструмент и човек, който държи контрола.
Човекът остава в центъра
При нас основната роля остава за хората. Виртуалните служители са важни, но най-важни остават хората, които движат този процес.
С навлизането на AI много неща се промениха в ежедневната работа на хората – било то за основатели на фирми, за разработчици и за други. Но това, което не се е променило, е, че човекът носи риска и отговорността за крайното решение, трябва да разбира какво прави и остава този, който движи процеса.
Но да, работата например за разработчика се промени из основи. Все по-малко време отива в механично писане на код и все повече в това да води решението в правилната посока.
За мен все повече стойност носи да насочвам ежедневните си усилия в захранването и поддържането на контекст (но като система, не хаотично) – чрез който AI ми се отплаща, като поема писането на кода, с важната уговорка: не за сметка на качеството. Друга дейност, не че е нова, но в която днес влагам повече усилия, е правилното формулиране на задачата.
Силен контекст + правилно формулирана задача = полезен AI разработчик.
На всеки три месеца си сверявам часовника
Софтуерната индустрия се променя непрекъснато с развитието на AI. Приключи времето, в което беше достатъчно човек да научи един или няколко езика за програмиране или да специализира дълбоко в дадена технология. Това за мен остава важно, но вече не е достатъчно. Днес е необходимо да се адаптираш непрекъснато. Това важи за разработчици, за основатели, а и за почти всяка професия и дейност.
Оперативният модел на фирмата по същия начин не е статичен – и той търпи еволюция.
Аз спазвам едно просто правило – имам настроено автоматично напомняне на всеки три месеца, което ми казва: „Спри текущата работа и провери докъде се разви AI през последните три месеца“. Когато го получа, отделям време да видя дали има нещо ново, което мога да използвам в начина си на работа и което реално би ми дало стойност. Например следващо ниво на автономност на AI или нов полезен инструмент. Ако преценя, че още не е узряло или не ми носи стойност на този етап, не го използвам.
След това предстоят три месеца работа, в които се изолирам от шума и цялото говорене около AI и се съсредоточавам върху реалната работа на фирмата. След три месеца пак си сверявам часовника и така периодично адаптирам процеса.
Докъде ще стигне AI в развитието си?
Не знам. Но знам, че живеем в изключително динамична ситуация, в която всеки трябва да се адаптира непрекъснато.
Смятам, че идва време, в което малък и силен екип ще може да прави големи неща.
Четете още
