Las últimas dos respuestas son acertadas, y ampliaré con algunos puntos personales que he encontrado útiles:
- Experiencia trabajando en proyectos más grandes con múltiples equipos para experimentar éxitos y fracasos con las personas. Esto es para que aprenda lo que es realista dados los recursos y procesos de una empresa. Raramente he estado en un proyecto donde se me ha dado suficiente tiempo ni personas para obtener la solución ‘ideal’, por lo que aprende muy rápidamente lo que puede lograr con los equipos con los que trabaja.
- Experiencia trabajando con diferentes tipos de personas (por las habilidades de comunicación y la inteligencia emocional necesarias para que las cosas sucedan)
- Reflexión constante sobre sus éxitos y fracasos. ¿Por qué tuvimos éxito esta vez, o por qué fallamos esta vez?
- Siempre encuentre las causas de los problemas. No presumas ni asumas cosas. Encuentre evidencia objetiva para probar la causa raíz. De lo contrario, volverá a morderte … aproximadamente 2 o 3 años después, cuando menos lo esperes.
- Diferenciar claramente qué es un ‘must’ versus qué es un ‘nice to have’.
- Trabaje para mantenerse objetivo y evite emocionarse en la toma de decisiones. es decir, escuche a sus clientes (miembros del equipo) – y elija una solución que haga felices a la mayoría de las personas -> no tiene sentido hacer una arquitectura que nadie quiera usar.
- No todos los problemas tienen que ser resueltos por software. Por ejemplo, a veces una sesión de capacitación sobre cómo usar un módulo funcionará, en lugar de hacer que su módulo de software sea 10 veces más complicado para evitar el mal uso (Confíe en sus compañeros). Otro ejemplo es pedirle al equipo de hardware que agregue una característica, en lugar de implementar una solución de software compleja que no sea 100% efectiva (resuélvala donde debería resolverse).
- Tome medidas activas para evitar que ocurran errores dos veces. (Pruebas de regresión, mitigación de riesgos, etc.).
- No seas indeciso por mucho tiempo. Probar algo y fallar puede ser más rápido. Un seguimiento -> no castigue el fracaso. En cambio, castigue la falta de respuesta efectiva a un fracaso.
- Mantenga el control de su deuda de diseño utilizando medidas objetivas. por ejemplo, si tenemos más de X problemas en el diseño, debemos dejar de parchear el diseño y resolver / refactorizar.
- Esté dispuesto a dar malas noticias a los gerentes por adelantado (gestión de expectativas) y obviamente tenga soluciones preparadas para suavizar el golpe. No tiene sentido ocultarlo.