Järjestelmätiimin suunnittelu

Yrityksen tiimin skaalaamiseen opitut mallit ja oppitunnit

Useimmat organisaatiot ymmärtävät järjestelmiä ja miksi ne ovat tärkeitä. Kuinka paljon se maksaa? Mitä joukkuetta tarvitsemme?

Järjestelmäjoukkue palvelee tuotejoukkoja (tai vastaavia)

Peter Merholzin ja Kristen Skinnerin erinomaisessa kirjassa Org Design for Design Orgs kuvataan malleja ja roolia suunnittelutiimien ja orgien säveltämisessä. Roolit ja joukkueen kokoonpano -luvussa ne kuvaavat apututkimusryhmää, joka palvelee monissa muissa ryhmissä:

"UX-tutkijoilla on nyt kriittinen massa olla omaa ryhmäänsä ... [yhdessä] tutkimuspäällikön kanssa ..., joka tukee tutkijoiden ammatillista kasvua ja ylläpitää globaalia ymmärrystä tutkimusnäkemyksistä kaikilla yrityksen tuotteilla ja palveluilla."

Lukeessani tätä, ajattelin itselleni “Yup, kuten suunnittelujärjestelmien tiimit” ratkaisemaan laajalle levinneet, yksinkertaisemmat suunnitteluongelmat - visuaalinen kieli, käytettävät käyttöliittymäkomponentit jne.

Tätä mallia silmällä pitäen olin yllättynyt kuullessani Peterin pohtimaan (Spotifyn) järjestelmätiimiä viime marraskuussa UI21: ssä, joka joutui ”hakkeroimaan korjaustiedoston, organisatorisen korjaustiedoston hänen kuvaamilleen malleille”. Ehkä olen väärinkäsitys. Mutta olen ollut vuosien varrella ~ 15–20 järjestelmäryhmässä, jotka palvelevat monia ryhmiä samalla tavoin (mutta ei samoja) kuin sellaiset tutkimuskäytännöt.

Kokemukseni mukaan optimaalinen järjestelmätiimi on monitieteinen ja itsenäinen palvelemaan monia ryhmiä, jotka tekevät digitaalisia asioita. Järjestelmätiimi käyttäytyy tuotteena, jota tuotteet (ja muut ryhmät) kuluttavat.

Kuka on siinä joukkueessa? Ovatko he kokopäiväisiä tai osa-aikaisia? Mitä tieteenaloja tulisi edustaa? Mistä joukkueista me hankkimme heitä?

Nämä kysymykset mielessä tämä artikkeli kuvaa järjestelmätiimin yleisiä kasvuvaiheita, jakaa esimerkkejä joukkueista, joita olen johtanut viimeisen neljän vuoden aikana, ja kattaa kuviot ja mahdolliset sudenkuopat, joita voi kohdata muodostettaessa ja käyttäessäsi järjestelmäryhmää.

Systems-tiimin kasvun vaiheet

Suurin osa henkilöistä, joiden kanssa puhun asiakkaissa, konferensseissa ja yhteisömme Design System Slack -järjestelmässä, kehittyvät yhdellä neljästä kasvuvaiheesta: varaajastimet, varatut henkilöt, omistautunut tiimi ja tiimitiimi.

Vaihe # 1: Varaajastimet

Järjestelmään sopivat henkilöt työskentelevät aikarajoilla usein kuvailevat, kuinka heidän intohimoinen purske ei ole oikeasti alkanut:

"Olen omillani. Olen luonut {Sketch-tarra-arkin tai mini-Bootstrap-koodisarjan} lisäaikaan, mutta kukaan muu ei käytä sitä. Kuinka otan seuraavan askeleen? ”

Perjantai-iltapäivisin tai sunnuntai-iltaisin rakennetut järjestelmät eivät kestä. Aloitusluonnoksen malli tai aloituskoodi on parempi kuin ei mitään. Spartalaiset pyrkimykset eivät kuitenkaan ole yrityksen käytäntö päätöksenteossa.

Takeaway: Älä turhota! Monet järjestelmämatkat alkavat siitä. Todista, että työkalusi johtavat tuloksiin - johdonmukaisuus, tehokkuus, uudelleenkäyttö - pilottihankkeissa. Se on askel kouluttamaan kuinka järjestelmä pyrkii hyödyttämään muita.

Vaihe 2: Varatut henkilöt

