Ocho reglas para una producción de software efectiva

Durante el curso de mi carrera, participé en múltiples proyectos de software de la vida real y observé cómo se hacen las cosas en todos los niveles: toma de decisiones, adopción de prácticas, creación de equipos, reclutamiento, distribución de habilidades, etc. Obviamente, diferentes enfoques produjeron diferentes resultados. . Siendo un tipo de persona orientada a la mejora, noté y recopilé las prácticas más efectivas y los mejores trucos prácticos para ayudarme en mi trabajo.

Aprender de la observación es una forma difícil y larga de hacerlo. Estaría extremadamente feliz de elegir este conocimiento antes de los libros. Desafortunadamente, no encontré ninguno sobre el tema. Así que decidí compartir mi experiencia con otros buscadores de este tipo de conocimiento. Con suerte, les ahorrará algunos años de investigación personal.

En este artículo, aprenderá cómo puede superar el rendimiento promedio de la industria mediante la producción de productos de software robustos y confiables que requieren de 5 a 10 veces menos mantenimiento. Puedo decir sin falsa modestia que en los últimos 10-15 años, yo (tanto personalmente como mis equipos) he superado todas las expectativas, dejando tras de sí una estela de éxitos. Los gerentes no pueden estar más felices.

Una vez, mi equipo logró un proyecto importante en un período de tiempo increíblemente corto, por lo que la alta gerencia nos otorgó un premio de "Equipo de alto rendimiento". Todo ello sin pernoctar y agotarnos los fines de semana. Solo trabajo normal.

Verá, el conocimiento efectivo de producción de software en sí mismo es un poder. De hecho, es una especie de magia negra que no muchas personas pueden comprender, incluso cuando se explica con palabras sencillas. Lo obtendrás gratis. Siga leyendo si quiere ser percibido como un mago de la producción de software.

¿Para quien es esto?

Permítanme hacer un importante, importante, importante descargo de responsabilidad aquí.

Dirijo esto a aquellos que necesitan un impulso de productividad. No todo en la vida se trata de productividad. No todos los proyectos de software tampoco. Hay casos en los que no eres juzgado por tu desempeño. Obviamente, estas prácticas no ayudarían entonces.

Estas técnicas serán más útiles para los líderes de equipo, arquitectos y gerentes de proyectos, aunque los desarrolladores de software senior también pueden beneficiarse de ellas.

Regla n.º 1: comprender la mentalidad de TI

La industria de TI es una mezcla de ciencia, tecnología, arte y negocios. Es bastante difícil navegar allí sin comprender estos aspectos en un nivel suficientemente bueno. El mayor problema es que la industria en sí es bastante compleja; por lo tanto, las mejores prácticas también son complejas. Necesita aprender mucho y verificar su conocimiento practicando mucho para tener éxito.

La increíble tasa de actualización de tecnología lo hace doblemente difícil. Ya no se necesita nada de lo que aprendiste hace diez años. Así que necesitas aprender a un ritmo acelerado.

Resumiendo todo lo anterior, podemos decir que tener éxito en el campo de TI no se basa en habilidades o sentimientos innatos sino en ejemplos prácticos duros. Nunca “sigas el instinto” o creas únicamente en base a tus sentimientos, incluidos los tuyos.

Si es así, vale la pena considerar la idea. De lo contrario, exija una explicación muy buena y muy detallada sobre cómo la elección de este camino mejora la vida de su equipo. Si pasa esta prueba, programe un proyecto ligero de prueba de conceptos que demuestre experimentalmente que encaja en su entorno.

Lo importante que hay que entender aquí es que no hay soluciones correctas o incorrectas porque hay muchas formas de resolver problemas de software. Sin embargo, hay buenas y malas interpretaciones de la solución.

Si una persona puede articular claramente la idea en detalle o establecer un vínculo entre la adopción de esta solución y el éxito del equipo para persuadir a otros miembros del equipo, entonces podemos confiar en la visión de esta persona y esperar una alta probabilidad de éxito.

Regla n.º 2: no mezclar metodologías de producción y desarrollo de software

La producción de software se basa en el desarrollo de software. Sin embargo, estos dos tienen objetivos, mentalidades y prácticas completamente diferentes. Tratar de resolver un problema de uno de estos reinos con los métodos de otro produce resultados ridículos. Es importante entender la distinción y utilizar métodos apropiados para cada uno de estos mundos.

El desarrollo de software es una combinación de arte y artesanía. El componente artístico siempre estará ahí, independientemente de las herramientas de automatización y las metodologías de desarrollo de software que existen. Por lo tanto, resolver tareas de desarrollo requiere máxima concentración y protección contra todas las demás señales de distracción.

