Tim Lister - Coautor de libros

• “El factor humano. Proyectos y equipos exitosos "(el libro original se llama" Peopleware ")
• "Waltzing with the Bears: Gestión de riesgos en proyectos de desarrollo de software"
• "Increíble con adrenalina y patrones de zombies. Patrones de comportamiento del equipo del proyecto

Todos estos libros son clásicos en su campo y están escritos con colegas de Atlantic Systems Guild . En Rusia, sus colegas son los más famosos: Tom Demarco y Peter Khrushchka , quienes también escribieron muchas obras famosas.

Tim tiene 40 años de experiencia en desarrollo de software, en 1975 (nadie que escribió este hubrast nació este año), Tim ya era vicepresidente ejecutivo de Yourdon Inc. Ahora se dedica a la consultoría, capacitación y redacción, de vez en cuando asiste a conferencias en todo el mundo con informes .

Especialmente para Habr, hicimos una entrevista con Tim Lister. Abrirá la conferencia DevOops 2019, y hemos acumulado muchas preguntas, sobre libros y más. Las entrevistas son realizadas por Mikhail Druzhinin y Oleg Chirukhin del comité del programa de la conferencia.

Michael: ¿Podría decir algunas palabras sobre lo que está haciendo ahora?

Tim: Soy el jefe de Atlantic Systems Guild. Somos seis en el Gremio, nos llamamos directores. Tres en los Estados Unidos y tres en Europa, por eso el Gremio se llama el Atlántico. Hemos estado juntos durante tantos años que simplemente no contarás. Todos tenemos nuestras propias especialidades. La última década, o incluso más, he estado trabajando con clientes. Mis proyectos incluyen no solo la gestión, sino también el establecimiento de requisitos, planificación de proyectos y evaluación. Parece que los proyectos que comienzan mal generalmente terminan mal. Por lo tanto, debe asegurarse de que todas las actividades estén realmente bien pensadas y de que las ideas de los creadores estén combinadas. Vale la pena considerar lo que está haciendo y por qué. Qué estrategias utilizar para completar el proyecto.

Durante muchos años he estado asesorando a clientes en una variedad de formas. Un ejemplo interesante es una empresa que fabrica robots para cirugía en las articulaciones de la rodilla y la cadera. El cirujano no opera de manera completamente independiente, sino que usa un robot. La seguridad aquí, francamente, es importante. Pero cuando intentas discutir los requisitos con personas que están enfocadas en resolver problemas ... Suena extraño, pero en los EE. UU. Está la FDA ( Administración Federal de Drogas), que autoriza productos como estos robots. Antes de vender y usar algo en personas vivas, debe 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 la prueba. Si cambia los requisitos, debe volver a realizar este enorme proceso de prueba una y otra vez. Nuestros clientes lograron incluir el diseño visual de las aplicaciones en sus requisitos. Tomaron 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 las rodillas y las caderas, todas estas cosas con la cámara, etc. Necesitamos reescribir los documentos con los requisitos para que nunca cambien, a menos que cambien algunas condiciones fundamentales realmente importantes. Si no hay un diseño visual en los requisitos, la actualización del producto será mucho más rápida. Nuestro trabajo es encontrar aquellos elementos que se ocupen de operaciones en la rodilla, caderas, espalda, extraerlos en documentos separados y decir que serán requisitos fundamentales. Hagamos un grupo aislado de requisitos sobre cirugía de rodilla. Esto generará un conjunto de requisitos más robusto. Hablaremos de toda la línea de productos y no de instancias específicas de robots.

Se hizo mucho trabajo, pero sin embargo llegaron a los lugares donde anteriormente habían pasado semanas y meses de pruebas repetidas sin significado ni necesidad, porque sus requisitos, descritos en papel, no coincidían con los requisitos reales sobre los que se construyeron los sistemas. Cada vez que la FDA les dijo: sus requisitos han cambiado, ahora debe verificar todo desde cero. Las verificaciones cruzadas completas de todo el producto mataron a la empresa.

Por lo tanto, hay tareas tan maravillosas cuando te encuentras al comienzo de algo interesante, y las primeras acciones establecen nuevas reglas del juego. Si lo hace tanto desde el punto de vista administrativo como técnico, esta actividad inicial comenzará a funcionar bien, existe la posibilidad de que la salida obtenga un excelente proyecto. Pero si esta parte se salió del camino y salió mal en algún lugar, si no puede encontrar el acuerdo fundamental ... no, no es que su proyecto necesariamente falle. Pero no podrá decir: "Estamos bien hechos, hemos hecho todo de manera muy efectiva". Estas son las cosas que hago, comunicarme con los clientes.

