Tim Lister - coautor de llibres

• "Factor humà. Projectes i equips d'èxit" (el llibre original es diu "Peopleware")
• "Vals amb els óssos: gestió del risc en projectes de programari"
• "Boig d'adrenalina i zombificat pels patrons. Patrons de comportament dels equips de projecte"

Tots aquests llibres són clàssics en el seu camp i han estat escrits conjuntament amb els seus companys Gremi de Sistemes Atlàntics. A Rússia, els seus col·legues són els més famosos: Tom DeMarco и Pere Hruschka, que també va escriure moltes obres famoses.

Tim té 40 anys d'experiència en desenvolupament de programari l'any 1975 (cap dels que van escriure aquest habrapost va néixer aquest any), Tim ja era el vicepresident executiu de Yourdon Inc. Ara passa el seu temps consultant, ensenyant i escrivint, amb visites ocasionals a amb informes conferències arreu del món.

Hem fet una entrevista amb Tim Lister especialment per a Habr. Obrirà la conferència DevOops 2019 i tenim moltes preguntes, sobre llibres i molt més. L'entrevista està realitzada per Mikhail Druzhinin i Oleg Chirukhin del comitè del programa de la conferència.

Miquel: Pots dir algunes paraules sobre el que estàs fent ara?

Tim: Sóc el cap de l'Atlantic Systems Guild. Som sis al Gremi, ens diem directors. Tres als EUA i tres a Europa, per això el Gremi es diu Atlàntic. Fa tants anys que estem junts que no els pots comptar. Tots tenim les nostres especialitats. He estat treballant amb clients durant l'última dècada o més. Els meus projectes inclouen no només la gestió, sinó també l'establiment de requisits, la planificació de projectes i l'avaluació. Sembla que els projectes que comencen malament solen acabar malament. Per tant, val la pena assegurar-se que totes les activitats estiguin realment ben pensades i coordinades, que les idees dels creadors es combinen. Val la pena pensar què estàs fent i per què. Quines estratègies utilitzar per portar a terme el projecte.

He estat assessorant clients de diferents maneres durant molts anys. Un exemple interessant és una empresa que fabrica robots per a cirurgia de genoll i maluc. El cirurgià no opera de manera totalment independent, sinó que utilitza un robot. La seguretat aquí, parlant francament, és important. Però quan intentes discutir els requisits amb gent centrada a resoldre problemes... Sonarà estrany, però als EUA hi ha FDA (Federal Drug Administration), que llicència de productes com aquests robots. Abans de vendre qualsevol cosa i utilitzar-la en persones vives, cal obtenir una llicència. Una de les condicions és mostrar els vostres requisits, quines són les proves, com les heu provat, quins són els resultats de les proves. Si canvieu els requisits, haureu de passar per tot aquest enorme procés de proves una i altra vegada. Els nostres clients van aconseguir incloure el disseny visual d'aplicacions en els seus requisits. Tenien captures de pantalla directament com a part dels requisits. Els hem de treure i explicar que, en la seva majoria, tots aquests programes no saben res de genolls i malucs, totes aquestes coses amb la càmera, etc. Hem de reescriure els documents de requisits perquè mai canviïn, tret que canviïn algunes condicions subjacents realment importants. Si el disseny visual no està en els requisits, l'actualització del producte serà molt més ràpida. La nostra feina és trobar aquells elements que tracten les operacions de genoll, malucs, esquena, extreure'ls en documents separats i dir que aquests seran els requisits fonamentals. Fem un grup aïllat de requisits sobre les operacions de genoll. Això ens permetrà construir un conjunt de requisits més estable. Parlarem de tota la línia de productes, i no de robots específics.

Es va treballar molt, però encara van arribar a llocs on abans passaven setmanes i mesos de proves repetides sense sentit ni necessitat, perquè els requisits descrits en paper no coincidien amb els requisits reals per als quals es van construir els sistemes. La FDA els va dir cada vegada: els vostres requisits han canviat, ara heu de comprovar-ho tot des de zero. Les comprovacions completes de tot el producte estaven matant l'empresa.

Per tant, hi ha tasques tan meravelloses quan et trobes al principi d'alguna cosa interessant i les primeres accions estableixen les regles posteriors del joc. Si t'assegures que aquesta activitat inicial comença a funcionar bé tant des del punt de vista directiu com tècnic, hi ha la possibilitat que acabis amb un gran projecte. Però si aquesta part s'ha despistat i ha anat malament, si no trobes els acords fonamentals... no, no és que el teu projecte fracassés necessàriament. Però ja no podreu dir: "Ho hem fet molt bé, ho hem fet tot de manera realment eficaç". Aquestes són les coses que faig quan em comunico amb els clients.

Miquel: És a dir, engegueu projectes, feu una mena de llançament i comproveu que els rails van en la direcció correcta?

Tim: També tenim idees sobre com unir totes les peces del trencaclosques: quines habilitats necessitem, quan es necessiten exactament, com és el nucli de l'equip i altres coses tan fonamentals. Necessitem empleats a temps complet o podem contractar algú a temps parcial? Planificació, gestió. Preguntes com: Què és el més important per a aquest projecte en particular? Com aconseguir-ho? Què sabem d'aquest producte o projecte, quins són els riscos i on es troben les incògnites, com afrontarem tot això? Per descomptat, en aquest moment algú comença a cridar "I agile?!" D'acord, sou tots flexibles, però què? Com és exactament el projecte, com el traureu d'una manera que s'adapti al projecte? No pots dir simplement que "el nostre enfocament s'estén a qualsevol cosa, som un equip Scrum!" Això és una tonteria i una tonteria. On aniràs a continuació, per què hauria de funcionar, on és el punt? Ensenyo als meus clients a pensar en totes aquestes preguntes.

19 anys d'àgil

Miquel: A Agile, la gent sovint intenta no definir res per endavant, sinó prendre decisions el més tard possible, dient: som massa grans, no pensaré en l'arquitectura general. No pensaré en un munt d'altres coses, li lliuraré una cosa que funcioni al client ara mateix.