La mejor manera de motivar a un desarrollador experimentado es presentarle una tarea en su forma puramente técnica con todos los factores humanos excluidos. Todos los requisitos también deben expresarse en lenguaje técnico. Deben ser fácilmente verificables para permitirles navegar hacia la meta durante su fase de investigación individual.

La producción de software, por el contrario, está más en el dominio de la administración de empresas. Sabe lo que necesita su cliente por un lado y sabe qué recursos de equipo tiene a su disposición por otro. Así que ahora trata de dirigir los esfuerzos de tu equipo para alcanzar la meta. Mientras tanto, también puede estimar su velocidad de progreso y presentar un plan bien versado al jefe. Las habilidades importantes allí son comprender los deseos de su cliente, comprender las fortalezas de su equipo y comunicar planes y cronogramas formales.

Dicho esto, me gustaría resaltar que muchos roles en el desarrollo de software están trabajando en ambos mundos, en la construcción de un puente entre el negocio y la tecnología, como líderes de equipo, arquitectos, analistas y gerentes de proyectos. Las personas en estos roles deben poder caminar fácilmente entre dos planos de la realidad y comprender cuándo es el momento de hablar de negocios y cuándo es el momento del arte.

Regla n.º 3: utilice el almacenamiento persistente como una extensión de la memoria humana

La memoria humana, aunque asombrosa en capacidad, tiene sus límites. Recuerdas las cosas con una precisión y una duración impredecibles, y cuando las olvidas, no hay forma de recordarlas a voluntad.

Es por eso que usamos el almacenamiento de memoria persistente para avanzar a una velocidad predecible. No se trata de documentación formal como manuales de usuario que se crean mucho después del hecho y para que los usen otras personas. Se trata de usar documentos literalmente como una extensión externa de su memoria durante el trabajo que lo ayuda a pasar por el proceso de desarrollo de software.

Le recomiendo que documente sus pensamientos y planes en el camino siempre que se enfrente a tareas no triviales o tareas que involucren a más de una persona. Trate de hacerlo lo más barato posible. No cree documentos formales con el logotipo de la empresa. Una buena herramienta sería un wiki de la empresa con el espacio de su proyecto. Crear páginas dedicadas a las tareas o problemas (30 segundos). Luego actualícelo cada vez que tenga una idea o esté a punto de discutirla con otros.

En una reunión, diga “espere, déjeme escribir esto” y dedique entre 10 y 30 segundos a expresarlo por escrito. La escritura no debe ser extensa, pero debe ser completa y coherente, como si estuvieras transfiriendo la idea en su totalidad al papel. Más adelante, tú o cualquier otra persona que lea tu pasaje debería entenderlo tan claro como lo entiendes ahora. Ese truco ahorra mucho tiempo, pero le permite documentar sobre la marcha.

Esta técnica tiene dos propósitos.

Primero, bloquea tu progreso en el camino hacia el éxito presionándolo con fuerza contra la piedra. No más riesgos de que alguien olvide algo, reitere lo mismo una y otra vez, o renegocia lo mismo que ya se negoció.

En segundo lugar, despejas tu mente y te deshaces del problema que te estaba molestando. Ahora tu mente está hambrienta por el próximo desafío. ¡Qué aumento de la productividad!

Esto se aplica a cualquier tamaño de proyecto o tarea. Para los más grandes, solo tendrá espacios más grandes con una jerarquía de páginas que crece gradualmente a medida que evoluciona su proyecto. ¡El concepto importante aquí es preparar un espacio y una estructura de documentación antes de comenzar con su tarea para establecer un protocolo de volcado rápido de memoria!

Para las personas que prefieren las analogías tecnológicas, compararía nuestra mente con un procesador con un poder de procesamiento inmenso pero una memoria operativa limitada. Esencialmente puedes pensar en una cosa a la vez. En esta analogía, su documentación sirve como almacenamiento persistente, mientras que su mente resuelve problemas complejos con un enfoque iterativo. En algún momento, decide comenzar la siguiente iteración, leer la documentación anterior y cargar el estado actual en su memoria operativa, pensando en ello por un tiempo y actualizando el código y la documentación con sus nuevos hallazgos. Paso a paso hasta completarlo.

Dicho todo lo anterior, no animo a las personas a procesar muchas tareas a la vez. Por el contrario, cuantas menos tareas tengas, mejor. Sin embargo, no muchas situaciones de trabajo están realmente optimizadas para el ser humano, y es posible que se requieran múltiples tareas y usted tiene que manejarlas de alguna manera. El truco anterior ayuda a manejarlo mejor.