Kun järjestelmäarvo tunnistetaan, johtaja siirtää yksilölle ennustettavissa olevan, mutta rajoitetun allokaation (10%? 25%) tuoteryhmän sitoutumisesta ja julkistaa järjestelmävastuun joukkueille ja ikäisille. Kun sinulla on valtuudet ja aika, voit alkaa julkaista konkreettisia tuotoksia säännöllisesti, olivatpa ne sitten standardisoitua suunnitteluomaisuutta vai koodattua sarjaa.

Tässä vaiheessa samanhenkiset järjestelmien kannattajat voivat alkaa koordinoida suunnittelua ja suunnittelua. Joku voi aloittaa myöhästymisen, mutta se voi mätä epämääräisesti määriteltyjen lippujen ollessa kuukausien ajan lepäämässä. Puoli leivotut asiakirjat kupliavat kiillottamattomille verkkosivuille tai (oi ei!) Yhteenkuuluvuuteen. Päivityksiä tapahtuu, mutta harvat tietävät milloin, miten tai miksi.

Jotta järjestelmä menestyisi, sen on julkaistava korkealaatuiset tuotokset ja palveltava käyttäjiä luotettavasti.

"Jos olet siinä hyvä, luot organisaatiosi kysyntää, joka ei pysty vastaamaan nykyisiin allokointeihin." - Jared Spool, UX: n tipping pointin ulkopuolella

Jatkuvan säännöllisen tuotoksen myötä asiakkaasi (tuoteryhmät) ottavat osia vastaan, yksilöt alkavat luopua hallinnasta järjestelmän ratkaisemiin ongelmiin, ja johto lämmittää ajatusta perustaa oma ryhmä.

Vaihe 3: Järjestelmätiimi - tuotteesta

Perustaessasi muodollista järjestelmätiimiä, pyrkiessään yhdistelmään tunnustetun auktoriteetin kanssa sekä suunnittelu- että tekniikan aloilta.

Korkean tason järjestelmätiimin kokoonpano koon mukaan

Äskettäin muodostani ja johtamasi joukkueet koostuvat sekoituksesta:

  • TÄYTYY TÄTÄ: Suunnittelijan jäsenet voivat ulottua ala-aloille - visuaalinen, vuorovaikutteinen, tietoarkkitehtuuri muutamia mainitakseni -, mutta joukkueen on erinomaisesti valmistettava tyylikäs visuaalinen kieli.
  • TÄYTYY TÄTÄ: Suunnittelu tuo etusijalle HTML- ja CSS-tietämyksen, maustetut taidot perustaa sopimukset ja työkalujen rakentaminen.
  • PITÄTÄ: Tuotteenhallinta- ja johtamistaidot visioiden luomiseksi, ajo-suunnan luomiseksi, kuratointisuunnitelmien laatimiseksi, seurannan seuraamiseksi ja backlogien, pykälien ja kriitikoiden järjestämiseksi.
  • VOI OLLA: Erikoisuuksia, kuten sisältöstrategia, saavutettavuus, suorituskyky, SEO ja muut. Vaikka järjestelmät ovat arvokkaita, pidä mielessä, että järjestelmät naisevat ennen kaikkea suunnittelun ja suunnittelun.
  • TÄYTÄNTÖÖNTÖINTI: QA ja tutkimus. Laadunvarmistusrahoitus ei useinkaan ole riittävä, ja järjestelmäryhmät voivat kuitenkin perustaa käytäntöjä laadun arvioimiseksi. Tutkimus voi olla olemassa sisaruspalveluna tuoteryhmille.

Vaihe 4: Joukkueiden järjestelmäjoukkue

Jotkut massiiviset yritykset (kuten luulen, että Google, IBM, GE, Cisco tai Microsoft) kasvattavat järjestelmien pyrkimyksiä kattaa useiden toisiinsa liittyvien joukkueiden sateenvarjo järjestelmän tavoitteiden saavuttamiseksi.

Joukkuejoukkueet

Useimmille meistä, jotka tarjoavat paljon vähemmän tuotteita kuin he tekevät, tämä mittakaava on täysin epärealistinen ja tarpeeton. Toki, on hyödyllistä nähdä kullekin harjoitukselle annetut mittasuhteet. Tämä mittakaava voi kuitenkin pelotella, jos se olisi Systems Team-as-Product -tiimin sponsoreita. Kohdista joukkueesi koko realistisiin tavoitteisiin ja tärkeimpiin tuloksiin, joita haluat saada.

Esimerkkejä järjestelmätiimistä