Michael: Es decir, ¿lanza proyectos, hace algún tipo de inicio y verifica que los rieles conduzcan en la dirección correcta?

Tim: También tenemos ideas sobre cómo armar todas las piezas del mosaico: qué habilidades necesitamos, cuándo se necesitan exactamente, cómo se ve el núcleo del equipo y otras cosas fundamentales. ¿Necesitamos empleados a tiempo completo o podemos reclutar 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á lo desconocido, cómo vamos a lidiar con todo esto? Por supuesto, alguien en este momento comienza a gritar "¿Pero qué hay de ágil?". Bueno, todos ustedes son flexibles, pero ¿y qué? ¿Cómo se ve exactamente el proyecto, cómo lo va a sacar para que se ajuste al proyecto? No se puede decir simplemente que "nuestro enfoque es impulsado por cualquier cosa, ¡somos un equipo scrum!" Esto es una tontería y una tontería. ¿A dónde vas a ir después? ¿Por qué debería ganar? ¿Dónde está el punto? Enseño a mis clientes a reflexionar sobre todos estos temas.

19 años de ajail

Michael: En Ajail, la gente a menudo trata de no determinar nada por adelantado, pero toma decisiones lo más tarde posible, diciendo: somos demasiado grandes, no pensaré en la arquitectura general. No pensaré en muchas otras cosas, en cambio, en este momento le proporcionaré al cliente algo que funcione.

Tim: Creo que las metodologías ágiles, comenzando con el Manifiesto Ágil en 2001, han abierto los ojos de la industria. Pero, por otro lado, nada es perfecto. Estoy completamente del lado del desarrollo iterativo. Las iteraciones tienen mucho sentido en la mayoría de los proyectos. Pero debe pensar en la pregunta: después de que el producto salió y comenzó a usarse, ¿cuánto tiempo dura? ¿Es este un producto que durará seis meses y luego será reemplazado por otro? ¿O es un producto que funcionará por muchos, muchos años? Por supuesto, no nombraré nombres, pero ... En Nueva York y su comunidad de financieros, los sistemas más fundamentales son muy antiguos. Es asombroso. Los miras y piensas que retrocederías en el tiempo, en 1994, y les dirías a los desarrolladores: “Vine del futuro, de 2019. Simplemente diseñe este sistema tanto como lo necesite. Hazlo extensible, piensa en la arquitectura. Luego se mejorará durante más de veinticinco años. Si retrasa el desarrollo un poco más, ¡nadie lo notará en una escala de historia! Cuando evalúa las cosas a largo plazo, debe considerar cuánto costará en su totalidad. A veces, una arquitectura bien diseñada realmente vale la pena, y otras no. Debe mirar a su alrededor y hacerse la pregunta: ¿estamos en una situación adecuada para tal solución?

Entonces, una idea como "Somos ágiles, el cliente mismo nos dirá lo que quiere recibir", es sobrenatural. Después de todo, los clientes ni siquiera saben lo que quieren, y más aún, no saben qué podrían obtener. Algunos comenzarán a citar ejemplos históricos como argumentos, ya lo he visto. Pero las personas técnicamente avanzadas no suelen decir eso. Dicen: "¡Ahora es el año 2019, tenemos tales oportunidades y podemos cambiar completamente nuestra visión de tales cosas!" En lugar de imitar las soluciones existentes, haciéndolas un poco más bellas y peinadas, a veces hay que salir y decir: "¡Reinventemos por completo lo que estamos tratando de hacer aquí!"

Y no creo que la mayoría de los clientes puedan pensar en un problema de esta manera. Solo ven lo que ya tienen, y eso es todo. Luego vienen con solicitudes como "hagámoslo un poco más fácil" o lo que sea que usualmente digan. Pero no somos meseros ni meseras para tomar un pedido sin importar lo estúpido que resulte, y luego hornearlo en la cocina. Somos sus guías Debemos abrir los ojos y decir: ¡hey, aquí tenemos nuevas oportunidades! ¿Te das cuenta de que realmente podemos cambiar cómo se hace esta parte de tu negocio? Uno de los problemas de adjayl es que se aleja de 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 en particular.

Quizás fui demasiado lejos con escepticismo: 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 comienza a encogerse de hombros. Preguntaría aquí: ¿qué estamos haciendo, cómo vamos a hacer esto? Y de alguna manera mágica siempre resulta que este cliente debe saber lo mejor de todo. Pero el cliente sabe lo mejor de todo solo cuando elige cosas ya construidas por alguien. Si quiero comprar un automóvil y sé el tamaño del presupuesto familiar, rápidamente recogeré un automóvil que se adapte a mi estilo de vida. ¡Aquí sé todo mejor que nadie! Pero, por favor, observe que alguien ya ha hecho la máquina. Cómo inventar un auto nuevo, no tengo idea, no soy un experto. Cuando creamos productos personalizados o algunos productos especiales, se debe tener en cuenta la voz del cliente, pero esta no es la única voz.

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