Regla No. 4: Deje de perder el tiempo en la estimación formal del tiempo

No hay dos proyectos iguales. La próxima vez que haga un proyecto similar, tendrá diferentes clientes, diferentes objetivos, un equipo diferente; tal vez incluso diferentes tecnologías. Incluso utilizando herramientas y componentes estándar, deberá personalizar su configuración y arquitectura. Cuando maneje proyectos de software, tenga en cuenta que implican entre un 50 % y un 100 % de trabajo personalizado. Requieren investigación, discusiones, pensamiento, pruebas y otras actividades altamente impredecibles. En la práctica, puede experimentar una enorme diferencia en lo que a primera vista parece ser exactamente el mismo tipo de proyecto y lo que ha hecho antes. Un nuevo tipo de proyecto, por extensión, es casi imposible de estimar con exactitud.

Si es tan impredecible, ¿cómo se supone que los gerentes de proyecto deben presentar un cronograma del proyecto y cumplirlo?

Hay un método formal para hacer esto descrito en la literatura; es decir, dividir todo el proyecto en pasos más pequeños, estimar cuánto dura cada paso y luego calcular la duración total del proyecto combinando la duración del trabajo de las piezas individuales. Hay toneladas de teoría detrás de este método que se enseña en los cursos de MBA.

Desafortunadamente, sin embargo, ninguna cantidad de matemáticas puede salvarlo. Este método es notoriamente inexacto, hasta el punto de que es completamente inutilizable y poco práctico, sin mencionar lo increíblemente lento que es. Nunca vi un gerente de proyecto que usara métodos formales de cálculo sin ningún ajuste, ni siquiera entre los fanáticos metodológicos. ¡Ni siquiera cuando la empresa impuso estrictamente el uso de dicho método! De hecho, los gerentes con mejor desempeño usan métodos alternativos completamente diferentes, como se describe a continuación:

Un buen gerente de proyecto toma nota del tipo de proyecto, el entorno, los recursos involucrados, el tipo de organización y todos los demás aspectos del trabajo que influyen en la duración real del proyecto. Por supuesto, nadie necesita aprender únicamente de sus propios errores. Tales observaciones se pueden hacer tanto directa como indirectamente; por ejemplo, a través de libros o estudiando proyectos realizados por otras personas o incluso simplemente pasando el conocimiento de persona a persona. Tal conocimiento estadístico de alto nivel mejora la navegación del cronograma del proyecto personal.

Me gustaría destacar dos consecuencias importantes del método descrito anteriormente.

Primero, la precisión de la estimación mejora con la experiencia. No hay forma posible de que una persona inexperta armada con cualquier metodología fuerte que tenga pueda ser buena en eso. En segundo lugar, incluso la mejor estimación sigue siendo buena solo en términos estadísticos. Es decir, se puede decir que un determinado proyecto puede durar entre cuatro y doce meses. Suponiendo que esto sea correcto, uno debe entender que existe un 50% de posibilidades de que el proyecto se ejecute durante su tiempo promedio de ocho meses.

Comprender la predicción estadística tiene un efecto tan increíble. Un gerente inteligente simplemente pondría una estimación de doce meses en un proyecto como ese y luego sorprendería a todos al completarlo antes de tiempo. En otras palabras, nadie esperaría que un equipo siguiera el cronograma del proyecto al día.

El consejo general para los gerentes de proyecto y sus jefes sería dejar de perder el tiempo en metodologías formales de estimación de tiempo. En su lugar, fomente la recopilación de información estadística sobre la duración del proyecto y comparta esta información en toda la empresa. Conozco empresas en las que se implementó un enfoque de este tipo en toda la empresa, lo que resultó en una precisión predictiva milagrosa.

Regla No. 5: Comprenda el costo de cambiar tareas y hacer malabarismos con las prioridades

La mente humana está asombrosamente diseñada por la naturaleza. Aunque es increíble, tiene sus limitaciones. En otras palabras, se diseñó para sobresalir en áreas particulares y en un tipo particular de tarea.

La mente de un desarrollador es definitivamente un gran activo en el desarrollo de software. ¿Usted, como gerente de proyecto, estaría interesado en comprenderlo mejor y colocarlo en una posición en la que se desempeñe mejor?

Pongámoslo en términos simples, evitando demasiada teoría. Recuerda, la teoría solo te lleva hasta cierto punto antes de que necesites aprender de la experiencia, ya sea la tuya o la de otros.

