Tim Lister - coautor de libros

• "Factor humano. Proyectos y Equipos Exitosos" (el libro original se llama "Peopleware")
• "Bailando con los osos: gestión de riesgos en proyectos de software"
• “Enloquecido por la adrenalina y zombificado por patrones. Patrones de comportamiento de los equipos de proyecto"

Todos estos libros son clásicos en su campo y fueron escritos junto con colegas en Gremio de sistemas atlánticos. En Rusia, sus colegas son los más famosos: Tom DeMarco и Peter Hruschka, quien también escribió muchas obras famosas.

Tim tiene 40 años de experiencia en desarrollo de software; en 1975 (ninguno de los que escribieron este habrapost nació este año), Tim ya era vicepresidente ejecutivo de Yourdon Inc. Ahora dedica su tiempo a consultar, enseñar y escribir, con visitas ocasionales a con informes conferencias alrededor del mundo.

Hicimos una entrevista con Tim Lister especialmente para Habr. Él abrirá la conferencia DevOops 2019 y tenemos muchas preguntas sobre libros y más. La entrevista está a cargo de Mikhail Druzhinin y Oleg Chirukhin del comité del programa de la conferencia.

Michael: ¿Puedes decir algunas palabras sobre lo que estás haciendo ahora?

Tim: Soy el jefe del Gremio de Sistemas Atlánticos. Somos seis en el Gremio, nos llamamos directores. Tres en EE.UU. y tres en Europa: por eso el gremio se llama Atlantic. Hemos estado juntos durante tantos años que simplemente no puedes contarlos. Todos tenemos nuestras especialidades. He estado trabajando con clientes durante la última década o más. Mis proyectos incluyen no sólo la gestión, sino también el establecimiento de requisitos, la planificación y la evaluación de proyectos. Parece que los proyectos que empiezan mal suelen terminar mal. Por lo tanto, vale la pena asegurarse de que todas las actividades estén realmente bien pensadas y coordinadas, de que se combinen las ideas de los creadores. Vale la pena pensar en lo que estás haciendo y por qué. Qué estrategias utilizar para llevar el proyecto a término.

He estado asesorando a clientes de diversas maneras durante muchos años. Un ejemplo interesante es una empresa que fabrica robots para cirugía de rodilla y cadera. El cirujano no opera de forma totalmente independiente, sino que utiliza un robot. La seguridad aquí, francamente, es importante. Pero cuando intentas discutir los requisitos con personas que se centran en resolver problemas... Puede sonar extraño, pero en EE. UU. hay FDA (Administración Federal de Medicamentos), que otorga licencias para productos como estos robots. Antes de vender algo y usarlo en personas vivas, es necesario obtener una licencia. Una de las condiciones es mostrar sus requisitos, cuáles son las pruebas, cómo las probó, cuáles son los resultados de las pruebas. Si cambia los requisitos, deberá pasar por todo este enorme proceso de prueba una y otra vez. Nuestros clientes lograron incluir el diseño visual de aplicaciones en sus requerimientos. Tenían capturas de pantalla directamente como parte de los requisitos. Tenemos que sacarlos y explicar que en su mayor parte todos estos programas no saben nada sobre rodillas y caderas, todas estas cosas con la cámara, etc. Necesitamos reescribir los documentos de requisitos para que nunca cambien, a menos que cambien algunas condiciones subyacentes realmente importantes. Si el diseño visual no está entre los requisitos, la actualización del producto será mucho más rápida. Nuestro trabajo es encontrar los elementos que se ocupan de las operaciones en la rodilla, las caderas y la espalda, separarlos en documentos separados y decir que estos serán los requisitos fundamentales. Hagamos un grupo aislado de requisitos sobre las operaciones de rodilla. Esto nos permitirá construir un conjunto de requisitos más estable. Hablaremos de toda la línea de productos y no de robots específicos.

Se trabajó mucho, pero aún así llegaron a lugares donde antes pasaban semanas y meses de pruebas repetidas sin sentido ni necesidad, porque los requisitos descritos en el papel no coincidían con los requisitos reales para los cuales se construyeron los sistemas. La FDA les decía cada vez: sus requisitos han cambiado, ahora necesita verificar todo desde cero. Las nuevas comprobaciones completas de todo el producto estaban acabando con la empresa.

Entonces, hay tareas tan maravillosas cuando te encuentras al comienzo de algo interesante, y las primeras acciones establecen las reglas adicionales del juego. Si se asegura de que esta actividad inicial comience a funcionar bien tanto desde el punto de vista administrativo como técnico, existe la posibilidad de que termine con un gran proyecto. Pero si esta parte se ha descarrilado y ha ido en alguna parte mal, si no puedes encontrar los acuerdos fundamentales... no, no es que tu proyecto necesariamente vaya a fracasar. Pero ya no podrás decir: "Lo hicimos muy bien, hicimos todo de manera muy efectiva". Estas son las cosas que hago cuando me comunico con los clientes.

Michael: Es decir, ¿lanzas proyectos, haces algún tipo de inicio y compruebas que los rieles van en la dirección correcta?

Tim: También tenemos ideas sobre cómo juntar todas las piezas del rompecabezas: qué habilidades necesitamos, cuándo exactamente se necesitan, cómo es el núcleo del equipo y otras cosas fundamentales. ¿Necesitamos empleados a tiempo completo o podemos contratar a alguien a tiempo parcial? Planificación, gestión. Preguntas como: ¿Qué es lo más importante para este proyecto en particular? ¿Cómo lograr esto? ¿Qué sabemos sobre este producto o proyecto, cuáles son los riesgos y dónde están las incógnitas, cómo vamos a afrontar todo esto? Por supuesto, en ese momento alguien empieza a gritar “¡¿Qué pasa con la agilidad?!” Está bien, sois todos flexibles, pero ¿y qué? ¿Cómo es exactamente el proyecto? ¿Cómo lo vas a llevar a cabo de una manera que se adapte al proyecto? No se puede decir simplemente que "nuestro enfoque se extiende a cualquier cosa, ¡somos un equipo Scrum!" Esto es una tontería y una tontería. ¿Adónde vas a ir ahora? ¿Por qué debería funcionar? ¿Cuál es el punto? Enseño a mis clientes a pensar en todas estas preguntas.

19 años de ágil

Michael: En Agile, la gente a menudo intenta no definir nada de antemano, sino tomar decisiones lo más tarde posible, diciendo: somos demasiado grandes, no pensaré en la arquitectura general. No pensaré en muchas otras cosas; en cambio, entregaré algo que funcione al cliente en este momento.