Tim: No lo tocaría. Creo que este es un gran documento histórico. Quiero decir, él es lo que es. Tiene 19 años, es viejo, pero en un momento hizo una revolución. Lo que hizo bien fue lanzar una reacción, comenzaron a susurrar sobre él. Lo más probable es que no trabajó en la industria en 2001, pero luego trabajó en procesos. Instituto de Ingeniería de Software, Cinco niveles del modelo de potencial de integridad de software (CMMI). No sé si esas leyendas de la antigüedad te dicen algo profundo, pero fue un gran avance. Al principio, la gente creía que si los procesos se construían correctamente, los problemas mismos se evaporarían. Y luego aparece el Manifiesto y dice: "No, no, no, nos basaremos en las personas, no en los procesos". Somos maestros en el desarrollo de software. Entendemos que el proceso ideal es un espejismo, no es así. Hay demasiada idiosincrasia en los proyectos; la idea de un proceso único e impecable para todos los proyectos no tiene sentido. Los problemas son demasiado complejos para afirmar que se ha encontrado una única solución para todo (hola, nirvana).

No pretendo mirar hacia el futuro, pero diré que la gente ahora ha comenzado a pensar más en los proyectos. Creo que el Manifiesto Ágil es muy bueno, salta hacia adelante y dice: “¡Hola! Estás en un barco y tú mismo lideras este barco. Deberá tomar una decisión: no solicitaremos una receta universal para todas las situaciones. Eres la tripulación del barco, y si eres lo suficientemente bueno, puedes encontrar el camino hacia la meta. Había otras naves antes que tú, y otras naves te perseguirán, pero sin embargo, en cierto sentido, tu viaje es único ”. Algo asi! Esta es una forma de pensar. Para mí, nada es nuevo bajo la luna, la gente ha navegado antes y volverá a nadar, pero para usted este es su viaje principal, y no le diré exactamente qué le sucederá. Debes tener las habilidades de trabajo en equipo coordinado, y si realmente lo son, todo saldrá bien y vendrás donde quieras.

Peopleware: 30 años después

Oleg: ¿ Peopleware también fue una revolución, como el Manifiesto?

Tim: Peopleware ... Tom y yo escribimos este libro, pero no pensamos que todo sucedería. De alguna manera, resonó con las ideas de muchas personas. Este fue el primer libro que dijo: 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 tales cosas solo, ¿verdad? Entonces, la idea de un "equipo" se ha vuelto muy importante. Y no solo desde el punto de vista de la administración, sino también para las personas de un almacén técnico que se unieron para resolver problemas profundos realmente complejos con un montón de incógnitas. Para mí personalmente, a lo largo de mi carrera, esta ha sido una gran prueba de inteligencia. Y aquí debe poder decir: sí, este problema es más de lo que puedo manejarlo yo mismo, pero juntos podemos encontrar una solución elegante de la que podemos estar orgullosos. Y creo que esta idea en particular resonó más. La idea es que trabajemos parte del tiempo por nuestra cuenta, parte del grupo y, a menudo, la decisión la toma el grupo. La resolución de problemas grupales se convirtió rápidamente en una característica importante de los proyectos complejos.

A pesar de que Tim tenía una gran cantidad de informes, hay muy pocos de ellos publicados en YouTube. Puede ver el informe de 2007 The Return of Peopleware. La calidad, por supuesto, deja mucho que desear.

Michael: ¿Ha cambiado algo en los últimos 30 años desde el lanzamiento del libro?

Tim: Puedes mirarlo desde muchos ángulos diferentes. Hablando sociológicamente ... una vez, en tiempos más simples, usted y el equipo estaban en la misma oficina. Podrían estar allí todos los días, tomar café juntos y hablar sobre el trabajo. Lo que realmente cambió es que ahora los equipos se pueden distribuir geográficamente, en diferentes países y zonas horarias, pero sin embargo están trabajando en la misma tarea, y esto agrega una capa completamente nueva de complejidad. Puede sonar pasado de moda, pero no hay nada mejor que la comunicación cara a cara, cuando todos se unen, trabajan juntos, puede ir a un colega y decirle: mira, ¿descubrí cómo te sientes al respecto? Las conversaciones cara a cara brindan una forma rápida de avanzar hacia la comunicación informal, y creo que esto también debería atraer a los amantes de la música. Y estoy preocupado porque en realidad el mundo resultó ser muy pequeño, y ahora todo está cubierto por equipos distribuidos, y todo esto es muy complicado.