Tim: Crec que les metodologies àgils, començant per Manifest àgil el 2001, va obrir els ulls a la indústria. Però, d'altra banda, res és perfecte. Estic a favor del desenvolupament iteratiu. La iteració té molt sentit en la majoria de projectes. Però la pregunta que cal pensar és: un cop el producte està fora i en ús, quant de temps dura? Es tracta d'un producte que durarà sis mesos abans de ser substituït per un altre? O és un producte que funcionarà durant molts, molts anys? Per descomptat, no posaré noms, però... A Nova York i la seva comunitat financera, els sistemes més fonamentals són molt antics. Això és increïble. Els mires i penses, si només poguessis retrocedir en el temps, al 1994, i dius als desenvolupadors: “Vaig venir del futur, del 2019. Només heu de desenvolupar aquest sistema durant el temps que necessiteu. Fes-lo ampliable, pensa en l'arquitectura. Després es millorarà durant més de vint-i-cinc anys. Si retardes una mica més el desenvolupament, en el gran esquema de les coses ningú ho notarà!" Quan estigueu estimant coses a llarg termini, heu de tenir en compte quant costarà en total. De vegades val la pena una arquitectura ben dissenyada, i de vegades no. Hem de mirar al nostre voltant i preguntar-nos: estem en la situació adequada per a aquesta decisió?

Així que una idea com "Estem per a l'àgil, el mateix client ens dirà què vol aconseguir": és súper ingènua. Els clients ni tan sols saben què volen, i més encara no saben què poden aconseguir. Alguns començaran a citar exemples històrics com a arguments, això ja ho he vist. Però la gent tècnicament avançada no sol dir això. Diuen: "Som el 2019, aquestes són les oportunitats que tenim i podem canviar completament la nostra manera de veure aquestes coses!" En lloc d'imitar les solucions existents, fer-les una mica més maques i pentinats, de vegades cal sortir i dir: "Reinventem completament el que estem intentant fer aquí!"

I no crec que la majoria dels clients puguin pensar en el problema d'aquesta manera. Només veuen el que ja tenen, això és tot. Després d'això, vénen amb peticions com "Fem-ho una mica més senzill", o el que sol dir. Però no som cambrers ni cambreres, així que podem agafar una comanda per més estúpid que resulti i després coure-la a la cuina. Som els seus guies. Hem d'obrir-los els ulls i dir: ei, aquí tenim noves oportunitats! Us adoneu que realment podem canviar la manera com es fa aquesta part del vostre negoci? Un dels problemes amb Agile és que elimina la consciència de què és una oportunitat, què és un problema, què fins i tot hem de fer, quines tecnologies disponibles s'adapten més a aquesta situació particular.

Potser estic sent massa escèptic aquí: hi ha moltes coses meravelloses passant a la comunitat àgil. Però tinc un problema amb el fet que en comptes de definir un projecte, la gent comença a aixecar les mans. Jo preguntaria aquí: què estem fent, com ho farem? I d'alguna manera màgicament sempre resulta que el client hauria de saber-ho millor que ningú. Però el client només sap millor quan escull entre les coses ja construïdes per algú. Si vull comprar un cotxe i sé la mida del meu pressupost familiar, seleccionaré ràpidament un cotxe que s'adapti al meu estil de vida. Aquí ho sé tot millor que ningú! Però tingueu en compte que algú ja ha fet els cotxes. No tinc ni idea de com inventar un cotxe nou, no sóc un expert. Quan creem productes personalitzats o especials, s'ha de tenir en compte la veu del client, però aquesta ja no és l'única veu.

Oleg: Heu esmentat el Manifest Agile. Hem d'actualitzar-lo o revisar-lo d'alguna manera tenint en compte la comprensió moderna del problema?

Tim: Jo no el tocaria. Crec que és un gran document històric. Vull dir, ell és el que és. Fa 19 anys, és vell, però en el seu temps va fer una revolució. El que va fer bé va ser que va provocar una reacció i la gent va començar a xiuxiuejar sobre ell. El 2001, el més probable és que encara no treballeu a la indústria, però després tothom va treballar segons els processos. Institut d'Enginyeria de Programari, cinc nivells del model de completesa de programari (CMMI). No sé si aquestes llegendes de l'antiguitat profunda us diuen alguna cosa, però aleshores va ser un gran avenç. Al principi, la gent creia que si els processos es configuraven correctament, els problemes desapareixerien per si mateixos. I després apareix el Manifest i diu: "No, no, no, ens basarem en persones, no en processos". Som mestres en desenvolupament de programari. Entenem que el procés ideal és un miratge; no passa. Hi ha massa idiosincràsia en els projectes, la idea d'un sol procés perfecte per a tots els projectes no té cap sentit. Els problemes són massa complexos per afirmar que només hi ha una solució a tot (hola, nirvana).

No m'imagino mirar cap al futur, però diré que ara la gent ha començat a pensar més en projectes. Crec que el Manifest Agile és molt bo per saltar i dir: "Ei! Estàs en un vaixell i tu mateix condueix aquest vaixell. Haureu de prendre una decisió: no suggerirem una recepta universal per a totes les situacions. Sou la tripulació del vaixell, i si sou prou bo, podeu trobar una manera d'arribar a l'objectiu. Hi havia altres vaixells abans que tu, i hi haurà altres vaixells després de tu, però tot i així, en cert sentit, el teu viatge és únic". Alguna cosa així! És una manera de pensar. Per a mi, no hi ha res de nou sota el sol, la gent ha navegat abans i tornarà a navegar, però per a tu aquest és el teu viatge principal, i no et diré què et passarà exactament. Has de tenir les habilitats de treball coordinat en equip, i si realment les tens, tot sortirà i arribaràs on vols.

Peopleware: 30 anys després

Oleg: El Peopleware va ser una revolució igual que el Manifest?

Tim: Peopleware... Tom i jo vam escriure aquest llibre, però no pensàvem que passaria així. D'alguna manera va ressonar amb les idees de molta gent. Aquest va ser el primer llibre que deia: el desenvolupament de programari és una activitat molt intensiva en humans. Malgrat la nostra naturalesa tècnica, també som una comunitat de persones que construeixen quelcom gran, fins i tot enorme, molt complex. Ningú pot crear aquestes coses sol, oi? Així que la idea de "equip" va esdevenir molt important. I no només des del punt de vista de la gestió, sinó també de tècnics que es van reunir per resoldre problemes profunds realment complexos amb un munt d'incògnites. Per a mi personalment, aquesta ha estat una gran prova d'intel·ligència al llarg de la meva carrera. I aquí cal que puguis dir: sí, aquest problema és més del que puc gestionar pel meu compte, però junts podem trobar una solució elegant de la qual ens sentim orgullosos. I crec que va ser aquesta idea la que va ressonar més. La idea que treballem part del temps pel nostre compte, part del temps com a part d'un grup, i sovint la decisió la pren el grup. La resolució de problemes en grup s'ha convertit ràpidament en una característica important de projectes complexos.