La mente humana tiene un gran potencial para resolver problemas y generar ideas. Desafortunadamente, no siempre es posible aprovechar este potencial, principalmente porque para respaldar la generación de ideas, debe mantener juntas todas las piezas del problema en su memoria activa al mismo tiempo. Es por eso que la resolución de problemas complejos pasa por una etapa de simplificación cuando una tarea se generaliza o reformula para eliminar piezas sin importancia y disminuir la cantidad de elementos guardados en la memoria simultáneamente. En otras palabras, podemos resolver un problema complejo muy limitado o múltiples problemas simples.

Sin embargo, la proporción no es lineal. Aumentar la cantidad de cosas que haces simultáneamente afecta drásticamente tus habilidades para resolver problemas. Es por eso que la humanidad siempre empleó y empleará la separación de roles como una optimización de la vida. Dos personas que trabajan por separado en dos tareas lograrán un avance más rápido que si ambas trabajan en ambas tareas al mismo tiempo.

Otro rasgo importante de la mente humana es su incapacidad para cambiar entre tareas inmediatamente como lo hacen las computadoras. De hecho, no puedes simplemente dejar de pensar en algo a voluntad. Tampoco puede comenzar a pensar inmediatamente en un nuevo concepto a toda velocidad. Ese tipo de inercia mental está perfectamente ilustrado por los operadores de control de tráfico aéreo. A pesar de que están mirando el radar y viendo la imagen completa, aún necesitan cargarlo en su memoria para operar rápidamente. Un operador nuevo tarda diez minutos en mirar la pantalla antes de que pueda reemplazar al antiguo en un cambio de turno.

Lo que lo empeora es que no podemos olvidar las cosas a voluntad. Todo lo que hemos aprendido se queda con nosotros y se desvanece gradualmente con el tiempo, ocupando un espacio que podríamos usar para nuevos conocimientos. Y lo que es peor, este efecto se ve agravado por una sensación de "asunto pendiente" a veces. Es mucho más fácil olvidar algo que está completo y que nunca necesitarás en el futuro. Mientras que cuando deja las cosas a un lado para terminarlas más tarde, su cerebro naturalmente se aferra a la información marcada como "para referencia futura", y no está dispuesto a dejar que el nuevo conocimiento tome su lugar.

Bueno. Ahora que hemos esbozado la idea de cambiar de tarea, veamos cómo funciona en un experimento mental de la vida real (por así decirlo).

Imagine que tiene a sus diez desarrolladores regulares trabajando en diez tareas regulares, una tarea por persona. Suponiendo que podamos encerrarlos en un entorno perfecto libre de distracciones, cada tarea puede ser resuelta en una cierta cantidad de tiempo por una sola mente. Todo tomará tanto tiempo como se necesita para completar la tarea individual más larga.

Ahora, repitamos el mismo experimento mental. Esta vez, cambiaremos constantemente las asignaciones de tareas entre los desarrolladores sin ninguna razón (importante). Todos los días, cada desarrollador tiene una nueva tarea en la que trabajar. Mejor aún, cambiémoslo cada hora. ¿Qué tan pronto terminarán, crees? Tal vez nunca.

El gerente del proyecto en el primer escenario pudo ejecutar el proyecto de manera efectiva. Los segundos lograron “ejecutarlo”, eso seguro… en el sentido de que facilitaron su muerte. Felicidades. Esta técnica de eliminación de proyectos es muy efectiva porque, además de la mera pérdida de tiempo, también reduce la moral de los empleados a cero.

La mayoría de la gente estaría de acuerdo con el ejemplo anterior cuando se les presenta de una manera puramente académica como esa. Sin embargo, en la vida real, de repente se olvidan de todo bajo la más mínima presión. El gran jefe exige un informe de progreso, o el cliente pregunta sobre una determinada fecha de implementación de funciones: casi cualquier evento externo puede hacer que un gerente de proyecto se apresure a ir al equipo y exprese su preocupación, seguido de una ráfaga de reasignaciones de tareas y malabarismos de prioridad en un intenta ganar un poco de tiempo aquí y allá, lo que finalmente resulta en nada más que desviar el proyecto aún más.

Ese es un escenario de la vida real que ocurre con bastante frecuencia, desafortunadamente.

Un buen gerente se pone de pie y protege al equipo de tales perturbaciones menores al absorber la onda expansiva emocional y convertirla en temas de discusión futuros productivos. Eso definitivamente es duro emocionalmente, pero es la única forma de mantener al equipo en un buen ritmo de trabajo y dejar que entreguen.

Regla n.º 6: utilice las revisiones de arquitectura como una forma de mejorar el diseño del sistema