Tim: Creo que las metodologías ágiles, empezando por Manifiesto Ágil en 2001, abrió los ojos de la industria. Pero, por otra parte, nada es perfecto. Estoy totalmente a favor del desarrollo iterativo. La iteración tiene mucho sentido en la mayoría de los proyectos. Pero la pregunta que debes plantearte es: una vez que el producto está disponible y en uso, ¿cuánto dura? ¿Es este un producto que durará seis meses antes de ser reemplazado por otro? ¿O es este un producto que funcionará durante muchos, muchos años? Por supuesto, no daré nombres, pero... En Nueva York y su comunidad financiera, los sistemas más fundamentales son muy antiguos. Esto es increíble. Los miras y piensas, si tan solo pudieras retroceder en el tiempo, hasta 1994, y decirles a los desarrolladores: “Vengo del futuro, de 2019. Simplemente desarrolle este sistema durante el tiempo que necesite. Hazlo ampliable, piensa en la arquitectura. Luego será mejorado durante más de veinticinco años. ¡Si retrasas el desarrollo un poco más, en el gran esquema de las cosas nadie se dará cuenta! Cuando estima cosas a largo plazo, debe considerar cuánto costará en total. A veces una arquitectura bien diseñada realmente vale la pena y otras no. Necesitamos mirar a nuestro alrededor y preguntarnos: ¿estamos en la situación adecuada para tomar tal decisión?

Entonces, una idea como “Somos partidarios de la agilidad, el propio cliente nos dirá lo que quiere obtener” es muy ingenua. Los clientes ni siquiera saben lo que quieren, y más aún, no saben qué podrían conseguir. Algunas personas empezarán a citar ejemplos históricos como argumentos, esto ya lo he visto. Pero la gente técnicamente avanzada no suele decir eso. Dicen: "¡Estamos en 2019, estas son las oportunidades que tenemos y podemos cambiar completamente la forma en que vemos estas cosas!" En lugar de imitar soluciones existentes, hacerlas un poco más bonitas y peinadas, a veces es necesario salir y decir: "¡Reinventemos completamente lo que estamos tratando de hacer aquí!".

Y no creo que la mayoría de los clientes puedan pensar en el problema de esa manera. Sólo ven lo que ya tienen, eso es todo. Después de lo cual vienen con peticiones como “hagamos esto un poco más simple”, o lo que suelen decir. Pero no somos camareros ni camareras, así que podemos tomar un pedido por muy estúpido que resulte y luego hornearlo en la cocina. Somos sus guías. Tenemos que abrirles los ojos y decir: ¡oye, aquí tenemos nuevas oportunidades! ¿Se da cuenta de que realmente podemos cambiar la forma en que se realiza esta parte de su negocio? Uno de los problemas con Agile es que elimina la conciencia de qué es una oportunidad, qué es un problema, qué debemos hacer, qué tecnologías disponibles son las más adecuadas para esta situación particular.

Quizás estoy siendo demasiado escéptico: están sucediendo muchas cosas maravillosas en la comunidad ágil. Pero tengo un problema con el hecho de que en lugar de definir un proyecto, la gente empieza a darse por vencida. Yo preguntaría aquí: ¿qué estamos haciendo, cómo lo vamos a hacer? Y de alguna manera mágicamente siempre resulta que el cliente debería saberlo mejor que nadie. Pero el cliente sólo sabe mejor cuando elige entre cosas ya construidas por alguien. Si quiero comprar un coche y sé cuál es el tamaño de mi presupuesto familiar, seleccionaré rápidamente un coche que se adapte a mi estilo de vida. ¡Aquí lo sé todo mejor que nadie! Pero tenga en cuenta que alguien ya ha fabricado los coches. No tengo idea de cómo inventar un auto nuevo, no soy un experto. Cuando creamos productos personalizados o especiales hay que tener en cuenta la voz del cliente, pero esta ya no es la única voz.

Oleg: Mencionaste el Manifiesto Ágil. ¿Necesitamos actualizarlo o revisarlo de alguna manera teniendo en cuenta la comprensión moderna del problema?

Tim: Yo no lo tocaría. Creo que es un gran documento histórico. Quiero decir, él es lo que es. Está cumpliendo 19 años, es viejo, pero en su época hizo una revolución. Lo que hizo bien fue que provocó una reacción y la gente empezó a susurrar sobre él. Lo más probable es que en 2001 usted todavía no estuviera trabajando en la industria, pero entonces todos trabajaban según procesos. Instituto de Ingeniería de Software, cinco niveles del modelo de integridad del software (CMMI). No sé si esas leyendas de la antigüedad profunda te dicen algo, pero fue un gran avance. Al principio, la gente creía que si los procesos se configuraban correctamente, los problemas desaparecerían por sí solos. Y luego llega el Manifiesto y dice: “No, no, no, nos basaremos en personas, no en procesos”. Somos maestros en el desarrollo de software. Entendemos que el proceso ideal es un espejismo, no sucede. Hay demasiada idiosincrasia en los proyectos, la idea de un único proceso perfecto para todos los proyectos no tiene ningún sentido. Los problemas son demasiado complejos para afirmar que sólo hay una solución para todo (hola, nirvana).

No pretendo mirar hacia el futuro, pero diré que ahora la gente ha empezado a pensar más en proyectos. Creo que el Manifiesto Ágil es muy bueno para saltar y decir: “¡Oye! Estás en un barco y tú mismo conduces este barco. Tendrá que tomar una decisión: no sugeriremos una receta universal para todas las situaciones. Eres la tripulación del barco y, si eres lo suficientemente bueno, podrás encontrar el camino hacia la meta. Hubo otros barcos antes que tú y habrá otros barcos después de ti, pero aun así, en cierto sentido, tu viaje es único”. ¡Algo como eso! Es una forma de pensar. Para mí no hay nada nuevo bajo el sol, la gente ha navegado antes y volverá a navegar, pero para ti este es tu viaje principal y no te diré qué te sucederá exactamente. Debes tener las habilidades para el trabajo coordinado en equipo, y si realmente las tienes, todo saldrá bien y llegarás a donde deseas.

Peopleware: 30 años después

Oleg: ¿Fue el Peopleware una revolución además del Manifiesto?

