Представяме ви Ивайло Митрев, Back-end Tech Lead и Георги Илиев, Data Delivery Tech-Lead в Documaster. Те ни разказват повече за процеса на разработка в компанията, защото всъщност той е ключовият фактор за успеха на Documaster и международното признание, което компанията изгражда от 2014 г. насам. Най-напред с доверието на големият брой клиенти от публичния сектор, за съхранението на данните им, а вече и с доверието на множеството клиенти от частния сектор, където сама по себе си компанията Documaster е стандарт за управление на документи.

Както знам в началото, вашият продукт е разработен, за да помогне на държавната и общинска администрация в Норвегия и е напълно съобразен с норвежкия стандарт за електронно управление на документи Noark. Откъде идва идеята за софтуер за управление на документация? Как стартира проектът?

Ивайло Митрев: Вече споменахте Noark. В Норвегия по закон се изисква софтуерно решение, което използва система, отговаряща на изискванията на този стандарт. Това е което Documaster представлява – продуктът за публичния сектор, който обслужва нашите клиенти повече от шест години. Мога да говоря за множество важни събития в историята на Documaster – най-важното, разбира се, е създаването на норвежката организация през 2014 г. Създадена е от трима души – двама норвежци и един българин, който е разработчик. Скоро след това те решават, че се нуждаят от четвърти човек – вторият разработчик на компанията. Двамата са отговорни за разработването на първоначалната версия на продукта, която поддържаме и досега за публичния сектор. Използват се технологии с отворен код като Java, PHP, Linux и т.н. По онова време това е някак нетрадиционно сред нашите конкуренти, тъй като повечето от тях бяха с базирани на Windows desktop приложения, които определено са по-трудни за поддръжка, докато Documaster е хостван в облака и разчита изцяло на технологии с отворен код.
Така, с този първоначален продукт, който бива разработен, успяват да спечелят публични търгове и за около година и половина вече имат десет клиента. Следващият най-голям етап бе създаването на офиса в България. Настоящият ни технически директор и съосновател, който е българин, успява да убеди останалата част от екипа, че в България има много талантливи хора с потенциал и че компанията може да създаде офис в страната – технологичният хъб на Documaster. Аз лично бях шестият човек, нает в екипа и това бе преди почти пет години. Постепенно разширихме хода между офисите, защото видяхме, че техническият екип в България работи “as a concept”. Първоначално бяхме базирани в малка жилищна сграда в София. След това се разширихме до втори и трети апартамент и в крайна сметка пораснахме толкова, че ни трябваше цяло помещение в офис сграда в столицата. В началото на 2018 г. нашият продукт имаше около 200 клиента – общини, музеи, училища и др. Това бе и времето, в което решихме да пробваме идеята си и в частния сектор.

Георги Илиев: Говорейки с цифри, аз бях двадесетия в компанията, така че се присъединих доста късно в играта. Присъединих се през 2017 г. и това бе много важна година за компанията, защото именно тогава получихме най-голямото си финансиране до момента – около 10 милиона евро. Спомням си, че се подготвях да тръгна на това приключение с Documaster. Компанията обаче не беше известно име за мен. Останах със страхотни впечатления от техническия екип и техническия директор, както и от хората в Норвегия. Въпреки това, бях малко колеблив и наблюдавах какво се случва в компанията, защото залагах почти всичко на нея. В края на 2017 г. обаче си спомням, че попаднах на съобщението от пресата за Documaster, спечелил най-високия търг в историята му от Норвежката дирекция на здравеопазването. Можете да си представите реакцията ми, когато прочетох за това, защото това е много важен клиент и документите, които се управляват, са изключително чувствителни. Нямаше как всяка компания да спечели този договор. От една страна, колебанието ми изчезна, а от друга, започнах да се питам – аз какво мога да донеса на масата? Тези момчета определено знаят какво правят. Прескачам напред към повече от три години и половина по-късно – миналият месец завършихме вероятно най-големия си търговски договор до момента. И това бе продуктът, който започнахме да изграждаме през 2018 г. Изключително горд съм, че бях част от приключението.

Колко специалисти бяха част от екипа на Documaster в началния етап от разработването на продукта за частния сектор? На кои технологични стекове е изграден той? Имаше ли предизвикателства, с които се сблъскахте и как ги преодоляхте?