La industria de TI opera con nociones de exceso y defecto de ingeniería. Cuando surge el tema en una entrevista, todo el mundo dice que el exceso de ingeniería es malo. Esa es fácil de responder porque la pregunta en sí misma transmite una connotación negativa de "sobre", que significa "demasiado". El verdadero conocimiento práctico sería reconocer cuándo su arquitectura se sobrediseña y evitarlo en las primeras etapas.

Déjame darte algunos de mis consejos probados y verdaderos sobre eso.

En primer lugar, se puede considerar que la solución tiene un exceso de ingeniería si existe otra solución más sencilla que ofrezca todas las funciones necesarias. Eso significa que si no conoce una solución más simple, entonces cualquier solución más simple que pueda ofrecer es la mejor a sus ojos, a menos que alguien demuestre que está equivocado.

Si nuestro arquitecto imaginario se esfuerza genuinamente por la perfección de la solución, la revisión de la arquitectura habitual garantiza que es lo suficientemente óptima. Desafortunadamente, la revisión de la arquitectura requiere al menos algunos otros arquitectos calificados. Corre el peligro de no estar disponible o ser poco práctico en muchos casos. En ausencia de una revisión por pares, los arquitectos son propensos a cometer errores comunes. Revisémoslos uno por uno y analicemos los posibles remedios para cada uno.

Uno de los errores más comunes es diseñar sin un objetivo comercial en mente. Parece obvio que cualquier actividad laboral debe estar ligada a la satisfacción del consumidor final o al éxito de la empresa oa una necesidad comercial similar. Sin embargo, a menudo, se puede ver arquitectura diseñada en su totalidad o en parte sin tener ese propósito en mente. El razonamiento está ausente o se reduce al uso de tantas campanas y silbatos modernos como sea posible.

El arquitecto en este caso no hace lo que el consumidor ha pagado. Más bien, juegan con juguetes geniales para su propia diversión y placer. Esto no es de ninguna manera aceptable en la industria formal. Y, sin embargo, parece suceder con bastante frecuencia de todos modos.

En ocasiones, el problema radica en la personalidad del arquitecto y su obsesión por determinadas tecnologías o herramientas. Simplemente les gusta usarlos y no pueden explicar de manera coherente qué necesidad comercial están tratando de resolver. Cerca de eso hay otro caso en el que la gente no sabe nada además de construir algo a partir de piezas pequeñas. Seguramente, cualquier evento externo desencadena su impulso de sumergirse en el mundo del diseño y nunca volver a un cliente real. Aunque el desencadenante inicial puede ser una entrada comercial válida, su desapego prolongado de la realidad disminuye la utilidad de su obra de arte.

La cura para esto es muy simple, pero requiere autodisciplina. Un buen arquitecto nunca debe tocar lápiz y papel hasta que pueda responder clara y honestamente por qué es necesario. Tal necesidad podría venir en diferentes formas. Puede ser un requisito formal, una necesidad implícita de mejora del producto o la aparición de nuevas tecnologías que restan eficacia al diseño anterior. En cualquier caso, no debería ser un disparador formal siempre que los propios arquitectos entiendan la fuerza impulsora. Entonces pueden usar esta fuerza como una verificación final de la calidad de su diseño.

Otro problema detectable más difícil está relacionado con el pensamiento de arquitectura de bloques. Las personas con esa mentalidad creen que hay una solución para todo y dicha solución siempre se implementa como un bloque de construcción. En otras palabras, traducen la funcionalidad a componentes directamente sin evaluar la arquitectura como un todo. Pueden simplemente adjuntar un componente que proporcione la funcionalidad deseada al sistema cuando surja la necesidad de dicha funcionalidad. La mayoría de las veces, esto satisface los requisitos formales pero deja el sistema en un estado incoherente. El nuevo bloque no se seleccionó sobre la base de la compatibilidad del sistema existente para el desarrollo, el soporte o incluso el modelo de licencia de la empresa. Entonces, el equipo intenta modificar la configuración existente o implementar esta funcionalidad a través de la capacidad del sistema existente. Como resultado, el soporte y el mantenimiento del sistema se convierten gradualmente en una pesadilla intrincada seguida de cerca por una degradación del rendimiento.

No existe una solución simple para este problema, ya que la ingeniería del sistema es un arte y nunca es posible predecir si se debe agregar un nuevo componente o se puede evitar. La mejor práctica probablemente sería mantener una acumulación de problemas de mantenimiento y arquitectura a lo largo del tiempo, seguida de revisiones periódicas de la arquitectura general del sistema. Esta revisión periódica también puede considerar tecnologías emergentes. Por lo tanto, el propósito general de las revisiones de la arquitectura no debe ser solucionar problemas, sino evaluar la viabilidad potencial de las mejoras deseadas y del sistema en su conjunto frente a la inevitabilidad inminente de la obsolescencia.