Tim: Peopleware... Tom y yo escribimos este libro, pero no pensamos que sucedería así. De alguna manera resonó con las ideas de mucha gente. Este fue el primer libro que decía: el desarrollo de software es una actividad muy intensiva en humanos. A pesar de nuestra naturaleza técnica, también somos una comunidad de personas que construyen algo grande, incluso enorme, muy complejo. Nadie puede crear cosas así por sí solo, ¿verdad? Entonces la idea de "equipo" se volvió muy importante. Y no solo desde el punto de vista de la gestión, sino también para los técnicos que se unieron para resolver problemas profundos realmente complejos con muchas incógnitas. Para mí personalmente, esta ha sido una gran prueba de inteligencia a lo largo de mi carrera. Y aquí hay que poder decir: sí, este problema es más de lo que puedo manejar solo, pero juntos podemos encontrar una solución elegante de la que podamos estar orgullosos. Y creo que fue esta idea la que más resonó. La idea de que trabajamos parte del tiempo solos, parte del tiempo como parte de un grupo y muchas veces la decisión la toma el grupo. La resolución de problemas en grupo se ha convertido rápidamente en una característica importante de los proyectos complejos.

A pesar de que Tim ha dado una gran cantidad de charlas, muy pocas de ellas están publicadas en YouTube. Puede consultar el informe “El regreso del Peopleware” de 2007. La calidad, por supuesto, deja mucho que desear.

Michael: ¿Ha cambiado algo en los últimos 30 años desde que se publicó el libro?

Tim: Puedes ver esto desde muchos ángulos diferentes. Sociológicamente hablando... Érase una vez, en tiempos más simples, usted y su equipo se sentaban en la misma oficina. Podrían estar cerca todos los días, tomar café juntos y hablar sobre el trabajo. Lo que realmente ha cambiado es que los equipos ahora pueden distribuirse geográficamente, en diferentes países y zonas horarias, pero siguen trabajando en el mismo problema, y ​​esto añade una capa completamente nueva de complejidad. Puede que esto suene a la vieja escuela, pero no hay nada como la comunicación cara a cara en la que están todos juntos, trabajando juntos, y puedes acercarte a un colega y decirle: mira lo que descubrí, ¿qué te parece esto? Las conversaciones cara a cara proporcionan una forma rápida de hacer la transición a la comunicación informal y creo que a los entusiastas ágiles también les debería gustar. Y también estoy preocupado porque en realidad el mundo se ha vuelto muy pequeño y ahora está todo cubierto de equipos distribuidos y todo es muy complejo.

Todos vivimos en DevOps

Michael: Incluso desde el punto de vista del comité del programa de la conferencia, tenemos gente en California, Nueva York, Europa, Rusia... todavía no hay nadie en Singapur. La diferencia geográfica es bastante grande y la gente está empezando a dispersarse aún más. Si hablamos de desarrollo, ¿puede contarnos más sobre devops y cómo romper barreras entre equipos? Existe el concepto de que todos están sentados en sus búnkeres y ahora los búnkeres se están derrumbando, ¿qué opinas de esta analogía?

Tim: Me parece que a la luz de los recientes avances tecnológicos, Devops es de gran importancia. Anteriormente, había equipos de desarrolladores y administradores, trabajaban, trabajaban, trabajaban y, en algún momento, apareció algo con lo que podía acudir a los administradores y implementarlo en producción. Y aquí comenzó la conversación sobre el búnker, porque los administradores son una especie de aliados, no enemigos, al menos, pero solo hablabas con ellos cuando todo estaba listo para entrar en producción. ¿Fuiste a ellos con algo y les dijiste: mira qué aplicación tenemos, pero podrías implementar esta aplicación? Y ahora todo el concepto de entrega ha cambiado para mejor. Quiero decir, existía la idea de que se podían impulsar cambios rápidamente. Podemos actualizar productos sobre la marcha. Siempre sonrío cuando aparece Firefox en mi computadora portátil y dice, oye, hemos actualizado tu Firefox en segundo plano, y tan pronto como tengas un minuto, ¿te importaría hacer clic aquí y te daremos la última versión? Y yo dije: "¡Oh, sí, cariño!" Mientras dormía, estaban trabajando para entregarme una nueva versión directamente en mi computadora. Esto es maravilloso, increíble.

Pero aquí está la dificultad: tienes esta característica al actualizar el software, pero integrar a las personas es mucho más difícil. Lo que quiero expresar en la conferencia magistral de DevOops es que ahora tenemos muchos más jugadores que nunca. Si piensas en todos los involucrados en un solo equipo…. Lo pensaste como un equipo y es mucho más que un simple equipo de programadores. Estos son evaluadores, gerentes de proyectos y muchas otras personas. Y cada uno tiene su propia visión del mundo. Los gerentes de producto son completamente diferentes a los gerentes de proyecto. Los administradores tienen sus propias tareas. Se vuelve un problema bastante difícil coordinar a todos los participantes para seguir siendo conscientes de lo que sucede y no volverse locos. Es necesario separar las tareas del grupo y las que corresponden a todos. Ésta es una tarea muy difícil. Por otro lado, creo que todo está mucho mejor que hace muchos años. Éste es exactamente el camino por el que las personas crecen y aprenden a comportarse correctamente. Cuando haces la integración, entiendes que no debe haber ningún desarrollo clandestino, para que en el último momento el software no salga como una caja sorpresa: ¡mira lo que hicimos aquí! La idea es que puedas realizar integración y desarrollo, y al final lo implementarás de una manera ordenada e iterativa. Todo esto significa mucho para mí. Esto permite crear más valor para los usuarios del sistema y para su cliente.

Michael: La idea general de Devops es ofrecer desarrollos significativos lo antes posible. Veo que el mundo ha comenzado a acelerarse cada vez más. ¿Cómo adaptarse a tales aceleraciones? ¡Hace diez años esto no existía!

Tim: Por supuesto, todo el mundo quiere cada vez más funciones. No es necesario moverse, simplemente acumule más. A veces incluso tienes que reducir la velocidad para que la siguiente actualización incremental aporte algo útil, y eso es completamente normal.

La idea de que necesitas correr, correr, correr no es la mejor. Es poco probable que alguien quiera vivir su vida así. Me gustaría que el ritmo de entregas marcara el ritmo propio del proyecto. Si simplemente produce un flujo de cosas pequeñas y relativamente sin significado, todo carece de significado. En lugar de intentar lanzar cosas sin pensar lo antes posible, lo que vale la pena discutir con los desarrolladores principales y los gerentes de productos y proyectos es la estrategia. ¿Esto tiene sentido?

Patrones y antipatrones

Oleg: Generalmente se habla de patrones y antipatrones, y esta es la diferencia entre la vida y la muerte de los proyectos. Y ahora, Devops irrumpe en nuestras vidas. ¿Tiene alguno de sus propios patrones y antipatrones que puedan acabar con el proyecto en el acto?

