Представяме ви Мартин Чаов, Software Architect в DraftKings, с повече от 10 години опит в ИТ сектора. Той ни запознава с тази интересна и отговорна професия, която е част от уравнението, водещо към добрия софтуер. А също и професия, която за да достави най-добрите решения за бизнеса, е необходимо да се разгърне в много различни нива, като политика, икономика, право и др.  

Как се запали по информационни технологии и на каква възраст беше? 

Не мисля, че е имало конкретен момент на запалване, така да се каже, но като цяло винаги си „чоплех“ разни неща и всичко се случи естествено. Като бях малък нямах здрави играчки, тъй като винаги ми трябваха моторчетата и лампичките и т.н., за да направя нещо, което на мен ми се върти в главата. В ИТ професиите част от длъжностната характеристика е точно това – да ти е интересно какво кара нещата да работят.

А компютърните игри повлияха ли ти? Доста програмисти сега, са стартирали защото са били геймъри като малки… 

Като дете какво друго да правиш с компютър, освен нещо, което някой друг ти е показал. А най-лесното нещо е този някой да ти е пуснал компютърна игра. Съгласен съм, че на доста хора точно това повлиява за последвалите кариерни избори. Когато бях малък нямаше достъпен интернет, нямаше някаква особена мултимедия. CD-ROM имаше един човек в квартала, ако даже има и един. Какво следва – играеш някоя игра, но тя ти омръзва, а след това или компютърът става „тухла“, или започваш да го разглабяш и разглеждаш. Аз правех второто, защото ми беше интересно какво има вътре, как работи и дали ще продължи да работи ако го сглобя обратно.

Това значи, че теб повече те е провокирал хардуера…

Като се замисля – да. От него тръгнаха нещата за мен, защото това е най-достъпното нещо, което можеш да правиш по един компютър, без някакви специални знания. Трябва ти само една отвертка. Това доведе и до първата ми работа, която бе в една малка Пловдивска фирма, в която сглабях компютри, инсталирах операционни системи и по-късно поддържах мрежи.

Вече си бил завършил? 

Малко се смесиха нещата, защото още в училище помагах в поддръжката на компютрите. Но не бе, всъщност, осъзната поддръжка. Просто имахме неработещи компютри, от които аз направих работещи. Учителите ме оставиха да си се занимавам (и да не преча). Не ми беше цел да сглабям работещ компютър, а ми беше интересно дали мога да изкарам достатъчно работещи и съвместими части, за да подкарам нещо. След това и във фирмата правех същото. За един чирак, това е най-ниско критичната работа. С това се захванах непосредствено след 12-ти клас.

А къде избра да учиш висше образование, след като вече си бил наясно със своя интерес? 

В средното ми образование участвах в много олимпиади, със съмнителни резултати. Учениците, които ходеха на такива, бяха освободени от училище. Фокусът ми не беше да участвам в олимпиадите, а да не ходя на училище. Но пък така се запознах с много хора, които притежаваха същите интереси като моите. Това, което се случи бе, че резултатите от последната олимпиада на която взех участие, се считаха за приемен изпит. Реално, имах оценка за влизане във ВУЗ в България и така избрах пловдивското ФМИ, защото живеех там по това време.

А какво ти даде академичната подготовка? Все пак това са четири години. 

При мен бяха пет години – явно не бързах да завърша. Най-напред се научих на търпение и работа с хора, които не е задължително да ми допадат. Особеното на университета е, че никой не го интересува ти кого харесваш или не. Разпределят студентите на екипи и след това всеки се оправя. Това е хубаво умение, което всеки трябва да придобие – работа в екип. Но има и нещо друго. Не смятам, че тогава съм го оценявал подобаващо, но от сегашна гледна точка разбирам, че университетът е среда без последствия. Най-лошото, което може да стане е да не си вземеш изпита, но тогава отиваш на поправка и това е! Този модел ти дава свободата да експериментираш, без това да коства ресурси. Това е страхотно! Курсовите работи не са досадното „домашно“ от училище. Колкото до знания и умения – тях всеки с желание може да ги придобие. Академичната подготовка е насочена да ти развие интелекта и любопитството, да те научи да изразяваш и представяш идеите си – все полезни качества за колаборация с хора.