Regla No. 7: Jugadores de Equipo de Valor

A la mayoría de los profesionales de la industria de TI se les preguntó en una entrevista si son buenos jugadores de equipo o si trabajan bien en equipo. Sin embargo, probablemente nadie vio nunca una definición clara en la literatura. Obviamente, una persona así contribuiría al éxito del equipo en general, pero pocas personas pueden realmente definir las cualidades personales distintivas que aseguran tal éxito.

Observé a muchas personas trabajando en diferentes niveles y vi cómo sus cualidades personales influyeron en el progreso del proyecto. Me gustaría presentar los siguientes consejos sobre las cualidades personales que son más útiles en el trabajo en equipo.

Comunicado

La primera y principal cualidad, por supuesto, es la capacidad de comunicarse.

Imagina una persona con cero habilidades de comunicación. Seguramente no recibir comentarios de los miembros del equipo los vuelve completamente inútiles. Esto es tan obvio que nadie está midiendo esta habilidad durante la entrevista, lo que implica que la habilidad está en un nivel suficientemente bueno siempre que la persona pueda hablar bien.

La comunicación no es una habilidad binaria de sí/no; es más una ventana de transferencia de información. Cuanto más amplio sea, más rápido y claro será el intercambio de información.

Dado que el rango de apertura de esa ventana varía mucho entre la población, la medida del ancho de dicha ventana es una característica importante de un jugador de equipo. Tenga en cuenta que estamos hablando de transmitir información en este contexto, pero no de hablar con fluidez o alentar a las personas, motivarlas u organizarlas a través de conversaciones y comunicaciones.

El estilo de comunicación también es irrelevante. La información se puede entregar de forma oral, textual, en imágenes o de forma mixta. La persona puede hablar rápido o lento. Pueden ser amigables, como mirarte a los ojos y sonreír todo el tiempo, o pueden mirar hacia otro lado y hablar con una voz monótona. El estilo puede afectar su percepción personal de su compañero de trabajo, pero siempre que entienda claramente lo que significan, cualquier estilo es suficiente.

Pasemos a casos prácticos sobre detección y medición de habilidades comunicativas.

Hay dos aspectos principales en las habilidades de comunicación en general. En primer lugar está la voluntad de compartir información. Algunas personas están ansiosas por compartir, pero otras tratan de ocultar la información. Esa inclinación es más o menos natural, pero se puede cambiar lentamente con auto motivación y entrenamiento. Es seguro asumir que la persona que muestra un tipo de disposición para compartir información también lo demostrará en el futuro. Es por eso que ese rasgo es bueno para predecir el éxito futuro de un candidato en un equipo.

En la vida real, las personas que intentan ocultar información son fáciles de notar. Por lo general, intentan dar información intencionalmente inútil en lugar de cualquier cosa que realmente necesiten. O bien, hacen preguntas preliminares para volver el flujo de información hacia adentro y minimizar sus respuestas a una ocurrencia de "necesidad de saber". Cualesquiera que sean sus tácticas, al final sentirá que no obtuvo la información deseada de ellos, o que obtener la información requirió demasiado esfuerzo adicional.

Es importante comprender la intención, ya que algunos tipos de personas abiertas pueden hacerle preguntas preliminares para comprender mejor su pregunta y luego brindarle la respuesta de la manera más conveniente. La persona que intenta ocultar la información hará preguntas adicionales solo para desviar la conversación y nunca responderá a su pregunta inicial.

Otra parte de la habilidad de comunicación es la capacidad de sintonizar con el oyente.

Diferentes personas tienen un nivel diferente de comprensión del tema, un estilo de comunicación diferente y tal vez incluso un interés diferente en detalles específicos. Algunas personas comunicativas inteligentes variarían el flujo de su conversación dependiendo de la capacidad del oyente para comprenderlo y preparar su respuesta para brindar información específica. En tal preparación, se pueden hacer algunas preguntas preliminares para reducir el interés del oyente. La capacidad de “resolver” las diferencias de comunicación es realmente una gran habilidad, ya que nos permite lograr la comprensión en casi todos los casos. Los habladores flexibles, por otro lado, a veces pueden estar atrapados en callejones sin salida de malentendidos sin solución.

Comprender las fortalezas y debilidades

Centrémonos en otra cualidad personal imprescindible para un jugador de equipo.

