Dimensional Data

Este oficial. Operațiunile cu produse sunt un lucru. O căutare rapidă pe Google va scoate o listă lungă de articole care laude tot ceea ce operațiunile de produs au de oferit, de la eficientizarea managerilor de produs până la colectarea și sinteza datelor. Când m-am ocupat pentru prima dată de operațiunile de produs la GitLab , nu existau prea multe definiții sau îndrumări pe acest subiect. Am înțeles ce înseamnă operațiunile de produs, deoarece „făceam asta” ca parte inseparabilă a rolurilor mele de management de produs și de lider de produs de câțiva ani. Dar nu am avut niciodată ocazia să mă concentrez doar pe operațiunile cu produse. Oricât de entuziasmat eram, eram și nervos. GitLab accelera spre o IPO și atât echipa de management al produsului, cât și produsul se aflau în modul de hiper creștere. Și, pentru început, echipele multifuncționale, de la distanță, erau în mișcare, sincronizate și asincrone, zi și noapte, pe tot globul. Așadar, am luat legătura cu colegii care și-au început deja călătoria operațiunilor de produs și am valorificat perspectiva, progresul și învățările pe care le-au împărtășit cu generozitate. Și, făcând asta, mi-am dat seama că toată lumea o făcea puțin diferit. Acum, doi ani și jumătate mai târziu, operațiunile cu produse sunt un lucru la GitLab. Și cea mai frecventă întrebare pe care o primesc de la colegii care mă adresează este: Cum pot configura operațiunile de produs pentru succes în organizația mea? Pentru a răspunde la această întrebare, voi presupune că toți dorim să fim conduși de produs și centrați pe client, iar „succesul” ar fi operațiunile de produs care ne ajută să ajungem acolo. Voi presupune, de asemenea, că suntem de acord cu sentimentul care a evoluat, definind responsabilitatea operațiunilor de produs pentru a se încadra în aceste domenii de bază: instrumente, date, experimentare, strategie și consilier de încredere. Deși nu există o singură formulă, voi împărtăși trei chei care au deschis ușile pentru ca operațiunile cu produse să aibă un impact și să crească cu GitLab. 1. Împuternicește operațiunile cu produse ca funcție proprie, cu un loc egal, alături de alte funcții care generează valoare La GitLab, desfășurăm operațiuni de produs ca o funcție independentă sub umbrela produsului. Linia directă de responsabilitate față de șeful tuturor produselor asigură că operațiunile de produs au conștientizarea, alinierea și responsabilitatea față de nevoile macro ale produsului și ale afacerii. Acest lucru permite, de asemenea, operațiunilor cu produse să mențină o viziune largă și imparțială, precum și nivelul corect de influență, pentru a dezvolta strategii/tactici care să servească produsul și afacerea fără favor față de niciun grup anume. Acest articol din Silicon Valley Product Group de Marty Cagan oferă un context mai util cu privire la motivul acestei abordări. 2. Faceți din operațiunile cu produse o operațiune mai întâi de oameni Înainte ca operațiunile cu produse să poată oferi eficiențe și instrumente care sunt utile pentru produs și afacere, operațiunile cu produse trebuie să înțeleagă toți clienții săi interni. În primul an, operațiunile de produs au luat formă la GitLab, o mare parte din energia mea s-a concentrat pe construirea de relații, nu numai cu membrii echipei de produs, ci și în întreaga organizație. A deveni un consilier de încredere înseamnă mai mult decât furnizarea de date, este vorba despre a simți durerea și de […]

Limbile specifice domeniului (DSL) sunt limbi mici, concentrate, cu un domeniu îngust de aplicabilitate. DSL-urile sunt adaptate pentru domeniul lor țintă, astfel încât experții în domeniu să poată oficializa idei pe baza cunoștințelor și a experienței lor. Acest lucru face ca DSL-urile să fie instrumente puternice care pot fi utilizate în scopul creșterii eficienței programatorului, fiind mai expresive în domeniul lor țintă, în comparație cu limbajele de uz general și prin furnizarea de concepte pentru a reduce sarcina cognitivă a utilizatorilor lor. Luați în considerare problema însumării soldurilor diferitelor conturi bancare într-un fișier CSV. Un exemplu de fișier CSV este furnizat în exemplul de mai jos, unde prima coloană conține numele titularului de cont, iar a doua coloană conține soldul contului. name, balance Lisa, 100.30 Bert, 241.41 Maria, 151.13 Puteți rezolva problema însumării soldurilor folosind un limbaj de uz general, cum ar fi Ruby , ca în fragmentul de cod de mai jos. În afară de faptul că codul de mai jos nu este foarte robust, conține o mulțime de boilerplate care sunt irelevante pentru problema în cauză, adică însumarea soldurilor contului. #!/usr/bin/env ruby exit ( 1 ) if ARGV . empty? || ! File . exist? ( ARGV [ 0 ]) sum = 0 File . foreach ( ARGV [ 0 ]). each_with_index do | line , idx | next if idx == 0 sum += Float ( line . split ( ‘,’ )[ 1 ]) end puts sum . round ( 2 ) Mai jos este un exemplu de script AWK care rezolvă aceeași problemă. AWK este un DSL care a fost special conceput pentru a rezolva problemele legate de procesarea textului. #!/usr/bin/awk -f BEGIN { FS = “,” }{ sum += $2 } END { print sum } Programul Ruby are o dimensiune de 208 de caractere, în timp ce programul AWK are o dimensiune de 56. Programul AWK este de aproximativ 4 ori mai mic decât omologul său Ruby. În plus, implementarea AWK este mai robustă, fiind mai puțin predispusă la erori care pot apărea în fișierul CSV (de exemplu, linii noi goale, câmpuri de date formatate greșit). Diferența semnificativă în ceea ce privește dimensiunea ilustrează faptul că DSL-urile, fiind mai concentrate pe rezolvarea unor probleme specifice, își pot face utilizatorii mai productivi, scutindu-i de sarcina de a scrie cod standard și îngustând focalizarea limbajului asupra problemei în cauză. Unele DSL-uri populare pe care majoritatea dezvoltatorilor de software le folosesc în mod regulat includ expresii regulate pentru potrivirea modelelor, AWK pentru transformarea textului sau limbajul standard de interogare pentru interacțiunea cu bazele de date. Provocări la proiectarea limbilor specifice domeniului Crearea de prototipuri, proiectarea și evoluția DSL-urilor este un proces provocator. Din experiența noastră, acesta este un ciclu explorator în care prototipați în mod constant ideile, le încorporați în limbaj, le încercați în realitate, colectați feedback și îmbunătățiți DSL-ul pe baza feedback-ului. Atunci când proiectați un DSL, există multe componente care trebuie implementate și evoluate. La un nivel foarte înalt există două componente principale: lexer/parserul de limbă și procesorul de limbaj. Lexer/parser-ul este componenta care acceptă intrarea conform definiției limbii, care este de obicei specificată prin intermediul unei gramatici a limbii. Faza de analizare/lexare produce un arbore de sintaxă care este apoi transmis procesorului de limbaj. Un procesor de limbaj evaluează arborele de sintaxă. În exemplul […]