Tim Lister - coautor de libros
- "Factor humano. Proxectos e equipos exitosos" (o libro orixinal chámase "Peopleware")
- "Vals cos osos: xestión do risco en proxectos de software"
- "Tolo de adrenalina e zombificado por patróns. Patróns de comportamento dos equipos do proxecto"
Todos estes libros son clásicos no seu campo e foron escritos xunto con colegas . En Rusia, os seus colegas son máis famosos - и , que tamén escribiu moitas obras famosas.
Tim ten 40 anos de experiencia no desenvolvemento de software; en 1975 (ningún dos que escribiron este habrapost naceu este ano), Tim xa era o vicepresidente executivo de Yourdon Inc. Agora pasa o seu tempo consultando, ensinando e escribindo, con visitas ocasionais a conferencias en todo o mundo.
Fixemos unha entrevista a Tim Lister especialmente para Habr. Abrirá a conferencia DevOops 2019 e temos moitas preguntas sobre libros e moito máis. A entrevista está realizada por Mikhail Druzhinin e Oleg Chirukhin do comité do programa da conferencia.
Michael: Podes dicir algunhas palabras sobre o que estás facendo agora?
Tim: Son o xefe do Gremio de Sistemas Atlánticos. Somos seis no Gremio, chamámonos directores. Tres nos Estados Unidos e tres en Europa, por iso o Gremio chámase Atlántico. Levamos tantos anos xuntos que non podes contalos. Todos temos as nosas especialidades. Estiven traballando con clientes durante a última década ou máis. Os meus proxectos inclúen non só a xestión, senón tamén a definición de requisitos, a planificación de proxectos e a avaliación. Parece que os proxectos que comezan mal normalmente acaban mal. Por iso, convén asegurarse de que todas as actividades estean realmente ben pensadas e coordinadas, que se combinen as ideas dos creadores. Paga a pena pensar no que estás facendo e por que. Que estratexias utilizar para levar a cabo o proxecto.
Levo moitos anos asesorando clientes de varias maneiras. Un exemplo interesante é unha empresa que fabrica robots para cirurxía de xeonllos e cadeiras. O cirurxián non opera de forma completamente independente, senón que usa un robot. A seguridade aquí, francamente falando, é importante. Pero cando intentas discutir os requisitos con persoas que se centran en resolver problemas... Soará raro, pero en EE.UU. hai (Federal Drug Administration), que licencia produtos como estes robots. Antes de vender algo e usalo en persoas vivas, cómpre obter unha licenza. Unha das condicións é mostrar os teus requisitos, cales son as probas, como as probaches, cales son os resultados das probas. Se cambias os requisitos, terás que pasar por todo este proceso de probas unha e outra vez. Os nosos clientes conseguiron incluír o deseño visual de aplicacións nas súas necesidades. Tiñan capturas de pantalla directamente como parte dos requisitos. Temos que sacalos e explicarlles que na súa maioría todos estes programas non saben nada de xeonllos e cadeiras, de todas estas cousas coa cámara, etc. Necesitamos reescribir os documentos de requisitos para que nunca cambien, a non ser que cambien algunhas condicións subxacentes realmente importantes. Se o deseño visual non está nos requisitos, a actualización do produto será moito máis rápida. O noso traballo é atopar aqueles elementos que tratan as operacións de xeonllos, cadeiras, costas, sacalos en documentos separados e dicir que estes serán os requisitos fundamentais. Imos facer un grupo illado de requisitos sobre as operacións de xeonllos. Isto permitiranos construír un conxunto de requisitos máis estables. Falaremos de toda a liña de produtos, e non de robots específicos.
Traballouse moito, pero aínda así chegaron a lugares onde antes pasaban semanas e meses de probas repetidas sen sentido nin necesidade, porque os requisitos descritos en papel non coincidían cos requisitos reais para os que se construían os sistemas. A FDA díxolles cada vez: os teus requisitos cambiaron, agora tes que comprobar todo desde cero. As comprobacións completas de todo o produto estaban matando a empresa.
Entón, hai tarefas tan marabillosas cando te atopas ao comezo de algo interesante e as primeiras accións establecen as regras posteriores do xogo. Se te aseguras de que esta primeira actividade comeza a funcionar ben tanto desde o punto de vista directivo como técnico, hai posibilidades de que acabes cun gran proxecto. Pero se esta parte saíu do carrí e saíu mal, se non atopas os acordos fundamentais... non, non é que o teu proxecto fracasará necesariamente. Pero xa non poderás dicir: "Fixemos moi ben, fixemos todo de xeito realmente eficaz". Estas son as cousas que fago cando me comunico cos clientes.
Michael: É dicir, lanzas proxectos, fas algún tipo de arranque e comprobas que os carrís van na dirección correcta?
Tim: Tamén temos ideas sobre como unir todas as pezas do quebracabezas: que habilidades necesitamos, cando se precisan exactamente, como é o núcleo do equipo e outras cousas tan fundamentais. Necesitamos empregados a tempo completo ou podemos contratar a alguén a tempo parcial? Planificación, xestión. Preguntas como: Que é o máis importante para este proxecto en particular? Como conseguir isto? Que sabemos deste produto ou proxecto, cales son os riscos e onde están as incógnitas, como imos afrontar todo isto? Por suposto, neste momento alguén comeza a gritar "E áxil?!" Está ben, todos son flexibles, pero que? Como é exactamente o proxecto, como o vas sacar de forma que se adapte ao proxecto? Non podes dicir simplemente que "o noso enfoque se estende a calquera cousa, somos un equipo Scrum!" Isto é unha tontería e unha tontería. Onde vas ir a continuación, por que debería funcionar, onde está o punto? Ensino aos meus clientes a pensar en todas estas preguntas.
19 anos áxil
Michael: En Agile, a xente adoita tentar non definir nada de antemán, senón tomar decisións o máis tarde posible, dicindo: somos demasiado grandes, non vou pensar na arquitectura xeral. Non pensarei noutras cousas; en cambio, entregarei algo que funcione ao cliente agora mesmo.
Tim: Creo que as metodoloxías áxiles, comezando en 2001, abriu os ollos da industria. Pero, por outra banda, nada é perfecto. Estou a favor do desenvolvemento iterativo. A iteración ten moito sentido na maioría dos proxectos. Pero a pregunta na que debes pensar é: unha vez que o produto está fóra e en uso, canto tempo dura? Trátase dun produto que durará seis meses antes de ser substituído por outro? Ou é este un produto que funcionará durante moitos, moitos anos? Por suposto, non vou poñer nomes, pero... En Nova York e na súa comunidade financeira, os sistemas máis fundamentais son moi antigos. Isto é incrible. Miras para eles e pensas, se só puideses retroceder no tempo, ata 1994, e dilles aos desenvolvedores: “Vinei do futuro, de 2019. Só ten que desenvolver este sistema durante o tempo que necesite. Faino expandible, pensa na arquitectura. Despois mellorarase durante máis de vinte e cinco anos. Se retrasas un pouco máis o desenvolvemento, no gran esquema das cousas ninguén se dará conta! Cando estás a estimar as cousas a longo prazo, debes ter en conta canto custará en total. Ás veces, unha arquitectura ben deseñada paga a pena, e ás veces non. Hai que mirar ao noso redor e preguntarnos: estamos na situación adecuada para unha decisión así?
Entón, unha idea como "Estamos para áxil, o propio cliente diranos o que quere conseguir" - é súper inxenuo. Os clientes nin sequera saben o que queren, e máis aínda non saben o que poderían conseguir. Algunhas persoas comezarán a citar exemplos históricos como argumentos, isto xa vin. Pero a xente técnicamente avanzada non adoita dicir iso. Din: "É 2019, estas son as oportunidades que temos e podemos cambiar completamente a forma de ver estas cousas!" En lugar de imitar as solucións existentes, facéndoas un pouco máis bonitas e peiteadas, ás veces cómpre saír e dicir: "Imos reinventar completamente o que estamos tentando facer aquí!"
E non creo que a maioría dos clientes poidan pensar no problema dese xeito. Só ven o que xa teñen, iso é todo. Despois diso, veñen con peticións como "imos facer isto un pouco máis sinxelo", ou o que adoitan dicir. Pero non somos camareiros nin camareiras, así que podemos coller un pedido por moi estúpido que resulte e despois cocelo na cociña. Somos os seus guías. Temos que abrirlles os ollos e dicir: oe, aquí temos novas oportunidades! Tes conta de que realmente podemos cambiar a forma en que se fai esta parte do teu negocio? Un dos problemas de Agile é que elimina a conciencia do que é unha oportunidade, o que é un problema, o que necesitamos facer, as tecnoloxías dispoñibles que son máis adecuadas para esta situación particular.
Quizais estou sendo demasiado escéptico aquí: hai moitas cousas marabillosas que suceden na comunidade áxil. Pero teño un problema co feito de que en vez de definir un proxecto, a xente comeza a botar as mans. Eu preguntaría aquí: que estamos facendo, como o imos facer? E dalgunha forma máxica sempre resulta que o cliente debería saber mellor que ninguén. Pero o cliente só sabe mellor cando elixe entre cousas que xa construíu alguén. Se quero comprar un coche e sei o tamaño do meu orzamento familiar, seleccionarei rapidamente un coche que se adapte ao meu estilo de vida. Aquí coñezo todo mellor que ninguén! Pero teña en conta que alguén xa fixo os coches. Non teño nin idea de como inventar un coche novo, non son un experto. Cando creamos produtos personalizados ou especiais hai que ter en conta a voz do cliente, pero esta xa non é a única voz.
Oleg: Mencionaches o Manifesto Agile. Necesitamos actualizalo ou revisalo tendo en conta a comprensión moderna do problema?
Tim: Non o tocaría. Creo que é un gran documento histórico. Quero dicir, é o que é. Está cumprindo 19 anos, é vello, pero no seu tempo fixo unha revolución. O que fixo ben foi que provocou unha reacción e a xente comezou a murmurar sobre el. Vostede, moi probablemente, aínda non estaba traballando na industria en 2001, pero entón todos traballaron segundo os procesos. Software Engineering Institute, cinco niveis do modelo de integridade de software (CMMI). Non sei se tales lendas de fonda antigüidade che din algo, pero entón foi un gran avance. Ao principio, a xente cría que se os procesos se configuraban correctamente, entón os problemas desaparecerían por si sós. E entón aparece o Manifesto e di: "Non, non, non, basearémonos en persoas, non en procesos". Somos mestres no desenvolvemento de software. Entendemos que o proceso ideal é un espellismo, non ocorre. Hai demasiada idiosincrasia nos proxectos, a idea dun único proceso perfecto para todos os proxectos non ten ningún sentido. Os problemas son demasiado complexos para afirmar que só hai unha solución para todo (ola, nirvana).
Non presumo mirar cara ao futuro, pero direi que agora a xente empezou a pensar máis nos proxectos. Creo que o Manifesto Áxil é moi bo para saltar e dicir: "¡Ei! Estás nun barco, e ti mesmo estás conducindo este barco. Terá que tomar unha decisión: non suxeriremos unha receita universal para todas as situacións. Vostede é a tripulación do barco e, se é o suficientemente bo, pode atopar un camiño para chegar ao seu obxectivo. Houbo outros barcos antes de ti, e haberá outros despois de ti, pero aínda así, en certo sentido, a túa viaxe é única". Algo así! É unha forma de pensar. Para min, non hai nada novo baixo o sol, a xente xa navegaba antes e volverá navegar, pero para ti esta é a túa principal viaxe, e non che direi que che vai pasar exactamente. Debes ter as habilidades de traballo coordinado en equipo e, se realmente as tes, todo sairá e chegarás onde querías.
Peopleware: 30 anos despois
Oleg: Foi Peopleware unha revolución igual que o Manifesto?
Tim: Peopleware... Tom e eu escribimos este libro, pero non pensabamos que pasaría así. Dalgunha maneira resonou coas ideas de moita xente. Este foi o primeiro libro que dixo: o desenvolvemento de software é unha actividade moi intensiva en humanos. A pesar da nosa natureza técnica, tamén somos unha comunidade de persoas que construímos algo grande, incluso enorme, moi complexo. Ninguén pode crear tales cousas só, non? Así que a idea de "equipo" fíxose moi importante. E non só dende o punto de vista de xestión, senón tamén de técnicos que se xuntaron para resolver problemas profundos realmente complexos cunha chea de incógnitas. Para min persoalmente, esta foi unha gran proba de intelixencia ao longo da miña carreira. E aquí cómpre dicir: si, este problema é máis do que podo manexar eu só, pero xuntos podemos atopar unha solución elegante da que podemos estar orgullosos. E creo que foi esta idea a que máis resoou. A idea de que traballamos parte do tempo pola nosa conta, parte do tempo como parte dun grupo, e moitas veces a decisión tómaa o grupo. A resolución de problemas en grupo converteuse rapidamente nunha característica importante dos proxectos complexos.
A pesar de que Tim deu un gran número de charlas, moi poucas delas están publicadas en YouTube. Podes ver o informe "O retorno do Peopleware" de 2007. A calidade, por suposto, deixa moito que desexar.
Michael: Cambiou algo nos últimos 30 anos desde a publicación do libro?
Tim: Podes ver isto desde moitos ángulos diferentes. Socioloxicamente falando... noutrora, en tempos máis sinxelos, ti e o teu equipo sentábamos no mesmo despacho. Poderías estar preto todos os días, tomar café xuntos e discutir sobre o traballo. O que realmente cambiou é que agora os equipos poden distribuírse xeográficamente, en diferentes países e zonas horarias, pero aínda así están a traballar no mesmo problema, e isto engade unha nova capa de complexidade. Isto pode parecer á vella escola, pero non hai nada como a comunicación cara a cara na que estás todos xuntos, traballando xuntos, e podes achegarte a un colega e dicir: mira o que descubrín, que che parece isto? As conversas cara a cara proporcionan unha forma rápida de pasar á comunicación informal, e creo que aos entusiastas áxiles tamén lles debería gustar. E tamén me preocupa porque en realidade o mundo resultou moi pequeno, e agora está todo cuberto de equipos repartidos, e todo é moi complexo.
Todos vivimos en DevOps
Michael: Mesmo dende o punto de vista do comité do programa das xornadas temos xente en California, en Nova York, Europa, Rusia... aínda non hai ninguén en Singapur. A diferenza de xeografía é bastante grande e a xente comeza a espallarse aínda máis. Se falamos de desenvolvemento, podes dicirnos máis sobre devops e romper barreiras entre equipos? Hai un concepto de que todo o mundo está sentado nos seus búnkers, e agora os búnkers están colapsando, que pensas desta analoxía?
Tim: Paréceme que á luz dos recentes avances tecnolóxicos, o devops é de gran importancia. Antes tiñas equipos de programadores e administradores, traballaban, traballaban, traballaban e nalgún momento apareceu algo co que podías acudir aos administradores e lanzalo para a produción. E aquí comezou a conversación sobre o búnker, porque os administradores son unha especie de aliados, non inimigos, polo menos, pero só falabas con eles cando todo estaba listo para entrar en produción. Acudiches a eles con algo e dicías: mira que aplicación temos, pero poderías lanzar esta aplicación? E agora todo o concepto de entrega cambiou para mellor. Quero dicir, existía a idea de que podías facer cambios rapidamente. Podemos actualizar produtos sobre a marcha. Sempre sorrío cando aparece Firefox no meu portátil e di: "Oe, actualizamos o teu Firefox en segundo plano e, en canto teñas un minuto, importaríache facer clic aquí e dámosche a última versión. E eu dixen: "Oh, si, nena!" Mentres estaba durmindo, estaban traballando para entregarme unha nova versión directamente no meu ordenador. Isto é marabilloso, incrible.
Pero aquí está a dificultade: tes esta función coa actualización do software, pero integrar persoas é moito máis difícil. O que quero expresar na presentación de DevOops é que agora temos moitos máis xogadores dos que tivemos nunca. Se pensas en todos os que participan nun só equipo... Pensaches nel como un equipo, e é moito máis que un equipo de programadores. Estes son probadores, xestores de proxectos e unha morea de persoas. E cada un ten a súa propia visión do mundo. Os xestores de produtos son completamente diferentes dos xestores de proxectos. Os administradores teñen as súas propias tarefas. Convértese nun problema bastante difícil coordinar a todos os participantes para seguir sendo conscientes do que está a suceder e non volverse tolos. É necesario separar as tarefas do grupo e as que se aplican a todos. Esta é unha tarefa moi difícil. Por outra banda, creo que todo está moito mellor que hai moitos anos. Este é exactamente o camiño no que a xente crece e aprende a comportarse correctamente. Cando realizas a integración, entendes que non debería haber desenvolvemento subterráneo, de xeito que no último momento o software non se arrastra como un jack-in-the-box: mira o que fixemos aquí! A idea é que poderás facer integración e desenvolvemento e, ao final, desenrolarás dun xeito ordenado e iterativo. Todo isto significa moito para min. Isto fai posible crear máis valor para os usuarios do sistema e para o seu cliente.
Michael: A idea de devops é ofrecer desenvolvementos significativos o antes posible. Vexo que o mundo comezou a acelerarse cada vez máis. Como adaptarse a tales aceleracións? Hai dez anos isto non existía!
Tim: Por suposto, todos queren máis e máis funcionalidades. Non hai que moverse, só acumula máis. Ás veces, incluso tes que reducir a velocidade para a próxima actualización incremental para traer algo útil, e iso é completamente normal.
A idea de que hai que correr, correr, correr non é a mellor. É pouco probable que alguén queira vivir así. Gustaríame que o ritmo das entregas marcase o propio ritmo do proxecto. Se só produces un fluxo de cousas pequenas e relativamente sen sentido, todo non ten sentido. En lugar de intentar lanzar as cousas o antes posible, o que paga a pena discutir cos principais desenvolvedores e xestores de produtos e proxectos é a estratexia. Será que isto ten sentido?
Patróns e antipatróns
Oleg: Normalmente falas de patróns e antipatróns, e esta é a diferenza entre a vida e a morte dos proxectos. E agora, devops irrompe nas nosas vidas. Ten algún dos seus propios patróns e antipatróns que poidan matar o proxecto no acto?
Tim: Os patróns e os antipatróns ocorren todo o tempo. Algo do que falar. Ben, hai isto que chamamos "cousas brillantes". Á xente gústalle moito as novas tecnoloxías. Simplemente quedan hipnotizados polo brillo de todo o que parece fresco e elegante, e deixan de facerse preguntas: é necesario? Que imos conseguir? Isto é fiable, ten algún sentido? Moitas veces vexo xente, por así dicilo, á vangarda da tecnoloxía. Están hipnotizados polo que está a pasar no mundo. Pero se miras máis de cerca as cousas útiles que fan, moitas veces non hai nada útil!
Acababamos de comentar cos nosos compañeiros que este ano é un aniversario, cincuenta anos desde que a xente pousou a Lúa. Isto foi en 1969. A tecnoloxía que axudou á xente a chegar alí non é nin sequera a tecnoloxía de 1969, senón de 1960 ou 62, porque a NASA quería utilizar só o que tiña boas probas de fiabilidade. E así o miras e entendes - si, e eran verdades! Agora, non, non, pero tes problemas coa tecnoloxía simplemente porque todo é empuxado demasiado, vendido desde todos os cracks. A xente grita desde todas partes: "Mira, que cousa, esta é a cousa máis nova, a cousa máis bonita do mundo, apta para absolutamente todos!" Ben, iso é todo... xeralmente todo isto resulta ser só un señuelo, e despois hai que tiralo todo. Quizais todo sexa porque xa son un vello e miro esas cousas con moito escepticismo, cando a xente corre para dicir que atopou a única forma máis correcta de crear as mellores tecnoloxías. Neste momento, esperta dentro de min unha voz que di: "Que desorde!"
Michael: De feito, cantas veces escoitamos falar da próxima bala de prata?
Tim: Exactamente, e este é o curso habitual das cousas! Por exemplo... parece que isto xa se converteu nunha broma en todo o mundo, pero aquí a xente adoita falar de tecnoloxía blockchain. E realmente teñen sentido en determinadas situacións! Cando realmente necesitas probas fiables dos acontecementos, de que o sistema funciona e de que ninguén nos enganou, cando tes problemas de seguridade e todas esas cousas mesturadas, a cadea de bloques ten sentido. Pero cando din que Blockchain agora vai atravesar o mundo, arrasando todo o que está ao seu paso? Soña máis! Esta é unha tecnoloxía moi cara e complexa. Técnicamente complexo e lento. Incluíndo puramente algorítmicamente, cada vez que necesites recalcular as matemáticas, cos máis mínimos cambios... e esta é unha gran idea, pero só para certos casos. Toda a miña vida e carreira foron sobre isto: ideas interesantes en situacións moi concretas. É moi importante comprender exactamente cal é a súa situación.
Michael: Si, a principal "cuestión da vida, do universo e de todo": esta tecnoloxía ou enfoque é axeitado para a túa situación ou non?
Tim: Esta cuestión xa se pode discutir co grupo de tecnoloxía. Quizais incluso traia algún consultor. Bótalle un ollo ao proxecto e comprende: faremos agora algo correcto e útil, mellor que antes? Quizais encaixará, quizais non. Pero o máis importante é que non tomes esa decisión por defecto, simplemente porque alguén dixo: "Necesitamos desesperadamente unha cadea de bloques! Acabo de ler sobre el nunha revista do avión! En serio? Nin sequera é divertido.
O mítico "enxeñeiro devops"
Oleg: Agora todos están implementando devops. Alguén le sobre devops en Internet e mañá aparece outra praza nun sitio de contratación. "Enxeñeiro de Devops". Aquí gustaríame chamar a túa atención: cres que este termo "enxeñeiro devops" ten dereito á vida? Hai unha opinión de que o devops é unha cultura, e algo non se suma aquí.
Tim: Máis ou menos. Deixe-los entón dar inmediatamente algunha explicación deste termo. Algo para facelo único. Ata que non demostren que hai unha combinación única de habilidades detrás dunha vacante como esta, non a comprarei. Quero dicir, ben, temos un título de traballo, "enxeñeiro de devops", un título interesante, si, que segue? Os postos de traballo xeralmente son algo moi interesante. Digamos "desenvolvedor": que é de todos os xeitos? As diferentes organizacións significan cousas completamente diferentes. Nalgunhas empresas, os programadores de alta calidade escriben probas que teñen máis sentido que as probas escritas por probadores profesionais especiais noutras empresas. Entón, que agora son programadores ou probadores?
Si, temos postos de traballo, pero se fai preguntas o tempo suficiente, ao final resulta que todos somos solucionadores de problemas. Somos buscadores de solucións, e algúns teñen algunhas habilidades técnicas e outras diferentes. Se vives nun ambiente onde penetrou DevOps, estás implicado na integración do desenvolvemento e a administración, e esta actividade ten un propósito bastante importante. Pero se che preguntan que fai exactamente e de que es responsable, resulta que a xente leva facendo todas estas cousas desde tempos inmemoriais. "Eu son o responsable da arquitectura", "Eu son o responsable das bases de datos" e así por diante, o que vexa, todo isto era antes de "devops".
Cando alguén me di o seu cargo, realmente non escoito moito. É mellor que che diga do que é realmente responsable, isto permitiranos entender moito mellor o problema. O meu exemplo favorito é cando unha persoa afirma ser un "xestor de proxectos". Que? Non significa nada, aínda non sei que fas. Un xestor de proxecto pode ser un desenvolvedor, o líder dun equipo de catro persoas, escribindo código, facendo traballo, que se converteu nun xefe de equipo, ao que a propia xente recoñece entre si como líder. E ademais, un director de proxecto pode ser un xestor que xestiona seiscentas persoas nun proxecto, xestiona outros xestores, encárgase de elaborar cronogramas e planificar os orzamentos, iso é todo. Estes son dous mundos completamente diferentes! Pero o seu título de traballo soa igual.
Imos darlle a volta a isto dun xeito un pouco diferente. En que es realmente bo, tes moita experiencia, tes talento? De que asumirás a responsabilidade porque pensas que podes xestionar a tarefa? E aquí alguén comezará a negar inmediatamente: non, non, non, non teño ganas de tratar cos recursos do proxecto, non é o meu negocio, son un tipo técnico e entendo a usabilidade e as interfaces de usuario, non Quero xestionar exércitos de persoas en absoluto, déixame que vaia a traballar.
E por certo, son un gran defensor dun enfoque no que este tipo de separación de habilidades funcione ben. Onde os técnicos poden facer crecer a súa carreira ata onde queiran. Non obstante, aínda vexo organizacións nas que os técnicos se queixan: terei que dedicarme á xestión de proxectos porque é o único camiño nesta empresa. Ás veces, isto leva a resultados terribles. Os mellores técnicos non son bos xestores en absoluto, e os mellores xestores non poden manexar a tecnoloxía. Sexamos honestos sobre isto.
Agora vexo moita demanda por isto. Se es un técnico, a túa empresa pode axudarche, pero, independentemente, necesitas, realmente necesitas atopar a túa propia carreira profesional porque a tecnoloxía segue cambiando e tes que reinventarte xunto con ela. En só vinte anos, as tecnoloxías poden cambiar polo menos cinco veces. A tecnoloxía é algo estraño...
"Expertos en todo"
Michael: Como pode a xente facer fronte a esa velocidade do cambio tecnolóxico? A súa complexidade crece, o seu número crece, a cantidade total de comunicación entre as persoas tamén medra, e resulta que non podes converterte nun "experto en todo".
Tim: Certo! Se traballas en tecnoloxía, si, definitivamente tes que escoller algo específico e afondar nel. Algunha tecnoloxía que a túa organización considera útil (e que quizais sexa realmente útil). E se xa non te interesa -nunca crería que diría isto- ben, quizais deberías pasar a algunha outra organización na que a tecnoloxía sexa máis interesante ou máis cómoda para estudar.
Pero en xeral, si, tes razón. As tecnoloxías están crecendo en todas as direccións á vez; ninguén pode dicir "son un tecnólogo experto en todas as tecnoloxías que existen". Por outra banda, hai xente de esponxa que literalmente absorbe o coñecemento tecnolóxico e está tola por iso. Vin un par de persoas deste tipo, literalmente respiran e víveno, é útil e interesante falar con eles. Eles estudan non só o que está a suceder dentro da organización, senón que, en xeral, falan diso, tamén son tecnólogos moi chulos, son moi conscientes e decididos. Só tentan manterse na crista da onda, independentemente de cal sexa o seu traballo principal, porque a súa paixón é o movemento da Tecnoloxía, a promoción da tecnoloxía. Se de súpeto coñeces a unha persoa así, deberías ir xantar con el e discutir varias cousas interesantes durante o xantar. Creo que calquera organización necesita polo menos un par de persoas deste tipo.
Riscos e incerteza
Michael: Enxeñeiros honrados, si. Tocamos a xestión de riscos mentres teñamos tempo. Comezamos esta entrevista cunha discusión sobre o software médico, onde os erros poden levar a graves consecuencias. Despois falamos do Programa Lunar, onde o custo dun erro é de millóns de dólares, e posiblemente varias vidas humanas. Pero agora vexo o movemento contrario na industria, a xente non pensa nos riscos, non intenta predicilos, nin sequera os observa.
Oleg: Move rápido e rompe cousas!
Michael: Si, móvete rápido, rompe cousas, máis e máis cousas, ata que morras por algo. Desde o teu punto de vista, como debería abordar agora o desenvolvedor medio a aprendizaxe da xestión do risco?
Tim: Tracemos aquí unha liña entre dúas cousas: os riscos e a incerteza. Estas son cousas diferentes. A incerteza prodúcese cando non tes datos suficientes nun momento dado para chegar a unha resposta definitiva. Por exemplo, na fase inicial dun proxecto, se alguén che pregunta "cando rematarás o traballo", se es unha persoa bastante honesta, dirás: "Non teño nin idea". Simplemente non o sabes, e está ben. Aínda non estudaches os problemas e non estás familiarizado co equipo, non coñeces as súas habilidades, etc. Isto é incerteza.
Os riscos xorden cando xa se poden identificar problemas potenciais. Este tipo de cousas poden ocorrer, a súa probabilidade é maior que cero, pero inferior ao cen por cento, nalgún lugar intermedio. Por iso, todo pode pasar, desde atrasos e traballos innecesarios, pero ata un desenlace fatal para o proxecto. O resultado, cando dis - rapaces, pleguemos os paraugas e deixemos a praia, nunca o remataremos, xa está todo, punto. Supuxemos que esta cousa funcionaría, pero non funciona en absoluto, é hora de parar. Estas son as situacións.
Moitas veces, os problemas son máis fáciles de resolver cando xa xurdiron, cando o problema está a suceder agora mesmo. Pero cando un problema está diante de ti, non estás facendo xestión de riscos, estás facendo resolución de problemas, xestión de crises. Se es un desenvolvedor ou xestor principal, debes estar preguntando que podería ocorrer que provocaría atrasos, tempo perdido, custos innecesarios ou o colapso de todo o proxecto? Que nos fará parar e comezar de novo? Cando todas estas cousas funcionen, que faremos con elas? Hai unha resposta sinxela que vale para a maioría das situacións: non fuxir dos riscos, traballa neles. Mira como podes resolver unha situación de risco, reducila a nada, convertela dun problema en outra cousa. En vez de dicir: ben, resolveremos os problemas segundo vaian xurdindo.
A incerteza e o risco deben estar na vangarda de todo o que trates. Podes tomar un plan de proxecto, mirar certos riscos críticos con antelación e dicir: temos que tratar con isto agora, porque se algo disto sae mal, nada máis importará. Non debes preocuparte pola beleza do pano da mesa se non está claro se podes cociñar a cea. Primeiro cómpre identificar todos os riscos de preparar unha deliciosa cea, tratar con eles e só entón pensar en todas as outras cousas que non representan unha ameaza real.
De novo, que fai o teu proxecto único? Imos ver que pode facer que o noso proxecto saia do carril. Que podemos facer para minimizar a probabilidade de que isto suceda? Normalmente non podes neutralizalos ao 100% e declarar coa conciencia tranquila: "Isto é todo, isto xa non é un problema, o risco resolveuse!" Para min isto é un sinal de comportamento adulto. Esta é a diferenza entre un neno e un adulto: os nenos pensan que son inmortais, que nada pode saír mal, todo estará ben! Ao mesmo tempo, os adultos observan como os nenos de tres anos saltan ao parque infantil, seguen os movementos cos seus ollos e din para si mesmos: "ooh-ooh, ooh-ooh". Estou preto e prepárome para atrapar cando o neno caia.
Por outra banda, a razón pola que me gusta tanto este negocio é porque é arriscado. Facemos cousas, e esas cousas son arriscadas. Requiren un enfoque adulto. O entusiasmo por si só non resolverá os teus problemas!
Pensamento da enxeñería de adultos
Michael: O exemplo cos nenos é bo. Se son un enxeñeiro común, estou encantado de ser un neno. Pero como avanzas cara a un pensamento máis adulto?
Tim: Unha das ideas que funciona igual de ben con un principiante ou un programador establecido é o concepto de contexto. O que estamos a facer, o que imos conseguir. Que é realmente importante neste proxecto? Non importa quen sexas neste proxecto, se es en prácticas ou o arquitecto xefe, todo o mundo necesita contexto. Necesitamos que todos pensen a unha escala máis grande que as súas propias obras. "Eu fago a miña peza e, mentres a miña peza funcione, estou feliz". Non e non outra vez. Sempre paga a pena (sen ser groseiro!) lembrarlle á xente o contexto no que traballa. O que todos intentamos conseguir xuntos. Ideas de que podes ser un neno sempre que todo estea ben coa túa peza do proxecto; por favor, non o fagas. Se cruzamos a meta, só a cruzaremos xuntos. Non estás só, estamos todos xuntos. Se todas as persoas do proxecto, tanto maiores como mozos, comezasen a falar sobre o que é exactamente importante para o proxecto, por que a empresa está a investir cartos no que todos intentamos conseguir... a maioría deles sentiranse moito mellor porque verá como o seu traballo se correlaciona co traballo de todos os demais. Por unha banda, entendo a peza da que son persoalmente responsable. Pero para rematar o traballo necesitamos tamén de todas as demais persoas. E se de verdade pensas que remataches, sempre temos traballo que facer no proxecto!
Oleg: En termos relativos, se traballas segundo Kanban, cando chegas ao pescozo de botella dalgunhas probas, podes deixar o que estabas facendo alí (por exemplo, a programación) e ir axudar aos probadores.
Tim: Exactamente. Creo que os mellores técnicos, se os miras atentamente, son os seus propios xestores. Como podo formular isto...
Oleg: A túa vida é o teu proxecto, que ti xestionas.
Tim: Exactamente! É dicir, asumes a responsabilidade, entendes o tema e entras en contacto coa xente cando ves que as túas decisións poden afectar o seu traballo, cousas así. Non se trata só de sentarte na túa mesa, facer o teu traballo e nin sequera darte conta do que está a suceder ao teu redor. Non non Non. Por certo, unha das mellores cousas de Agile é que propuxeron sprints curtos, porque así o estado de cousas de todos os participantes é claramente observable, poden velo todos xuntos. Falamos uns dos outros todos os días.
Como entrar na xestión de riscos
Oleg: Existe algunha estrutura de coñecemento formal nesta área? Por exemplo, son un programador de Java e quero entender a xestión de riscos sen converterme nun verdadeiro xestor de proxectos por educación. Probablemente lerei primeiro "Canto custa un proxecto de software" de McConnell, e despois que? Cales son os primeiros pasos?
Tim: O primeiro é comezar a comunicarse coas persoas do proxecto. Isto proporciona unha mellora inmediata na cultura de comunicación cos compañeiros. Debemos comezar abrindo todo por defecto, en lugar de ocultalo. Diga: estas son as cousas que me molestan, estas son as que me deixan espertar pola noite, hoxe espertei pola noite e dixen: meu Deus, teño que pensar nisto! Os demais ven o mesmo? Como grupo, debemos responder a estes problemas potenciais? Debe ser capaz de apoiar un debate sobre estes temas. Non hai unha fórmula preparada previamente pola que traballemos. Non se trata de facer hamburguesas, senón de persoas. "Facer unha hamburguesa con queixo, vender unha hamburguesa con queixo" non é cousa nosa para nada, e por iso gústame tanto este traballo. Gústame cando todo o que facían os directivos agora pasa a ser propiedade do equipo.
Oleg: Falaches en libros e entrevistas sobre como a xente se preocupa máis pola felicidade que polos números nun gráfico. Por outra banda, cando lle dis ao equipo: estamos pasando aos devops, e agora o programador debe comunicarse constantemente, isto pode estar lonxe da súa zona de confort. E neste momento pode, digamos, ser profundamente infeliz. Que facer nesta situación?
Tim: Non estou seguro de que facer exactamente. Se un desenvolvedor está demasiado illado, en primeiro lugar non ven por que se está a facer o traballo, só miran a súa parte do traballo e necesitan entrar no que eu chamo "contexto". Debe descubrir como todo está conectado. E, por suposto, non me refiro a presentacións formais nin nada parecido. Falo do feito de que cómpre comunicarse cos compañeiros sobre o traballo no seu conxunto, e non só sobre a parte da que é responsable. Aquí é onde podes comezar a discutir ideas, acordos comúns para facer que o teu traballo encaixe ben e como afrontar un problema común xuntos.
Para axudalos a adaptarse, adoitan querer enviar técnicos a adestramentos e discuten sobre a formación. A un amigo gústalle dicir que o adestramento é para cans. Hai formación para as persoas. Unha das mellores cousas de aprender como programador é interactuar cos teus compañeiros. Se alguén é realmente bo en algo, deberías velo traballar ou falar con el sobre o seu traballo ou algo así. Algún Kent Beck convencional falaba constantemente de programación extrema. É divertido porque XP é unha idea tan sinxela, pero causa moitos problemas. Para algúns, facer XP é como verse obrigado a desnudarse diante dos amigos. Xa verán o que estou facendo! Son os meus compañeiros, non só verán, senón que tamén entenderán! Terrible! Algunhas persoas comezan a poñerse moi nerviosas. Pero cando te das conta de que esta é a mellor forma de aprender, todo cambia. Traballas en estreita colaboración coa xente, e algunhas persoas entenden o tema moito mellor ca ti.
Michael: Pero todo isto obrígache a saír da túa zona de confort. Como enxeñeiro, tes que saír da túa zona de confort e comunicarte. Como solucionador de problemas, tes que poñerte constantemente nunha posición débil e pensar no que pode saír mal. Este tipo de traballo está deseñado inherentemente para ser unha molestia. Póñase conscientemente en situacións estresantes. Normalmente a xente foxe deles, á xente gústalle ser nenos felices.
Tim: O que se pode facer, pode saír e dicir abertamente: "Todo está ben, podo manexar! Non son o único que se sente incómodo. Comentemos varias cousas incómodas, todos xuntos, como un equipo!" Estes son os nosos problemas comúns, debemos tratar con eles, sabes? Creo que os desenvolvedores xenios idiosincráticos son como mamuts, desapareceron. E a súa importancia é moi limitada. Se non podes comunicarte, non podes participar ben. Polo tanto, só fala. Sexa honesto e aberto. Sinto moito que isto sexa desagradable para alguén. Imaxinades, hai moitos anos que houbo un estudo segundo o cal o principal medo nos Estados Unidos non é a morte, pero adiviñade que? Medo a falar en público! Isto significa que nalgún lugar hai persoas que prefiren morrer antes que dicir un eloxio en voz alta. E creo que abonda con que teñas unhas habilidades básicas, dependendo do que fagas. Habilidades de expresión oral, habilidades de escritura, pero só o que sexa realmente necesario no teu traballo. Se traballas como analista, pero non sabes ler, escribir e falar, entón, por desgraza, non terás nada que facer nos meus proxectos!
O prezo da comunicación
Oleg: Non é máis caro empregar a estes empregados salientes por varias razóns? Despois de todo, están constantemente conversando en lugar de traballar!
Tim: Refírome ao núcleo do equipo, e non só a todos. Se tes alguén que é realmente xenial para axustar bases de datos, adora axustar bases de datos e vai seguir axustando as túas bases de datos o resto da súa vida e xa está, guay, continúa así. Pero falo de persoas que queren vivir no propio proxecto. O núcleo do equipo, orientado ao desenvolvemento do proxecto. Estas persoas realmente precisan comunicarse constantemente entre elas. E sobre todo ao comezo do proxecto, cando discutes riscos, formas de acadar obxectivos globais e similares.
Michael: Isto aplícase a todos os implicados no proxecto, independentemente da especialización, habilidades ou formas de traballar. Todos estades interesados no éxito do proxecto.
Tim: Si, sentes que estás suficientemente inmerso no proxecto, que a túa tarefa é axudar a que o proxecto se faga realidade. Se es programador, analista, deseñador de interfaces, calquera persoa. Esta é a razón pola que veño traballar todas as mañás e isto é o que facemos. Somos responsables de todas estas persoas, independentemente das súas habilidades. Este é un grupo de persoas que teñen conversas entre adultos.
Oleg: De feito, falando de empregados faladores, tentei simular as obxeccións da xente, especialmente dos xestores, aos que se lles pide que cambien aos devops, a esta nova visión do mundo. E vostedes, como consultores, deberían ser conscientes destas obxeccións moito mellor ca min, como desenvolvedor! Comparte o que máis preocupa aos xestores?
Tim: xestores? Hm. Na maioría das veces, os xestores están sometidos a presión por problemas, ante a necesidade de liberar algo con urxencia e facer unha entrega, etc. Observan como constantemente discutimos e discutimos sobre algo, e ven así: conversas, conversas, conversas... Que outras conversas? Volve ao traballo! Porque falar non lles parece traballo. Non escribes código, non probas software, non pareces facer nada, por que non te mandas a facer algo? Despois de todo, a entrega xa está nun mes!
Michael: Vaia escribir algún código!
Tim: Paréceme que non lles preocupa o traballo, senón a falta de visibilidade do progreso. Para que pareza que estamos cada vez máis preto do éxito, necesitan vernos premendo botóns do teclado. Todo o día dende a mañá ata a noite. Este é o problema número un.
Oleg: Misha, estás pensando en algo.
Michael: Sentímolo, perdínme nos pensamentos e peguei un flashback. Todo isto lembroume un rally interesante que aconteceu onte... Onte houbo demasiadas concentracións... E todo soa moi familiar!
A vida sen soldos
Tim: Por certo, non é para nada necesario organizar "rallyes" para a comunicación. Quero dicir, as discusións máis útiles entre desenvolvedores ocorren cando só falan entre eles. Entras pola mañá cunha cunca de café, e hai cinco persoas reunidas e discutindo furiosamente algo técnico. Para min, se son o xestor deste proxecto, é mellor sorrir e ir a algún lugar sobre o meu negocio, deixar que o discutan. Xa están implicados na medida do posible. Este é un bo sinal.
Oleg: Por certo, no teu libro tes unha morea de notas sobre o que é bo e o que é malo. Usas algún deles ti mesmo? Relativamente falando, agora tes unha empresa, e unha que está estruturada dun xeito moi pouco ortodoxo...
Tim: Poco ortodoxo, pero este aparello nos convén perfectamente. Coñecémonos dende hai moito tempo. Confiamos uns nos outros, confiámonos moito antes de facernos socios. E, por exemplo, non temos ningún soldo. Nós só traballamos e, por exemplo, se gañei cartos dos meus clientes, todo o diñeiro foi para min. Despois diso, pagamos as cotas de socio á organización, e isto é suficiente para apoiar a propia empresa. Ademais, todos nos especializamos en cousas diferentes. Por exemplo, traballo con contadores, cubro declaracións fiscais, fago todo tipo de cousas administrativas para a empresa e ninguén me paga por iso. James e Tom traballan no noso sitio web e ninguén lles paga tampouco. Mentres pagues as túas cotas, a ninguén se lle ocorrerá dicir o que tes que facer. Por exemplo, Tom agora traballa moito menos que antes. Agora ten outros intereses; fai algunhas cousas que non son para o Gremio. Pero mentres pague as súas cotas, ninguén se achegará a el e lle dirá: "Ei, Tom, vai traballar!" É moi doado tratar cos compañeiros cando non hai cartos entre vós. E agora a nosa relación é unha das ideas fundamentais en relación ás diferentes especialidades. Funciona e funciona moi ben.
Mellor consello
Michael: Volvendo ao "mellor consello", hai algo que lle dis aos teus clientes unha e outra vez? Hai unha idea sobre o 80/20, e algúns consellos probablemente se repitan con máis frecuencia.
Tim: Unha vez pensei que se escribías un libro como Waltzing with Bears, cambiaría o curso da historia e a xente pararía, pero... Pois mira, as empresas adoitan pretender que todo lles vai ben. En canto pasa algo malo, é un choque e unha sorpresa para eles. "Mira, probamos o sistema, e non pasa ningunha proba do sistema, e isto son outros tres meses de traballo non programado, como puido pasar isto? Quen sabía? Que podería saír mal? En serio, cres isto?
Estou tentando explicar que non debes enfadarte demasiado pola situación actual. Necesitamos falalo, entender realmente o que puido saír mal e como evitar que tales cousas sucedan no futuro. Se aparece un problema, como o combateremos, como o conteremos?
Para min, todo isto paréceme asustado. A xente trata con problemas complexos e molestos e segue a finxir que se cruzan os dedos e esperan o mellor, o "mellor" sucederá. Non, non funciona así.
Practica a xestión de riscos!
Michael: Na súa opinión, cantas organizacións se dedican á xestión de riscos?
Tim: O que me enfurece é que a xente simplemente anota os riscos, mira a lista resultante e vaise a traballar. De feito, identificar os riscos para eles é xestión de riscos. Pero a min isto paréceme un motivo para preguntar: vale, hai unha lista, que vai cambiar exactamente? Debe cambiar as súas secuencias estándar de accións tendo en conta estes riscos. Se hai algunha parte máis difícil do traballo, cómpre abordala e só despois pasar a algo máis sinxelo. Nos primeiros sprints, comeza a resolver problemas complexos. Isto xa parece xestión de riscos. Pero normalmente a xente non pode dicir o que cambiaron despois de compilar unha lista de riscos.
Michael: E aínda así, cantas destas empresas están implicadas na xestión de riscos, un cinco por cento?
Tim: Desafortunadamente, non me gusta dicir isto, pero esta é unha parte moi insignificante. Pero máis de cinco, porque hai proxectos realmente grandes, e simplemente non poden existir se non fan polo menos algo. Digamos que me sorprenderei moito se é polo menos un 25%. Os pequenos proxectos adoitan responder a tales preguntas deste xeito: se o problema nos afecta, entón resolverémolo. Entón, eles mesmos con éxito se meten en problemas e se involucran na xestión de problemas e xestión de crises. Cando intentas resolver un problema e o problema non se soluciona, benvido á xestión de crises.
Si, escoito moitas veces: "resolveremos os problemas a medida que xurdan". Seguro que o faremos? Decidiremos realmente?
Oleg: Podes facelo inxenuamente e simplemente escribir invariantes importantes na carta do proxecto e, se os invariantes rompen, só tes que reiniciar o proxecto. Acontece que é moi piadoso.
Michael: Si, pasoume que cando se desencadeaban riscos, o proxecto simplemente redefiniuse. Bonito, bingo, problema resolto, non te preocupes máis!
Tim: Prememos o botón de reinicio! Non, non funciona así.
Conferencia principal en DevOops 2019
Michael: Chegamos á última pregunta desta entrevista. Estás chegando ao próximo DevOops cunha conferencia, poderías levantar o telón do segredo sobre o que vas contar?
Tim: Agora mesmo, seis deles están escribindo un libro sobre a cultura laboral, as regras non ditas das organizacións. A cultura está determinada polos valores fundamentais da organización. Normalmente a xente non se decata diso, pero levando moitos anos traballando na consultoría, estamos acostumados a notalo. Entras nunha empresa e, literalmente, en poucos minutos comezas a sentir o que está a pasar. Chamámoslle "sabor". Ás veces, este perfume é moi bo, e ás veces é, ben, oops. As cousas son moi diferentes para as diferentes organizacións.
Michael: Eu tamén levo anos traballando na consultoría e entendo ben do que falas.
Tim: De feito, unha das cousas das que paga a pena falar na keynote é que non todo está determinado pola empresa. Ti e o teu equipo, como comunidade, tes a túa propia cultura de equipo. Esta podería ser a empresa enteira, ou un departamento separado, un equipo separado. Pero antes de dicir, isto é o que cremos, isto é o importante... Non se pode cambiar unha cultura antes de que se comprendan os valores e crenzas detrás de accións específicas. O comportamento é fácil de observar, pero buscar crenzas é difícil. DevOps é só un gran exemplo de como as cousas son cada vez máis complexas. As interaccións son cada vez máis complexas, non se están facendo máis limpas nin máis claras en absoluto, polo que debes pensar en que cres e no que calan todos os que te rodean.
Se queres conseguir resultados rápidos, aquí tes un bo tema: viches empresas onde ninguén di "non sei"? Hai lugares onde literalmente torturas a unha persoa ata que admite que non sabe algo. Todo o mundo sábeo todo, todo o mundo é un erudito incrible. Achégase a calquera persoa e el ten que responder ao instante á pregunta. En vez de dicir "Non sei". Hurra, contrataron unha morea de eruditos! E nalgunhas culturas é xeralmente moi perigoso dicir "non o sei"; pódese percibir como un sinal de debilidade. Tamén hai organizacións nas que, pola contra, todo o mundo pode dicir "non o sei". Aí é completamente legal, e se alguén comeza a lixo en resposta a unha pregunta, o normal é responder: "Non sabes do que falas, non?" e convertelo todo nunha broma.
O ideal é que che gustaría ter un traballo no que puideses estar constantemente feliz. Non será doado, non todos os días son soleados e agradables, ás veces hai que traballar duro, pero cando comeces a facer balance, resultará: wow, este é un lugar realmente marabilloso, síntome ben traballando aquí, tanto a nivel emocional como intelectual. E hai empresas nas que vas como consultor e te das conta ao instante de que non aguantaches durante tres meses e fuxirías horrorizado. Isto é do que quero falar na reportaxe.
Tim Lister chegará cunha conferencia maxistral á conferencia DevOops 2019, que terá lugar do 29 ao 30 de outubro de 2019 en San Petersburgo. Podes mercar entradas . Agardámoste en DevOops!
Fonte: www.habr.com