La mayoría de las personas estaría de acuerdo en que un entorno de equipo debería ser más amigable que el mundo circundante promedio para fomentar la colaboración y aumentar la productividad. Por lo tanto, es importante que un equipo entienda las áreas fuertes y débiles de cada miembro para distribuir adecuadamente las tareas y cubrir las debilidades con fortalezas. El primer paso en este camino es que todos los miembros midan honestamente sus habilidades entre sí. Psicológicamente, esto puede ser difícil ya que naturalmente tendemos a ocultar nuestros puntos débiles de los demás, protegiéndonos a nosotros mismos.

Aquí es donde la atmósfera amistosa del equipo viene a ayudar.

Por lo tanto, se espera que el nuevo miembro juegue según las reglas del equipo. Desafortunadamente, algunas personas no pueden bajar la guardia incluso en un ambiente amigable. Se comportan como lobos solitarios durante toda su vida. Esto es más fuerte que ellos. Lamentablemente, tal actitud no contribuye a los esfuerzos del equipo.

Hay una técnica fácil para reconocer a esos lobos solitarios en la entrevista. Nunca admiten que no saben algo. Por supuesto, a la gente le gusta mostrar lo mejor de sí misma, mostrando todas sus habilidades y tratando de resolver cada problema difícil. Sin embargo, hay un límite de conocimiento para todos. Nuestros límites dan forma a nuestras habilidades. No admitir límites significa que los candidatos se presentan como un sabelotodo, igualmente buenos en todo y en nada.

Cuando contrate a un especialista, probablemente querrá evitar a esas personas. Además, esa actitud arrogante a menudo viene con otro rasgo de bandera roja: la falta de voluntad para pedir ayuda. La capacidad de pedir ayuda es absolutamente esencial para el trabajo en equipo. Sin ella, no podemos progresar y desarrollarnos tan rápidamente. Una persona tan terca quemaría los recursos y el tiempo de la empresa, luchando indefinidamente en tareas difíciles pero nunca pidiendo ayuda a sus compañeros de equipo. Hay un truco fácil para detectar a tales candidatos en la entrevista. Hágales una pregunta que no tenga sentido o mencione algún término sin sentido. Una persona normal, idealmente curiosa, simplemente diría que no sabe y preguntaría qué es. Una persona a la defensiva nunca haría eso, incluso si resalta que no hay una respuesta correcta o incorrecta y que "no sé" no los descalifica.

Regla No. 8: Centrarse en la organización del trabajo en equipo

Hay tan poca información sobre la organización del trabajo en equipo como sobre cualquier tema anterior. Todo el mundo sabe que el trabajo en equipo es mejor, pero cómo construir y mantener un equipo sigue siendo un misterio. Sin embargo, incluso si es imposible cubrir todos los aspectos de la formación de equipos, al menos podemos explorar algunas técnicas clave de formación de equipos aquí.

Experiencia en construcción

Cada proyecto de TI es único. Para tener éxito en él, uno necesita aprender y dominar los detalles del proyecto. Pueden incluir tanto conocimientos técnicos como no técnicos. Un ejemplo de conocimiento no técnico podría ser una red personal para la gerencia, los clientes, los equipos de soporte técnico, etc. El conocimiento técnico especial son detalles adicionales además de las habilidades generales de TI.

Por ejemplo, es posible que necesite conocer a Maven para construir un proyecto. Sin embargo, la estructura de construcción exacta, la ubicación de las propiedades y el filtrado variarán según el proyecto. Como con cualquier tipo de conocimiento, dominar esos detalles lleva tiempo; cuanto más tiempo se invierte en ello, mejor se puede realizar. El tiempo es el recurso más valioso que tienes. Desea mantener a su miembro del equipo enfocado en la misma área funcional durante el mayor tiempo posible para capitalizar su experiencia y desarrollarlos aún más, mejorando así constantemente el desempeño del equipo.

Desafortunadamente, no es posible hacerlo indefinidamente. Por un lado, la gente puede aburrirse. Por otro lado, corre el riesgo de perder su experiencia, poniendo inesperadamente en riesgo su proyecto.

Veamos si hay formas de hacer frente a las desventajas sin obstaculizar mucho el rendimiento del equipo.

Distribuya las áreas de enfoque entre los miembros del equipo y permítales desarrollar su experiencia en ellas. En algún momento, alcanzan un nivel lo suficientemente alto que tiene sentido en el alcance de este proyecto. El esfuerzo de aprendizaje adicional no lo mejorará significativamente en este punto. Sin motivación y desafío, las personas inteligentes se aburren y comienzan a odiar su trabajo.