Tot i que Tim ha donat un gran nombre de xerrades, molt poques d'elles es publiquen a YouTube. Podeu consultar l'informe "The Return of Peopleware" del 2007. La qualitat, és clar, deixa molt a desitjar.

Miquel: Ha canviat alguna cosa en els últims 30 anys des que es va publicar el llibre?

Tim: Podeu mirar-ho des de molts angles diferents. Sociològicament parlant... una vegada, en temps més senzills, tu i el teu equip estàveu asseguts a la mateixa oficina. Podríeu estar a prop cada dia, prendre un cafè junts i parlar de feina. El que realment ha canviat és que ara els equips es poden distribuir geogràficament, en diferents països i zones horàries, però encara estan treballant en el mateix problema, i això afegeix una nova capa de complexitat. Això pot semblar a la vella escola, però no hi ha res com la comunicació cara a cara on esteu tots junts, treballant junts i podeu apropar-vos a un company i dir-li: mira què he descobert, com t'agrada això? Les converses cara a cara ofereixen una manera ràpida de passar a la comunicació informal, i crec que als entusiastes àgils també els hi hauria d'agradar. I també em preocupa perquè en realitat el món ha quedat molt petit, i ara està tot cobert d'equips distribuïts, i tot és molt complex.

Tots vivim a DevOps

Miquel: Fins i tot des del punt de vista del comitè del programa de conferències, tenim gent a Califòrnia, a Nova York, Europa, Rússia... encara no hi ha ningú a Singapur. La diferència de geografia és força gran i la gent comença a estendre's encara més. Si estem parlant de desenvolupament, ens pots dir més sobre devops i trencar barreres entre equips? Hi ha el concepte que tothom està assegut als seus búnquers, i ara els búnquers s'esfondren, què en penseu d'aquesta analogia?

Tim: Em sembla que a la llum dels avenços tecnològics recents, el devops té una gran importància. Anteriorment, teníeu equips de desenvolupadors i administradors, treballaven, treballaven, treballaven i en algun moment va aparèixer una cosa amb la qual podríeu venir als administradors i llançar-lo per a la producció. I aquí va començar la conversa sobre el búnquer, perquè els administradors són una mena d'aliats, no enemics, almenys, però només parlaves amb ells quan tot estava a punt per sortir a la producció. Els vau anar amb alguna cosa i els vau dir: mira quina aplicació tenim, però podries desplegar aquesta aplicació? I ara tot el concepte de lliurament ha canviat a millor. Vull dir, hi havia aquesta idea que podríeu impulsar els canvis ràpidament. Podem actualitzar els productes sobre la marxa. Sempre somric quan apareix Firefox al meu ordinador portàtil i em diu: eh, hem actualitzat el vostre Firefox en segon pla, i tan aviat com tingueu un minut, us importaria fer clic aquí i us donarem la darrera versió. I vaig dir: "Oh, sí, nena!" Mentre dormia, estaven treballant per lliurar-me una versió nova directament al meu ordinador. Això és meravellós, increïble.

Però aquí hi ha la dificultat: teniu aquesta funció amb l'actualització del programari, però integrar persones és molt més difícil. El que vull expressar a la presentació de DevOops és que ara tenim molts més jugadors que mai. Si només penseu en tots els implicats en un sol equip... Ho pensaves com un equip, i és molt més que un equip de programadors. Es tracta de provadors, gestors de projectes i un munt d'altres persones. I cadascú té les seves pròpies opinions sobre el món. Els gestors de producte són completament diferents dels gestors de projectes. Els administradors tenen les seves pròpies tasques. Esdevé un problema bastant difícil coordinar tots els participants per seguir sent conscients del que està passant i no tornar-se bojos. Cal separar les tasques del grup i les que s'apliquen a tothom. Aquesta és una tasca molt difícil. D'altra banda, crec que tot està molt millor que fa molts anys. Aquest és exactament el camí pel qual les persones creixen i aprenen a comportar-se correctament. Quan fas la integració, entens que no hi hauria d'haver cap desenvolupament subterrani, de manera que a l'últim moment el programari no s'arrossega com un jack-in-the-box: mira què hem fet aquí! La idea és que pugueu fer integració i desenvolupament, i al final es desplegarà d'una manera ordenada i iterativa. Tot això significa molt per a mi. Això fa possible crear més valor per als usuaris del sistema i per al vostre client.

Miquel: La idea de devops és oferir desenvolupaments significatius tan aviat com sigui possible. Veig que el món ha començat a accelerar cada cop més. Com adaptar-se a aquestes acceleracions? Fa deu anys això no existia!

Tim: Per descomptat, tothom vol més i més funcionalitat. No cal moure's, només acumula'n més. De vegades, fins i tot heu d'alentir la velocitat per a la propera actualització incremental per aportar alguna cosa útil, i això és completament normal.

La idea que cal córrer, córrer, córrer no és la millor. És poc probable que algú vulgui viure la seva vida així. M'agradaria que el ritme d'entregues marqui el ritme propi del projecte. Si només produeixes un flux de coses petites i relativament sense sentit, tot no té sentit. En lloc d'intentar llançar coses tan aviat com sigui possible, el que val la pena discutir amb els principals desenvolupadors i gestors de productes i projectes és l'estratègia. Fins i tot això té sentit?

Patrons i antipatrons

Oleg: Normalment parles de patrons i antipatrons, i aquesta és la diferència entre la vida i la mort dels projectes. I ara, devops irromp a les nostres vides. Té algun dels seus propis patrons i anti-patrons que puguin matar el projecte al moment?

