Recientemente, veo muchos ejemplos de cómo los gerentes de proyectos técnicos (también conocido como CTO) siguen los cánones del culto de Cargo en el desarrollo y la gestión de proyectos, en lugar de introducir entidades según sea necesario y construir el proceso en función de las necesidades actuales, los recursos disponibles y las habilidades artistas intérpretes o ejecutantes Hablaremos sobre cómo identificar a un cultista de Cargo y qué riesgos asumen para el proyecto.
Debates diarios por la mañana (también conocido como Daily Standup)
A mi pregunta natural a uno de estos CTO: cuán tangible es el beneficio de este evento, el CTO respondió honestamente: "Yo tampoco lo sé". A pesar de algunas ventajas para el equipo, parte del cual trabajó de forma remota, las discusiones se redujeron a "Ayer escribí código, hoy escribo código y mañana planeo escribir código también, pero, bueno, todavía corrijo tales errores". Como resultado, tenemos menos media hora de cada miembro del equipo. Una ventaja adicional para los trabajadores remotos es la comunicación diaria con el equipo, para algunos es importante. En mi opinión, la utilidad de tales debates diarios para el desarrollo es bastante pequeña, ya que la tarea principal de tales reuniones generales es brindar a todos información sobre el estado actual del desarrollo, planes para el futuro cercano (de una semana a un mes), para discutir algunos temas que interesan todos. Muy a menudo, tales discusiones se deslizan en discusiones sobre algunos problemas de nicho que son interesantes para un par de personas, y el resto comienza a aburrirse y espera cuándo terminará. Esto ciertamente debería ser suprimido y discutido más tarde, en un formato más restringido. El estado actual de desarrollo y los planes son muy importantes, pero es suficiente discutirlos una vez a la semana o incluso menos, dependiendo de la velocidad con la que trabaje el equipo.
Despliegue en la nube
Actualmente, hay muchas herramientas disponibles que le permiten describir la infraestructura del proyecto (servicios, redes, dependencias) en una forma conveniente, por ejemplo, Terraform. Esto es ciertamente útil, pero con un cierto tamaño de proyecto, por ejemplo, cuando se vuelve bastante complicado. Para la mayoría de las startups y proyectos pequeños, esta es una herramienta redundante, ya que la infraestructura cambia extremadamente raramente, y se necesita la capacidad de implementar rápidamente otra Producción, en términos generales, una vez al año, muchas startups simplemente no pueden sobrevivir. Por lo tanto, cuanto más simple se describa el proyecto, mejor, para muchos, Docker Compose será suficiente.
Cobertura de código con pruebas unitarias
El entusiasmo excesivo por las pruebas lleva al hecho de que se gastan recursos de desarrollo preciosos en él, aumenta significativamente el costo de refactorización (después de todo, todas las pruebas afectadas deben reescribirse) y a menudo crea la ilusión de la confiabilidad del código y la corrección de su funcionamiento. Conocí una startup donde, después de un año de desarrollo, ¡se escribieron más de 2000 pruebas solo para backend! Para avanzar de manera efectiva en el desarrollo, las pruebas deben cubrir solo secciones realmente importantes del código donde se realizan algunos cálculos y el diagnóstico manual de errores es difícil. A menudo, para las nuevas empresas, la cobertura de la prueba puede retrasarse hasta que la estructura del código se estabilice, y la lógica empresarial se aclare y es poco probable que cambie significativamente. Para las pruebas de unidades frontend, a menudo son ineficaces, ya que generalmente no hay suficientes cálculos y algoritmos complejos, y es mejor cubrir la funcionalidad básica de SPA, como presionar botones durante la fase de prueba de BlackBox a través de Selenium o similares.
Gestión del proceso de desarrollo.
CTO Cargo Cultist siempre usa esas herramientas y tecnologías que alguna vez funcionaron para él antes, leyó antes sobre algunas cosas interesantes o le dijeron sobre ellas. La aplicabilidad de todo esto en las condiciones actuales es difícil de evaluar para él, por lo que sigue claramente los cánones del culto a Cargo: "después de todo, un avión voló antes, así que lo estoy haciendo bien". Convencer a CTO de que es mejor usar otras herramientas y tecnologías para el proyecto actual se convierte en una tarea ardua y no trivial, porque CTO no está acostumbrado a analizar las consecuencias.
Gestión del equipo
Hay un camino para el cultista de Cargo, y él lo sigue. El hecho de que la gestión del equipo debe desarrollarse sobre la base del estado actual del proyecto, sus requisitos, calificaciones y limitaciones del contratista es nuevo para él y no le da ninguna importancia, ya que tiene un alto riesgo de no poder hacer frente. No es fácil para él admitir que debe haber una actitud diferente hacia los desarrolladores Senior y Middle, que hay desarrolladores con especialidades en comunicaciones, enfoque de negocios y responsabilidad. Para él, todas las piezas en el tablero de ajedrez son casi iguales; él hace los movimientos casi iguales. Lo más probable es que no haya escuchado sobre el hecho de que es necesario identificar y usar los puntos más fuertes de cada desarrollador. Debido a esto, la eficiencia del trabajo del equipo se reduce significativamente, los desarrolladores lo notan muy bien y esto los hace menos satisfechos con el trabajo, generalmente se caracteriza por una rotación decente. A menudo, a estos CTO les gusta decir que todos tienen desarrolladores Fullstack, aunque personalmente rara vez he visto frontend y backend igualmente fuertes, es necesario conocer demasiadas tecnologías a un buen nivel.
Cómo no convertirse / no ser un cultista del Cargo
- Siempre tome un enfoque crítico para introducir nuevas entidades (servicios, tecnologías). Si hay personas en su equipo que conocen bien MySQL pero no han trabajado con Postgres, entonces no tiene sentido elegir Postgres si esto no le brinda ventajas significativas.
- El proceso de desarrollo debe adaptarse al equipo y al negocio. Si Vasya trabaja en Scrum y cubre todo con pruebas unitarias, esto no significa que este enfoque también funcione para usted, siempre debe evaluar críticamente y comparar con otras opciones (Cascada). Como regla general, lo que funciona para un equipo pequeño deja de funcionar para un equipo grande y viceversa.
- Identifique las fortalezas de los miembros del equipo y utilícelas al máximo. Esto aumentará la eficiencia de todo el equipo, y los empleados estarán más felices, ya que aportan más beneficios por menos esfuerzo.