Todos vivimos en DevOps

Michael: Incluso desde el punto de vista del comité del programa de la conferencia, tenemos personas en California, en Nueva York, Europa, Rusia ... en Singapur todavía no hay nadie. La diferencia en geografía es bastante grande, y las personas comienzan a distribuirse aún más. Si ya estamos hablando de desarrollo, ¿puede contarnos más sobre devops y la destrucción de obstáculos entre equipos? Existe el concepto de que todos están sentados en sus bunkers, y ahora los bunkers se están desmoronando, ¿qué le parece esta analogía?

Tim: Me parece que, a la luz de los recientes avances tecnológicos, devops es de gran importancia. Anteriormente, tenías equipos de desarrolladores y administradores, trabajaban, trabajaban, trabajaban y, en algún momento, apareció algo con lo que podías acudir a los administradores y extenderlo a la producción. Y aquí comenzó la conversación sobre el búnker, porque los administradores son como aliados, no enemigos, al menos, pero solo hablaste con ellos cuando todo estaba listo para salir a la venta. Usted fue a ellos con algo y les dijo: miren, ¿cuál es nuestra aplicación, pero podrían implementarla? Y ahora todo el concepto de entrega ha cambiado para mejor. Quiero decir, surgió la idea de que puedes impulsar el cambio rápidamente. Podemos actualizar productos sobre la marcha. Siempre sonrío cuando aparece un Firefox en mi computadora portátil y dice: hey, hemos actualizado su Firefox en segundo plano, y tan pronto como tenga un minuto, ¿podría hacer clic aquí y le daremos un nuevo lanzamiento? Y yo estoy como: "¡Oh sí, bebé!" Mientras dormía, justo en mi computadora, estaban trabajando para proporcionarme un nuevo lanzamiento. Esto es maravilloso, increíble.

Pero aquí está la dificultad: tiene esta característica con actualizaciones de software, pero integrar a las personas es mucho más difícil. Lo que quiero decir en la conferencia magistral de DevOops es que ahora tenemos muchos más jugadores que nunca. Si solo piensa en todos los que participan en el trabajo de un solo equipo ... Lo pensaste como un equipo, y es mucho más que un equipo de programadores. Estos son evaluadores, gerentes de proyectos y muchas otras personas. Y todos tienen sus propios puntos de vista sobre el mundo. Los gerentes de producto son completamente diferentes de los gerentes de proyecto. Los administradores tienen sus propias tareas. Se convierte en un problema bastante difícil coordinar a todos los participantes, para seguir siendo conscientes de lo que está sucediendo y no salir de las bobinas. Es necesario separar las tareas del grupo y las tareas relacionadas con todos. Esta es una tarea muy difícil. Por otro lado, creo que todo esto ha mejorado mucho más que hace muchos años. Este es exactamente el camino en el que las personas crecen y aprenden a comportarse correctamente. Cuando participa en la integración, comprende que no debe haber desarrollo clandestino, por lo que en el último momento el software no sale de la caja: ¡mire lo que hicimos aquí! La idea es que puede hacer integración y desarrollo, y al final lo implementará de manera ordenada e iterativa. Todo esto es de gran importancia para mí. Esto permite crear más valor para los usuarios del sistema y para su cliente.

Michael: La idea de Devopse es entregar un trabajo significativo lo antes posible. Veo que el mundo comenzó a acelerarse más y más. ¿Cómo adaptarse a tales aceleraciones? ¡Hace diez años, esto no era!

Tim: Por supuesto, todos quieren cada vez más funcionalidades. No es necesario moverse, solo acumula más. A veces, incluso tiene que reducir la velocidad para que la próxima actualización incremental traiga al menos algo útil, y esto es completamente normal.

La idea de que necesitas ejecutar-ejecutar-ejecutar no es la mejor. Casi nadie quiere vivir de esta manera. Me gustaría que el ritmo de las entregas establezca el propio ritmo del proyecto. Si solo produce una corriente de cosas pequeñas y relativamente sin sentido, todo esto en total no tiene sentido. En lugar de tratar de liberar las cosas lo antes posible, lo que vale la pena discutir con los principales desarrolladores y gerentes de productos y proyectos es la estrategia. ¿Esto tiene sentido?

Patrones y antipatrones

Oleg: Usualmente hablas 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 pueden matar el proyecto en el acto?