Tim: Els patrons i els anti-patrons succeeixen tot el temps. Alguna cosa de què parlar. Bé, hi ha això que anomenem "coses brillants". A la gent li agraden molt les noves tecnologies. Simplement queden hipnotitzats per la brillantor de tot allò que sembla fresc i elegant, i deixen de fer preguntes: és fins i tot necessari? Què aconseguirem? Aquesta cosa és fiable, té algun sentit? Sovint veig gent, per dir-ho així, a l'avantguarda de la tecnologia. Estan hipnotitzats pel que està passant al món. Però si mireu més de prop quines coses útils fan, sovint no hi ha res útil!

Acabàvem de discutir amb els nostres companys que aquest any és un any d'aniversari, cinquanta anys des que la gent va aterrar a la Lluna. Això va ser l'any 1969. La tecnologia que va ajudar a la gent a arribar-hi no és ni tan sols la tecnologia de 1969, sinó de 1960 o 62, perquè la NASA volia utilitzar només allò que tenia bones proves de fiabilitat. I així ho mireu i enteneu, sí, i eren certs! Ara, no, no, però et poses problemes amb la tecnologia simplement perquè tot està empès massa, es ven des de totes les esquerdes. La gent crida des de tot arreu: "Mira, quina cosa, això és el més nou, el més bonic del món, apte per a tots!" Bé, això és tot... normalment tot això resulta ser només un esquer, i després s'ha de llençar tot. Potser tot és perquè ja sóc un vell i miro aquestes coses amb molt d'escepticisme, quan la gent s'acaba i diu que ha trobat l'única manera més correcta de crear les millors tecnologies. En aquest moment, una veu es desperta dins meu que em diu: "Quin embolic!"

Miquel: De fet, quantes vegades hem sentit parlar de la propera bala de plata?

Tim: Exacte, i aquest és el curs habitual de les coses! Per exemple... sembla que això ja s'ha convertit en una broma arreu del món, però aquí es parla sovint de tecnologia blockchain. I realment tenen sentit en determinades situacions! Quan realment necessiteu proves fiables dels esdeveniments, que el sistema funciona i que ningú ens ha enganyat, quan teniu problemes de seguretat i totes aquestes coses barrejades, la cadena de blocs té sentit. Però quan diuen que Blockchain ara arrasarà per tot el món, escombrant tot al seu pas? Somia més! Aquesta és una tecnologia molt cara i complexa. Tècnicament complex i requereix temps. Incloent purament algorítmicament, cada vegada que cal recalcular les matemàtiques, amb els més mínims canvis... i aquesta és una gran idea, però només per a determinats casos. Tota la meva vida i carrera han estat sobre això: idees interessants en situacions molt concretes. És molt important entendre exactament quina és la vostra situació.

Miquel: Sí, la principal "qüestió de la vida, l'univers i tot": aquesta tecnologia o enfocament és adequat o no a la teva situació?

Tim: Aquesta qüestió ja es pot discutir amb el grup de tecnologia. Potser fins i tot porteu algun consultor. Fes una ullada al projecte i entén: farem ara alguna cosa correcta i útil, millor que abans? Potser encaixarà, potser no. Però el més important, no prenguis aquesta decisió per defecte, simplement perquè algú va dir: "Necessitem desesperadament una cadena de blocs! Acabo de llegir sobre ell en una revista a l'avió!" De debò? Ni tan sols fa gràcia.

El mític "enginyer devops"

Oleg: Ara tothom està implementant devops. Algú llegeix sobre devops a Internet i demà apareix una altra vacant en un lloc de reclutament. "enginyer devops". Aquí m'agradaria cridar la vostra atenció: creus que aquest terme "enginyer devops" té dret a la vida? Hi ha una opinió que el devops és una cultura, i alguna cosa no s'afegeix aquí.

Tim: Més o menys. Deixeu-los llavors donar immediatament una mica d'explicació d'aquest terme. Alguna cosa per fer-lo únic. Fins que no demostrin que hi ha una combinació única d'habilitats darrere d'una vacant com aquesta, no la compraré! Vull dir, bé, tenim un títol de treball, "enginyer devops", un títol interessant, sí, què després? Els títols de feina són generalment una cosa molt interessant. Diguem-hi "desenvolupador": què és de totes maneres? Organitzacions diferents signifiquen coses completament diferents. En algunes empreses, els programadors d'alta qualitat escriuen proves que tenen més sentit que les proves escrites per provadors professionals especials d'altres empreses. Què, ara són programadors o provadors?

Sí, tenim càrrecs, però si fas preguntes el temps suficient, al final resulta que tots som solucionadors de problemes. Som buscadors de solucions, i alguns tenen algunes habilitats tècniques i d'altres de diferents. Si vius en un entorn on DevOps ha penetrat, estàs compromès en la integració del desenvolupament i l'administració, i aquesta activitat té un propòsit força important. Però si et demanen què fas exactament i de què ets responsable, resulta que la gent ha estat fent totes aquestes coses des de temps immemorials. "Sóc el responsable de l'arquitectura", "Sóc el responsable de les bases de dades" i així successivament, el que sigui, veieu, tot això era abans de "devops".

Quan algú em diu el seu càrrec, realment no escolto gaire. És millor que et digui de què és realment responsable, això ens permetrà entendre molt millor el tema. El meu exemple preferit és quan una persona afirma ser un "director de projectes". Què? No vol dir res, encara no sé què fas. Un director de projecte pot ser un desenvolupador, el líder d'un equip de quatre persones, escrivint codi, fent feina, que s'ha convertit en un líder d'equip, a qui les mateixes persones reconeixen entre elles com a líder. I també, un director de projecte pot ser un gestor que gestiona sis-centes persones en un projecte, gestiona altres responsables, s'encarrega d'elaborar horaris i planificar pressupostos, això és tot. Són dos mons completament diferents! Però el seu títol de feina sona igual.

Donem la volta a això una mica diferent. En què ets bo, tens molta experiència, tens talent? De què assumiràs la responsabilitat perquè creus que pots gestionar la tasca? I aquí algú començarà a negar immediatament: no, no, no, no tinc cap ganes de tractar amb els recursos del projecte, no és el meu negoci, sóc un noi tècnic i entenc la usabilitat i les interfícies d'usuari, no ho entenc. Vull gestionar exèrcits de persones, millor que vagi a treballar.