А и имаш четири години, в които да натрупаш много сериозна основа. При частните центрове, например, за три месеца можеш да се преквалифицираш към нова сфера и конкретна позиция. 

Имам смесени чувства към частните образователни центрове. Те дават възможност на много хора да се докоснат до програмирането и да се преквалифицират. Това в сегашната динамична икономическа среда позволява на хората бързо да реализират доход и да се грижат за семействата си, което никак не е за подценяване!
Проблемът с тези центрове е, че те дават ограничена представа за програмирането. За два-шест месеца ще се научиш да работиш едно нещо. Да кажем, че би се справял добре! Но това е редно да е само стартът за теб. Не може да си кажеш „намерих си работа, готово!“. Трябва да продължиш да учиш. Образованието продължава през целия живот и няма как да се завърши.
Качествени кадри излизат и от частните, и от държавните учебни заведения, така че всичко опира и до индивида. От друга страна, късата образователна форма ти дава шанс да отидеш и да „пипнеш“ професията, както се казва. Така можеш да прецениш занимава ли ти се с това наистина.

Което при академичното образование е по-сложно, защото можеш да усетиш че ИТ секторът не е за теб, но да си изгубил 2 години преди това в измъчено учене. 

Не съм съгласен, че това са две изгубени години! Да кажем, учиш информатика. На втората година решаваш, че това не ти е на сърце. Но придобитите знания и умения ще те съпътстват до края на живота ти и умишлено, или подсъзнателно, ти ще се възползваш от тях. Това не е изгубено време и аз имам много такива примери от практиката ми. Някой път буквално ми изскача в главата нещо, преподадено в първи курс, което ми решава проблема. Всяка една професия, която се практикува е повлияна от това да имаш допълнителни знания и аналитично мислене. Поне аз не се сещам да има такава, в която да знаеш по-малко е по-добре.

А как достигна до софтуерната архитектура, която е от най-сериозните и престижни професии? 

Не знам дали е толкова престижна, колкото някои хора си мислят. Просто е едно от звената, които са необходими, за да се достави качествен продукт. Архитектурата е част от едно уравнение, в което всеки един аспект е важен за получаването на качествен софтуер. Позицията е отговорна, но аз не съм се целил в нея. При мен нещата се развиха естествено. Работата ми постепенно измести фокус от едно, към второ и трето. Изглежда моите умения по-добре пасват на бизнес процесите, на автоматизацията и проектирането, отколкото на самото програмиране. Архитектът е полезен като част от екипа. Той сам по себе е толкова ключова фигура, колкото всяка друга.

Какво представлява твоята работа и какви качества трябва да се притежават? 

Това по-скоро зависи от компанията, в която работиш и нишата, в която се развиваш. Основната част е изследователска дейност. Идват нови изисквания и архитектът трябва да ги разбере, да осъзнае как ще паснат на текущата система, да проектира възможност за тяхната интеграция, да изследва и проверява нови технологии и инструменти за постигане на целите на компанията. Също така, трябва да проектира дизайнът – връзките между компонентите в една софтуерна система. Да изготвя диаграми, макети и т.н. Ще дам пример и с PESTEL анализ. За да може един архитект да даде решение на проблем свързан със съхранение на лични данни, той трябва да е наясно и със ситуацията около бизнеса. Трябва да знае как се развиват някои законови рамки и какви са ограниченията наложени от тях. Пример – как се пазят данни по GDPR. Архитектът трябва да разбира, какви ограничения са му наложени от външни фактори. Бих казал, че един софтуерен архитект трябва да разбира от много неща. Определено и житейският опит помага.

С какви трудности се сблъсква един софтуерен архитект в ежедневен план? 