Vaikka olen osallistunut suunnittelujärjestelmäryhmiin jatkuvasti vuodesta 2006 lähtien, käytäntö hieroi huomattavasti vuoden 2012 aikana, kun reagointi tapahtui, HTML & CSS vahvistui ja yksisarviset alkoivat (osittain) suunnitella systemaattisesti koodilla.

Seuraavat esimerkit kuvaavat järjestelmäryhmämalleja, joihin olen ollut mukana siitä lähtien.

Esimerkki 1: e-kauppa reagoi nopeasti

Mikä toimi hyvin: Tämä omistautunut joukkue suunnitteli ja dokumentoi runsaita standardeja räätälöityyn verkkoon perustuvaan kokemukseen. Se oli ”iso kahuna” -järjestelmä: tyyli, vuorovaikutus, komponentit, kuviot, brändi, toimituksellinen, SEO, saavutettavuus, teokset! Koska yrityksen "vastaamiseen" kului ~ 2 vuotta, järjestelmä oli kriittinen erilaisen asiakasmatkan lähentämisessä.

Mitä olen tehnyt eri tavalla vuodesta: Huokaus, tekniikka. Järjestelmätiimimme rakensi vankan komponenttikirjasto prototyyppisesti reagoivien mallien rakentamiseksi ja vakiosivuston rakentamiseksi. Suunnittelujohtajat vastustivat kuitenkin koodiamme eivätkä koskaan rakentaneet kirjastoa heidän yhteisölleen. Lopputulos? Päällekkäiset ponnistelut, tehottomuudet ja epäjohdonmukaisuudet lukuun ottamatta laitteita, jotka liittävät koodimme rakenteisiinsa.

Olen luvannut koskaan jatkaa kooditonta järjestelmää uudestaan ​​ympäristöissä, jotka sitä tietysti tarvitsevat, mutta suunnittelujohdot estävät harjoittamisen.

Esimerkki 2: Suunnittelukieli räjähtävälle organisaatiolle

Mikä sujui hyvin: Järjestelmätiimi johti organisaation ilmapalloiltaan noin 30 - yli 200 suunnittelijalle 12–18 kuukaudessa, jaetun suunnittelukielen kehittämiseen, joka on dokumentoitu räätälöityjen standardien verkkosivustolla (siis käyttöliittymän kehittäjä). Suunnitteluorganisaation massiivisen, hajautetun mittakaavan vuoksi palkkasimme liittovaltion suunnittelijoita vuorovaikutuksen, UX: n ja kuvakkeiden perusteisiin.

Vaikka laajuus oli pienempi - vain visuaalinen tyyli, painikkeet ja muodot kuuden työkuukauden aikana -, sitä pidettiin menestyksenä ottaen huomioon mittakaava ja edessä olevat haasteet.

Mitä olen tehnyt eri tavalla vuodesta: Lisää sisäistä henkilökuntaa tekemässä ja yhdistämässä. Vaikka tuotimme tehokkaasti tuotoksia, niin suuren yhteisön paimentamista rasittivat maantiede, tekniikka ja silti epävakaa toimintatapa. Org tarvitsi lisää talon sisäistä henkilöstöä ja vakautta siihen.

Ja taas: koodi. Meidän olisi pitänyt julkaista paketti ja pyytää anteeksi myöhemmin.

Esimerkki 3: Suora verkkosivustokirjasto

Mikä hyvin toiminut: Suunniteltu, rakennettu ja dokumentoitu erillisen toimiston selkeästi määritellyllä visuaalisella kielellä monipuolisia, sisältörikkaita verkko-ominaisuuksia varten. Tiimimme lähetti onnistuneesti ensimmäisen julkaisun kolmen kuukauden aikana, ja sitä seurasi ylläpito ja kasvu rajoitetun ajan.

Mitä olen tehnyt eri tavalla vuodesta: Huolimatta avoimista varoituksista kapasiteetin säilyttämiseksi hengissä, kirjasto meni lepotilaan henkilöstön hajottua. Perintö- ja käyttöönotosuunnitelmamme eivät olleet riittävän vahvoja kestämään toimistoni lähtöä. Projekteista lähtien olen varmasti suunnitellut määrärahat ja peräkkäin sisäisten johtajien kanssa koko järjestelmän muodostavan ajan.

Esimerkki 4: Digitaalinen ekosysteemi

