Hoy continuamos conociendo el libro " Team Geek: The Ideal IT Company " de Brian Fitzpatrick y Ben Collins-Sussman, dedicado a la comunicación "en el trabajo" en todas sus formas. La última vez comenzamos con las comunicaciones dentro del equipo y hablamos principalmente sobre cómo les afecta la mentalidad de cada empleado individual. Esta vez tenemos que mirar al equipo de manera más amplia, como un grupo unido con su propia cultura interna, que de alguna manera se forma y se necesita para algo.
La cultura del equipo es un conjunto de conocimientos, valores y objetivos específicos de un grupo particular de programadores. Esto incluye los métodos para crear el código del programa, el estilo de comunicación entre las personas y las formas de organizar el flujo de trabajo; hay muchos componentes. Algunos de ellos no son demasiado críticos, van y vienen fácilmente (por ejemplo, la costumbre de pedir pizza y jugar juegos de mesa los viernes), otros forman la "columna vertebral" de la cultura y pueden sobrevivir a generaciones enteras de programadores (por ejemplo, procedimientos para los procesos de inspección de códigos, pruebas, documentación, etc. Más).
En su forma original, la cultura generalmente la establecen los fundadores y el equipo técnico original. Posteriormente, inevitablemente se desarrolla y sufre cambios, pero para equipos sólidos y probados (se pueden citar como ejemplo Google, Apple, Microsoft, Oracle) la mayoría de las veces conserva su rostro original hasta cierto punto: la conexión con las raíces no se pierde por completo.
Contrariamente a la creencia popular, la cultura de equipo no está completamente en manos y conciencia del líder. Si realmente existe (sobre lo que pasa si realmente no hay cultura, hablaremos un poco más adelante), es transmitido por casi todos los empleados. Esto se hace evidente cuando observa cómo suele integrarse un equipo de novatos. El nuevo desarrollador se hace una idea de cómo se acepta aquí, qué es importante y qué no es importante a través de la interacción con los colegas: qué se presta atención en su código, cómo y en qué tono explican la necesidad de arreglos, cómo son los conflictos. resuelto.
Cultura de equipo autosuficiente: una metáfora de la panadería
¿Por qué trabajar en la cultura de equipo?
Entonces, la cultura del equipo es una especie de mezcla difusa de diferentes actitudes y acuerdos que permite a las personas que trabajan juntas permanecer en la misma onda. Surge una pregunta natural: ¿Vale la pena preocuparse por esto? La influencia mutua de los empleados entre sí en el proceso de trabajo se produce de forma natural, por lo que es probable que cualquier cultura se forme por sí misma.
El problema aquí es que, como con todos los procesos espontáneos, una cultura en evolución espontánea generará más entropía y puede producir resultados impredecibles. Es decir, tarde o temprano habrá gente que decidirá con sus propias manos determinar "como es costumbre aquí". Si resultan cuerdos y actúan en la misma dirección, el final será feliz. Pero la mayoría de las veces, se convierte en las mismas viejas guerras de oficinas o, peor aún, en focos de decadencia dentro del equipo.
Así que dejar pasar las cosas no es la mejor opción. Anteriormente, hablamos del hecho de que la cultura no se puede inculcar a la fuerza, pero se puede abordar su formación con conciencia. Si cada participante no solo se comporta de acuerdo con los principios del último capítulo, sino que también intenta llevarlos al nivel del equipo, reprime las acciones que son peligrosas para la cooperación y no teme negociar reglas comunes para todos, el riesgo de sorpresas desagradables disminuye.
¿Cuál debería ser la cultura del equipo?
Por supuesto, es imposible responder a esta pregunta de manera inequívoca y exhaustiva. Los cultivos son extremadamente diversos y la gama de variaciones productivas y saludables es amplia. El trabajo bien organizado y cómodo puede ser tanto en una puesta en marcha caótica, donde todos están en la junta, como en una gran empresa con procesos claros y manteniendo la distancia. Tratar de establecer un punto de referencia para cada uno de los muchos elementos no tiene sentido.
En los términos más generales, la cultura debería ser:
- . . , , . , : .
- . , , , , . . , , – .
- . , , , : , , . , – , .
- . , , . , . , .
Los canales de comunicación son el componente más fácil de controlar de la cultura y los autores les prestan la mayor atención. Sin embargo, antes de entrar en detalles, dan un par de consejos sobre otros elementos más sutiles.
Cuando se trata de formas de tomar decisiones, entonces, en su mayor parte, los programadores prefieren modelos democráticos. Quizás esto se deba a su notorio deseo de independencia, o quizás el hecho es que la profesión es intrínsecamente creativa, pero el hecho es que es importante que los desarrolladores tengan voz y la capacidad de compartir sus propios pensamientos. Los líderes deben tener esto en cuenta al organizar los procesos de toma de decisiones. No es necesario resolver todos los problemas mediante una votación general, basta con que los empleados sean realmente escuchados y el sistema presupone un consenso suficiente para que sientan su implicación.
En cuanto a la forma de comunicación, debería inclinarse hacia la cortesía enfatizada en lugar de la agresividad. El problema con los equipos que usan un grito o un tono asertivo para afirmarse a sí mismos es que presionan y abruman a las personas de mente más tranquila. Una persona propensa a los conflictos se sentirá bastante cómoda tanto en un entorno agresivo como entre gente educada. Una persona tranquila, reservada (de las que hay muchas entre los programadores), por el contrario, no podrá abrirse adecuadamente en un equipo agresivo. En consecuencia, al alentar o simplemente adoptar una forma de comunicación ofensiva, automáticamente cortamos a algunos de los posibles empleados fuertes. Esto no es práctico.
Al mismo tiempo, debe entenderse que la cultura de la corrección y el respeto mutuo es más frágil y vulnerable a las influencias externas. Un principiante asertivo es suficiente para sacudir la armonía. Por lo tanto, es muy importante poner fin a cualquier intento de ir en contra de la forma de comunicación aceptada y evitar que las personas obtengan victorias mediante un comportamiento destructivo. La mejor manera de hacerlo es simplemente negarse a comunicarse en un tono agresivo.
Canales de comunicación
Hemos encontrado que la fijación y transmisión de información juega un papel decisivo en la cultura del equipo. En las condiciones modernas, tenemos muchas herramientas disponibles para este propósito; esta sección proporciona una descripción general de los más comunes.
Una característica común de los equipos exitosos es que utilizan activamente varios canales de comunicación para asegurarse de que todos estén al tanto de la dirección general del movimiento y del progreso actual del trabajo. Al mismo tiempo, se hace hincapié en aquellos canales que, en primer lugar, ponen la información a disposición del público y, en segundo lugar, aprovechan las posibilidades de la comunicación asincrónica.
Además, los autores consideran una serie de herramientas específicas a través de las cuales se lleva a cabo la comunicación en los equipos técnicos; aclarando su propósito y reglas de uso.
Definición de misión
De tal título, el lector-programador probablemente se santiguará, pero de hecho, no todo da tanto miedo. En el trabajo técnico, la misión se formula a nivel de proyectos individuales y tiene como objetivo no elogiar a la empresa en términos vagamente ornamentados, sino indicar claramente lo que se está haciendo y lo que no se está haciendo. En otras palabras, una declaración de misión es una definición lacónica de la dirección del desarrollo del producto y limita su alcance.
Digamos eso:
La misión de GWT es mejorar radicalmente la experiencia del usuario de la World Wide Web al permitir a los desarrolladores aprovechar las herramientas Java existentes para crear aplicaciones AJAX para cualquier navegador moderno.
Como personas involucradas activamente en proyectos de código abierto, Fitzpatrick y Sussman pudieron ver por su propia experiencia cuánto tiempo, energía y nervios pueden ahorrarle al equipo a largo plazo tal medida. Cuando nuevos miembros se unen constantemente al trabajo, cada uno con sus propias ambiciones, comentarios e ideas brillantes, el “núcleo” del grupo debe tener una comprensión clara y uniforme de la esencia del proyecto. De lo contrario, el trabajo irá de acuerdo con el escenario de la fábula del cisne, el cáncer y el lucio, o se trombará constantemente debido a los intentos de aclarar estos problemas en el camino.
En consecuencia, una declaración de misión es útil de dos maneras. En primer lugar, si existe un desacuerdo entre las partes interesadas clave sobre los objetivos y el alcance del proyecto, saldrá a la luz de inmediato y se resolverá sin demora. En segundo lugar, el resultado de la discusión será un documento con las principales tesis, a las que se podrá hacer referencia a los recién llegados aburridos o excesivamente entusiastas.
La declaración de misión le da al equipo un punto de apoyo en cualquier decisión relacionada con el proyecto, pero no debe considerarse absolutamente inviolable. A veces sucede (principalmente en las startups) que los objetivos o las circunstancias del trabajo cambian radicalmente. En situaciones de emergencia, tiene sentido evaluar honestamente si la misión original sigue siendo relevante y modificarla en consecuencia.
Documentación del proyecto
Si la misión está diseñada para desarrollar una respuesta común para todos los participantes del proyecto a la pregunta "qué", entonces la documentación del proyecto implica un trabajo similar sobre la pregunta "cómo".
El documento del proyecto presenta un esquema más detallado del futuro proyecto y su llenado técnico. Por lo general, tiene un propietario, dos o tres autores y una buena cantidad de revisores que contribuyen con sus comentarios. Escribir documentación, no importa lo difícil que sea soportarla, debe preceder al trabajo en el código; el momento en el que no se ha escrito una sola línea es el más adecuado para escuchar las críticas y ajustar los planes de implementación. El documento de proyecto terminado es muy conveniente de usar al elaborar una hoja de ruta, resaltar etapas de trabajo, etc.
La documentación de diseño por su naturaleza es mucho más flexible que la declaración de misión; no es un dogma, sino una sustancia viva. Durante el proceso de desarrollo, es necesario revisar algunos detalles, e idealmente, la documentación debe reflejar todos estos cambios en tiempo real para que el equipo pueda estar al día. En realidad, lamentablemente, a menudo se edita después del lanzamiento del producto.
Reuniones
Mucha gente pensará que sería bueno hacer la señal de la cruz aquí también: las reuniones tienen una mala reputación entre los desarrolladores. Según los autores, la razón es que están mal organizados y se utilizan a menudo donde sería más razonable recurrir a un canal de comunicación asincrónico.
Un buen ejemplo de una elección infructuosa del formato es la “reunión”, que se realiza con una regularidad determinada (normalmente una vez a la semana) y con mucha gente. Por lo general, allí se leen anuncios importantes, se resumen los resultados generales, etc. De hecho, todo el contenido de los folletos es muy fácil y productivo de traducir a una lista de correo electrónico, excepto en aquellos casos en los que precisamente se necesita una amplia discusión colectiva.
En cuanto a las reuniones, de las que realmente no puede prescindir, se deben tener en cuenta las siguientes reglas al realizarlas:
- . – , , , . « » — . , - .
- , , . , . , , .
- . – .
- (, ). , – Google .
Listas de correo El correo electrónico es una herramienta muy útil para documentar el historial del proyecto en segundo plano. Es mucho más fácil extraer información de él que de los mensajeros, donde hay mucho más tráfico y muchas menos regulaciones. Por eso, es recomendable enviar toda la información importante en listas de correo, independientemente de dónde sonara antes: copias de planos y notas de reuniones, resultados de discusiones sobre determinados problemas, documentos de proyectos, análisis de errores. Así, se forma un data warehouse centralizado, donde en cualquier etapa será posible regresar para no solo encontrar cierta información, sino también rastrear el origen de las decisiones y el curso de la discusión. Por supuesto, el archivo debe estar equipado con una búsqueda indexada.
La importancia de la documentación y, en consecuencia, de los correos está determinada por la forma compacta con la que se ubica al equipo en el espacio. Si algunos empleados trabajan de forma remota o se presentan en la oficina de forma irregular, la práctica sostenible de duplicar las noticias importantes del proyecto por correo se convierte en una necesidad urgente. De lo contrario, la mayor parte de la información que "está en el aire" (discusiones en pasillos y mesas cercanas, transmisión oral de nueva información a quienes no estuvieron en la reunión) pasará por ellos.
Si el equipo es grande y los procesos son turbulentos, los participantes pronto comenzarán a ahogarse en una corriente de anuncios heterogéneos. En esta situación, la documentación se divide en diferentes mailings temáticos (desarrollo, análisis del código del programa, soporte al usuario, testing, etc.), que incluyen a los empleados interesados. Sin embargo, es mejor comenzar con una secuencia: si hay una necesidad de separación, se lo comunicarán rápidamente.
Mensajeros en línea Los mensajeros
se encuentran en algún punto intermedio entre la comunicación sincrónica y asincrónica. No son óptimos para la documentación, pero son indispensables para resolver problemas rápidamente, especialmente en equipos distribuidos. Desde el punto de vista de la cultura de mando, aquí son importantes dos aspectos.
Primero, la línea divisoria entre discusiones públicas y privadas. La gran mayoría de mensajeros tanto internos como comerciales le dan al usuario la oportunidad de elegir entre comunicarse con una persona específica o con un grupo de personas, y esto es muy conveniente. Sin embargo, según Fitzpatrick y Sussman, últimamente ha habido una tendencia al aislamiento: las discusiones tienen lugar cada vez más en privado.
En algunos aspectos, esto no es malo: los asuntos privados definitivamente no "obstruirán el aire" a todos los empleados. Pero, por otro lado, las personas se ven privadas de la oportunidad de seguir el curso de la discusión, insertar sus comentarios y conocer de inmediato los cambios. Los novatos también pierden mucho, ya que podrían obtener mucha información valiosa simplemente leyendo en silencio discusiones activas en el chat general. A menudo, las discusiones se vuelven privadas, no porque sean demasiado de nicho, sino todo por el mismo miedo a la vulnerabilidad: no quieres hacer preguntas o hacer sugerencias frente a todos, ¿y si resultan ser estúpidos? Los desarrolladores deben captar esa motivación y tratar de no ocultar lo que es más prudente para permanecer en el dominio público.
En segundo lugar, debe recordar que los mensajeros instantáneos, a pesar de todas las reacciones instantáneas, no son un sustituto completo de la comunicación en vivo. No tienen entonaciones y expresiones faciales que puedan suavizar o aclarar algunas frases. Esto aumenta el riesgo de malentendidos que amenacen los principios de modestia, respeto y confianza, y esto debe tenerse en cuenta.
Sistema de seguimiento de errores
Esta herramienta no es tan común como las mencionadas anteriormente. Puede ser de gran beneficio en determinadas condiciones:
- Disponibilidad de un procedimiento de procesamiento y clasificación de errores, que asegure su registro y corrección oportunos. Si no se presta suficiente atención a la depuración del sistema, la gente no lo usará o abusará de él en pequeñas formas.
- . « » , .
- . – .
- . , , .
La comunicación como parte del desarrollo La
comunicación en el equipo técnico tiene lugar no solo alrededor, sino también directamente dentro del código. El canal principal aquí son, por supuesto, los comentarios de los desarrolladores .
Los autores abordan brevemente las reglas básicas de los comentarios de código, que probablemente sean familiares para todos: explicar no lo que se está haciendo, sino por qué se hace, tratar de comentar a nivel de funciones y métodos, ser lacónico y no dejarse llevar. lejos de los detalles. El resto del estilo de comentar es algo subjetivo, cada equipo desarrolla el suyo en función de las necesidades y el ambiente general. Lo principal es que este estilo general debería existir en principio; el hecho mismo de la uniformidad en este caso es más importante que las características específicas.
Otra forma de comunicación dentro del código es la atribución , es decir, la firma del desarrollador en el archivo. La costumbre de dejar su nombre en un documento nos llegó desde la antigüedad; en programas antiguos, a menudo puede ver tales autógrafos:
Fitzpatrick y Sussman insisten en que hoy estas firmas deben considerarse anacrónicas. Desde un punto de vista psicológico, el deseo de indicar la autoría, por supuesto, sigue siendo natural y comprensible: esta es una manifestación de orgullo y un sentido de responsabilidad por el trabajo realizado. En el aspecto práctico, sin embargo, esto plantea más problemas que beneficios. Ahora el desarrollo, como ya establecimos en la primera parte del artículo, se ha convertido en una actividad de equipo. En realidad, varias personas pueden estar involucradas en una pieza de código a la vez, lo que significa que resolver el problema de la autoría puede generar controversia, resentimiento y, en última instancia, pérdida de tiempo.
En el entorno actual, es más conveniente realizar un seguimiento de la autoría a nivel de proyecto, en lugar de hacerlo directamente en el código. Cuando necesite saber exactamente a quién contactar si tiene preguntas sobre una parte particular del código, el sistema de control de versiones acudirá al rescate.
Ahora que hemos analizado el núcleo de la "dimensión humana" en una empresa de TI desde todos los lados, podemos pasar a las capas periféricas: elementos extraños que rodean a equipos y usuarios.