Suntem in febra lansarii Dropthework. Multa vreme (ani deja), munca noastra a fost precum in cercetare. Identificam o problema, gandeam o solutie, o implementam. O testam, manual sau automat, apoi treceam mai departe. Solutiile, din fericire, nu erau doar din registrul cercetarii. Ci solutii practice. Multe dintre ele deja implementate. Altele vin curand.
Problemele erau/sunt fie reale, fie inchipuite. Cele reale isi aveau/au sursa in cerinte specifice ale unor clienti. Se poate citi mai degraba in registrul prieteni. N-am lucrat in piata libera in ultimii ani, ci doar am ajutat cateva companii a caror activitate avea legatura cu produsul. La Dropthework ma refer. Sau inchipuite. De obicei de mine. Ma gandeam la tot soiul de implementari si decideam brusc ca lucrurile pot fi facute mai bine.
Dupa ultima vacanta (putin mai lunga decat oamenii is obisnuiti, destul de normala pentru mine) am intrat in mood-ul de sprint (no pun intended @agile fans) final pentru lansare. Si am descoperit, inca o data, ca detaliile sunt cele care consuma timp. Acei extra 5% care fac diferenta intre un MVP si un produs serios. Doar ca cei 5% consuma, in functie de cum ai gandit primii 91% (stiu ca raman 4% dar acolo nici macar nu speram sa ajungem prea curand), intre o viata si o vesnicie:).
Daca pana acum ne-am descurcat cu Jira full + Confluence (asa am inceput – deh, reflexele trecutului), apoi am migrat mai jos in universul “atlasian” la Trello (apropos – poate scriu intr-o zi – sunt utilizator Trello din prima zi in care a fost lansat produsul) cand ne-am apropiat de lansare am inceput sa ne gandim la multe. Organizarea proceselor care nu tin de produs, suport, facturi, planuri, discutii cu potentialii clienti, comunicare, strategie de marketing, mailuri, casute, documentatie si tot asa.
Sunt diverse saas-uri in piata care rezolva punctual niste probleme, insa overhead-ul integrarii este urias. Si nici nu-i flexibil. Integrarile de diverse tool-uri sunt potrivite unor organizatii mari si stabile. La noi nu-i cazul. Putem schimba prioritati de mai multe ori in timpul zilei. Sau al noptii. Caci nu avem un program normal de lucru.
Intrucat nevoile is tot acolo, dar solutii potrivite lor nu gaseam…. am inceput sa construim un univers de diverse tool-uri. Unele super specifice – gen platforma de administrat formulare pe mai multe site-uri – doar webservice-ul si o mica interfata grafica – nu de alta, dar preferam sa nu injectam formulare intr-un design gandit altfel. Cele mai multe probabil nu vor iesi din laborator. Altele – generice. Solutii ce pot acoperi nevoile multor echipe mici, dar cu nevoi mari. O sa auziti multe de la noi in urmatoarea perioada.
Putin despre noi – desi pare ca n-am lucrat in ultimii 5 ani (si dintr-un unghi este corect – intrucat as spune ca mai mult ne-am jucat) din diverse initiative am atins (o lista non exhaustiva generata pe loc de o memorie incarcata) – platforme de crypto construite de la zero, wrappere de crypto, solutii KYC via machine learning si niste algoritmi bazati pe KISS, management de crypto ATMs, aplicatii dedicate unor fluxuri medicale specifice, solutii ecommerce de tot genul – de la chestii simple la integrari diverse – marketplace-uri multiple, integrari cu tool-uri destepte de marketing si CRO, solutii de booking management pentru servicii intr-un singur loc sau in locatiile clientului, ERP de productie facut peste airtable, jocuri – si nu niste chestii pe mobil – dev + infra de MMPORG. Plus joaca de-a wordpress-ul, inclusiv cu front custom scris peste core (cum am facut si cu Shopify), framework-uri destepte, solutii multisite pt distributie pe mai multe orase si/sau tari, platforme B2B destepte, am atins putin (note to self aici) zona de hospitality, chestii faine pe marketing. Networking si security. Nu de alta, dar nu se poate fara. Si sa nu uitam de retail. Retail-ul e urmatoarea noastra provocare. De vara.
Ne-am jucat peste retele crypto nativ sau cu node-uri hostate, ne-am dat si prin Azure, cateva servicii din AWS sunt daily driver si fac parte din ecosistemul Dropthework, avem cateva conturi de DO (aka Digital Ocean) cu ceva productie pe acolo, suntem confortabili cu cloud-ul privat sau cu solutiile inchiriate local/regional sau global. Preferam localul ori de cate ori se poate. Uneori nu se poate. Servere fizice mai noi sau mai vechi(chiar pe abordarea commodity + software driven), solutii de virtualizare, vm-uri sau containere (cu mai multe arome – chioare sau lxc, cu compose sau fara), K8s (sau Kubernetes pentru neinitiati) pentru productia Dropthework. Mergem mai sus pe scara abstractizarii: serverless (am facut niste BF-uri faine din care am invatat multe si implementat in Dropthework) is the new black. Sau ce culoare e acum la moda. Basca ca ne place edge-ul. Si nu din motive de senzori pentru spionat tot felul de chestii prin orasele de 15 minute pe care cu drag si spor tovarasii tfl-isti le vor implementate. Ci pentru niste scenarii specifice in care e nevoie de viteza. Nici la software nu ne-am abtinut. Php, C cu arome, Python, Rust, mai nou Ruby pe sine (poanta de geek), tot felul de JS – in fata, in spate, pe la mijloc – asta este singura lume mai miscatoare decat noi – in 3 saptamani daca nu ai ultima varianta de framework + nu stiu ce pachete lansate, hmmm…. ieri, deja esti obsolete. Nu putem fi toti DHH si sa stam pe sine. Chiar daca ne-ar placea sa avem tot timpul dreptate. Alta poanta geek-ish rau.
Sa revenim la subiectul articolului (care intrerupe si seria de povesti din spatele dezvoltarii Dropthework – revin si cu acea serie zilele astea). Am lansat un prim produs si vreau sa povestesc putin despre el. Se potriveste oricarei echipe (mai mari sau mai mici) in anumite conditii. De oriunde. Scriu in romana acum pentru ca mi-as dori sa fie folosit ca si avantaj competitiv de firme mici si destepte de la noi. Am experienta lunga in spate cu diverse solutii de suport, de email sau documentatie. Interna sau externa. Am folosit, dezvoltat sau implementat multe solutii legate de aceste procese. Le-am folosit ca utilizator, ca manager direct sau manager mai mare care si-a dorit claritate operationala. Am analizat multiple modalitati de “get things done”. Fast. De obicei.
Desi “se” uita ca in acest domeniu (si in multe altele): bine este mai repede decat mai repede. Vorba inventata de mine. Dar “science backed”. Citez un apropiat ce a folosit sintagma asta de curand. Intr-un domeniu nu foarte clar oamenilor de stiinta, dar cine-s eu sa opresc visatorii. Si in trecut am auzit intr-un context “eu sunt cu stiinta” intr-o discutie despre religie. Inteleg cum sunt spalati pe creier tfl-istii nostri. Sper doar sa fie mancati de dragoste la un moment dat. Si atunci vor sti si ei. Pentru conformitate, totusi, nu exista stiinta mai mare decat stiinta rugaciunii. Eventual a inimii. Jesus is King! Nu de alta, dar citind cele scrise mai sus cu privire la ce-am facut (si-s sigur ca am uitat chestii pe traseu) ai zice ca suntem vreo 50 de insi. Si ne-am ocupat de business de dimineata pana seara. Nu-i cazul. Vin dupa un sezon de schi de 90+ zile. Doar cu ajutorul celui de sus am ajuns sa facem ce facem. Si sa intelegem atat. Nu-i de la noi. Este de sus.
Inchizand paranteza, sa revenim la argumentatie: am facut suport (am petrecut o noapte de Craciun si un an nou intr-o sala Maxbet – de ex – si nu ca sa ma joc la ruleta sau broscute din alea), am documentat, am gestionat echipe, am prioritizat clienti sau canale, am luat feedback. Am implementat Jira, am implementat Zendesk, m-am distrat cu universul Zoho sau Freshdesk, am implementat si folosit HelpScout, am vandut, implementat, folosit si am fost partner Hubspot, tone de alte solutii locale sau self-hosted, sau solutii de documentare (de ordinul zecilor as spune). Prin urmare personalitatea mea multipla s-a putut desfasura in voie in rolul de Product Owner. Asta imi place. La asta cred ca-s cel mai bun. Desi, pentru consistenta, chiar si in acest caz corect este Product Owners. Am jucat rol si de client, si de agent, si de manager, si de devops, pe alocuri si de dev, de om in spatele unui calculator sau a unui telefon. Si tot asa. Ce am lansat (acum vreo 2 zile, cred): https://opkivo.com. Acolo gasiti site-ul cu ceva descriere. Nu-i chiar tot. N-am avut timp sa bibilim site-ul, dar in mare se intelege. La final pun si un video (construit de un tool AI de la google pe baza informatiilor de pe site). Aici ar trebui sa folosesc ceva cuvinte genz like, dar imi e teama ca o sa incurc iar aura cu rizz sau delulu si rad copiii de mine.
Fluxul este urmatorul: exista un sistem stil inbox in care primesti informatiile din afara. Pe baza adreselor de mail de tip: help@, sup(p)ort@, sales@, blabla@… Suportam atat mailboxuri full conectate prin imap, cat si shared mailboxes/distribution lists care n-au mailbox, dar care pot forwarda mesajele. Mesajele forwardate le preluam, parsam si dirijam catre inbox-ul cu pricina. Vizibilitatea la nivel de Inbox este 100% la nivel de tenant. Nu cereti altceva – RBAC rules gen – pentru ca nu vom implementa. Asta este regula. Transparenta totala la nivel organizational. Exista solutii si pentru “EU shit v2 law compliance legal regulament v.07 ×14 companies” – cate 1 tenant pe fiecare proces ce se doreste izolat. De acolo – fiecare mesaj devine ticket – sau – cum il denumim in produs – thread (de obicei e cu mai multe ping-pong-uri). Avem mesaje automate configurabile. Evident. N-am uitat. Cred ca nici colegii n-au uitat de cate ori am inceput o sedinta, formala sau informala, cu a citi articolul lui Radu Georgescu cu “John, please acknowlege!” (link aici – https://www.radugeorgescu.com/2011/12/06/john-please-acknowledge/). Daca ma calca vreodata o masina, s-ar putea ca de la lingura aia sa o patesc:P.
Am rezistat tentatiilor si cerintelor de a automatiza triaj-ul sau alocarea algoritmica a thread-ului. Am pastrat un concept (motivele sunt fiziologice and “science backed”::) inspirat de asumarea scrumiana. E mai bine pe termen lung. Avem un buton de take care genereaza dopamina. Kind of kidding (cand il inchizi, insa, sigur genereaza)! Relatia este thread-taker. Aka responsabilul intern de SFTC. Aka solve for the customer. Noi n-am uitat de documentele care au stat la baza culturii organizationale Hubspot. Ei (cu mici exceptii) au uitat complet. Pacat de produs si initiativa. Nu-l vad supravietuind, dar … oricum nu stiu ce se va intampla in urmatoarea perioada. Strategic vorbind, lumea lui a apus. Fara a nu repeta modificarea masiva de cultura (in jos – daca n-am fost clar din prima).
Atat separat, dar mai ales asociat unui thread avem un concept liniar de task-uri. Nu le spunem DO-uri in acest caz, desi….. cine stie ce ne rezerva viitorul. Nu pot fi alocate, nu pot fi transferate si sunt private 100%. Aka nici admin-ul de organizatie nu le poate vedea (sorry, but no sorry pt managerii obsedati de micro management si control). Thread-ul nu poate fi inchis cu munca deschisa. A ta sau a altora. Pentru ca desi nu este o solutie de project management, permite fluxuri avansate prin multipli operatori/departamente via take – take – take. Si nu-i site-ul de sah al lui Magnus sau Niemann. Nu stiu care este cu el. Nici asa nu poti vedea task-ul asociat unui ticket, insa o sa fii notificat de aplicatie unde este munca nefinalizata si stii cu cine sa comunici.
Cum comunici? Pentru un thread – varianta ideala este Internal tab si utilizarea contextului @ pentru a notifica un coleg. Atat. Simplu si eficient. Partea de private/public am pastrat-o si in implementarea KB. Aka knowledge base. Utila atat pentru proceduri, dar si pentru comunicare publica. Intrucat suportam nativ migrarea private → public recomandam scrierea informatiilor cu gandul ca la un moment dat vor ajunge publice. Avem deja suport pentru domenii custom. Si suportam un singur site/wiki/faq/support home – zi-i cum vrei per tenant. Daca exista cerere mare – sunt flexibil in a primi idei in aceasta zona. Momentan este pe principiul KIS. Aka KISS, dar fara al doilea S.
Din experienta – este poate cea mai buna platforma de suport din piata. Da, nu are chestii ultra mega enterprise pe care oricum nu le mai foloseste nimeni, nu de alta, dar agentii au ajuns mai ieftin decat indienii. Este o platforma gandita sa nu piarda munca pe drum, sa get things done sau, si mai frumos, “The operational inbox for work that cannot get lost. Shared inboxes, tasks, and knowledge for small teams who keep work moving.” asa cum am scris pe site. Aka aici https://opkivo.com.
Si cand am scris ca-i cea mai buna nu am comparat-o relativ, ci absolut. La relativ nu prea avem concurenta reala. Planul nostru de intrarea este 9.99 cu 3 team members – aka 3.33 eur/luna. Nu mai fac analogia cu pretul unui cappucino. Si implementarea este ceva de ordinul minutelor. Nu de alta, dar filosofia este clutter-less.
Ce stim despre viitorul aplicatiei: vor mai veni 2 canale de inbound. Cine le ghiceste? Hint: vom adauga inca 1 canal la outbound. O sa vina si versiune de mobil. Aplicatie. It’s a must. O sa dureze putin onboarding-ul la Apple si Google. Cum primim, incepem si implementarea (cateva componente importante sunt deja acolo).
Altfel stati prin zona. O sa tot comunicam, o sa tot lansam. Tot din zona asta: Small business. No small tools.
Si video-ul: https://youtu.be/DRC8IkQ9jmw