Mikä sujui hyvin: Parin sisäisen suunnittelijan kanssa suunnitellakseen ja dokumentoidaksesi tyyliä ja komponentteja lippulaivatuotteiden uudelleensuunnitteluun, jonka olimme tehneet vuosineljänneksen ennen. Vielä parempi, tekniikka sijoitti kolme puoliaikaista kehittäjää lippulaivatuotteista, jotka kudottivat järjestelmän tuotoksia asteittain meneillään olevaan tuotetyöhön.

Julkaisimme kirjasto v1.0: n kolmen kuukauden kuluessa ja seurasimme neljännesvuosijaksoilla työkalujen parantamiseksi ja kirjaston luettelon laajentamiseksi. Suunnittelussa, suunnittelussa ja tuotteissa, jotka kutsuttiin koolle vuoden 2017 suunnitteluun, VP Engineering tervehti järjestelmää:

”Tärkein asia, jonka teimme viime vuonna, oli tämän järjestelmän rakentaminen. Se on kaiken tulevan työmme perusta. "

Esimerkki 5: Kirjasto kilpailijoiden kanssa

Mikä on toiminut tähän mennessä: Kun aloimme optimoida ja laajentaa olemassa olevaa ydinkirjastoa, lisäkirjastoja syntyi muille toimialoille. Joukkueet olivat hämmentyneitä: mitä hyväksyä? Kilpailun sijasta koordinoimme ponnisteluja ja integroimme suurempaan, yhdeksi joukkueeksi.

Ryhmän muodostamiseen ja refaktorikoodiin liittyi lyhytaikainen vetäminen palvelemaan joustavasti kaikkia. Myös ruumista ja suunnittelua jatkettiin. Etäisyys eteenpäin tuottaa kuitenkin yhdessä lähitulevaisuudessa, ja toimitusjohtaja ja toinen varapuheenjohtaja näyttävät olevan vakuuttuneita:

“Olin tietoinen ja olin myöntänyt, että meillä olisi kaksi kirjastoa, mutta sitten syntyi kolmas. Olen iloinen siitä, että olemme löytäneet tavan tehdä vain yksi. "

Toinen komponentti käytännön skaalaamisessa oli liittoutuneen suunnittelijayhteisön sitoutuminen omiin huolenaiheisiin: UX, kuvakkeet, tuotemerkki, kaaviot, sisältö ja saavutettavuus. Vaikka yhdelläkään näistä ”segmentin omistajista” ei ole omistettu kapasiteettiaan, kaikki ovat nyt yhteyspisteitä keskustelemaan keskusteluihin, ajamaan prioriteetteja ja ottamaan vertaisryhmiä mukaan toimittamaan tuloksia.

Oppitunnit Järjestelmäjoukkojen johtaminen

# 1. Koodattu suunnittelu on totuus. Sekoitus ja suunnittelu.

Olen osallistunut tarpeeksi tiimeihin jo vuodesta 2006 lähtien suunnittelumahdollisuuksien mallipohjaisten kirjastojen suunnittelussa ja dokumentoinnissa. Olen vakuuttunut siitä, että suunnittelujärjestelmän arvo kasvaa kymmenkertaiseksi, kun silta muodostuu vahvan suunnittelun ja suunnittelukäytäntöjen välillä.

Kyllä, on olemassa maailmanlaajuisia olosuhteita (esimerkki: Google Material), joissa suunnitteluspesifikaatti jopa ilman koodia on välttämätöntä. Käytännössäni visuaalisen kielen, komponenttien ja muiden kehysten yhdistäminen rakennettuun koodiin takaa kuitenkin järjestelmän luvatun tehokkuuden, selkeyden ja ylläpidettävyyden.

Poistuminen: Asiakasta riippumatta, tärkein alustava tiedustelu on siitä, kuka kustakin alueesta voi työskennellä yhdessä tämän yhteisen tavoitteen saavuttamiseksi.

# 2. Puoliaikakapasiteetti on vahvuus, ei heikkous

Huomaatko kaavan jokaisessa yllä olevassa joukkueessa? Kaikki henkilöstön jäsenet ovat sitoutuneet puoliaikaisesti, muuten pysyneet sitoutuneina tuotteeseen. Keskisuurilla joukkueilla sellaiset sitoumukset luovat suhteita 3–5 tärkeimpään tuoteryhmään. Tämä antaa näkyvyyden siihen, mitä tärkeät tuotteet tarvitsevat, ja minimoi vääristymät yksittäisiin tuotteisiin.

Suunnittelijat ja insinöörit, jotka kokoontuvat järjestelmäryhmiksi, jotka on kuitenkin kohdennettu erilaisiin tuotteisiin

