En este artículo, hablaré sobre la creación de flujos de trabajo en un pequeño departamento de desarrollo web. El departamento se formó desde cero e inmediatamente comenzó un trabajo autónomo, por lo que tuvimos que construir procesos de producción nosotros mismos, pisar todo tipo de rastrillos y sacar las conclusiones necesarias de esto. Con la esperanza de que esto ayude a alguien a ahorrar tiempo, dinero y nervios, describiré los problemas que enfrentamos y nuestras opciones para resolverlos.
Es importante tener en cuenta que esta no es una metodología universal que se pueda implementar en cualquier equipo de desarrollo, y todo será maravilloso de inmediato. Esta es solo una combinación de técnicas bien conocidas y experiencia práctica, que pudimos ajustar de manera efectiva a nuestras características de desarrollo. No existe una solución única y simple para este problema. Siempre debe basarse en el tamaño y la experiencia del equipo en sí, las características del negocio, los detalles de los proyectos, etc.
Los datos iniciales de nuestro departamento: un pequeño equipo de producto (5-10 personas), parcialmente distribuido (algunos empleados trabajan de forma remota, algunos en la oficina) con clientes dentro de la empresa. Proyectos web. No hay especialistas en administración de sistemas dentro del departamento, pero hay departamentos involucrados en la empresa.
Comunicación del equipo
Comencemos construyendo una comunicación efectiva dentro del departamento. En cualquier equipo, es importante construir canales efectivos y formas de comunicación, pero cuando el equipo se distribuye, esta necesidad se intensifica. Aquí alcanzó su máxima nitidez porque el equipo solo estaba parcialmente distribuido. Tuvimos que aprender a fusionar los mundos de la oficina y los empleados remotos.
El problema más importante que hemos encontrado son las discusiones verbales. El personal de la oficina siempre tiene la tentación de empacar rápidamente una taza de café y discutir el estado del proyecto. Sin embargo, en este caso, los trabajadores remotos no podrán participar en esta discusión, por lo tanto, no podrán contribuir con sus ideas y, de hecho, no sabrán que algo está sucediendo. Como regla, esto resulta en una desincronización de las acciones del equipo, discusiones repetidas debido a la aparición de nuevos pensamientos y sugerencias de la parte distribuida del equipo y solo un regusto desagradable.
Quedó claro que algunas cosas comunes importantes deberían discutirse por escrito en chats generales o en algunas llamadas grupales.
Esto da lugar a otro problema muy común que aparece en los equipos en los que necesita escribir mucho: el problema de la cultura de la escritura. No puedes simplemente ir a un colega, tirarte de la manga, dibujar algo en una servilleta y agregar gestos a tu historia. Por un lado, esto complica el trabajo y, por otro, las personas desarrollan la habilidad de escribir sus pensamientos de una manera comprensible y estructurada. Como resultado de este enfoque, la documentación comenzó a formalizarse mejor, las tareas comenzaron a formularse con mayor claridad, todos comenzaron a pensar en cómo presentar sus pensamientos de tal manera que fueran comprensibles para los demás desde la primera lectura.
Todo lo anterior no significa que hayamos abandonado completamente la comunicación personal, las llamadas de voz y video. Sin embargo, establecimos que los resultados de tales debates deberían registrarse por escrito, como una especie de artefacto de conocimiento, siempre disponible para todos.
Mire brevemente la lista banal de herramientas con las que resolvimos nuestras tareas de comunicación dentro del equipo.
Primero, comenzamos una conversación en Telegram. Pero luego, en relación con el crecimiento del equipo, nos dimos cuenta de que en una conversación ya estábamos cerca y cambiamos a Slack. Allí dividimos el flujo general en canales temáticos y establecemos reglas claras, por qué razones escribir en qué canal. Esto ayudó a evitar mezclar información útil e inundaciones.
Además, cambiar a Slack nos dio algunas buenas oportunidades para la automatización y la integración con otros servicios, como un sistema de gestión de repositorio o un rastreador de errores.
- Llamadas de audio y video: Skype for Business.
- Realizamos tareas en Jira.
- La base de conocimiento se almacena en Confluence.
Planificación de tareas, ejecución y control.
Cuando creamos las comunicaciones, el problema de establecer, controlar y completar tareas dentro del equipo se volvió relevante (hablaré sobre trabajar con el cliente a este respecto un poco más adelante).
No teníamos una sola lista de tareas, sus prioridades, estado de preparación, etc. En lugar de un plan claro, transparente y rastreable, estaba presente la planificación y ejecución espontánea a corto plazo.
Para hacer frente a esta situación, comenzamos a usar un rastreador de errores (de hecho, probamos cinco de ellos). Comenzaron a aparecer esquemas de la dirección general del proyecto, una comprensión del estado en el que aparecían ciertas tareas y la imagen general en su conjunto. Sin embargo, nos enfrentamos al problema de la falta de disciplina cuando usamos el rastreador de errores, que comenzó a devaluar muchos de nuestros esfuerzos. No todas las tareas se iniciaron en el rastreador de errores, las existentes no siempre se actualizaron, etc. En pocas palabras, la imagen del estado del proyecto ha dejado de ser relevante y confiable.
Para combatir esto, hemos desarrollado e implementado nuestra propia cultura de gestión de tareas:
- El trabajo no debe realizarse hasta que se haya iniciado la tarea correspondiente. Esto ayuda a mantener actualizada la historia del proyecto y el trabajo del equipo.
- Cuando se trabaja con una tarea, es necesario cambiar su estado de manera oportuna. En nuestro caso, hay suficientes cuatro estados: "Para hacer": el estado de inicio de la tarea, "En curso": la tarea que está en progreso, "En espera": la tarea que comenzaron a realizar, pero el trabajo está suspendido (estamos esperando información adicional ), "Listo": la tarea está lista. La preparación de la tarea debe ser confirmada de alguna manera por el cliente o gerente dentro del equipo.
- Con el tiempo, el número de tareas y proyectos ha aumentado significativamente, por lo que hemos dividido la lista general de trabajos en subproyectos separados, y la tarea debe iniciarse de acuerdo con esta lista de subproyectos.
- La tarea debe tener asignada prioridad. Esto ayuda a comprender qué tareas en qué orden deben realizarse para obtener el máximo beneficio del proyecto.
- Tareas revisadas periódicamente y sus prioridades. Dado que los proyectos viven y se desarrollan, y los planes comerciales a veces cambian, con el tiempo, algunas tareas se vuelven menos relevantes o incluso requieren su eliminación.
- Algunas discusiones clave sobre tareas que se llevaron a cabo verbalmente o por escrito en el chat requieren que se arregle la solución final en la tarea misma, de modo que cuando la completemos siempre veamos la información más relevante al respecto y su historia. A menudo sucede que la declaración inicial del problema después de una serie de discusiones se transforma en algo completamente diferente, y necesitamos monitorear esto.
- Si la tarea se transfiere de un grupo de especialistas a otro dentro del equipo, entonces el grupo de transferencia debe fijar en él todos los artefactos de conocimiento necesarios que deben transferirse al siguiente grupo. Por ejemplo, un equipo de diseño debe adjuntar maquetas y toda la documentación necesaria para el desarrollo antes de transferir la tarea al equipo de desarrollo. Esto evita preguntas innecesarias, distracciones y cambios de contexto.
- Adjuntar confirmaciones a las tareas. Usando algunas reglas para nombrar commits, automáticamente adjuntamos enlaces a commits a las tareas de GitLab. Esto ayuda enormemente en el desarrollo para comprender quién, qué, cómo y cuándo realizó esta tarea. Y en la dirección opuesta, mediante confirmaciones con el nombre correcto, siempre puede encontrar una tarea que contenga el motivo de los cambios realizados.
Comunicación con el cliente
La siguiente categoría de dificultades que necesitábamos resolver era trabajar con los clientes. Lo primero que tuvimos que erradicar fue poner palabras en palabras. Si introdujimos la cultura de la escritura dentro del departamento, ha llegado el momento de extenderla a los contactos externos.
No es ningún secreto que a otro gerente le gusta acercarse al desarrollador, en palabras decirle lo que hay que hacer, meter los dedos en la pantalla para persuadirlo e irse, con la esperanza de que todo se haga bien y a tiempo. En esta situación, el gerente y el desarrollador pueden ser reemplazados por un propietario del producto y un cierto gerente del equipo de desarrollo que lidera todas estas tareas. El resultado de esto no cambiará.
Hay varios problemas con este enfoque:
- Lo que se dice en palabras y gestos se olvidará (al menos parcialmente) sobre mañana, en el mejor de los casos, pasado mañana. No se trata tanto de algunas pequeñas cosas, sino del peligro de olvidarse por completo de la tarea. Al mismo tiempo, es imposible confirmar de ninguna manera que se lo pones a alguien o que alguien te prometió hacer al menos algo.
- Por lo general, tal declaración del problema es bastante caótica, y no hay detalles profundos en ella. Como resultado, es muy difícil aclarar la información que falta.
- Como se discutió anteriormente, la declaración del problema en palabras satisface la renuencia corruptora a aprender a formular sus pensamientos por escrito para que otras personas entiendan.
Cuando tiene muchos clientes, y cada uno tiene sus propias características, es difícil construir un único orden de trabajo con todos. Idealmente, nos gustaría llevar a todos los clientes a un rastreador de errores, donde puedan establecer tareas, establecer prioridades, discutir detalles, aceptar el trabajo. Pero esto sigue siendo una tarea imposible. Sin embargo, pudimos encontrar un compromiso en el que las tareas fluyen juntas en un flujo estrictamente escrito a nuestro departamento de correo corporativo, y por nuestra parte, el gerente comienza y las lleva más lejos en el rastreador de errores de acuerdo con las reglas que ya se han establecido en nuestro país. Las tareas dejaron de perderse, olvidarse, almacenarse en la mente de personas específicas, discutidas por la composición incompleta de los especialistas requeridos, etc.
Luego, nos enfrentamos a un problema más importante: es difícil para el cliente formular una tarea. El cliente no siempre es lo suficientemente competente (o más bien, casi siempre lo suficientemente insuficiente) en la formulación de especificaciones técnicas para el equipo técnico. Y esto es normal. No se puede ignorar el factor humano: puede ser banal para el cliente sentirse avergonzado e incómodo de venir al equipo con una solicitud cuando él mismo aún no ha sido capaz de formularla por completo. Uno de los criterios de un equipo profesional maduro es la capacidad de ayudar al cliente a identificar sus problemas, requisitos y soluciones.
A menudo sucede que el cliente, en lugar de tener un problema, presenta una solicitud para la implementación de una solución que ya ha inventado. Para no sorprendernos ni a nosotros mismos ni al cliente con los resultados del trabajo en los ToR elaborados "en una servilleta", creamos una lista básica de preguntas para el cliente. Sobre la base de estas respuestas, es más fácil para el cliente comprender lo que realmente quiere y para el equipo de desarrollo lo que se requiere de él. Y luego es el turno de hacer algunas preguntas sugerentes para aclarar o identificar los requisitos.
Por lo tanto, antes de la primera reunión con el cliente, le pedimos que complete previamente (tanto como sea posible) y que nos envíe esta lista de verificación para que luego no tenga que perder el tiempo en las mismas preguntas, sino que inmediatamente comience un diálogo fructífero. Vale la pena señalar que al interactuar con el cliente, es importante no solo aclarar las respuestas que proporcionó, sino también sobre la base de su problema declarado para ayudarlo a identificar aquellos requisitos en los que podría no haber pensado.
Lista de preguntas para el cliente:
- ¿Cuál es el propósito del proyecto? ¿Qué problema resuelve esto? ¿Qué valor comercial tiene?
- ¿Es esta la única solución posible a este problema? Si no, ¿qué otras opciones hay?
- ¿Existen requisitos generales que abarquen todo el proyecto? Por ejemplo, si se trata de una tienda en línea, debe cumplir plenamente con la legislación que rige el comercio en línea.
- ¿Hay algún requisito funcional? ¿Qué debe hacer una sección (página, proyecto)? Por ejemplo, la sección debe proporcionar información sobre los productos de la compañía y, a través del formulario en la página, recopilar aquellos que deseen hacer preguntas sobre este producto o adquirirlo.
- ¿Hay requisitos no funcionales? ¿Qué tan bien debería hacer esto? Por ejemplo, el tiempo de apertura de la página no debe ser superior a 5 segundos.
- Requisitos adicionales Formato gratuito en el que puedes derramar el alma.
Otro problema que tuvimos que enfrentar: tareas que vienen de todos lados simultáneamente. Cuando hay muchos clientes en diferentes proyectos, todos quieren dar a su tarea la más alta prioridad. En el caso ideal general, probablemente, tal problema no puede resolverse al 100%. ¿Cómo vivimos con esto? Con la introducción de la disciplina en la formulación y gestión de tareas, así como algunos elementos de las metodologías ágiles, nuestro grupo de tareas se ha vuelto más ágil, transparente para un observador externo y, lo más importante, predecible. Hemos establecido un orden y planes dentro de nuestro equipo, y solo necesitamos fortalecer los comentarios con los clientes. Al debatir las prioridades, los plazos y los planes, aprendimos a construir un diálogo argumentativo, en lugar de arrojarnos ciegamente a las tareas y extinguir constantemente incendios en llamas (que en realidad no siempre son relevantes y no siempre son incendios).
También tratamos de erradicar el clásico antipatrón "gestión de gaviotas" en el marco de este párrafo, cuando un cliente o gerente ingresaba a tareas "establecidas" y se alejaba con plena confianza de que una vez que estableciera una tarea, ciertamente obtendría un excelente resultado. Como ha demostrado la práctica, el resultado con este enfoque no fue el más impresionante. ¿Cómo lidiar con eso? Aquí tampoco hay un consejo universal, ninguna frase mágica que cambie el comportamiento de las personas. Para hacer esto, necesitas hablar, educar, explicar, mostrar, puedes decir educar. Solo el trabajo educativo y los ejemplos positivos y negativos muy visuales o muy medibles (y preferiblemente ambos) ayudarán a superar suficientemente el "manejo de la gaviota".
Dev vs Ops
Y nuestro último problema importante es el problema de comunicación entre los departamentos de desarrollo y operaciones.
Nos enfrentamos a una situación clásica en la que los desarrolladores no entienden muy bien cómo funciona el servidor y un equipo de administración de terceros no comprende realmente cómo funciona la aplicación. Cada dificultad en la unión de estas dos esferas nos fue dada con dolor y mucho tiempo. Era difícil incluso diagnosticar de qué lado del problema:
- ¡Lo programó allí!
- No, ¡ahí tienes algo con el servidor!
En este caso, nos ayudó que apareció un desarrollador en el equipo que estaba bien versado en administración. Pudo hablar con cada grupo en su idioma y diagnosticar cada problema desde ambos lados. Las discrepancias comenzaron a disminuir, pero seguimos atados a este hombre. Para desatar todos estos problemas de sí mismo, comenzó a ayudar a los administradores a comprender cómo funciona la aplicación y a los programadores: lo que está sucediendo en el servidor. Añadimos a la explicación de la documentación de escritura de voz y obtenemos no solo el conocimiento de todo el equipo, sino también el trabajo más coordinado de los departamentos de Desarrollo y Operaciones. Sí, en grandes secciones de la sangrienta empresa hay equipos especiales y personas calificadas que configurarán todo para que los desarrolladores ni siquiera sepan cómo y dónde funciona su trabajo en el servidor. Sin embargo, en equipos pequeños sería bueno desarrollar este nivel de competencia en las personas, así como tener al menos un empleado que ya esté bien desarrollado a este respecto.
Desarrollo
Paralelamente a todo esto, emprendimos el desarrollo de una cultura de desarrollo.
No me enfocaré en la parte técnica, y ahora ya es un estándar de facto y casi todos carecen de la comprensión de la necesidad de un sistema de control de versiones, CI / CD y otras herramientas de desarrollo, ensamblaje e implementación. Me detendré solo en los momentos suaves de desarrollo.
- Codestyle Es bastante importante desarrollar y aprobar explícitamente las reglas para el diseño del código. En primer lugar, es estéticamente agradable ver una sola mirada armoniosa en el proyecto, en lugar de un zoológico de diferentes estilos y estándares. En segundo lugar, aumenta la legibilidad del código y, como sabemos, la mayoría de las veces el programador no escribe su código, sino que lee el de otra persona.
- Naming commits . Introdujimos ciertas reglas para nombrar confirmaciones, de modo que por el nombre de la confirmación quedaba claro qué cambios se hicieron, por quién y dentro de qué tarea.
- Revisión de código . Los detalles de nuestros proyectos y el equipo es tal que no tenemos una revisión obligatoria del código, sin la cual es imposible verter nuestro código en producción. Sin embargo, establecimos que al menos una persona mira el código que está presionando un colega. Esto ayuda a notar las deficiencias, introducir ideas alternativas y mantenerse al día con todas las partes del sistema. La revisión del código se ha vuelto especialmente relevante con el creciente número y complejidad de los proyectos, por lo que cada desarrollador ya no tiene tiempo para trabajar en todos los proyectos lo suficiente como para comprender todos sus detalles.
- Alinear la arquitectura dentro del equipo desde el principio . A menudo sucede que, en un esfuerzo por crear una característica más rápido, el frontend comienza a hacer algo por sí mismo, el backend comienza rápidamente por sí mismo, y luego resulta que se integra con gran dificultad o no se integra en absoluto. En el desarrollo de grandes características, discutimos conjuntamente de antemano la arquitectura, los formatos de intercambio de datos, etc. Como resultado, la integración ha dejado de ser larga y dolorosa.
- Desarrollo impulsado por CV . Este es un problema en el que los desarrolladores arrastran nuevas tecnologías (frescas, de moda, bien remuneradas) al proyecto no por el bien del proyecto, sino por una marca en el currículum. Estamos abiertos a las nuevas tecnologías y tratamos de desarrollar nuestros proyectos tecnológicamente, sin embargo, es importante mantener un equilibrio en el que habrá progreso tecnológico y proyectos completados con éxito dentro de un plazo razonable. Hay dos cosas importantes en este tema resbaladizo: que el cliente no supera los plazos para que los desarrolladores no tengan un descanso, y que el equipo de desarrollo (o, al menos, el líder del equipo competente o el equipo técnico) se preocupa no solo por desarrollar su perfil de LinkedIn, sino también por el bienestar del proyecto en general
Refactorización, deuda técnica y principio de mejora continua.
Nuestro departamento comenzó a formarse alrededor de una flota existente de proyectos realizados por subcontratistas. Naturalmente, no había documentación allí, nadie siguió la relevancia y la calidad del código. Como entendimos que todavía tenemos que trabajar, mantener y desarrollar esto durante mucho tiempo, se decidió dedicar parte del tiempo a poner las cosas en orden en el proyecto: refactorización, eliminación de código irrelevante, etc.
Como el proyecto era grande, el nivel de entropía también era alto. Nos dimos cuenta de que en una sola sesión es imposible superar todo físicamente y abandonar moralmente la perspectiva de un trabajo tan colosal. Decidimos aplicar el principio japonés de mejora continua "kaizen". Dividimos la deuda técnica en muchas partes pequeñas y poco a poco, pero cerramos regularmente estas pequeñas partes, modificando y mejorando continuamente tanto los proyectos como el trabajo del equipo mismo.
Moralmente, esto no causó ningún inconveniente, pero al mismo tiempo no tuvo un impacto significativo en el desarrollo de nuevas funcionalidades y la cobertura de los requisitos comerciales. Después de un año y medio, descubrimos que la antigua deuda técnica se había pagado por completo, y esto nos abrió oportunidades para desarrollar la funcionalidad de un nivel fundamentalmente nuevo de complejidad e importancia.Por supuesto, esto no significa que ahora no tenemos deuda técnica. A medida que los proyectos viven, evolucionan, crecen y se desarrollan, ciertamente se acumula. Sin embargo, lo supervisamos cuidadosamente, lo posponemos en un grupo especial de tareas y regularmente dedicamos algo de tiempo a pagarlo. Tal trabajo continuo con deuda técnica nos permite encontrar un equilibrio entre el desarrollo de nuevas funcionalidades y el soporte de alta calidad para las antiguas.En nuestro caso, nosotros, los desarrolladores, pudimos explicar y mostrar a los negocios la importancia de pagar la deuda técnica. ¿Cómo hicimos esto? En la práctica, hemos demostrado situaciones en las que, si no refactoriza o realiza otros cambios estructurales al proyecto actual, el desarrollo de una nueva funcionalidad o el cambio del anterior será imposible en principio (o posible, pero varias veces más lento).Implementar metodologías ágiles
La implementación de algunas ideas de metodologías ágiles nos permitió aumentar la transparencia de nuestro trabajo tanto dentro del equipo como para el negocio, para hacer que el desarrollo sea más predecible y flexible, y el resultado más estable.Lo primero que hicimos fue organizar stand-ups diarios dentro del equipo. Dado que el equipo está distribuido, Slack asignó un canal separado para esto, en el que cada empleado escribe tres puntos cada mañana: en qué tareas trabajó ayer, en qué planea trabajar hoy, hay algún problema que impida su trabajo. Está prohibido inundar este canal, discutir las tareas o problemas de alguien. Este canal es estrictamente para la agregación de información sobre el estado de las cosas. Las discusiones restantes deben llevarse a cabo en los canales temáticos apropiados. Esto permitió que cada persona en el equipo entendiera lo que están haciendo sus colegas, lo que está sucediendo con el proyecto en general, quién puede y debe ser ayudado. Si sin stand-ups los problemas se callaron, y después de mucho tiempo de repente resultó que la tarea aún no estaba lista, ahora está claro quién necesita ayuda,qué se debe hacer para que el equipo trabaje de manera más efectiva.Luego, decidimos desarrollar sprints. Todos los viernes al final del día, realizamos una retrospectiva del sprint, observamos qué tareas se planificaron, qué está listo, qué no está listo y, si algo no está listo, ¿por qué sucedió esto? Pensamos en qué problemas tuvimos y qué podríamos hacer para evitar dificultades similares en el futuro. Luego, planificamos un sprint para la próxima semana basado en la carga de trabajo de diferentes áreas dentro del equipo y las prioridades comerciales. Como resultado, al comienzo de la semana, todos los desarrolladores saben qué hacer y en qué orden, y la empresa sabe cuáles serán sus necesidades en un futuro próximo, y ya puede formar su propia "Lista de deseos" para los próximos sprints. Vale la pena decir que no nos libramos de tareas repentinas que pueden interrumpir nuestros planes de sprint.En este caso, debe actuar sobre la base de la naturaleza específica del trabajo: ¿con qué frecuencia surgen tales tareas? Cuanto? ¿Se puede predecir esto? En nuestro caso específico en desarrollo, calculamos experimentalmente cuánto tiempo en promedio cae en tareas no planificadas e intentamos colocar este margen en el sprint. Por separado, vale la pena señalar que después de comenzar a trabajar en sprints, pudimos averiguar específicamente cuánto trabajo se nos entrega en una entrada no programada, analizar y reducir esta cantidad, discutir cuidadosamente las prioridades con el cliente y mostrar claramente cómo el deseo momentáneo de obtener la función más necesaria en este momento afecta en la productividad general de todo el equipo.¿Cuál es el tiempo promedio para tareas no planificadas y tratar de establecer este margen en el sprint. Por separado, vale la pena señalar que después de comenzar a trabajar en sprints, pudimos averiguar específicamente cuánto trabajo se nos entrega en una entrada no programada, analizar y reducir esta cantidad, discutir cuidadosamente las prioridades con el cliente y mostrar claramente cómo el deseo momentáneo de obtener la función más necesaria en este momento afecta en la productividad general de todo el equipo.¿Cuál es el tiempo promedio para tareas no planificadas y tratar de establecer este margen en el sprint. Por separado, vale la pena señalar que después de comenzar a trabajar en sprints, pudimos averiguar específicamente cuánto trabajo se nos entrega en una entrada no programada, analizar y reducir esta cantidad, discutir cuidadosamente las prioridades con el cliente y mostrar claramente cómo el deseo momentáneo de obtener la función más necesaria en este momento afecta en la productividad general de todo el equipo.cómo un deseo momentáneo de obtener una característica innecesaria en este momento afecta la productividad general de todo el equipo.cómo un deseo momentáneo de obtener una característica innecesaria en este momento afecta la productividad general de todo el equipo.También pasamos de lanzamientos largos a lanzamientos cortos. Anteriormente, recibimos TK, semanas o meses hicimos un paquete completo de características, y solo entonces se lo mostramos al cliente. Como resultado, a menudo resultó que el cliente cambió de opinión o no esperaba exactamente eso, y comenzamos a rehacer todo o parte de lo que ya habíamos hecho. Y realizar cambios en un gran conjunto de características listas para usar es un placer dudoso. Ahora estamos demostrando todas las características lo antes posible para que el cliente tome una decisión, ya sea si esto es lo que realmente quería o si algo debe cambiarse. Cuanto más rápido lo apruebe o lo envíe para su revisión, menos trabajo invertiremos, por lo tanto, más rápido entrará en producción la característica. Como resultado, las características comenzaron a llegar a la producción más rápido, las hipótesis se probaron más rápido y el proyecto fue más rápido.Factor de bus
Como nuestro equipo es pequeño, inmediatamente comenzamos a pensar en los problemas que podríamos encontrar durante la rotación del personal. Personas específicas se han convertido en los únicos custodios de algunos conocimientos, los proyectos se han expandido lo suficiente y, por lo tanto, comenzamos a desarrollar una cultura de almacenamiento y gestión del conocimiento.La erradicación de este problema fue ayudada por la acumulación de artefactos de conocimiento que pasaron de las cabezas de personas específicas al mundo físico escrito. A saber:- Todo el trabajo se lleva a cabo solo si hay una tarea en el rastreador de errores. Esto le permite hacer un historial completo de cambios en el proyecto.
- Si en algún momento del chat o de la reunión discutimos los cambios en la tarea, debemos reflejar en la tarea misma el resultado de esta discusión.
- . , Gitlab. , .
- Confluence , - , .
- - postmortem « — — — ».
Todavía hay buenas prácticas, en las que, por supuesto, debe conocer la medida y no elevarla al absoluto: si se le pregunta sobre alguna parte del sistema que solo usted conoce, entonces es recomendable escribir documentación al respecto y responder con un enlace. Por lo tanto, nunca más tendrá que responder esta pregunta y preguntarle a otras personas.Este método de mantener artefactos de conocimiento nos ha ayudado repetidamente a encontrar información sobre aquellas partes del proyecto que de otra manera se perderían necesariamente. Y también redujo significativamente los riesgos para el proyecto y el equipo durante la rotación de personal. El último ejemplo: recuperamos rápida y fácilmente información sobre la lógica de negocios, el principio de operación y el método de implementación de la herramienta, que fue realizada por el empleado que renunció hace dos años.Si aplicamos trabajo con stand-ups y sprints a esta técnica, entonces el factor bus se reduce aún más. No hace mucho tiempo, realizamos un experimento: un desarrollador estaba de vacaciones y otro desarrollador trabajó. En ese momento, cuando el primero se fue de vacaciones, el segundo se fue de vacaciones. La esencia del experimento era no escribir cartas explicativas, mensajes, no entregar el caso y ver cuán difícil sería para una persona después de unas largas vacaciones entender lo que estaba sucediendo en su ausencia, qué cambió, exactamente cómo y qué planes para el futuro. Como lo ha demostrado la práctica, ver el rastreador de errores, las confirmaciones, la documentación, los stand-ups y los sprints le permitieron al empleado ingresar al curso de los negocios con bastante facilidad y continuar su trabajo de forma autónoma.Conclusión
En conclusión, me gustaría señalar que ninguno de los problemas anteriores se resolvió de inmediato y sin problemas. El cambio organizacional es siempre un trabajo largo y metódico. No puedes decir "ahora hacemos esto" y esperar que ahora todo sea diferente. Cualquier decisión que tome, cualquier evento que organice, requiere control, capacitación e iluminación de las personas, tiempo para adaptar tanto el equipo a las nuevas técnicas como las técnicas mismas a una situación específica. También noto que la imposición de una metodología en las personas es un proceso muy laborioso e ineficiente. La gente descansará, olvidará (s), quizás incluso saboteará.Para que los cambios requeridos comiencen en el equipo, el equipo mismo debe querer hacer estos cambios. Es necesario monitorear cómo está, identificar áreas problemáticas, estar al tanto de estos problemas, encontrar soluciones y solo luego implementarlas. Por supuesto, no todos los miembros del equipo deberían y quieren hacer esto, pero si hay alguien que vio estos problemas y propuso sus soluciones, primero iluminará al equipo.Comparta su conocimiento, observaciones, experiencia, discuta, muestre y pruebe dónde están los problemas ahora y qué pasos se pueden tomar para resolverlos. Solo de esta manera se pueden llevar a cabo transformaciones organizacionales a gran escala de la manera más eficiente posible. Incluso si es un líder y quiere impulsar su posición y su decisión, intente hacerlo de la manera más convincente y convincente posible, ahorrando así tiempo en la implementación y salvando al equipo de negatividad indeseable.Publicado por Evgeny Antonov, Jefe del Grupo de Desarrollo de Tecnologías Positivas