Георги Илиев: Бях първият разработчик в този екип и когато се присъединих към него, той бе сформиран от продуктов мениджър в Норвегия, UX специалист, който делеше времето си между публичния продукт и това ново възникващо нещо, което тогава дори не наричахме продукт. Малко след това към нас се присъединиха Front-end разработчик в Норвегия и синиър UX специалист в Осло. Това беше екипът, който разработи първия прототип, който в крайна сметка бе внедрен в производство за клиент в края на 2018 г. Бяхме скромни по размер, но отговаряхме на обема на работа, която вършихме тогава. Относно предизвикателствата ще започна с личните си. Когато се присъединих към Documaster, имах собствени очаквания относно вида работа, която да свърша, и вида предизвикателства, които да реша. Очаквах основно да работя върху страхотни функции – да създавам страхотни неща, които ще завладеят света. Още на втория ми ден на работа бях в разговор, в който обсъждахме компоненти на AI, които мислехме да вградим в информационната система на банка, за да филтрираме чувствителната комуникация и да не позволим на важна такава да напусне системата. Не, че банката го искаше, но въпреки това го обсъждахме. Имах една торба, така да се каже, с решения за проблеми, които вероятно никой не се опитваше да реши.
Скоро след като осъзнахме, че разполагаме с идеите за решаване на проблеми, провеждаме срещите, но не отиваме никъде. Благодарение на страхотен професионалист, продуктов мениджър, бяхме изтеглени от „замъците в небето“ и просто си припомнихме, че сме тук, за да изградим продукт и това означава, че трябва да подходим към работата по съвсем различен начин. Не бива да се опитваме да прилагаме решения на проблеми, които никой не се опитва да реши. Трябваше да идентифицираме проблем, който беше достатъчно широко разпространен и достатъчно значим за организациите. Решението е второстепенно за проблема. По този начин трябваше да дестилираме послание, което да представяме на нашите потенциални клиенти – “Какъвто и проблем да имате, ние имаме решението на този проблем“. Още преди да се присъединя към компанията, продуктовият мениджър е водил преговори с потенциални клиенти в цяла Норвегия и е открил, че това, което имаме в зрелия вече продукт (Documaster Archive), не е достатъчно добро за нуждите на корпоративните клиенти. Това бе изненада, защото продуктът бе 100% идеален и подходящ за професионални архивисти в норвежкия публичен сектор. И изведнъж този удивителен инструмент, нямаше смисъл за клиентите, с които разговаряхме. Разбрахме, че ако искаме да генерираме някакъв интерес, трябва да измислим “proof of concept” възможно най-бързо – прототип или MVP – защото това, с което разполагахме, просто не предизвиква интерес. И така, след вече зрелият продукт на Documaster, ние трябваше да измислим малък набор от функционалности, които внедрени правилно, да ни направят успешни.
Правейки това, бе необходимо да се срещнем с много потенциални клиенти за много кратко време, така че да съберем отправните точки. Не е достатъчно един клиент да хареса това, което правиш, защото изграждаш продукт – трябва да си сигурен, че имаш достатъчно клиенти, които биха се възползвали от функцията, която се изгражда. Но това идва с определена цена.
За да сме сигурни, че сме на една и съща страница при среща с клиент, трябваше да се развием много бързо и да изпробваме различни неща, за да сме сигурни, че имаме какво да покажем на следващата среща с клиента. В този ред, трябваше да възприемем нещо като манталитет на стартъп. И това се случва в организация, която вече е установила качество и име в публичния сектор. От тази гледна точка, наличието на екип с малък размер, бе полезно за нас, защото скъси цикъла на развитие. Комуникацията бе директна, почти без “ticket” система. Всичко се случваше добре за известно време, но също така създаде напрежение, защото изведнъж имаме това малко стартиращо нещо, което се случва в голяма зряла организация. Това бе едно от основните предизвикателства през първата година.
Колкото до технологичния стек. Тъй като трябваше да бъдем изключително тактични в подхода си, не можехме да си позволим да започнем да изграждаме нещо от нулата, затова решихме, че каквото и да правим, то трябва да е върху съществуващото ядро ​​на Documaster. Поне Back-end частта. Използвахме компонент на Java сървъра, излагащ уеб услуги чрез PHP слой и това от своя страна кореспондира с Postgre back-end и използва Apache Solar за full-text индексиране. На всичкото отгоре добавихме нов Java компонент, междинен софтуер, който да кореспондира с уеб услугите и да изпълнява бизнес логика, като на свой ред захранва чисто новия Front-end, имплементиран на React.js. Това бе продуктовата архитектура, която внедрихме при нашия първи платен клиент в края на 2018 г., като имахме и разширение със самостоятелен компонент, написано на Python, което бе отговорно за преработката на някои документи.
Тази първоначалната архитектура се разви през следващата година и през 2019 г. премахнахме PHP слоя, защото трябваше постоянно да подобряваме ефективността си. В края на 2019 г. имахме трима клиенти, плащащи, и още около дузина пилотни такива.

Какво беше необходимо за мигриране на продукта от публичния към частния сектор? Какви промени и внедрения са необходими?