I, per cert, sóc un gran defensor d'un enfocament en què aquest tipus de separació d'habilitats funcioni bé. On els tècnics poden fer créixer la seva carrera tant com vulguin. Tanmateix, encara veig organitzacions on els tècnics es queixen: hauré d'anar a la gestió de projectes perquè aquesta és l'única manera d'aquesta empresa. De vegades, això porta a resultats terribles. Els millors tècnics no són gens bons gestors, i els millors gestors no poden manejar la tecnologia. Siguem sincers sobre això.

Ara veig molta demanda per això. Si ets un tècnic, la teva empresa et pot ajudar, però, independentment, necessites, realment necessites trobar la teva pròpia carrera professional perquè la tecnologia no para de canviar i has de reinventar-te amb ella! En només vint anys, les tecnologies poden canviar almenys cinc vegades. La tecnologia és una cosa estranya...

"Experts en tot"

Miquel: Com pot la gent fer front a aquesta velocitat de canvi tecnològic? La seva complexitat creix, el seu nombre creix, la quantitat total de comunicació entre persones també creix i resulta que no es pot convertir en un "expert en tot".

Tim: Dret! Si treballes en tecnologia, sí, definitivament has de triar alguna cosa concreta i aprofundir-hi. Alguna tecnologia que la vostra organització troba útil (i potser serà útil). I si ja no us interessa - mai m'hauria cregut que ho diria - bé, potser hauríeu de traslladar-vos a alguna altra organització on la tecnologia sigui més interessant o més convenient per estudiar.

Però en general, sí, tens raó. Les tecnologies creixen en totes direccions alhora, ningú pot dir "sóc un tecnòleg expert en totes les tecnologies que existeixen". D'altra banda, hi ha gent d'esponja que literalment absorbeix el coneixement tecnològic i n'està boig. He vist un parell d'aquestes persones, literalment respiren i viuen, és útil i interessant parlar amb ells. No només estudien què passa dins de l'organització, sinó que en general en parlen, també són tecnòlegs genials, són molt conscients i decidits. Només intenten mantenir-se a la cresta de l'onada, independentment de quina sigui la seva feina principal, perquè la seva passió és el moviment de la Tecnologia, la promoció de la tecnologia. Si de sobte et trobes amb una persona així, hauries d'anar a dinar amb ell i discutir diverses coses interessants durant el dinar. Crec que qualsevol organització necessita almenys un parell d'aquestes persones.

Riscos i incertesa

Miquel: Enginyers honrats, sí. Toquem la gestió del risc mentre tenim temps. Vam començar aquesta entrevista amb una discussió sobre programari mèdic, on els errors poden tenir conseqüències nefastes. Després vam parlar del Programa Lunar, on el cost d'un error és de milions de dòlars, i possiblement diverses vides humanes. Però ara veig el moviment contrari a la indústria, la gent no pensa en els riscos, no intenta predir-los, ni tan sols els observa.

Oleg: Mou-te ràpid i trenca coses!

Miquel: Sí, mou-te ràpid, trenca coses, més i més coses, fins que mors per alguna cosa. Des del vostre punt de vista, com hauria d'enfocar el desenvolupador mitjà ara la gestió del risc d'aprenentatge?

Tim: Tracem aquí una línia entre dues coses: els riscos i la incertesa. Aquestes són coses diferents. La incertesa es produeix quan no tens prou dades en un moment donat per arribar a una resposta definitiva. Per exemple, en l'etapa molt inicial d'un projecte, si algú et pregunta "quan acabaràs el treball", si ets una persona bastant honesta, diràs: "No en tinc ni idea". Simplement no ho saps, i està bé. Encara no has estudiat els problemes i no estàs familiaritzat amb l'equip, no coneixes les seves habilitats, etc. Això és incertesa.

Els riscos sorgeixen quan ja es poden identificar problemes potencials. Aquest tipus de coses poden passar, la seva probabilitat és superior a zero, però inferior al cent per cent, en algun punt intermedi. Per això, pot passar qualsevol cosa, des de retards i treballs innecessaris, fins i tot fins a un resultat fatal per al projecte. El resultat, quan dius, nois, pleguem els para-sols i marxem de la platja, no l'acabarem mai, ja s'ha acabat, punt. Vam suposar que això funcionaria, però no funciona gens, és hora d'aturar-se. Aquestes són les situacions.

Sovint, els problemes són més fàcils de resoldre quan ja han sorgit, quan el problema està passant ara mateix. Però quan tens un problema davant teu, no estàs fent una gestió de riscos, sinó que estàs fent la resolució de problemes, la gestió de crisi. Si sou un desenvolupador o gestor principal, us haureu de preguntar què podria passar que podria provocar retards, pèrdua de temps, costos innecessaris o el col·lapse de tot el projecte? Què ens farà parar i començar de nou? Quan totes aquestes coses funcionin, què en farem? Hi ha una resposta senzilla que és vàlida per a la majoria de situacions: no fugis dels riscos, treballa-hi. Vegeu com podeu resoldre una situació de risc, reduir-la a no res, convertir-la d'un problema en una altra cosa. En lloc de dir: bé, anirem resolent els problemes a mesura que surtin.

La incertesa i el risc haurien d'estar al capdavant de tot el que tracteu. Podeu fer un pla del projecte, mirar certs riscos crítics amb antelació i dir: hem de tractar-ho ara, perquè si alguna cosa d'això surt malament, res més importarà. No us hauríeu de preocupar per la bellesa de les estovalles a la taula si no està clar si podeu cuinar el sopar. Primer cal identificar tots els riscos de preparar un sopar deliciós, tractar-los i només després pensar en totes les altres coses que no representen una amenaça real.

De nou, què fa que el vostre projecte sigui únic? Vegem què pot fer que el nostre projecte surti dels rails. Què podem fer per minimitzar la probabilitat que això passi? Normalment no es pot neutralitzar al 100% i declarar amb la consciència tranquil·la: "Això és, això ja no és un problema, el risc s'ha resolt!" Per a mi, això és un signe de comportament adult. Aquesta és la diferència entre un nen i un adult: els nens pensen que són immortals, que res pot sortir malament, tot anirà bé! Al mateix temps, els adults observen com els nens de tres anys salten al pati, segueixen els moviments amb els ulls i es diuen a si mateixos: "ooh-ooh, ooh-ooh". Em quedo a prop i em preparo per agafar quan el nen cau.