По-скоро бих ги нарекъл предизвикателства. Основна част от работата е комуникация. Много от нещата, които изглеждат тривиални за архитекта и бизнеса, трябва да бъдат преведени по съответен начин на инженерите. Най-големите проблеми при съвместната работа идват точно оттам – когато някой не разбира, че не разбира нещо. Тогава се получава развален телефон с предаване и препредаване, а когато информацията е преминала през няколко души, то вече е тотално трансформирана. Това е свойство на човешкия език, някои думи имат много значения и ние архитектите трябва да бъдем крайно изчерпателни и ясни.
Мога да дам пример с предизвикателства в гейминг бизнеса, който е строго регулиран. Има регулаторни органи и те определят правилата, по които бизнесът може да протича в дадена страна. Ако искаш да практикуваш онлайн залагания в Италия, трябва да знаеш, че когато всеки потребител се опитва да заложи, трябва да се изпрати заявка към държавен сървър, така че да се провери дали този човек може да заложи тази сума и какъв ще му е данъкът. Да речем, това го няма никъде другаде. Ако твоят бизнес е започнал от Англия, САЩ или Канада, този детайл много ще те изненада като стигнеш Италианския пазар. Също така – залаганията на живо в Австралия изискват ‘two factor verification”. Изпращат ти съобщение с код, който ти трябва да потвърдиш, че искаш да заложиш и всичко това отново отива в държавен сървър, но тук е намесен и мобилният оператор, който изпраща съобщение с код. Това са някои примери за изисквания, които няма как да вземеш предвид от ден първи. Да не говорим, че много от тях се променят с всяка промяна на правителство. Бизнесът ти зависи от това да се напаснеш към тях.
Ето и YouTube. Те имат алгоритми, чрез които маркират съдържание, което не можеш да използваш, защото изисква лиценз. Имат т. нар. takedown notices, което е сложна система и едновременно задоволява потребителите и големите корпорации, държащи правата за филми, клипове, музика и т.н. Но тази система е пълна с прецеденти. Редовно случаи стигат до съд и решението на съда променя начинът, по който тази система ще продължи да работи. И ето, че това са решения, които не зависят от софтуерната архитектура и/или имплементация, затова трябва да сме гъвкави. Не случайно споменах и PESTEL анализ, защото архитектите трябва да разбираме от нещата, които могат да повлиаят бизнесът ни – политическа, икономическа, социокултурна и технологична среда.

До какви проблеми за продукта може да доведе липсата на една добра софтуерна архитектура и всъщност, коя е добрата и как можем да я разпознаем? 

Най-напред е добре да окачествим коя е добрата архитектура. Тя решава проблем – предначертава пътя, по който системата ще се развива. Много е трудно една софтуерна архитектура да бъде определена като добра или лоша. Тя е баланс на компромиси между различни параметри – цена, време за изработка, всичко ли ще пишем сами или ще използваме готови компоненти, какви възможности за разширяване и конфигурация ще има, време за отговор, достъпност, леснота на промяна и т.н. Доста често архитектурата се прави на различни етапи. Имаме такава, изкарана до „пусков“ етап, т.е. minimal viable product. Но това не е архитектурата, която ще се развива, а тази, с която най-бързо можем да достигнем до потребители и да започнем да генерираме печалба за компанията. Ако тази идея се докаже, научените уроци от работата на системата, ще бъдат използвани за създаването на следващото ниво – разширяването. Но и не е задължително да се стига до там. Може пък от пускането на MVP (minimal viable product) да ни е доказало, че имаме нужда от тотално друга архитектура. В този смисъл, бих определил добрата архитектура като такава, която подпомага бизнеса в неговите цели. От нея трябва да стават ясно видими изискванията и ограниченията на една софтуерна система.

А лоша софтуерна архитектура? Има ли такава и как се отразява на времето за изпълнение на проекта? 