Tim: Los patrones y antipatrones ocurren todo el tiempo. Algo de que hablar. Bueno, existe algo que llamamos "cosas brillantes". A la gente le gustan mucho las nuevas tecnologías. Simplemente quedan hipnotizados por el brillo de todo lo que parece moderno y elegante, y dejan de hacerse preguntas: ¿es necesario? ¿Qué vamos a lograr? ¿Es esto confiable? ¿Tiene algún sentido? A menudo veo gente, por así decirlo, a la vanguardia de la tecnología. Están hipnotizados por lo que sucede en el mundo. Pero si observas más de cerca las cosas útiles que hacen, ¡a menudo simplemente no hay nada útil!

Estábamos discutiendo con nuestros camaradas que este año es un aniversario, cincuenta años desde que la gente llegó a la luna. Esto fue en 1969. La tecnología que ayudó a la gente a llegar allí ni siquiera es tecnología de 1969, sino más bien de 1960 o 62, porque la NASA quería utilizar sólo lo que tuviera buena evidencia de confiabilidad. Y entonces lo miras y entiendes: ¡sí, y eran verdad! Ahora, no, no, pero te metes en problemas con la tecnología simplemente porque todo se presiona demasiado, se vende por todas partes. La gente grita por todas partes: “¡Mira, qué cosa, esto es lo más nuevo, lo más hermoso del mundo, apto para absolutamente todos!” Bueno, eso es todo... normalmente todo esto resulta ser sólo un señuelo, y luego hay que tirarlo todo. Tal vez todo se deba a que ya soy un anciano y miro esas cosas con mucho escepticismo, cuando la gente sale corriendo y dice que han encontrado la única y más correcta manera de crear las mejores tecnologías. En ese momento se despierta en mi interior una voz que dice: “¡Qué lío!”

Michael: De hecho, ¿con qué frecuencia hemos oído hablar de la próxima solución milagrosa?

Tim: ¡Exactamente, y este es el curso habitual de las cosas! Por ejemplo… parece que esto ya se ha convertido en una broma en todo el mundo, pero aquí se habla mucho de la tecnología blockchain. ¡Y en realidad tienen sentido en determinadas situaciones! Cuando realmente necesitas evidencia confiable de los eventos, de que el sistema funciona y de que nadie nos engañó, cuando tienes problemas de seguridad y todo eso mezclado, blockchain tiene sentido. ¿Pero cuando dicen que Blockchain ahora se extenderá por todo el mundo, arrasando con todo a su paso? ¡Sueña más! Esta es una tecnología muy costosa y compleja. Técnicamente complejo y requiere mucho tiempo. Incluso de forma puramente algorítmica, cada vez es necesario recalcular las matemáticas, con los más mínimos cambios... y esta es una gran idea, pero sólo en determinados casos. Toda mi vida y mi carrera han girado en torno a esto: ideas interesantes en situaciones muy específicas. Es muy importante entender exactamente cuál es su situación.

Michael: Sí, la principal “cuestión de la vida, el universo y todo”: ¿esta tecnología o enfoque es adecuado para su situación o no?

Tim: Esta cuestión ya se puede discutir con el grupo de tecnología. Tal vez incluso traiga algún consultor. Eche un vistazo al proyecto y comprenda: ¿haremos ahora algo correcto y útil, mejor que antes? Tal vez encaje, tal vez no. Pero lo más importante es no tomar esa decisión por defecto, simplemente porque alguien soltó: “¡Necesitamos desesperadamente una cadena de bloques! ¡Acabo de leer sobre él en una revista en el avión! ¿En serio? Ni siquiera es gracioso.

El mítico “ingeniero devops”

Oleg: Ahora todo el mundo está implementando Devops. Alguien lee sobre Devops en Internet y mañana aparece otra vacante en un sitio de contratación. "ingeniero devops". Aquí me gustaría llamar su atención: ¿cree que el término "ingeniero devops" tiene derecho a la vida? Existe la opinión de que Devops es una cultura y algo no cuadra aquí.

Tim: Más o menos. Entonces que den inmediatamente alguna explicación sobre este término. Algo que lo haga único. Hasta que demuestren que existe una combinación única de habilidades detrás de una vacante como esta, ¡no la aceptaré! Quiero decir, bueno, tenemos un título de trabajo, "ingeniero devops", un título interesante, sí, ¿qué sigue? Los títulos de trabajo son generalmente algo muy interesante. Digamos "desarrollador", ¿qué es de todos modos? Diferentes organizaciones significan cosas completamente diferentes. En algunas empresas, programadores de alta calidad escriben pruebas que tienen más sentido que las escritas por evaluadores profesionales especiales en otras empresas. Entonces, ¿ahora son programadores o probadores?

Sí, tenemos títulos de trabajo, pero si haces preguntas lo suficiente, eventualmente resulta que todos solucionamos problemas. Buscamos soluciones y algunos tienen algunas habilidades técnicas y otros diferentes. Si vive en un entorno donde ha penetrado DevOps, está involucrado en la integración del desarrollo y la administración, y esta actividad tiene algún propósito bastante importante. Pero si te preguntan qué haces exactamente y de qué eres responsable, resulta que la gente ha estado haciendo todas estas cosas desde tiempos inmemoriales. "Soy responsable de la arquitectura", "Soy responsable de las bases de datos", etc., lo que sea, todo esto fue antes de "devops".

Cuando alguien me dice su puesto de trabajo, realmente no escucho mucho. Es mejor dejar que te diga de qué es realmente responsable, esto nos permitirá entender mucho mejor el asunto. Mi ejemplo favorito es cuando una persona dice ser un "gerente de proyecto". ¿Qué? No significa nada, todavía no sé lo que haces. Un gerente de proyecto puede ser un desarrollador, un líder de un equipo de cuatro personas, que escribe código, realiza un trabajo, que se ha convertido en un líder de equipo, a quien las personas mismas reconocen entre sí como un líder. Y además, un director de proyecto puede ser un director que gestiona a seiscientas personas en un proyecto, gestiona a otros directores, es responsable de elaborar cronogramas y planificar presupuestos, eso es todo. ¡Estos son dos mundos completamente diferentes! Pero el título de su trabajo suena igual.

Vamos a darle la vuelta a esto un poco diferente. ¿En qué eres realmente bueno, tienes mucha experiencia, tienes talento? ¿De qué te responsabilizarás porque crees que puedes realizar la tarea? Y aquí alguien inmediatamente comenzará a negar: no, no, no, no tengo ningún deseo de lidiar con los recursos del proyecto, no es asunto mío, soy un tipo técnico y entiendo la usabilidad y las interfaces de usuario, no Si no quiero gestionar ejércitos de personas, será mejor que me ponga a trabajar.