D'altra banda, el motiu pel qual m'agrada tant aquest negoci és perquè és arriscat. Fem coses, i aquestes coses són arriscades. Requereixen un enfocament adult. L'entusiasme per si sol no solucionarà els teus problemes!

Pensament d'enginyeria per a adults

Miquel: L'exemple amb els nens és bo. Si sóc un enginyer normal, llavors estic encantat de ser un nen. Però, com avança cap a un pensament més adult?

Tim: Una de les idees que funciona igual de bé amb un desenvolupador principiant o establert és el concepte de context. Què estem fent, què aconseguirem. Què és realment important en aquest projecte? No importa qui siguis en aquest projecte, tant si ets intern com si ets arquitecte en cap, tothom necessita context. Hem d'aconseguir que tothom pensi a una escala més gran que les seves pròpies obres. "Faig la meva peça, i mentre la meva peça funcioni, estic feliç". No i no de nou. Sempre val la pena (sense ser groller!) recordar a la gent el context en què treballen. Allò que tots intentem aconseguir junts. Idees que pots ser un nen sempre que tot estigui bé amb la teva part del projecte; si us plau, no ho facis. Si creuem la meta, només la creuarem junts. No estàs sol, estem tots junts. Si tota la gent del projecte, tant grans com joves, comencés a parlar sobre què és exactament important per al projecte, per què l'empresa està invertint diners en allò que tots estem intentant aconseguir... la majoria d'ells es sentiran molt millor perquè veurà com el seu treball es correlaciona amb el treball de tots els altres. D'una banda, entenc la peça de la qual sóc personalment responsable. Però per acabar la feina també necessitem tota la resta de persones. I si realment creus que ja has acabat, sempre tenim feina per fer en el projecte!

Oleg: Relativament parlant, si treballes segons Kanban, quan et trobes amb el coll d'ampolla d'algunes proves, pots deixar el que estàveu fent allà (per exemple, programació) i anar a ajudar els provadors.

Tim: Exactament. Crec que els millors tècnics, si els mireu de prop, són els seus propis directius. Com puc formular això...

Oleg: La teva vida és el teu projecte, que tu gestiones.

Tim: Exactament! Vull dir, t'assumes la responsabilitat, entens el tema i entres en contacte amb la gent quan veus que les teves decisions poden afectar la seva feina, coses així. No es tracta només de seure al teu escriptori, fer la teva feina i ni tan sols adonar-te del que passa al teu voltant. No no No. Per cert, una de les millors coses d'Agile és que van proposar sprints curts, perquè així l'estat de coses de tots els participants és clarament observable, ho poden veure tot junts. Parlem els uns dels altres cada dia.

Com entrar en la gestió del risc

Oleg: Hi ha alguna estructura de coneixement formal en aquesta àrea? Per exemple, sóc un desenvolupador de Java i vull entendre la gestió del risc sense convertir-me en un veritable gestor de projectes per part de l'educació. Probablement llegiré primer "Quant costa un projecte de programari" de McConnell, i després què? Quins són els primers passos?

Tim: El primer és començar a comunicar-se amb la gent del projecte. Això proporciona una millora immediata en la cultura de comunicació amb els companys. Hem de començar obrint-ho tot per defecte, en lloc d'amagar-ho. Digues: aquestes són les coses que em molesten, aquestes són les coses que em mantenen despert a la nit, avui m'he despertat a la nit i vaig dir: Déu meu, he de pensar-hi! Els altres veuen el mateix? Com a grup, hem de respondre a aquests problemes potencials? Heu de poder donar suport a una discussió sobre aquests temes. No hi ha una fórmula preparada prèviament per la qual treballem. No es tracta de fer hamburgueses, sinó de persones. "Fer una hamburguesa amb formatge, vendre una hamburguesa amb formatge" no és gens el nostre, i per això m'agrada tant aquesta feina. M'agrada quan tot el que feien els directius ara passa a ser propietat de l'equip.

Oleg: Has parlat en llibres i entrevistes sobre com la gent es preocupa més per la felicitat que pels números d'un gràfic. D'altra banda, quan dius a l'equip: estem passant a devops, i ara el programador s'ha de comunicar constantment, això pot estar molt fora de la seva zona de confort. I en aquest moment pot ser, diguem-ne, profundament infeliç. Què fer en aquesta situació?

Tim: No estic segur de què fer exactament. Si un desenvolupador està massa aïllat, no veu per què s'està fent el treball en primer lloc, només mira la seva part del treball i han d'entrar en el que jo anomeno "context". Ha d'esbrinar com està tot connectat. I, per descomptat, no em refereixo a presentacions formals ni res semblant. Parlo del fet que has de comunicar-te amb els companys sobre el conjunt de la feina, i no només sobre la part de la qual ets responsable. Aquí és on podeu començar a discutir idees, acords comuns per fer que el vostre treball encaixi bé i com abordar un problema comú junts.

Per ajudar-los a adaptar-se, sovint volen enviar tècnics a la formació i discuteixen la formació. A un amic meu li agrada dir que l'entrenament és per a gossos. Hi ha formació per a la gent. Una de les millors coses de l'aprenentatge com a desenvolupador és interactuar amb els teus companys. Si algú és realment bo en alguna cosa, hauríeu de veure'l treballar o parlar-li sobre la seva feina o alguna cosa així. Alguns Kent Beck convencionals parlaven constantment de programació extrema. És divertit perquè XP és una idea tan senzilla, però causa molts problemes. Per a alguns, fer XP és com veure's obligat a despullar-se davant dels amics. Ja veuran què faig! Són els meus companys, no només veuran, sinó que també ho entendran! Terrible! Algunes persones comencen a posar-se molt nervioses. Però quan t'adones que aquesta és la millor manera d'aprendre, tot canvia. Treballes estretament amb la gent, i algunes persones entenen el tema molt millor que tu.

Miquel: Però tot això t'obliga a sortir de la teva zona de confort. Com a enginyer, has de sortir de la teva zona de confort i comunicar-te. Com a solucionador de problemes, has de posar-te constantment en una posició feble i pensar en què podria sortir malament. Aquest tipus de treball està dissenyat intrínsecament per ser una molèstia. Et poses conscientment en situacions estressants. Normalment la gent fuig d'ells, a la gent els agrada ser nens feliços.