Ако целта е продуктът да се достави бързо, а архитектурата прави изработката тромава, това значи че дадената архитектура не е за този проект, но това пък не значи и че е лоша по принцип. Има много случаи, в които някой по-млад или неопитен специалист взима готово решение, което изглежда сякаш ще пасне на неговият проблем. Лошата архитектура прикрива слабите страни на софтуерната система. Последиците от едно такова нещо доста често са по-големи от това да се повлияе на времето за разработка. Най-страшното нещо е да разбереш, в моментът в който пуснеш системата, че тя не може да се справи с повече от 10 потребители, а би трябвало да поема десетки хиляди заявки в секунда. Ето това вече е сериозно, защото архитектурата много добре е прикрила този проблем и никой не е успял да го забележи и тества. В крайна сметка това, което се получава е, че цялата система е неизползваема от ден първи. Това е много по-страшен сценарий, отколкото системата да се забави с ден, месец или шест месеца.

Това значи, че архитектурата е като пъзел – подреждат се парчетата от различните компоненти, дизайн, бизнес гледни точки и т.н. Но колкото и добре да изглежда, може да има нещо пропуснато в кода, останал бъг, който да смути целия проект… 

Не бих я нарекъл пъзел, защото той има един определен правилен начин на подреждане. Тя е баланс от компромиси. Да, нещо може да струва малко по-скъпо сега, но да те изведе по-бързо на пазара, което може да е по-важно за бизнеса в момента. Следователно ти насочваш ресурсите си в тази посока. После обаче ще има нужда да се разширява системата като възможности и тогава вече бързото решение ще дойде твърде скъпо и ресурсите ще трябва да бъдат вложени в това да се изработи по-финансово-рентабилна алтернатива. Затова архитектурата се прави на етапи и тази, с която е достигнат един етап, може да не е тази, с която да се продължи напред.

Ти самия пишеш ли код активно? Част ли е това от ежедневните ти задължения? 

Кодя, но това не е основната част от работата ми. Ако архитектът коди, фирмата започва да губи пари от него, защото уменията и знанията му трябва да бъдат насочени другаде. В същото време е добре архитектът да може да си подреди парчетата от архитектурата и да може да даде работещ макет като част от документацията. Това е добре да се прави при критични неща и такива, които трябва да се изтестват, преди да достигнат до взимане на крайно решение за имплементацията.

Задължително ли е софтуерните архитекти да са насочени и към бизнес частта на продукта? Това ли е по-невидимо звено, което ги прави ефективни. 

Архитектът решава бизнес проблеми, така че май няма как да не е насочен към бизнеса.

Но някой, който не разбира бизнес частта не може да работи тази професия – софтуерна архитектура? 

Има как! Бизнесът се учи. Освен това има и различни профили архитекти: enterprise, system, solution, software, technical. Въпреки, че вече имах години опит в гейминг индустрията, като започнах с тази роля, не разбирах толкова добре бизнеса, както днес. Но като говорим за бизнес, не става въпрос за продажба на софтуер. Става въпрос да се избират бизнес изискванията, които софтуерната система трябва да покрие, да се разбират и нуждите на потребителите. Представете си, че трябва да направим програма, която винаги ще работи с числа. Какво ще стане ако тази програма не получи число? Бизнесът ще каже, „ние задължително трябва да работим с числа, няма как да не получи такова“. Това е така, но има хора, които нарочно няма да изпратят число в системата и ние трябва да сме наясно как тя ще се справи с това. Тук влизаме в обхватът на NFRs (non-functional requirements). Тяхното разбиране има отношение към проектирането на софтуерната архитектура.
Мога да използвам метафора, която да обясни софтуерната архитектура от друг аспект. Ако някой се чуди какво точно представлява, то нека погледне архитектурата на сгради, чертежите. Там не виждаме къде ще има апартамент, сауна и т.н. Там виждаме местоположение, аварийни изходи, електрическа инсталация и т.н. Това е погледът относно нещата, които са трудни да се променят. След като построим сградата, много трудно ще се преместят носещите стени или ще се подмени ВиК инсталация или дизайна на одушниците. Софтуерната архитектура се занимава с аналогични проблеми. Нейната цел е да изрази тези основни рамки и лимитации на системата, а оттам разработчици попълват кутийките със съответните системи.