Y, por cierto, soy un gran defensor de un enfoque en el que este tipo de separación de habilidades funcione bien. Donde los técnicos pueden hacer crecer su carrera tanto como quieran. Sin embargo, todavía veo organizaciones en las que los técnicos se quejan: tendré que dedicarme a la gestión de proyectos porque es la única manera en esta empresa. A veces esto conduce a resultados terribles. Los mejores técnicos no son buenos administradores en absoluto, y los mejores administradores no pueden manejar la tecnología. Seamos honestos sobre esto.

Veo mucha demanda para esto ahora. Si eres un aficionado a la tecnología, tu empresa puede ayudarte, pero de todos modos, necesitas, realmente necesitas encontrar tu propia trayectoria profesional porque la tecnología sigue cambiando y necesitas reinventarte junto con ella. En sólo veinte años, las tecnologías pueden cambiar al menos cinco veces. La tecnología es algo extraño...

"Expertos en todo"

Michael: ¿Cómo puede la gente hacer frente a tal velocidad del cambio tecnológico? Su complejidad está creciendo, su número está creciendo, la cantidad total de comunicación entre las personas también está creciendo y resulta que no puedes convertirte en un "experto en todo".

Tim: ¡Bien! Si trabajas en tecnología, sí, definitivamente necesitas elegir algo específico y profundizar en ello. Alguna tecnología que su organización considere útil (y que tal vez realmente lo sea). Y si ya no estás interesado en ello (nunca hubiera creído que diría esto), bueno, tal vez deberías mudarte a otra organización donde la tecnología sea más interesante o más conveniente para estudiar.

Pero en general sí, tienes razón. Las tecnologías crecen en todas direcciones a la vez, nadie puede decir “soy un tecnólogo experto en todas las tecnologías que existen”. Por otro lado, hay personas esponja que literalmente absorben conocimientos tecnológicos y se vuelven locos por ellos. He visto a un par de personas así, literalmente lo respiran y lo viven, es útil e interesante hablar con ellos. No solo estudian lo que sucede dentro de la organización, sino que en general hablan de ello, también son tecnólogos geniales, son muy conscientes y decididos. Simplemente intentan mantenerse en la cresta de la ola, independientemente de cuál sea su trabajo principal, porque su pasión es el movimiento de la tecnología, la promoción de la tecnología. Si de repente te encuentras con una persona así, deberías ir a almorzar con ella y discutir varias cosas interesantes durante el almuerzo. Creo que cualquier organización necesita al menos un par de personas así.

Riesgos e incertidumbre

Michael: Ingenieros honorables, sí. Toquemos la gestión de riesgos mientras tengamos tiempo. Comenzamos esta entrevista con una discusión sobre software médico, donde los errores pueden tener consecuencias nefastas. Luego hablamos del Programa Lunar, donde el coste de un error es de millones de dólares, y posiblemente de varias vidas humanas. Pero ahora veo el movimiento opuesto en la industria: la gente no piensa en los riesgos, no intenta predecirlos, ni siquiera los observa.

Oleg: ¡Muévete rápido y rompe cosas!

Michael: Sí, muévete rápido, rompe cosas, más y más cosas, hasta morir por algo. Desde su punto de vista, ¿cómo debería abordar el desarrollador promedio el aprendizaje de la gestión de riesgos ahora?

Tim: Tracemos aquí una línea entre dos cosas: riesgos e incertidumbre. Estas son cosas diferentes. La incertidumbre ocurre cuando no se tienen suficientes datos en un momento dado para llegar a una respuesta definitiva. Por ejemplo, en las primeras etapas de un proyecto, si alguien te pregunta “cuándo terminarás el trabajo”, si eres una persona bastante honesta, dirás: “No tengo idea”. Simplemente no lo sabes y está bien. Aún no has estudiado los problemas y no estás familiarizado con el equipo, no conoces sus habilidades, etc. Esto es incertidumbre.

Los riesgos surgen cuando ya se pueden identificar problemas potenciales. Este tipo de cosas pueden suceder, su probabilidad es mayor que cero, pero menor que el cien por ciento, en algún punto intermedio. Por eso, puede pasar cualquier cosa, desde retrasos y trabajos innecesarios, hasta un desenlace fatal para el proyecto. El resultado, cuando decís: chicos, pleguemos las sombrillas y dejemos la playa, nunca lo terminaremos, se acabó y punto. Supusimos que esto funcionaría, pero no funciona en absoluto, es hora de parar. Estas son las situaciones.

A menudo, los problemas son más fáciles de resolver cuando ya han surgido, cuando el problema está ocurriendo ahora mismo. Pero cuando tienes un problema justo frente a ti, no estás haciendo gestión de riesgos: estás resolviendo problemas, gestionando crisis. Si usted es un desarrollador o gerente líder, debe preguntarse qué podría suceder que provocaría retrasos, pérdida de tiempo, costos innecesarios o el colapso de todo el proyecto. ¿Qué nos hará parar y empezar de nuevo? Cuando todas estas cosas funcionen, ¿qué haremos con ellas? Hay una respuesta sencilla y válida para la mayoría de situaciones: no huyas de los riesgos, trabaja en ellos. Vea cómo puede resolver una situación de riesgo, reducirla a nada, convertirla de un problema en otra cosa. En lugar de decir: bueno, solucionaremos los problemas a medida que surjan.

La incertidumbre y el riesgo deben estar a la vanguardia de todo lo que afronte. Se puede tomar un plan de proyecto, observar ciertos riesgos críticos de antemano y decir: tenemos que abordar esto ahora, porque si algo sale mal, nada más importará. No debes preocuparte por la belleza del mantel sobre la mesa si no está claro si puedes cocinar la cena. Primero hay que identificar todos los riesgos de preparar una deliciosa cena, afrontarlos y sólo después pensar en todo lo demás que no supone una amenaza real.

Nuevamente, ¿qué hace que su proyecto sea único? Veamos qué puede hacer que nuestro proyecto se descarrile. ¿Qué podemos hacer para minimizar la probabilidad de que esto suceda? Por lo general, no es posible simplemente neutralizarlos al 100% y declarar con la conciencia tranquila: “¡Ya está, esto ya no es un problema, el riesgo se ha resuelto!”. Para mí esto es una señal de comportamiento adulto. Ésta es la diferencia entre un niño y un adulto: los niños piensan que son inmortales, que nada puede salir mal, ¡todo estará bien! Al mismo tiempo, los adultos observan cómo los niños de tres años saltan en el patio de recreo, siguen los movimientos con la vista y se dicen a sí mismos: "ooh-ooh, ooh-ooh". Me paro cerca y me preparo para atraparlo cuando el niño se caiga.