Tähän liittyy riskejä:

  • Tuote johtaa myöntämällä puoliaikaisen järjestelmän kapasiteetin, mutta silti osoittaen ja odottaen tuotteelleen vähintään 32 tuntia viikossa viikossa.
  • Tiimin jäsenet ylittävät useita ristiriitaisia ​​rituaaleja (punnitus, suunnittelu, kritiikki), jotka vääristävät kokousten määrää verrattuna asioiden tekemiseen.

Takeaway: Voit mennä puoliaikaajassa, odota vain kohdistusta. Hallita ylös ja yli. Erottaa sitoumukset, jotka taipuvat niihin, jotka rikkovat. Se tulee monimutkaiseksi, mutta ei tarpeeksi vahingoittaakseen yritystä vakavasti.

# 3. Tasapainota jatkuvuutta rotaation kanssa

Järjestelmäryhmille, joissa on yli 2 työntekijää mistä tahansa tieteenalasta, tunnistamme joskus pysyviä jäseniä, jotka on tarkoitettu vuodeksi tai pidempään. Nämä jäsenet voivat laajentua täysipäiväisesti ja pysyä paitsi päätöksissä ja valmistelukokouksissa, myös heimurituaaleissa. Jatkuvuus on tärkeää. Toisaalta, vuorottelemme muita järjestelmän henkilöstöä, kun käyttöönotto tapahtuu useiden tuotteiden välillä.

Esimerkiksi ensimmäisen julkaisun jälkeen etsimme, mitkä tuotteet ovat omaksujien ”seuraava aalto”. Näissä tuotteissa etsimme käytettävissä olevia ja lahjakkaita suunnittelijoita ja insinöörejä, jotka ovat käytettävissä kolmen tai kuuden kuukauden puoliaikakierroksella järjestelmätiimin kanssa. Jokainen voittaa: järjestelmää oppitaan syvällisesti ja ennustettavasti sovellettavaksi, ja tuote voi laajentaa ja kehittää ytimen sen hyödyksi.

# 4. Ennakoi määräajoin tapahtuvaa supistumista mahdollisuutena

On tavallista, että jotkut järjestelmän henkilökunnat vaihtavat takaisin kokopäiväiseen tuotetyöhön merkittävän järjestelmän julkaisun jälkeen. Se on okei.

Suorita siirtyminen tehtäviin järjestelmän huolenaiheiden integroinnin ympärillä, seuraa, kuinka entinen järjestelmäryhmän jäsen toteuttaa järjestelmäpotentiaalin tilassaan, ja käytä näitä tuoteparannuksia rakentaakseen järjestelmän etujen ja joustavuuden kerronnan.

# 5. Uudet jäsenet järjestelmän laadun lakmustestinä

Uuden ryhmän jäsenen integrointi on loistava (ja helppo) testitapaus järjestelmäsi suunnittelun selkeydestä, koodin laadusta ja järjestelmälupausten noudattamisesta.

Viime vuonna neljäs insinööri saapui ja paljasti heti järjestelmän surkeat prosessidokumentaatiot joillakin alueilla, samoin kuin riittämätön keskittyminen tiettyihin saavutettavuustesteihin. Seuraavan kuukauden aikana me kaikki ryöstämme parantaaksemme näitä ominaisuuksia. Hyödyntäen tämän hetken, uusi jäsenmme hyppäsi ratkaisemaan joitain näistä haasteista ja loi vaikutusvaltaisen aseman jo joukkueessa olevien "pitkien ajastimien" rinnalla.

# 6. Järjestelmähenkilöstön tulisi kattaa vaalipiirit

Palveleeko järjestelmä salkkua yhdelle, mutta ei kaikille toimialoille? Silloin se on raja, mistä hankit henkilökunnan. Onko järjestelmä markkinointi- ja tuoteorganisaatioita kattava? Työskentele sitten ahkerasti luodaksesi (vähintään) säännöllisen, tarkoituksenmukaisen yhteistyön kahden välillä tai (ihannetapauksessa) yhdistämällä molempien organisaatioiden henkilöstö käytännöksi.

Ilman asianmukaista edustusta on vaikeaa saada täällä ihmisten tekemää järjestelmää, jonka ryhmät hyväksyvät sinne ja kaikkialle.

27. huhtikuuta 2017: Artikkelin kaaviot päivitettiin sukupuolen erityisyyden poistamiseksi vastauksena lukijan kommenttiin.