Аналогично погледнато, това значи ли, че софтуерните инженери не гледат с добро на архитектите? 

Абсолютно! В строителния бизнес явно е същото. Това произлиза от нивото, на което се разглежда проблемът. Когато той е при един програмист, който смята, че може да го реши с два реда код, а архитектът го кара да направи отделни пакети, които да комуникират със специфичен протокол. Това означава, че на програмиста не му е ясно защо трябва да се направи точно така и какъв проблем се решава. Ако той смята, че два реда код стигат, значи има скъсана комуникация. Всичко може да се напише с малко код, но не е това идеята. Не решаваме проблем, който да води събиране на програмата в един ред…

Това значи, че т. нар. soft skills са много важни и за тази професия.

Комуникацията е ключът към всичко!

Интересно е, че напоследък все повече HR специалисти споделят, че програмистите трябва да притежават „меки умения“. Явно разработчиците не са както носещата им се слава от преди години, за забили глави в компютрите хора, които не говорят с никого. 

Когато проблемът се решава от един програмист, може би е окей. Но когато имаме стотици програмисти в една компания от над 2000 души, няма как комуникацията да ти е слабо звено, иначе няма да си полезен за организацията си. В кварталната гаражна фирма може да си нацупен и като влезе клиент да го изгониш, но когато си се събрал с екип, общуването е водещо. Често не търсим най-добрият специалист, а този с който можем общуваме ефективно.

А има ли го и този момент, че в компания от 2000 души е по-труден микро мениджмънта и някак може да се допусне дадени хора да се скатават, защото е по-трудно да наблюдаваш кой какво прави? 

Не съм съгласен! Има си инструменти за проследяване. Може би е имало подобно явление преди години, но сега, работата на всеки се разглежда, оценява и прогнозира. Компанията знае колко може да произведе и колко работа й върши даден служител. Би трябвало тези проблеми да са разрешени вече. Поне в компаниите по западен маниер…

Разкажи за MChaov Ltd., какво представлява? Свързано е с консултантска дейност? 

Да, това е фирма, която преди около 10 години създадох с цел да развивам собствена дейност и да не работя повече на трудов договор! Имах най-различни начинания, но се появи компанията SBTech, за която започнах да изпълнявам поръчки от типа графичен дизайн. Малко по малко те започнаха да ми изпращат все повече задачи, Front-end и други. Така започнах и по-сериозно да се занимавам с JavaScript. В един момент ми даваха толкова много работа, че стана нерентабилно да работим през фирмата. Поради тази причина, с тях преминахме на трудов договор, а MChaov Ltd. остана за странични проекти. Колкото до консултантската дейност – развивам такава, доколкото са ми интересни проектите. Тя изисква много време и ако трябва да консултирам бизнес, който като ниша не ми е познат, то трябва да отделя голям ресурс да вникна във всичките му процеси. Това може да отнеме и месеци. Затова по-скоро към момента се захващам с проекти свързани с обучение на хора или проектиране и програмиране на софтуерни системи.

В началото значи си бил нещо като външен контрактор за SBTech?

Да, но в даден момент обхватът на интересите ни се припокри и бе естествена стъпка да премина на трудов договор с тях.

По какви интересни проекти си работил през твоята фирма? 