Por otro lado, la razón por la que me gusta tanto este negocio es porque es arriesgado. Hacemos cosas y esas cosas son arriesgadas. Requieren un enfoque adulto. ¡El entusiasmo por sí solo no resolverá tus problemas!

Pensamiento de ingeniería para adultos

Michael: El ejemplo con los niños es bueno. Si soy un ingeniero corriente, me complace ser un niño. Pero, ¿cómo avanzar hacia un pensamiento más adulto?

Tim: Una de las ideas que funciona igualmente bien tanto con un principiante como con un desarrollador establecido es el concepto de contexto. Qué estamos haciendo, qué vamos a conseguir. ¿Qué es realmente importante en este proyecto? No importa quién sea usted en este proyecto, si es pasante o el arquitecto jefe, todos necesitan contexto. Necesitamos lograr que todos piensen en una escala mayor que la de sus propios trabajos. “Hago mi pieza y, mientras mi pieza funcione, soy feliz”. No y no otra vez. Siempre vale la pena (¡sin ser grosero!) recordarle a la gente el contexto en el que trabajan. Lo que todos intentamos lograr juntos. Ideas de que puedes ser un niño siempre y cuando todo esté bien con tu parte del proyecto; por favor, no hagas eso. Si cruzamos la línea de meta, solo la cruzaremos juntos. No estás solo, estamos todos juntos. Si todas las personas en el proyecto, tanto jóvenes como mayores, comenzaran a hablar sobre qué es exactamente importante para el proyecto, por qué la empresa está invirtiendo dinero en lo que todos estamos tratando de lograr... la mayoría de ellos se sentirán mucho mejor porque Veremos cómo su trabajo se correlaciona con el trabajo de todos los demás. Por un lado, entiendo la pieza de la que soy personalmente responsable. Pero para terminar el trabajo necesitamos también a todas las demás personas. Y si realmente crees que ya terminaste, ¡siempre tenemos trabajo que hacer en el proyecto!

Oleg: Relativamente hablando, si trabajas de acuerdo con Kanban, cuando te encuentres con el cuello de botella de algunas pruebas, puedes dejar lo que estabas haciendo allí (por ejemplo, programar) e ir a ayudar a los evaluadores.

Tim: Exactamente. Creo que los mejores técnicos, si los miras de cerca, son como sus propios gerentes. ¿Cómo puedo formular esto...?

Oleg: Tu vida es tu proyecto, que tú gestionas.

Tim: ¡Exactamente! Quiero decir, asumes la responsabilidad, entiendes el tema y entras en contacto con la gente cuando ves que tus decisiones pueden afectar su trabajo, cosas así. No se trata simplemente de sentarse en su escritorio, hacer su trabajo y ni siquiera darse cuenta de lo que sucede a su alrededor. No no no. Por cierto, una de las mejores cosas de Agile es que propusieron sprints cortos, porque de esta manera se puede observar claramente el estado de cosas de todos los participantes, pueden verlo todos juntos. Hablamos el uno del otro todos los días.

Cómo entrar en la gestión de riesgos

Oleg: ¿Existe alguna estructura de conocimiento formal en esta área? Por ejemplo, soy desarrollador de Java y quiero entender la gestión de riesgos sin convertirme en un verdadero director de proyectos por formación. Probablemente leeré primero "¿Cuánto cuesta un proyecto de software" de McConnell y luego qué? ¿Cuáles son los primeros pasos?

Tim: La primera es comenzar a comunicarse con las personas del proyecto. Esto proporciona una mejora inmediata en la cultura de comunicación con los compañeros. Necesitamos comenzar abriendo todo de forma predeterminada, en lugar de ocultarlo. Diga: estas son las cosas que me molestan, estas son las cosas que me mantienen despierto por la noche, hoy me desperté por la noche y dije: ¡Dios mío, necesito pensar en esto! ¿Los demás ven lo mismo? Como grupo, ¿deberíamos responder a estos problemas potenciales? Debe poder apoyar una discusión sobre estos temas. No existe una fórmula preparada previamente con la que trabajemos. No se trata de hacer hamburguesas, se trata de personas. “Hacer una hamburguesa con queso, vender una hamburguesa con queso” no es lo nuestro en absoluto, y por eso amo tanto este trabajo. Me gusta cuando todo lo que antes hacían los directivos ahora pasa a ser propiedad del equipo.

Oleg: Has hablado en libros y entrevistas sobre cómo la gente se preocupa más por la felicidad que por los números en un gráfico. Por otro lado, cuando le dice al equipo: nos estamos moviendo hacia Devops y ahora el programador debe comunicarse constantemente, esto puede estar muy fuera de su zona de confort. Y en este momento puede, digamos, sentirse profundamente infeliz. ¿Qué hacer en esta situación?

Tim: No estoy seguro de qué hacer exactamente. Si un desarrollador está demasiado aislado, no ve por qué se está haciendo el trabajo en primer lugar, simplemente mira su parte del trabajo y necesita entrar en lo que yo llamo "contexto". Necesita descubrir cómo está conectado todo. Y por supuesto, no me refiero a presentaciones formales ni nada por el estilo. Me refiero al hecho de que es necesario comunicarse con los compañeros sobre el trabajo en su conjunto, y no sólo sobre la parte de la que es responsable. Aquí es donde pueden empezar a discutir ideas, acuerdos comunes para que su trabajo encaje bien y cómo abordar juntos un problema común.

Para ayudarlos a adaptarse, a menudo quieren enviar técnicos a capacitación y discuten sobre capacitación. A un amigo mío le gusta decir que el adiestramiento es para perros. Hay formación para la gente. Una de las mejores cosas de aprender como desarrollador es interactuar con sus compañeros. Si alguien es realmente bueno en algo, deberías verlo trabajar o hablar con él sobre su trabajo o algo así. Algún Kent Beck convencional hablaba constantemente de programación extrema. Es curioso porque XP es una idea muy simple, pero causa muchos problemas. Para algunos, hacer XP es como verse obligados a desnudarse delante de amigos. ¡Verán lo que estoy haciendo! ¡Son mis colegas, no sólo verán, sino que también comprenderán! ¡Horrible! Algunas personas empiezan a ponerse muy nerviosas. Pero cuando te das cuenta de que ésta es la mejor manera de aprender, todo cambia. Trabajas en estrecha colaboración con la gente y algunas entienden el tema mucho mejor que tú.

Michael: Pero todo esto te obliga a salir de tu zona de confort. Como ingeniero, debes salir de tu zona de confort y comunicarte. Como solucionador de problemas, tienes que ponerte constantemente en una posición débil y pensar en lo que podría salir mal. Este tipo de trabajo está inherentemente diseñado para ser una molestia. Te pones conscientemente en situaciones estresantes. Por lo general, la gente huye de ellos, les gusta ser niños felices.

