Aventura de a crea un produs digital este o experiență ce dezvoltă fondatorii atât ca indivizi cât și ca profesioniști. Există diferențe majore între fondatorii experimentați și cei care sunt la primul startup tech. Din experiența de a colabora pe foarte multe astfel de proiecte ca designer, împărtășesc unele observații ce vor ajuta fondatorii novici să își depășească limitele. Ca psiholog, voi prezenta aceste observații din perspectiva biasurilor cognitive. Acestea sunt deviații sistematice de la gândirea rațională, ce se întâmplă fără să ne dăm seama. Toți oamenii suferă de astfel de biasuri. Cele de mai jos sunt cele mai frecvente și neproductive biasuri care îi afectează pe fondatorii novici. Ne concentrăm pe sfera dezvoltării de produs care, chiar dacă este doar o dimensiune a antreprenoriatului, este cea în care am cea mai multă experiență.

Este acel moment al anului, din nou. Au trecut deja trei luni din 2017 și mai sunt doar trei luni până la mijlocul anului. Trebuie să setăm obiectivele pentru trimestrul următor. Ce ar trebui să includem? La ce să renunțăm? Pe ce ar trebui să ne concentrăm mai mult? Iată o scurtă privire din spatele cortinei, asupra a ceea ce am învățat în timpul implementării OKR-s eficiente în echipele cu care am lucrat. OKR-s sau Obiective și Rezultate-Cheie (Objectives and Key Results) este un sistem de stabilire și comunicare a obiectivelor și a rezultatelor într-o organizaţie. OKR-s sunt o modalitate simplă de a crea structură pentru companie, echipe și pentru membrii echipei.

Prima dată, când am susținut o prelegere cu titlu de “Incursiunea DevOps in spațiul Enterprise”, a fost la finalul anului 2014 în cadrul conferinței DevConFu. Ulterior, am susținut prelegerea cu mai multe ocazii pe parcursul anului 2015 la diferite conferințe din Europa. Un timp, am considerat-o o “temă închisă” și nu am fost interesat să o extind, până când mi s-a solicitat să o susțin din nou în anul 2016 și mai apoi în anul 2017. Enterprise este o noțiune folosită excesiv. Majoritatea o asociază cu procese lente și ineficiente. Nimeni nu vrea să aibă de- a face cu așa ceva! În același timp, de fiecare dată când întreb publicul: “Câți dintre voi ați lucrat într-o companie Enterprise?” — peste 95% ridică mâna. Cumva, natura umană ne face să preferăm modelele simple ale lumii. A fi o companie start-up vs. a fi o companie enterprise, dezvoltarea cu microservicii vs. bătălia cu un monolit? Suntem oare majoritatea de partea nefastă/greșită? Probabil că nu.

Steve Ballmer, Microsoft CEO, aducea în 2012 la cunoștința publicului larg și a fanilor produselor Microsoft dezvoltate în ultimii 30 de ani, misiunea companiei: „a computer on every desk and in every home”. Desigur, drumul către această nouă misiune declarată începuse odată cu lansarea revoluționarei și, în egală măsură, controversatei platforme Windows 8, care a fost proiectată pentru a fi prezentă pe toate clasele de dispozitive, de la desktop și laptop, la telefoane mobile, tablete și consolă XBOX. Microsoft a trebuit însă să mai aștepte doi ani până la momentul când Bill Gates a luat decizia de a veni în prima linie ca „Founder and Technology Advisor” și a destituit fostul CEO, înlocuindu-l cu Satya Nadella, fostul director al diviziei de tehnologii și platforme cloud. Datorită aceastei schimbări binevenite, Microsoft aduce în fața publicului larg și a întregii lumi, misiunea companiei: „Our mission is to empower every person and every organization on the planet to achieve more!”, Satya Nadella CEO Microsoft.

Deși ne place să credem că pentru design sunt suficiente talentul și creativitatea, organizarea procesului de design este un factor critic pentru succesul unui proiect. În cele ce urmează, descriem câteva idei care ajută la structurarea unei strategii de design, mai ales pentru proiectele de design de interfețe pentru software.

Continuous Integration este o practică DevOps din domeniul dezvoltării de software prin care fiecare membru al echipei de programatori își integrează munca cu ceilalți colegi în codul sursă de mai multe ori pe zi. Ea este considerată o formă de control al calității. Integrările sunt verificare de un build automat care este utilizat pentru a detecta erorile de integrare cât mai repede posibil și pentru a testa aplicația. În acest cadru intră Jenkins, o unealtă de Continuous Integration și Continuous Deployment, folosită pe mai multe platforme (cross-platforms) de dezvoltare.

Publicat în Numărul 57 Citeşte mai mult

Ultimii câţiva ani au adus cu ei o schimbare majoră a mentalităţii persoanelor în ceea ce priveşte software-ul şi modul în care îl folosesc. Această schimbare a fost adusă de către omniprezentul smartphone, apariţia cloud computing-ului şi de către mai recentul internet of things (IoT). Dacă sunt luate în combinaţie cu o constantă creştere în competiţia dintre companiile software pe o piaţă cu tendințe de stagnare pe anumite segmente, puteţi înţelege cu mai mare uşurinţă cum stau lucrurile în momentul de faţă.

Așa cum se întâmplă în foarte multe companii cu experiență îndelungată în IT, există o mare dorință de a se obține o modalitate prin care programatorii să cunoască efectele muncii lor nu numai în contextul modulului la care lucrează, dar mai ales din perspectiva întregului produs software comercializat. Acest lucru ar putea părea relativ ușor, dar în cazul unei soluții complexe, cum ar fi cazul unui ERP, cu multiple module atașate la core-ul soluției, este un demers presărat cu momente tensionate.

Fiecare modificare adusă aplicației este urmată de schimbări în unul sau mai multe teste. Ce se întâmplă când o nouă funcţionalitate aduce schimbări la mai multe data providere? În timp, data providerele din testele automate încep să devină tot mai încărcate, pline de date şi tot mai greu de urmărit. Să presupunem că avem de testat un magazin virtual, care suportă un tip de cont ( cont normal) şi se poate accesa din trei domenii de internet diferite. Acest magazin este prezentat doar în limba engleză.

Multe companii ajung să depindă de anumite soluții software de business din varii motive: fie ca urmare a utilizării îndelungate a acestora, fie ca urmare a unei adaptări (adeseori laborioase și de durată) a soft-ului la particularitățile respectivelor afaceri, fie pur și simplu pentru că softul în cauză este unul foarte bun în comparație cu celelalte soluții de pe piață. Un exemplu poate fi cel al soluțiilor ERP (enterprise resource planning) adaptate în funcție de procesele de business ce prezintă interes pentru compania beneficiară. Aceste softuri ajung să fie particularizate și utilizate într-un asemenea grad ridicat, încât pentru unele companii este imposibil să-și desfășoare activitatea fără ele. (De exemplu: companiile de transport, companiile de distribuție, instituțiile financiare, etc.). Mai pot exista și alte exemple.