Има някои доста шантави такива. Ще споделя доколкото ми позволяват договорите за неразгласяване (NDA). С колеги работихме по проект, който трябваше да е много конкурентен на iTunes. Разработвахме го на PHP. Накрая никой не чу за проекта, беше толкова секретен, че дори и не видя бял ден. Но като know-how бе много полезен за нас.
Работил съм по билинг система за ISP на ISP-та. Това беше преди много години, но беше първият ми сблъсък със система с десетки различни нива на достъп.
Скоро работих по една система, която се оказа типичен пример за extreme programming. Започнахме с една страница A4 изисквания и трябваше да сглобим макет за няколко дни – например за два. Обаче, накрая на ден втори, изискванията бяха повече от 50 страници и в крайна сметка се стигна до система, в която се качват CSV файлове, генерирани от втора система, event sourcing архитектура, защото файловете се агрегираха като информация, но трябваше да може и да се трие определен файл и данните да се опреснят. Системата имаше push нотификации през Azure и бе написана на много езици – .NET Core за бекенд, а от другата страна клиенти на Swift, Typescript, Java и тн. Дизайна се промени няколко пъти по време на разработката, защото изискванията се пишеха по време на самата разработка. Към средата преминахме от Linux + PgSQL на Windows и MSSQL. Като цяло всичко това е много забавно и на мен ми харесва – приемам го като предизвикателство! В крайна сметка проектът беше успешен, а това е най-важното за клиента!

А какви технологии използваш в сегашната работа? Както спонема, ти трябва да следиш и с какви би могло да се изпълни по-добре нещо…

Зависи на кое казваме „технология“. Списъкът като цяло е голям: .NET, .NETCore, TypeScript, React, различни бази данни, различни инструменти по CI/CD процесите и прочее…
Технологиите нямат значение! Смятам за голяма грешка на много програмисти, че се профилират като начин на мислене и взимане на решение. Няма нищо лошо да си експерт с тясна специализация. Проблемът е, когато имаш само един чук и се опитваш да решиш всички проблеми само с него. Тогава всеки проблем ти прилича на пирон! Има неща, които е по-добре да се решат с други инструменти – отверка, трион и т.н. Смятам, че не трябва да се ограничаваме в един език. Добре е да може да се пише и на други, за да може да се види как подобни проблеми могат да се решават с различните езици. Има неща, които много лесно се решават с JavaScript, но и такива, за които би било нерентабилно. Проблемът трябва да се решава с правилните инструменти! Например, Node.js се хоства по-лесно на Linux, ако трябва да сложиш база на същата машина по-добре да не е MSSQL… Ако избереш второто, то тогава има ограничения, които идват с този избор. В моята работа се старая да прилагам правилните инструменти към правилните проблеми.

Има ли с какво към момента да се подобри българският ИТ пазар? 

Ще споделя само мнение, защото нямам достатъчна компетения да говоря за целият пазар. Това, което виждам е, че поколението, което влиза в сектора, до голяма степен няма истинското желание да се занимава с това. Повечето се захващат с тази работа поради икономически причини, което е напълно нормално и напълно уважително, но без това желание, развитието им е под голям въпрос, което води и до това, че те няма да има как да развиват и тези след тях. Това значи, че ще имаме деградация. Това, което може да се подобри е опит да се възпита любов в тези хора към технологиите. Много често забелязваме следното – търси се React или Angular Developer. Човекът е решил, че няма да се занимава с нищо друго освен Angular или React. Паднал си е по една технология и не е склонен да учи друга, дори и тя да му изкарва повече пари. Навлязал е в зона на комфорт. А по този начин специалистите доста закърняват. Смятам, че не трябва да се обвързваш технологично. Трябва да си с отворено съзнание и да подхождаш към всяко ново нещо с нагласата за нов урок. Интересно е как различните технологии разрешават подобни проблеми.

Попитах не за друго, но например, при интервю с председателя на БАСКОМ, той сподели, че очаква в България да се появят хората, които да направят следващия Facebook. Не буквално разбира се, а по-скоро като метафора за постижение, което може да разтърси целия свят и да промени начина ни на живот. От друга страна, според приятел, работещ в сектора, това е невъзможно за България, защото тук пазарът е малък и някой с лекота може да те откупи за 100 милиона, а ти ще се съгласиш, защото си решаваш проблемите до края на живота, че и отвъд него. А и така или иначе е много възможно да няма как да си развиеш фирмата, защото пазарът е пълен от големи конгломерати и ти нямаш ресурса да ги достигнеш. Ако Google дочуе за твоята идея, ще се впрегнат и за месец ще направят това, което ти за 3 години… 