Tim: ¿Qué se puede hacer? Puedes salir y decir abiertamente: “¡Todo está bien, puedo manejarlo! No soy el único que se siente incómodo. ¡Discutamos varias cosas incómodas, todos juntos, como equipo! Estos son nuestros problemas comunes, debemos afrontarlos, ¿sabes? Creo que los desarrolladores genios idiosincrásicos son como mamuts, desaparecieron. Y su importancia es muy limitada. Si no puedes comunicarte, no puedes participar bien. Por lo tanto, simplemente habla. Sea honesto y abierto. Lamento mucho que esto sea desagradable para alguien. ¿Te imaginas, hace muchos años hubo un estudio según el cual el principal temor en Estados Unidos no es la muerte, pero adivina qué? ¡Miedo a hablar en público! Esto significa que en algún lugar hay personas que preferirían morir antes que decir un cumplido en voz alta. Y creo que es suficiente que tengas algunas habilidades básicas, dependiendo de lo que hagas. Habilidades para hablar y escribir, pero sólo en la medida que realmente sea necesaria en su trabajo. Si trabaja como analista, pero no sabe leer, escribir ni hablar, lamentablemente no tendrá nada que hacer en mis proyectos.

El precio de la comunicación.

Oleg: ¿No resulta más caro contratar a empleados tan extrovertidos por diversas razones? Después de todo, ¡están charlando constantemente en lugar de trabajar!

Tim: Me refiero al núcleo del equipo, y no sólo a todos. Si tienes a alguien que es realmente bueno ajustando bases de datos, le encanta ajustar bases de datos y va a continuar ajustando tus bases de datos por el resto de su vida y eso es todo, genial, sigue así. Pero me refiero a personas que quieren vivir en el proyecto mismo. El núcleo del equipo, orientado al desarrollo del proyecto. Estas personas realmente necesitan comunicarse constantemente entre sí. Y especialmente al comienzo del proyecto, cuando se discuten los riesgos, las formas de lograr objetivos globales y cosas por el estilo.

Michael: Esto se aplica a todos los involucrados en el proyecto, independientemente de su especialización, habilidades o formas de trabajar. Todos estáis interesados ​​en el éxito del proyecto.

Tim: Sí, sientes que estás lo suficientemente inmerso en el proyecto, que tu tarea es ayudar a que el proyecto se haga realidad. Si eres programador, analista, diseñador de interfaces, cualquiera. Esta es la razón por la que vengo a trabajar todas las mañanas y esto es lo que hacemos. Somos responsables de todas estas personas, independientemente de sus habilidades. Este es un grupo de personas que tienen conversaciones de adultos.

Oleg: De hecho, hablando de empleados habladores, traté de simular las objeciones de las personas, especialmente de los gerentes, a quienes se les pide que cambien a Devops, ante esta visión completamente nueva del mundo. ¡Y ustedes, como consultores, deberían conocer estas objeciones mucho mejor que yo, como desarrollador! ¿Compartir qué es lo que más preocupa a los directivos?

Tim: ¿Gerentes? Mmm. La mayoría de las veces, los gerentes están bajo presión por problemas, ante la necesidad de liberar algo urgentemente y realizar una entrega, etc. Observan cómo discutimos y discutimos constantemente sobre algo, y lo ven así: conversaciones, conversaciones, conversaciones... ¿Qué otras conversaciones? ¡Volver al trabajo! Porque para ellos hablar no les parece trabajo. No escribes código, no pruebas software, parece que no haces nada. ¿Por qué no enviarte a hacer algo? ¡Después de todo, la entrega ya es en un mes!

Michael: ¡Ve a escribir un código!

Tim: Me parece que no les preocupa el trabajo, sino la falta de visibilidad del progreso. Para que parezca que nos estamos acercando al éxito, necesitan vernos presionando botones en el teclado. Todo el día desde la mañana hasta la noche. Este es el problema número uno.

Oleg: Misha, estás pensando en algo.

Michael: Lo siento, me perdí en mis pensamientos y capté un flashback. Todo esto me recordó un rally interesante que ocurrió ayer... Ayer hubo demasiados mítines... ¡Y todo me suena muy familiar!

Vida sin salario

Tim: Por cierto, no es necesario organizar "mítines" para la comunicación. Quiero decir, las discusiones más útiles entre desarrolladores ocurren cuando simplemente hablan entre ellos. Entras por la mañana con una taza de café y hay cinco personas reunidas discutiendo furiosamente algo técnico. Para mí, si soy el director de este proyecto, es mejor simplemente sonreír e ir a algún lugar a ocuparme de mis asuntos, dejar que lo discutan. Ya están involucrados tanto como sea posible. Esta es una buena señal.

Oleg: Por cierto, en tu libro tienes un montón de notas sobre lo que es bueno y lo que es malo. ¿Usas alguno de ellos tú mismo? Relativamente hablando, ahora tienes una empresa, y una que está estructurada de una manera muy poco ortodoxa...

Tim: Poco ortodoxo, pero este dispositivo nos conviene perfectamente. Nos conocemos desde hace mucho tiempo. Confiamos el uno en el otro, confiábamos mucho el uno en el otro antes de convertirnos en socios. Y, por ejemplo, no tenemos ningún salario. Simplemente trabajamos y, por ejemplo, si yo ganaba dinero con mis clientes, todo el dinero iba a parar a mí. Después de eso, pagamos cuotas de membresía a la organización, y esto es suficiente para mantener a la propia empresa. Además, todos nos especializamos en cosas diferentes. Por ejemplo, trabajo con contadores, completo declaraciones de impuestos, hago todo tipo de trámites administrativos para la empresa y nadie me paga por ello. James y Tom trabajan en nuestro sitio web y nadie les paga tampoco. Mientras pague sus cuotas, a nadie se le ocurrirá decirle lo que debe hacer. Por ejemplo, Tom ahora trabaja mucho menos que antes. Ahora tiene otros intereses; algunas cosas no las hace para el Gremio. Pero mientras pague sus cuotas, nadie se le acercará y le dirá: "¡Oye, Tom, ve a trabajar!". Es muy fácil tratar con compañeros cuando no hay dinero entre vosotros. Y ahora nuestra relación es una de las ideas fundamentales en relación con las diferentes especialidades. Funciona y funciona muy bien.

mejor consejo

Michael: Volviendo al "mejor consejo", ¿hay algo que les cuente a sus clientes una y otra vez? Existe una idea sobre 80/20 y algunos consejos probablemente se repitan con más frecuencia.