Tim: Patrones y antipatrones ocurren todo el tiempo. De que hablar. Bueno, hay una cosa que llamamos "cosas brillantes". A la gente realmente le gustan las nuevas tecnologías. Simplemente están hechizados por la brillantez de todo lo que se ve genial y elegante, y dejan de hacer preguntas: ¿es incluso necesario? ¿Qué vamos a lograr? ¿Es esto confiable? ¿Tiene algún sentido? A menudo veo personas, digamos, a la vanguardia de la tecnología. Están hipnotizados por lo que está sucediendo en el mundo. Pero si observa de cerca, qué bien hacen, a menudo, ¡simplemente no hay nada útil!

, – , , . 1969. , – 1969 , 1960 62, NASA , . – , ! -, , , . : «, , , , !». - … , . , , , , , . , : « !».

: , ?

: , ! … , , -. ! , , , – . , , ? ! . , . , , … – . : . , .

: , « , »: ?

: . - . – - , , ? , – . , , - : « ! !». Enserio? .

«-»

: . - , «-» . : , , «-», ? , – , - .

: -. - . - , . , , , ! , , «-», , , ? – . , «» — , ? . - , , , . , ?

, , , , – . , - , - – . , DevOps, , - . , , , . « », « » , , – «».

- , , . , , . – , « ». ? , , . - , , , , , . , - , , , , . ! - .

- -. , , ? , , ? - : --, , , , , .

, , . , . , , : , . , . , . .

. – , , , , , , ! - . – …

« »

: ? , , , – « ».

: ! – , - . - , ( , ). – , – , - , .

, . , « - , ». , -, , . , , . , , , , , . , , , – , . , . , .

: , . , , . , . , – , – . , , , .

: Move fast and break things!

: , , , – -. , ?

: : . . , - , . , , - , « », , : « ». , . , , . – .

, . , , , - . - , , . , – , , , , . , , , . .

, , . , – , . , , , , , ? ? , ? , : , . , , , - . : , .

, . , : , , - , . , , . , , , .

, ? , . , . 100%, : «, , !». . – , , , ! , , , : « – , – ». , - .

, , – . , . . !

: . , . ?

: , , – . , . - ? , , , , . , , . « , – ». . ( !) , . . , , – , . , . , . , , , , , , … , , . , , . . , , , !

: , , - , (, ) .

Tim: bien. Creo que los mejores técnicos, si los miras de cerca, son como gerentes en sí mismos. Cómo formularlo ...

Oleg: Tu vida es tu proyecto que administras.

Tim: bien! Quiero decir, asumiste la responsabilidad, entiendes el problema y entras en contacto con las personas cuando ves que tus decisiones pueden afectar su trabajo, todo con ese espíritu. No se trata solo de sentarse a la mesa, hacer su trabajo, y ni siquiera saber lo que está sucediendo a su alrededor. No no no Por cierto, una de las mejores cosas de Agile es que sugirieron carreras cortas, ya que el estado de cosas de todos los participantes está bien observado, pueden verlo todos juntos. Todos los días hablamos el uno del otro.

Cómo ingresar a la gestión de riesgos

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

Tim: Lo primero es comenzar a comunicarse con las personas en el proyecto. Esto proporciona una mejora instantánea en la cultura de comunicación con colegas. Debe 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 así: ¡dioses, esto debe ser considerado! ¿Los demás ven lo mismo? Como grupo, ¿debemos responder a estos problemas potenciales? Debe poder mantener una discusión sobre estos temas. No existe una fórmula preparada por la cual trabajamos. Esta no es la producción de hamburguesas, se trata de personas. "Hice una hamburguesa con queso - venda una hamburguesa con queso" - esto no se trata de nosotros en absoluto, y es por eso que amo tanto este trabajo. Me gusta cuando todo lo que los gerentes hicieron antes, ahora se convierte en propiedad del equipo.

Oleg: Usted dijo en libros y entrevistas que las personas están más preocupadas por la felicidad que por los números en el gráfico. Por otro lado, cuando le dices al equipo: cambiamos a devops, y ahora el programador debe comunicarse constantemente, esto puede estar mucho más allá de su zona de confort. Y en este momento, él puede, digamos así, ser profundamente infeliz. ¿Qué hacer en esta situación?

Tim: No estoy seguro de qué hacer exactamente. Si el desarrollador está demasiado aislado, no ve por qué se hace el trabajo, simplemente mira su parte del trabajo y necesita profundizar en lo que yo llamo el "contexto". Necesita descubrir cómo todo está interconectado. Y, por supuesto, no me refiero a la presentación formal o algo así. Le digo que debe comunicarse con sus colegas sobre el trabajo en su conjunto, y no solo sobre la parte de la que es responsable. Y en este momento, puede comenzar a discutir ideas, acuerdos generales, para que su trabajo vaya bien y cómo apoyarse en un problema común.