Tim: El que es pot fer, pots sortir i dir obertament: "Tot està bé, m'ho puc gestionar! No sóc l'únic que se sent incòmode. Parlem de diverses coses incòmodes, tots junts, com a equip!" Aquests són els nostres problemes comuns, hem de tractar-los, saps? Crec que els desenvolupadors genis idiosincràtics són com mamuts, van desaparèixer. I la seva importància és molt limitada. Si no pots comunicar-te, no pots participar bé. Per tant, només parleu. Sigues honest i obert. Em sap molt greu que això sigui desagradable per a algú. Us imagineu que fa molts anys hi va haver un estudi segons el qual la principal por als Estats Units no és la mort, però endevineu què? Por a parlar en públic! Això vol dir que en algun lloc hi ha gent que prefereix morir que dir un compliment en veu alta. I crec que n'hi ha prou amb tenir unes habilitats bàsiques, segons el que facis. Habilitats d'expressió oral, habilitats d'escriptura, però només tant com es necessita realment en el teu treball. Si treballes com a analista, però no saps llegir, escriure o parlar, llavors, malauradament, no tindreu res a fer en els meus projectes!

El preu de la comunicació

Oleg: No és més car contractar treballadors tan extrovertits per diferents motius? Després de tot, estan xerrant constantment en lloc de treballar!

Tim: Em referia al nucli de l'equip, i no només a tothom. Si teniu algú a qui li agrada ajustar les bases de dades, li agrada ajustar les bases de dades i seguirà ajustant les vostres bases de dades durant la resta de la seva vida i ja està, genial, segueix així. Però parlo de persones que volen viure en el propi projecte. El nucli de l'equip, orientat al desenvolupament del projecte. Aquestes persones realment necessiten comunicar-se constantment entre elles. I sobretot a l'inici del projecte, quan parles de riscos, maneres d'assolir objectius globals i similars.

Miquel: Això s'aplica a totes les persones implicades en el projecte, independentment de l'especialització, habilitats o maneres de treballar. Tots esteu interessats en l'èxit del projecte.

Tim: Sí, sents que estàs prou immers en el projecte, que la teva tasca és ajudar a que el projecte es faci realitat. Tant si sou programador, analista, dissenyador d'interfícies, qualsevol persona. Aquesta és la raó per la qual vinc a treballar cada matí i això és el que fem. Som responsables de totes aquestes persones, independentment de les seves habilitats. Aquest és un grup de persones que tenen converses entre adults.

Oleg: De fet, parlant d'empleats parlants, vaig intentar simular les objeccions de la gent, especialment dels directius, a qui se'ls demana que canviïn als devops, a aquesta nova visió del món. I vosaltres, com a consultors, hauríeu de ser conscients d'aquestes objeccions molt millor que jo, com a desenvolupador! Compartiu què és el que més preocupa als directius?

Tim: Gestors? Hm. Molt sovint, els directius estan sota pressió per problemes, davant la necessitat d'alliberar alguna cosa amb urgència i fer un lliurament, i similars. Miren com discutim i discutim constantment sobre alguna cosa, i ho veuen així: converses, converses, converses... Quines altres converses? Tornar a la feina! Perquè parlar no els sembla feina. No escrius codi, no proves programari, no sembla que facis res, per què no t'envies a fer alguna cosa? Al cap i a la fi, el lliurament ja és en un mes!

Miquel: Aneu a escriure un codi!

Tim: Em sembla que no els preocupa la feina, sinó la falta de visibilitat del progrés. Perquè sembli que estem més a prop de l'èxit, han de veure'ns prement botons del teclat. Tot el dia des del matí fins al vespre. Aquest és el problema número u.

Oleg: Misha, estàs pensant en alguna cosa.

Miquel: Ho sento, em vaig perdre en els pensaments i vaig agafar un flashback. Tot això em va recordar un ral·li interessant que va tenir lloc ahir... Ahir hi va haver massa concentracions... I tot em sona molt familiar!

Vida sense sous

Tim: Per cert, no és gens necessari organitzar "concentracions" per a la comunicació. Vull dir, les discussions més útils entre desenvolupadors es produeixen quan només parlen entre ells. Entres al matí amb una tassa de cafè i hi ha cinc persones reunides i discutint furiós alguna cosa tècnica. Per a mi, si sóc el gerent d'aquest projecte, és millor només somriure i anar a algun lloc sobre el meu negoci, que ho parlin. Ja estan implicats tant com poden. Això és un bon senyal.

Oleg: Per cert, al teu llibre tens un munt de notes sobre què és bo i què és dolent. En fas servir algun d'ells tu mateix? Relativament parlant, ara tens una empresa i una que està estructurada d'una manera molt poc ortodoxa...

Tim: Poc ortodox, però aquest aparell ens va perfectament. Ens coneixem des de fa molt de temps. Confiem els uns en els altres, ens vam confiar molt abans de fer-nos socis. I per exemple, no tenim cap salari. Només treballem i, per exemple, si guanyava diners dels meus clients, tots els diners anaven a mi. Després d'això, paguem quotes de soci a l'organització, i això és suficient per donar suport a la pròpia empresa. A més, tots estem especialitzats en coses diferents. Per exemple, treballo amb comptadors, omple declaracions d'impostos, faig tota mena de coses administratives per a l'empresa i ningú em paga per això. James i Tom treballen al nostre lloc web i ningú els paga tampoc. Mentre paguis les teves quotes, a ningú se li ocorrerà dir-te què has de fer. Per exemple, Tom ara treballa molt menys que abans. Ara té altres interessos que fa algunes coses que no són per al Gremi. Però mentre pagui les seves quotes, ningú s'acostarà a ell i li dirà: "Ei, Tom, vés a treballar!" És molt fàcil tractar amb els companys quan no hi ha diners entre vosaltres. I ara la nostra relació és una de les idees fonamentals en relació a diferents especialitats. Funciona i funciona molt bé.

El millor consell

Miquel: Tornant al "millor consell", hi ha alguna cosa que digueu als vostres clients una i altra vegada? Hi ha una idea sobre el 80/20, i alguns consells probablement es repeteixen més sovint.