Tim: Alguna vez pensé que si escribieras un libro como Waltzing with Bears, cambiaría el curso de la historia y la gente se detendría, pero... Bueno, mira, las empresas muchas veces fingen que todo está bien para ellas. Tan pronto como sucede algo malo, es un shock y una sorpresa para ellos. “Mire, probamos el sistema y no pasa ninguna prueba del sistema, y ​​​​estos son otros tres meses de trabajo no programado, ¿cómo pudo suceder esto? ¿Quien sabe? ¿Qué puede salir mal? En serio, ¿crees esto?

Estoy tratando de explicarte que no deberías enojarte demasiado por la situación actual. Necesitamos hablarlo, comprender realmente qué pudo haber salido mal y cómo evitar que cosas así sucedan en el futuro. Si aparece un problema, ¿cómo lo combatiremos, cómo lo conteneremos?

Para mí, todo esto parece aterrador. La gente se enfrenta a problemas complejos y desconcertantes y sigue fingiendo que si simplemente cruzan los dedos y esperan lo mejor, “lo mejor” realmente sucederá. No, no funciona de esa manera.

¡Practique la gestión de riesgos!

Michael: En su opinión, ¿cuántas organizaciones participan en la gestión de riesgos?

Tim: Lo que me enfurece es que la gente simplemente anota los riesgos, mira la lista resultante y se pone a trabajar. De hecho, identificar riesgos para ellos es gestión de riesgos. Pero a mí esto me parece una razón para preguntar: está bien, hay una lista, ¿qué cambiarás exactamente? Debe cambiar sus secuencias estándar de acciones teniendo en cuenta estos riesgos. Si hay alguna parte más difícil del trabajo, es necesario abordarla y solo entonces pasar a algo más simple. En los primeros sprints, empieza a resolver problemas complejos. Esto ya parece gestión de riesgos. Pero normalmente la gente no puede decir qué cambiaron después de compilar una lista de riesgos.

Michael: Y, sin embargo, ¿cuántas de estas empresas participan en la gestión de riesgos, el cinco por ciento?

Tim: Desafortunadamente, odio decir esto, pero es una parte muy insignificante. Pero más de cinco, porque hay proyectos realmente grandes y simplemente no pueden existir si no hacen al menos algo. Digamos que me sorprendería mucho que fuera al menos el 25%. Los proyectos pequeños suelen responder a estas preguntas de esta manera: si el problema nos afecta, lo solucionaremos. Luego se meten exitosamente en problemas y se involucran en la gestión de problemas y crisis. Cuando se intenta solucionar un problema y el problema no se soluciona, bienvenido a la gestión de crisis.

Sí, escucho a menudo: "resolveremos los problemas a medida que surjan". ¿Seguramente lo haremos? ¿Realmente decidiremos?

Oleg: Puede hacerlo de manera ingenua y simplemente escribir invariantes importantes en el estatuto del proyecto y, si las invariantes fallan, simplemente reinicie el proyecto. Resulta muy piembucky.

Michael: Sí, me pasó que cuando se desencadenaron riesgos simplemente se redefinió el proyecto. Bien, bingo, problema resuelto, ¡no te preocupes más!

Tim: ¡Presionemos el botón de reinicio! No, no funciona de esa manera.

Conferencia magistral en DevOops 2019

Michael: Llegamos a la última pregunta de esta entrevista. Vienes al próximo DevOops con una keynote, ¿podrías levantar el telón del secretismo sobre lo que vas a contar?

Tim: En este momento, seis de ellos están escribiendo un libro sobre la cultura laboral, las reglas tácitas de las organizaciones. La cultura está determinada por los valores fundamentales de la organización. Normalmente la gente no se da cuenta de esto, pero después de haber trabajado en consultoría durante muchos años, estamos acostumbrados a notarlo. Entras en una empresa y, literalmente, a los pocos minutos empiezas a sentir lo que está pasando. A esto lo llamamos "sabor". A veces este aroma es realmente bueno y otras veces es, bueno, ¡ups! Las cosas son muy diferentes para diferentes organizaciones.

Michael: Yo también llevo años trabajando en consultoría y entiendo bien de qué estás hablando.

Tim: Realmente, una de las cosas de las que vale la pena hablar en la keynote es que no todo lo determina la empresa. Usted y su equipo, como comunidad, tienen su propia cultura de equipo. Podría ser toda la empresa, o un departamento separado, un equipo separado. Pero antes de que dijeras, esto es lo que creemos, esto es lo importante... No se puede cambiar una cultura antes de que se comprendan los valores y creencias detrás de acciones específicas. El comportamiento es fácil de observar, pero buscar creencias es difícil. DevOps es sólo un gran ejemplo de cómo las cosas se vuelven cada vez más complejas. Las interacciones solo se vuelven más complejas, no se vuelven más limpias ni más claras en absoluto, por lo que debes pensar en lo que crees y sobre lo que todos los que te rodean guardan silencio.

Si quieres conseguir resultados rápidos, aquí tienes un buen tema: ¿has visto empresas en las que nadie dice “no sé”? Hay lugares donde literalmente torturas a una persona hasta que admite que no sabe algo. Todo el mundo lo sabe todo, todo el mundo es un erudito increíble. Te acercas a cualquier persona y él tiene que responder instantáneamente a la pregunta. En lugar de decir "No lo sé". ¡Hurra, contrataron a un grupo de eruditos! Y en algunas culturas generalmente es muy peligroso decir “no sé”; puede percibirse como un signo de debilidad. También hay organizaciones en las que, por el contrario, todo el mundo puede decir “no lo sé”. Allí es completamente legal, y si alguien se pone a hacer tonterías ante una pregunta, es completamente normal que responda: “No sabes de lo que estás hablando, ¿verdad?”. y convertirlo todo en una broma.

Idealmente, le gustaría tener un trabajo en el que pueda ser constantemente feliz. No será fácil, no todos los días son soleados y agradables, a veces hay que trabajar duro, pero cuando empiezas a hacer balance, resultará: guau, este es un lugar realmente maravilloso, me siento bien trabajando aquí. tanto emocional como intelectualmente. Y hay empresas a las que vas como consultor y al instante te das cuenta de que no podrías soportarlo durante tres meses y huirías horrorizado. De esto es de lo que quiero hablar en el informe.

Tim Lister llegará con una keynote "Personajes, comunidad y cultura: factores importantes para la prosperidad"a la conferencia DevOops 2019, que tendrá lugar del 29 al 30 de octubre de 2019 en San Petersburgo. puedes comprar entradas en el sitio web oficial. ¡Te esperamos en DevOops!

Fuente: habr.com