Para adaptarse, los técnicos a menudo también quieren enviarlos a entrenamientos, discutir entrenamientos. A un amigo mío le gusta decir que el entrenamiento es para perros. Hay entrenamiento para personas. Una de las mejores cosas para enseñar a un desarrollador es comunicarse con sus colegas. Si alguien realmente tuvo éxito en algo, debería ver cómo funciona, o discutir con él el trabajo, o algo así. Algunos condicional Kent Beck hablaban constantemente sobre programación extrema. Es divertido, porque XP es una idea muy simple, pero causa muchos problemas. Para alguien, hacer XP es como estar obligado a desnudarse delante de amigos. ¡Verán lo que estoy haciendo! ¡Son mis colegas, no solo verán, sino que también entenderán! Horrible Alguien está empezando a ponerse seriamente nervioso. Pero cuando te das cuenta de que esta es la mejor manera de aprender, todo cambia. Trabajas estrechamente con las personas, y algunas personas entienden el tema mucho mejor que tú.

Michael: Pero todo esto te hace abandonar tu zona de confort. Como ingeniero, debe salir de su zona de confort, comunicarse. Como persona que resuelve problemas, debe ponerse constantemente en una posición débil y considerar qué puede salir mal. Tal trabajo está diseñado inherentemente para ser inconveniente. Conscientemente te pones en situaciones estresantes. Por lo general, las personas huyen de ellos, a las personas les gusta ser niños felices.

Tim: ¿Qué se puede hacer? Puedes salir y decir abiertamente: “¡Todo está en orden, puedo manejarlo! No estoy solo en la incomodidad. ¡Discutamos varias cosas incómodas, todos juntos, como un equipo! ” Estos son nuestros problemas comunes, debemos lidiar con ellos, ¿entiendes? Creo que los desarrolladores brillantes idiosincrásicos son como mamuts, desaparecieron. Sí, y tienen un valor muy limitado. Si no puede comunicarse, no puede participar normalmente. Por lo tanto, solo dilo. Se honesto y abierto. Lamento mucho que alguien sea desagradable. Imagínese, hace muchos años hubo un estudio según el cual el principal temor en los EE. UU. No es la muerte, pero ¿adivina qué? ¡Miedo a hablar en público! Entonces, en algún lugar hay personas que tienen más probabilidades de morir que decir un cumplido en voz alta. Y tú, creo, solo tienes algunas habilidades básicas, dependiendo de lo que hagas. Habilidades de conversación, habilidades de escritura, pero tanto como sea realmente necesario en su trabajo. Si trabajas como analista, pero no sabes leer, escribir y hablar, ¡lamentablemente no tendrás nada que hacer en mis proyectos!

Precio de la comunicación

Oleg: ¿El uso de tales empleados salientes es más costoso por varias razones? ¡Al final, hablan constantemente en lugar de trabajar!

Tim: Tenía en mente el núcleo del equipo, y no todos seguidos. Si tiene un especialista que realmente configura sus bases de datos, le encanta configurar sus bases de datos y continuará configurando sus bases de datos por el resto de su vida, y eso es genial, continúe así. Pero estoy hablando de personas que quieren vivir en el proyecto en sí. El núcleo del equipo, destinado a desarrollar el 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 similares.

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

Tim: Sí, siente que está profundamente inmerso en el proyecto, que su tarea es ayudarlo a hacerse realidad. Sé un 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: En realidad, hablando de empleados habladores, traté de simular las objeciones de las personas, en particular, los gerentes a quienes se les ofrece cambiar a devops, a esta nueva visión del mundo. ¡Y para ustedes, como consultores, estas objeciones deberían conocerse mucho mejor que para mí como desarrollador! ¿Compartir lo que más les importa a los gerentes?

Tim: ¿Gerentes? Hm. Muy a menudo, los gerentes están bajo la presión de los problemas, ante la necesidad de liberar algo urgentemente y hacer una entrega y cosas por el estilo. Nos observan discutir y discutir constantemente, y lo ven así: conversaciones, conversaciones, conversaciones ... ¿Qué otras conversaciones? ¡Vuelve al trabajo! Porque las conversaciones no les parecen trabajo. No escribe código, no prueba el software, aparentemente no hace nada, ¿por qué no lo envía a hacer negocios? Después de todo, ¡la entrega ya está en un mes!