Георги Илиев: Причината за създаване на Documaster Archive бе, че искахме да обслужваме нуждите на публичния сектор в Норвегия, които по закон бяха задължени да имат система за електронно управление на записи, съобразена със специфичен стандарт. По някакъв начин, спецификациите, вградени в този продукт, вече бяха налице. Те бяха изброени в самия стандарт. Докато разработвайки продукта за частния пазар, нямахме абсолютно никакви спецификации и не знаехме какво ще изградим.
Поради тази причина ние събирахме данни и отправни точки от срещите с клиенти и по този начин създадохме нашата пътека, която е нещо различно от конкретни фиксирани спецификации. Знаехме, че всеки потенциален клиент, ако иска среща с нас, то значи вече има някакъв проблем с управлението на своите документи. По тази причина, няма как да отидеш в организация, която не използва инструмент за съхранение и управление на документи и да им продадеш такъв софтуер. Те няма изведнъж, от следващия ден да стартират. Ако тази организация използва дадени инструменти за управление, то те най-вероятно са силно персонализирани и специализирани, така че да обслужват нуждите.
В тази връзка – каквото и да им предложим, то трябва да е по-добро от това, което вече използват и няма как ние просто да премахнем функционалностите, които вече използват. Ние бяхме в ранен етап и не знаехме все още какво искаме да включва нашият продукт. Но сигурното бе, че искаме високо ниво на UX така че, каквото и да измислим, да бъде лесно за използване от крайния потребител.
Друго нещо е, че в продукта на публичния сектор сложността на модула за данни, който е внедрен в релационната база данни, е повече или по-малко засегнат във Front-end. И това е така, защото потребителите са силно специализирани и се нуждаят от всички тези добавки там, за да си вършат работата правилно. Този модул бе почти невъзможно да се обясни на някой, който не се интересува от архиви. Открихме, че просто трябваше да скрием повечето сложности. Затова поставихме фасада пред съществуващото API на Documaster, която основно да филтрира онова, което не е интересно за нашите клиенти от частния сектор, и го превежда на неутрален общ език, който не е конкретен за дадена индустрия.
Така, поставяйки фасада между съществуващото API на Documaster и новия Front-end, то front-end разработчикът успя да се съсредоточи върху това, което наистина има значение – потребителското изживяване. Изведнъж back-end развитието бе някак избутано малко по-назад. Това не означава, че е загубило значението си. Точно обратното. Фокусирайки се изключително върху UX, голямо ниво на тяга беше дадено на back-end разработката.

Каква технология стои зад прехода на информация от различни legacy системи в единен стандарт?

Георги Илиев: Ще започна с малко предистория. Вече не говорим за един единствен стандарт. Стандартът плаши клиентите. Можем да говорим за Noark в публичния сектор. Но тази дума няма никакъв смисъл за корпоративните клиенти. Те искат само да се уверят, че всички doc файлове, които имат, са добре структурирани. Вместо това говорим за модула за данни на Documaster и това е стандартът, който преобразуваме. Тъй като Documaster е млада компания и работим, опитвайки се да споделим пазара с големите имена там, трябва да ударим по-горе и всеки път, когато отидем на клиентска демонстрация, няма начин да генерираме интерес, като просто показваме скрийншот на Documaster или преместване някакъв документ на екрана. Ако искахме да сме сигурни, че клиентът ни приема сериозно, трябваше да покажем, че техните собствени данни се чувстват у дома си с нашия продукт. Така че от самото начало разработването целеше миграция на реални клиентски документи.
Самият модул за данни на Documaster, който имаме днес, е резултат от безмилостно тестване на хипотези, много срещи и изпробване на различни неща. В резултат на този процес вярвам, че сега най-накрая имаме модул, който е достатъчно прост, за да се обясни на неспециалист, като същевременно е мощен и разширяем, за да обслужва нуждите на новите клиенти в нови насоки. Вече не трябва да се връщаме към обсъжданията, да променяме някои функции и т.н. Модулът, който обслужваме през последните години, всъщност е стандартът, към който прехвърляме клиентски данни.
Дори в ранните етапи, ние не искахме някой да ни каже, че нещо се е счупило по продукта. Затова, единственият начин това да се гарантира е, чрез мигриране на данните от API. Ако мигрираме съществуваща система, която клиентът използва през последните 10 години, то това е най-добрата система, която той е могъл да измисли. Ако е имало някакъв друг начин да се структурира съдържанието, то е щяло да се направи. Ние всъщност прекарваме време с клиентските данни и ги изучаваме – вземаме малка извадка от документите, внасяме ги по начина, по който смятаме, че трябва да бъде, след което споделяме работата си и чакаме обратна връзка.
Този процес на мигриране може да отнеме много време, но го правим, докато клиентът не е доволен. В крайна сметка, вземаме цялото legacy съдържание, което клиентът е предоставил, и изпълняваме така наречения “dry run”. Това обикновено се случва в демо или тестова среда. Даваме достъп на клиента за целите на „user acceptance testing“, а след като получим одобрение, извършваме абсолютно същите стъпки в производствената среда. Що се отнася до инструментите, ние сме доста гъвкави и сме свободни да избираме език, фреймуъркове и т.н. Често използваме някои ETL инструменти като Apache Airflow, но всеки клиент е специфично предизвикателство и не се страхуваме да експериментираме с нови технологии.

Очаквайте Част II на интервюто на DevStyleR с Ивайло Митрев и Георги Илиев от Documaster.