Tim: Una vegada vaig pensar que si escrivies un llibre com Waltzing with Bears, canviaria el curs de la història i la gent s'aturaria, però... Bé, mira, les empreses sovint pretenen que tot els va bé. Tan bon punt passa alguna cosa dolenta, és un xoc i una sorpresa per a ells. "Mira, vam provar el sistema i no passa cap prova del sistema, i això són tres mesos més de treball no programat, com podria passar això? Qui sabia? Què podria sortir malament? De debò, t'ho creus?

Intento explicar-vos que no us hauríeu d'enfadar massa per la situació actual. Hem de parlar-ne, entendre realment què podria haver anat malament i com evitar que aquestes coses succeeixin en el futur. Si apareix un problema, com el combatrem, com el contenirem?

A mi, tot això em fa por. La gent s'enfronta a problemes complexos i molestos i segueix pretenent que si només creuen els dits i esperen el millor, realment passarà el "millor". No, no funciona així.

Practica la gestió del risc!

Miquel: Segons la teva opinió, quantes organitzacions participen en la gestió del risc?

Tim: El que m'enfada és que la gent simplement escriu els riscos, mira la llista resultant i se'n va a treballar. De fet, identificar riscos per a ells és una gestió de riscos. Però això em sembla una raó per preguntar: d'acord, hi ha una llista, què canviaràs exactament? Heu de canviar les vostres seqüències estàndard d'accions tenint en compte aquests riscos. Si hi ha alguna part més difícil de la feina, heu d'abordar-la i només després passar a una cosa més senzilla. En els primers sprints, comença a resoldre problemes complexos. Això ja sembla una gestió de riscos. Però normalment la gent no pot dir què han canviat després d'elaborar una llista de riscos.

Miquel: I, tanmateix, quantes d'aquestes empreses estan implicades en la gestió del risc, un cinc per cent?

Tim: Malauradament, odio dir això, però aquesta és una part molt insignificant. Però més de cinc, perquè hi ha projectes realment grans, i simplement no poden existir si no fan almenys alguna cosa. Diguem que em sorprèn molt si és com a mínim un 25%. Els projectes petits solen respondre aquestes preguntes d'aquesta manera: si el problema ens afecta, llavors el resoldrem. Llavors es fiquen amb èxit en problemes i es dediquen a la gestió de problemes i a la gestió de crisi. Quan intenteu resoldre un problema i el problema no es resol, benvingut a la gestió de crisi.

Sí, sovint escolto: "Anem a resoldre els problemes a mesura que surtin". Segur que ho farem? De veritat decidirem?

Oleg: Podeu fer-ho de manera ingenua i simplement escriure invariants importants a la carta del projecte i, si els invariants es trenquen, només cal que reinicieu el projecte. Resulta molt delicada.

Miquel: Sí, em va passar que quan es van desencadenar riscos, el projecte simplement es va redefinir. Bonic, bingo, problema resolt, no et preocupis més!

Tim: Premem el botó de reinici! No, no funciona així.

Conferència a DevOops 2019

Miquel: Arribem a l'última pregunta d'aquesta entrevista. Arribeu al proper DevOops amb una ponència, podríeu aixecar el teló del secret sobre el que explicareu?

Tim: Ara mateix, sis d'ells estan escrivint un llibre sobre la cultura laboral, les regles tàcites de les organitzacions. La cultura està determinada pels valors fonamentals de l'organització. Normalment la gent no se n'adona, però havent treballat molts anys en consultoria, estem acostumats a notar-ho. Entres en una empresa i, literalment, en pocs minuts comences a sentir el que està passant. A això l'anomenem "sabor". De vegades, aquesta olor és molt bona, i de vegades ho és, bé, vaja. Les coses són molt diferents per a diferents organitzacions.

Miquel: Jo també porto anys treballant en consultoria i entenc bé de què parles.

Tim: De fet, una de les coses que val la pena parlar a la presentació és que no tot està determinat per l'empresa. Tu i el teu equip, com a comunitat, tens la teva pròpia cultura d'equip. Això podria ser tota l'empresa, o un departament separat, un equip separat. Però abans de dir, això és el que creiem, això és el que és important... No es pot canviar una cultura abans que s'entenguin els valors i creences que hi ha darrere d'accions concretes. El comportament és fàcil d'observar, però la recerca de creences és difícil. DevOps és només un gran exemple de com les coses són cada cop més complexes. Les interaccions només són cada cop més complexes, no es tornen més netes ni més clares, així que hauríeu de pensar en què creus i sobre què calla tothom al teu voltant.

Si voleu aconseguir resultats ràpids, aquí teniu un bon tema per a vosaltres: heu vist empreses on ningú diu "no ho sé"? Hi ha llocs on tortures literalment una persona fins que admet que no sap res. Tothom ho sap tot, tothom és un erudit increïble. T'acostes a qualsevol persona i ha de respondre a la pregunta a l'instant. En lloc de dir "no ho sé". Hura, van contractar una colla d'erudits! I en algunes cultures generalment és molt perillós dir “no ho sé” es pot percebre com un signe de debilitat. També hi ha organitzacions en què, per contra, tothom pot dir “no ho sé”. Allà és totalment legal, i si algú comença a fer brossa responent a una pregunta, és del tot normal respondre: "No saps de què parles, oi?" i convertir-ho tot en broma.

Idealment, t'agradaria tenir una feina on poguessis ser feliç constantment. No serà fàcil, no tots els dies són assolellats i agradables, de vegades cal treballar molt, però quan comencis a fer balanç, sortirà: va, aquest és un lloc realment meravellós, em sento bé treballant aquí, tant emocionalment com intel·lectualment. I hi ha empreses on vas com a consultor i a l'instant t'adones que no ho pots aguantar durant tres mesos i que fugiries horroritzat. Això és del que vull parlar a l'informe.

Tim Lister arribarà amb una conferència "Caràcters, comunitat i cultura: factors importants per a la prosperitat"a la conferència DevOops 2019, que tindrà lloc del 29 al 30 d'octubre de 2019 a Sant Petersburg. Podeu comprar entrades al lloc web oficial. T'esperem a DevOops!

Font: www.habr.com