Michael: ¡ Ve a escribir el código!

Tim: Me parece que no les preocupa el trabajo, sino la falta de visibilidad para avanzar. Para que piensen que nos estamos acercando al éxito, necesitan ver cómo presionamos los botones del teclado. Todo el día desde la mañana hasta la tarde. Este es el problema número uno.

Oleg: Misha, has pensado algo.

Michael: Lo siento, pensé, capté un flashback. Todo esto me recordó una manifestación interesante que tuvo lugar ayer ... Ayer hubo demasiadas manifestaciones ... ¡Y todo esto suena muy familiar!

Vida sin sueldos

Tim: Por cierto, no es necesario organizar "reuniones" para la comunicación. Quiero decir, las discusiones más útiles entre los desarrolladores ocurren cuando solo hablan entre sí. Entras por la mañana con una taza de café, y allí los cinco nos reunimos y discutimos algo técnico ferozmente. Para mí, si soy el gerente de este proyecto, es mejor sonreír e ir a algún lugar sobre su negocio, dejar que discutan. Ya están involucrados tanto como sea posible. Esta es una buena señal.

Oleg: Por cierto, aquí tienes un montón de notas en tu libro sobre lo que es bueno y lo que es malo. ¿Usas alguno de ellos tú mismo? Relativamente hablando, aquí tienes una compañía ahora, e incluso una estructura muy poco ortodoxa ...

Tim: Poco ortodoxo, pero ese dispositivo es genial para nosotros. Nos conocemos desde hace mucho tiempo. Confiamos el uno en el otro, confiamos el uno en el otro mucho antes de convertirnos en socios. Y, por ejemplo, no tenemos ningún salario en absoluto. Simplemente trabajamos y, por ejemplo, si gané dinero de mis clientes, entonces todo el dinero se fue a mí. Después de eso, pagamos las cuotas de membresía a la organización, y esto es suficiente para mantener la propia empresa. Además, todos nos especializamos en diferentes cosas. Por ejemplo, trabajo con contadores, lleno declaraciones de impuestos, hago todo tipo de tareas administrativas para la empresa y nadie me paga por esto. James y Tom trabajan en nuestro sitio y nadie les paga tampoco. Mientras pague sus cuotas, nadie pensará en decirle lo que necesita hacer. Por ejemplo, Tom ahora trabaja mucho menos que antes. Ahora tiene otros intereses, algo que no hace por el Gremio. Pero mientras pague sus deudas, nadie se le acercará y le dirá: "¡Oye Tom, ven y trabaja!" Es muy fácil tratar con colegas cuando no hay dinero entre ustedes. Y ahora nuestra relación es una de las ideas fundamentales, aplicada a diferentes especialidades. Funciona y funciona muy bien.

Mejor consejo

Michael: Volviendo al "mejor consejo", ¿hay algo que repites a tus clientes una y otra vez? Existe una idea sobre 80/20, y seguramente algunos consejos se repiten con más frecuencia.

Tim: Una vez pensé que si escribías un libro como "Waltzing with the Bears", cambiará el curso de la historia y la gente se detendrá, pero ... Bueno, mira, a menudo las compañías fingen que les está yendo bien. Tan pronto como sucedió algo malo, fue un shock y una sorpresa para ellos. “Mira, probamos el sistema, y ​​no pasa ninguna prueba del sistema, y ​​estos son otros tres meses de trabajo extraordinario, ¿cómo podría suceder esto? Quien sabia ¿Qué pudo haber salido mal? En serio, ¿crees eso?

Estoy tratando de explicarte que no deberías enojarte demasiado con la situación actual. Necesita discutirlo, para comprender realmente lo que podría haber salido mal y cómo prevenir tales cosas en el futuro. Sin embargo, si el problema se manifiesta, cómo lo combatiremos, cómo contenerlo.

Para mí, todo parece aterrador. Las personas lidian con problemas complejos y desagradables, y continúan fingiendo que si simplemente cruzan los dedos y esperan lo mejor, esto realmente “mejor” realmente sucederá. No, eso no funciona.

¡Participe en la gestión de riesgos!

Michael: En tu opinión, ¿cuántas organizaciones están involucradas 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 va a trabajar. De hecho, identificar los riesgos para ellos es la gestión de riesgos. Pero para mí esto parece una razón para la pregunta: bueno, hay una lista, ¿qué cambiarás exactamente? Debe cambiar su secuencia estándar de acciones teniendo en cuenta estos riesgos. Si hay alguna parte más difícil del trabajo, debe hacerlo, y solo luego pasar a la más simple. En los primeros sprints, comienza a resolver problemas complejos. Ahora esto es similar a la gestión de riesgos. Pero, por lo general, las personas no pueden decir qué cambiaron después de compilar una lista de riesgos.

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

