Proiectarea unei echipe de sisteme

Modele și lecții învățate pentru scalarea unei echipe pentru o întreprindere

Majoritatea organizațiilor ajung să înțeleagă sistemele și de ce sunt importante. Cu toate acestea, cât costă? De ce echipă avem nevoie?

O echipă de sistem servește echipe de produse (sau similare)

Cartea excelentă a lui Peter Merholz și Kristen Skinner Org Design for Design Orgs descrie modele și roluri în compunerea echipelor de design și org. În capitolul Rolul și Compoziția echipei, ei descriu o echipă de cercetare adjunctă care servește la multe alte echipe:

„Cercetătorii UX au acum o masă critică pentru a fi propria lor echipă ... [cu] un șef de cercetare ... care susține creșterea profesională a cercetătorilor și menține o înțelegere globală a informațiilor de cercetare în toate produsele și serviciile unei companii.”

Când am citit acest lucru, m-am gândit „Yup, cum ar fi echipele de sisteme de proiectare”, rezolvând problemele de proiectare mai simple, mai simple - un limbaj vizual, componente de interfață utilizabile etc.

Cu acest model în minte, am fost surprins să aud Peter să reflecte asupra echipei de sisteme (Spotify) din noiembrie anul trecut la UI21, ca unul care trebuia să „pirateze un patch, un patch organizațional pentru [modelele]” descrise de el. Poate că am înțeles greșit. De-a lungul anilor am fost între ~ 15-20 de echipe de sisteme, care servesc mai multe echipe în mod similar cu aceste practici de cercetare (dar nu la fel).

În experiența mea, echipa de sisteme optime este multidisciplinară și independentă pentru a servi mai multe echipe care fac lucruri digitale. Echipa de sistem se comportă ca un produs consumat de produse (și de alte echipe).

Cine face parte din acea echipă? Sunt cu normă întreagă sau cu jumătate de normă? Ce discipline ar trebui reprezentate? Din ce echipă (echipă) le furnizăm?

Având în vedere aceste întrebări, acest articol ilustrează etapele comune ale creșterii unei echipe de sisteme, împărtășește exemple de echipe pe care le-am condus în ultimii patru ani și acoperă tiparele și posibile capcanele pe care le puteți confrunta în timp ce formați și operați o echipă de sisteme.

Etapele dezvoltării echipei de sisteme

Majoritatea persoanelor cu care stau de vorbă la clienți, conferințe și sistemul de design al comunității noastre Slack evoluează pe una dintre cele patru etape de creștere: cronometre de rezervă, persoane alocate, echipă dedicată și echipă de echipe.

Etapa # 1: Temporizatoare de rezervă

Persoanele care se potrivesc cu sistemul de lucru pe marginile timpului descriu adesea modul în care explozia lor pasională nu a decolat cu adevărat:

"Sunt pe cont propriu. Am creat o foaie de {Sketch sticker sau mini-kit de cod Bootstrap} în timpul meu suplimentar, dar nimeni altcineva nu o folosește. Cum fac pasul următor? ”

Sistemele construite vineri după-amiază sau duminică seara nu rezistă. Un șablon Sketch sau un cod de început este mai bun decât nimic. Cu toate acestea, eforturile spartane nu sunt o practică a întreprinderii în procesul de elaborare.

Take away: Nu te descuraja! Multe călătorii în sistem încep astfel. Dovedește-ți instrumentele care duc la rezultate - consecvență, eficiență, reutilizare - în proiectele pilot. Este o etapă importantă pentru a educa modul în care eforturile unui sistem beneficiază de alții.

Etapa 2: Individ (e) alocat

Pe măsură ce valoarea sistemului este recunoscută, un manager sculptează o alocare previzibilă, dar limitată (10% - 25%) a unei persoane din angajamentul echipei de produs și face publică responsabilitatea sistemului către echipe și colegi. Împuternicit cu un mandat și timp, începeți să eliberați în mod regulat ieșiri tangibile, indiferent dacă sunt elemente de proiectare standardizate sau un kit codat.

În acest moment, avocații sistemelor cu gândire similară pot începe coordonarea în proiectare și inginerie. Este posibil ca cineva să înceapă o perioadă de timp, dar poate putrezi cu bilete definite vag, care se țin luni întregi. Documentația pe jumătate coaptă se extinde pe pagini web nepoluate sau (oh nu!) Confluență. Actualizările se întâmplă, dar puțini știu când, cum și de ce.