Ако смяташ, че 100 милиона ти стигат и си готов да ги вземеш – защо не? Но това значи, че на теб целта ти е била друга. Повечето хора, които са направили тези компании като Facebook, Twitter, YouTube, не са ги създали, за да ги купи Google или за да се продадат и да станат мултимилиардна корпорация. Доста от тези неща са направени като студентски проект или някаква идея, която им се е сторило готино да разцъкат с приятели и т.н. Това е ключът – те са родени от страст към решаване на проблеми и от страст към програмирането. Зукербърг не се е събудил една сутрин с идеята „сега ще покорим света с Facebook”. Тези неща се раждат естествено в среда, която провокира хората да пробват идеите си и да ги реализират. Всъшност много от тези проекти са започнали именно в университет.

Ако подобни компании са родени от чисти технологични намерения и се върнем на това, което каза, че забелязваш липсата на такива в идващото поколение програмисти, то май няма да се създаде у нас нещо толкова гигантско… 

Да, но пак казвам, че не е напълно лошо. Има нужда от всякакви хора на пазара. Тези, които са насочени от икономическите причини към пазара, обикновено са готови да вършат всякаква работа от 9 до 17 и да им се махне от главата, а за това има много място в индустрията. Особено в аутсорсинга. Там нещата са насочени основно така. Не, че нямат нужда от тесни специалисти, но когато работата е повече на парче, то фокусът е другаде.

А как се отразява работата от вкъщи на теб и въобще на DraftKings? Според някои специалисти има опасен за българския пазар фактор, че много компании видяха, че дистанционната работа се получава, а нашият пазар вече не е толкова евтин, и някои компании могат да запожат на служители от други страни. 

Не мисля, че home office моделът ще измести офисът изцяло. Когато работиш в голям екип, нищо не може да замени физическото присъствие при комуникация, то изгражда доверие по съвсем различен начин. Това, което бих дал като лични наблюдения е, че в home office опцията, рязко се изостря разликата между тези, на които им се работи и са съвестни и тези, които го правят колкото да си вземат заплатата и започват да скатават от работата.
Проблемите с дистанционната работа обаче са свързани повече със сигурност. За да дадеш достъп до вътрешно фирмената мрежа, даден служител трябва да отговаря на някои изисквания. Случаен лаптоп, закупен от някой си магазин, който не е преминал през сертификация от ИТ отдела, няма как да е сигурен и да бъде вързан в мрежата без риск. Когато се работи с данни с висока чувствителност, то това става опасно. Ако имаш изтичане на имейли и пароли на потребители. Един такъв гаф може да има големи финансови изражения. Често се подхожда несериозно към тези рискове и смятам, че за много организации дистанционната работа е предизвикателство за ИТ отделите.

Ако си загубиш фирмените данни, предполагам си губиш и бизнеса…

При някои е така! В SBTech се наемат външни фирми, които се опитваха да пробият софтуерът и офиса. Появяваха се хора и се опитваха да плъгнат флашка в даден компютър и да източат файлове. Правят се одити с външни фирми. Например, пристига облечен като доставчик на пица човек и действа. А за SBTech сертифицирането е от огромно значение, клиентите са държави. Не някакви локални бакалии, които имат сайт за промотиране на био продукти. Такива тестове (Pen. Testing) се правят по цял свят и са изискване за взимането на лиценз в някои пазарни ниши.

Предполагам, със служебен сертифициран лаптоп се изключват някои рискове при дистанционната работа? 

Да. Сега остава всичките ти служители да работят на лаптопи, което не е най-ефективното нещо. Те са по-слаби машини и е по-удобно да си на мощен компютър, на два монитора и т.н. Не всеки има място в дома си за цялата тази компютърна система. Поради тази причина преживяването на хората варира. Home office за някои е рай, но за други е бич. Аз съм по-средата … все пак имам жена и дете.