Tim: Desafortunadamente, es desagradable para mí decir esto, pero esta es una parte muy insignificante. Pero más de cinco, porque hay proyectos realmente grandes, y simplemente no pueden existir a menos que hagan al menos algo. Digamos que estaría muy sorprendido si es al menos el 25%. Los proyectos pequeños generalmente responden a estas preguntas de esta manera: si el problema nos toca, lo resolveremos. Luego se sumergen con éxito en el problema y se dedican a la gestión de problemas y la gestión de crisis. Cuando intenta resolver un problema, pero el problema no está resuelto, bienvenido a la gestión de crisis.

Sí, a menudo escucho, "resolveremos los problemas a medida que estén disponibles". ¿Estaremos en lo cierto? ¿Decidiremos exactamente?

Oleg: Puedes hacerlo ingenuamente y simplemente escribir invariantes importantes en el acta constitutiva del proyecto, y si los invariantes se descomponen, simplemente reinicia el proyecto. Resulta de una manera muy pembucco.

Mikhail: Sí, me ocurrió que cuando los riesgos funcionaban, el proyecto simplemente se redefinía. Bien, bingo, el problema está resuelto, ¡no más preocupaciones!

Tim: ¡ Presiona el botón de reinicio! No, eso no funciona.

Keynote en DevOops 2019

Michael: Llegamos a la última pregunta de esta entrevista. Llegarás al próximo DevOops con una nota clave, ¿podrías abrir el velo del secreto 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á establecida por los valores centrales de la organización. Por lo general, las personas no se dan cuenta de esto, pero nosotros, trabajando en consultoría durante muchos años, estamos acostumbrados a notarlo. Entras en la empresa y solo unos minutos más tarde comienzas a sentir lo que está sucediendo. Lo llamamos "aroma". Algunas veces este aroma es realmente bueno, y otras veces, bueno, vaya. Las diferentes organizaciones tienen cosas muy diferentes.

Michael: También he estado trabajando en consultoría durante años y entiendo bien de qué estás hablando.

Tim: En realidad, una de las cosas de las que vale la pena hablar en la nota clave es que no todo está determinado por la empresa. Usted y su equipo, como comunidad, tienen su propia cultura de equipo. Puede ser toda la compañía, o un departamento separado, un equipo separado. Pero antes de decir: eso es en lo que creemos, eso es importante ... No puede cambiar su cultura antes de darse cuenta de los valores y creencias detrás de acciones concretas. El comportamiento es fácil de observar y buscar creencias es difícil. DevOps es solo un gran ejemplo de cómo las cosas se ponen cada vez más difíciles. Las interacciones se vuelven más complicadas, no se vuelven más limpias y entendibles en absoluto, por lo que debes pensar en lo que crees y en lo que todos los que están en silencio no hablan.

Si desea obtener resultados rápidos, este es un buen tema: ¿ha visto empresas en las que nadie diga "No sé"? Hay lugares en los que debes torturar literalmente a una persona hasta que admita que no sabe algo. Todos lo saben todo, todos son eruditos increíbles. Te acercas a cualquier persona y él tiene que responder instantáneamente algo a la pregunta. En lugar de decir "No sé". ¡Hurra, contrataron a una multitud de eruditos! Y en algunas culturas es muy peligroso decir "No sé", se puede percibir como una manifestación de debilidad. Hay organizaciones en las que, por el contrario, todos pueden decir "No sé". Es completamente legal allí, y si alguien en respuesta a una pregunta comienza a frotar el juego, es perfectamente normal responder: "No entiendes de qué estás hablando, ¿verdad?" y hazlo una broma.

Idealmente, me gustaría tener un trabajo donde puedas ser feliz todo el tiempo. No será fácil, no todos los días son soleados y agradables, a veces necesitas trabajar duro, pero cuando comienzas a resumir, resulta: wow, este es realmente un lugar maravilloso, trabajo bien aquí, tanto emocional como intelectualmente. Y hay empresas a las que acude como consultor y al instante se da cuenta de que no habría sobrevivido durante tres meses y se habría escapado con horror. De eso es de lo que quiero hablar en el informe.

Tim Lister llegará con la Keynote "Personajes, comunidad y cultura: factores importantes para la prosperidad" en la conferencia DevOops 2019, que se realizará del 29 al 30 de octubre de 2019 en San Petersburgo. Las entradas se pueden comprar en el sitio web oficial . ¡Nos vemos en DevOops!