Pentru ca un sistem să prospere, trebuie să publice rezultate de înaltă calitate și să servească în mod dependent adoptatorii.

„Dacă vă pricepeți la asta, creați o cerere în cadrul organizației dvs. care nu poate face față cu alocările curente.” - Jared Spool, dincolo de punctul de înclinare UX

Cu un flux constant de rezultate obișnuite, clienții dvs. (echipele de produse) adoptă piese, indivizii încep să renunțe la control la problemele rezolvate de sistem și managementul se încălzește la ideea formării unei echipe dedicate.

Etapa 3: Echipa de sistem - ca și echipă de produs

În crearea unei echipe formale de sistem, străduiește-te pentru un amestec cu autoritate recunoscută atât din domeniul proiectării, cât și din cel al ingineriei.

Compoziția echipei de sistem la nivel înalt, după mărime

Echipele pe care le-am format și condus recent sunt compuse ca un amestec de:

  • TREBUIE să aibă: membrii proiectării pot cuprinde subdiscipline - vizual, interacțiune, arhitectură informațională pentru a numi câteva - dar echipa trebuie să exceleze în crearea unui limbaj vizual elegant.
  • TREBUIE SĂ: Ingineria aduce un accent frontal cu cunoștințe HTML și CSS, abilități experimentate pentru a stabili convenții și construirea de instrumente.
  • Ar trebui să aibă: abilități de gestionare a produsului și leadership pentru a stabili viziunea, direcția de conducere, curatarea foilor de parcurs, monitorizarea adopției și organizarea de backlogs, scrums și critici.
  • PUTEM FI: Preocupări de specialitate precum strategia de conținut, accesibilitatea, performanța, SEO și multe altele. Deși este valabil, rețineți că sistemele se însoțesc în primul rând de proiectare și inginerie.
  • UTILIZAT NU FACE: QA și Cercetare. Finanțarea QA de multe ori nu este suficientă și echipele de sistem pot stabili, oricum, practici pentru evaluarea calității. Cercetările pot exista ca servicii de asistență pentru echipele de produse.

Etapa 4: Echipa sistemului de echipe

Unele întreprinderi masive (cum ar fi, bănuiesc, Google, IBM, GE, Cisco sau Microsoft) dezvoltă eforturi de sistem pentru a întinde o umbrelă de mai multe echipe interrelaționate pentru a îndeplini obiectivele sistemului.

Echipa de echipe

Pentru majoritatea dintre noi, care servesc mult mai puține produse decât ei, această scară este complet nerealistă și inutilă. Sigur, este util să vedeți proporțiile atribuite fiecărei practici. Cu toate acestea, această scară care se poate speria ar fi sponsorii unei echipe de sistem ca produs. Aliniați dimensiunea echipei dvs. cu obiective realiste și rezultate cheie pe care doriți să le obțineți.

Exemple de echipă de sistem

Deși am participat la echipele de sisteme de proiectare continuu începând cu 2006, practica a evoluat considerabil în jurul anului 2012, când s-a întâmplat sensibilitatea, HTML și CSS s-au consolidat și unicornii au început (parțial) să proiecteze sistematic în cod.

Următoarele exemple exprimă o evoluție a modelelor de echipă de sistem cu care am fost implicat de atunci.

Exemplul 1: comerț eComerce Going Responsive

Ce a funcționat bine: această echipă dedicată a proiectat și documentat standarde copioase într-o experiență personalizată bazată pe web. A fost sistemul „mare kahuna”: stil, interacțiune, componente, modele, brand, editorial, SEO, accesibilitate, lucrări! Întrucât întreprinderea a avut nevoie de aproximativ 2 ani pentru a „răspunde”, sistemul a fost esențial în convergența unei călătorii disparate a clienților.

Ceea ce am făcut altfel de când: suspin, inginerie. Echipa noastră de sistem a construit o bibliotecă de componente robustă pentru prototipuri cu proiecte responsive și pentru construirea site-ului standard. Cu toate acestea, conducerea ingineriei a rezistat codului nostru și nu a construit niciodată o bibliotecă pentru comunitatea lor. Rezultatul? Eforturi duplicitare, ineficiențe și neconcordanțe, cu excepția celor care devin codul nostru în realizările lor.

M-am promis să nu urmărim niciodată un sistem fără cod în medii care, în mod evident, au nevoie de el, dar ingineria duce la blocarea urmăririi.

Exemplul 2: Un limbaj de proiectare pentru un organ care explodează