Evite esto abriendo posibilidades de aprendizaje en otros lugares para ellos. Mantenlos informados de los proyectos y el stack tecnológico de la empresa, y abre nuevos retos. Si su interés se encuentra dentro del alcance del proyecto, obtienes la doble recompensa de mantener a tu equipo desafiado y al mismo tiempo ampliar los conjuntos de habilidades útiles del equipo. However, any self development is good to avoid boredom, even if it doesn't intersect with immediate project needs. As long as the team expert brains are engaged, they keep supporting already-learned project areas in the back of their minds.

When leaving the company, team experts take a big portion of expertise with them. One of the countermeasures you can use is to widely disseminate documentation that can be updated on the fly. Think of the “persistent memory storage” mentioned earlier.

Still, a project manager would love to duplicate knowledge in team member heads if possible. Having two of every expert would be a simple solution for that, albeit twice as expensive. But there is a leaner way to do it. The trick is to let most of your developers develop expertise in multiple areas, so that each project aspect is covered by at least one deep expert. At the same time, chose a few senior members to grow the breadth along with the depth of their expertise. Usually, this role is best played by a team development lead or an architect. The team lead interacts with all team members and participates in all task implementations. They can tap into each and every aspect of the project, understanding all of its internals. This way, even if you lose one of the experts, the leader can take over and keep on the project progressing until you can hire and train the replacement.

Another flavor of same idea is to cross-train developers in adjacent areas, letting them to observe, learn, and occasionally try their peers' work. Keep in mind that this cross-training needn't be extensive, so it doesn't disrupt focus on developers' primary tasks and doesn't impede productivity. Developing expertise across leadership and cross-training developers builds you a cushion of protection against unforeseen life culprits and allow you some time to maneuver with project resources.

Minimizing Distraction

Software development is a chain of complex and creative problem solving. Even though, with industry development, these complex problems get more and more automated, the work doesn't become easier. It still involves a large amount of art and individual insight, which is very hard to predict and sometimes even harder to wrangle.

Developers are the edge of the weapon. Their concentration is equivalent to the hardness of the weapon's tip. Increase their focus and you'll cut through problems like a hot knife through butter. Distract them and you'll end up clumsily poking at the butter with a blunted stick.

This cannot be over emphasized: Non-problem-solving work can be intensified with motivation or extra effort. For problem solving work, you need maximum detachment from the mundane world. It is difficult to leave all everyday problems behind, and a good project manager should build a quiet development environment in both the physical and mental senses. A developer's workplace should be analogous to a sensory deprivation tank.

Physically, this is implemented as a closed work space. Every team member should have a cube at least where they can dive into solitude. It is preferable to avoid loud noises and aisle conversations. Quick interpersonal communications should be maintained by emails and chats. Large groups should use closed rooms for their meetings to not distract others. This is a pretty standard picture for office life as it used to be.

Unfortunately, the open space paradigm is being adopted more and more widely even in large offices. I would warn against his fad. Even worse, together with open spaces, top management encourages in-place team conversations. That is, in essence, shouting to a person in another row over an uninvolved team member's head. A developer that is interrupted by loud conversation twenty times a day won't have a shred of concentration left. Certainly a major performance killer.

Allowing for a Learning Curve

Knowledge itself is power. This is especially true for such a complex industry as IT. Every task here has its regular cycle: learn, research, implement. The learning phase in particular is invaluable. Not only does better understanding allow better and faster implementation, there are certain knowledge thresholds that must be passed in order to achieve something at all. Of course, there is no point in over-learning either. Each skill should match the production need and not much above it.

However, often, developers are pressured in the opposite direction; to stop learning and to do nothing but produce. Learning is perceived as wasted effort, as it doesn't move the task progress bar. This seems like a really easy problem to solve, sitting at home and reading this article. Yet in the real life, the slightest work pressure turns every manager into that demanding idiot who insists that everybody “stop learning and start doing something already.” I swear, I have heard those exact words so many times throughout my career… A good manager and team leader should understand that learning is an important part of the process even if it doesn't directly increment the progress bar.

Building a Competitive Development Workshop

The tips and tricks presented above are a subset of effective software production expertise. By understanding and applying them in real life, you'll improve your production effectiveness little by little. If you think they are largely unconnected and lacking a theoretical base, you are absolutely right.

I would like to highlight that building a competitive development workshop is not a single-discipline task. It requires knowledge and expertise in multiple adjacent areas. Building such expertise is a hard work. There is no single theoretical base or idea that would solve all your problems at once. Believing in such a silver bullet just serves to distract you from the real goal.

Try out these tips at work to see if they are worth adopting permanently. If you find them useful (or not), leave a comment below and share your experience!