Ce a funcționat bine: Odată cu organizarea balonului de la ~ 30 până la 200+ designeri în 12-18 luni, echipa de sistem a condus la dezvoltarea unui limbaj de design partajat documentat pe un site de standarde personalizate (astfel, dezvoltatorul front-end). Având în vedere scara masivă, distribuită a organului de proiectare, am angajat designeri federați pentru a conduce interacțiunea, UX-ul și elementele de bază ale pictogramelor.

Deși domeniul de aplicare a fost mai mic - doar stilul vizual, butoanele și formularele în șase luni de muncă -, a fost apreciat ca un succes având în vedere amploarea și provocările cu care se confruntă.

Ce am făcut diferit de atunci: crearea și conectarea mai multor personal intern. În timp ce produceam eficient rezultate, păstorirea unei comunități atât de mari a fost încordată de geografie, tehnologie și practici operaționale instabile. Organul avea nevoie de mai mult personal al sistemului și stabilitate pentru asta.

Și, din nou: cod. Ar fi trebuit să lansăm un kit și să ne cerem iertare mai târziu.

Exemplu 3: Biblioteca de site-uri web simplu

Ce a funcționat bine: înarmat cu un limbaj vizual bine definit dintr-o agenție separată, am proiectat, construit și documentat o bibliotecă de componente simplă pentru proprietăți web bogate în conținut. Echipa noastră a desfășurat cu succes o primă versiune în trei luni, urmată de întreținere și creștere pentru o perioadă limitată.

Ce am făcut diferit de când: În ciuda avertismentelor cu privire la capacitatea necesară pentru menținerea ei în viață, biblioteca a intrat în hibernare pe măsură ce personalul s-a dispersat. Planul nostru de succesiune și derulare nu a fost suficient de puternic pentru a rezista la plecarea agenției mele. În cadrul proiectelor, am planificat în mod afirmativ alocări și succesiune cu lideri interni pe toată perioada formativă a unui sistem.

Exemplul 4: Ecosistemul de produs digital

Ce a funcționat bine: am împerecheat cu un designer intern pentru a proiecta și documenta stilul și componentele bazate pe reproiectarea produsului principal, pe care le-am făcut cu un sfert înainte. Și mai bine, ingineria a investit trei dezvoltatori cu jumătate de normă din produse-pilot, care împlinesc progresiv sistemul în activitatea de lucru în desfășurare.

Am lansat o bibliotecă v1.0 în trei luni și am urmat cu cicluri trimestriale pentru perfecționarea instrumentelor și extinderea catalogului bibliotecii. În calitate de proiectare, inginerie și produs convenit pentru planificarea anului 2017, VP Engineering a salutat sistemul:

„Cel mai important lucru pe care l-am făcut anul trecut a fost construirea acestui sistem. Este baza tuturor lucrărilor noastre viitoare. ”

Exemplul 5: Biblioteca cu concurenții

Ce a funcționat bine, până acum: În timp ce am început să optimizăm și să extindem o bibliotecă de bază existentă, au apărut biblioteci suplimentare în alte linii de afaceri. Echipele erau confuze: care să adopte? În loc să concurăm, am coordonat eforturile și ne-am integrat într-o echipă mai mare și unică.

A existat o tracțiune pe termen scurt pentru re-echipa și codul refactor pentru a servi în mod flexibil tuturor. De asemenea, scrums și planificarea au durat mai mult. Cu toate acestea, drumul nostru înainte se va produce împreună pentru viitorul previzibil, iar CEO și un alt VP par convinși:

„Am simțit și am recunoscut că vom avea două biblioteci, dar apoi a apărut o a treia. Sunt încântat să văd că am găsit o modalitate de a face doar unul. ”

O altă componentă a scalării practicii a fost implicarea comunității de proiecte federate pentru preocupări proprii: UX, pictograme, marcă, diagrame, conținut și accesibilitate. Deși niciunul dintre acești „proprietari de segmente” nu are capacitate dedicată, toți sunt acum puncte de contact pentru a modera discuțiile, a conduce prioritățile și a angaja colegii pentru a oferi rezultate.

Lecții învățate Gestionarea echipelor de sistem

# 1. Designul codat este Adevărul. Blend Design și Inginerie.

Am participat la suficiente echipe din 2006 realizând biblioteci de șabloane de design și documentând designul. Sunt convins că valoarea unui sistem de proiectare crește de zece ori atunci când se formează o punte între proiectele puternice și practicile de inginerie.

Da, există condiții la scară mondială (exemplu: Google Material) în care este necesară o specificație de design chiar și fără cod. Cu toate acestea, în practica mea, unificarea unui limbaj vizual, a componentelor și a altor cadre în codul construit realizează eficiența, claritatea și întreținerea promisă a sistemului.

Take away: Indiferent de client, cea mai importantă anchetă inițială este cu privire la cine din fiecare zonă poate colabora pentru a atinge acest obiectiv comun.

# 2. Capacitatea timpului jumătate este o forță, nu o slăbiciune

Observați modelul din fiecare echipă de mai sus? Toți membrii personalului sunt angajați la o jumătate de normă, în caz contrar rămânând angajați cu un produs. Pentru o echipă cu dimensiuni moderate, astfel de angajamente creează relații în 3-5 echipe cheie de produse. Acest lucru permite vizibilitatea asupra a ceea ce au nevoie de produse importante și minimizează părtinirea față de orice produs.

Proiectanți și ingineri, convenind ca echipe de sistem, totuși alocați pentru produse disparate

Acest lucru vine cu riscuri:

  • Produsul conduce concesionând o capacitate de sistem cu jumătate de normă, dar încă mai alocă și așteaptă 32 sau mai multe ore de capacitate pe săptămână pentru produsul lor.
  • Membrii echipei străbătură mai multe ritualuri conflictuale (scrum, planificare, critică) care distorsionează proporția întâlnirilor față de „finalizarea lucrurilor”.

Take away: Puteți merge cu semicronometri, doar așteptați să vă aliniați. Pentru a gestiona în sus și peste tot. Pentru a distinge angajamentele de încovoiere de cele care se rup. Va fi complicat, dar nu suficient pentru a deteriora grav efortul.

# 3. Continuitatea echilibrului cu rotație

Pentru echipele de sistem cu 2+ angajați de la orice disciplină, uneori vom identifica membri permanenți destinat unui angajament de un an sau mai mult. Acești membri pot escalada la timp complet și pot persista nu doar decizii și convenții, ci și ritualuri tribale. Continuitatea este importantă. Pe de altă parte, vom roti alți angajați ai sistemului, deoarece adoptarea are loc pe produse.

De exemplu, după o lansare inițială, vom căuta ce produse sunt „următorul val” de adopți. În cadrul acestor produse, vom căuta designeri și ingineri disponibili și talentați, disponibili pentru un tur jumătate de trei sau șase luni cu echipa de sistem. Toată lumea câștigă: sistemul este învățat profund și previzibil, iar un produs poate să se extindă și să evolueze nucleul spre propriul beneficiu.

# 4. Anticipează contracția periodică ca o oportunitate

Este obișnuit ca unii angajați ai sistemului să se reorienteze la lucrările cu normă întreagă după o lansare semnificativă a sistemului. Asta e ok.

Participați la trecerea la sarcini în jurul integrării problemelor sistemului, monitorizați modul în care fostul membru al echipei de sistem realizează potențialul sistemului în spațiul lor și folosiți îmbunătățirile produsului pentru a construi relatarea beneficiilor și flexibilității sistemului.

# 5. Noi membri la bord ca test Litmus de calitate a sistemului

Integrarea unui nou membru al echipei este un caz de testare excelent (și ușor) pentru claritatea proiectării sistemului, calitatea codului și respectarea promisiunilor sistemului.

Anul trecut, un al patrulea inginer s-a îmbarcat și a expus imediat documentația penibilă a procesului sistemului în unele zone, precum și o concentrare insuficientă asupra testelor specifice de accesibilitate. În luna următoare, toți ne-am certat să îmbunătățim acele calități. Profitând de acest moment, noul nostru membru a sărit pentru a rezolva unele dintre aceste provocări și a stabilit o poziție influentă alături de „cronometrele lungi” deja existente în echipă.

# 6. Personalul sistemului ar trebui să aplice circumscripțiile

Sistemul servește un portofoliu pentru unul, dar nu pentru toate liniile de activitate? Atunci aceasta este limita de unde provineți personalul. Sistemul acoperă marketingul și organizațiile de produse? Apoi, muncește din greu pentru a stabili (cel puțin) o colaborare regulată, semnificativă între cei doi sau (în mod ideal) să îmbine personalul de la ambele organe împreună într-o practică.

Fără o reprezentare adecvată, este greu să obții un sistem format din oameni adoptați de echipe de acolo și de pretutindeni.

27 aprilie 2017: Diagramele articolului au fost actualizate pentru a elimina specificul de gen, ca răspuns la comentariile unui cititor.