Esto se reduce a lo que comencé a pensar como "El conflicto eterno" (entre negocios e ingeniería). No tengo la solución, ya que es un problema que nunca desaparece, pero puedes hacer cosas para ayudar a mitigar.
Lo que la gente a menudo no se da cuenta es que, como ingenieros, estamos asumiendo que el problema del "negocio exitoso" siempre es un hecho. Queremos que nuestro código sea agradable, ordenado y fácil de mantener para que podamos agregar nuevas funciones y ajustar las existentes rápidamente y con un mínimo de clientes haciendo QA por nosotros descubriendo casos extraños que hubieran sido frustrados por un mejor código. Mantener a los clientes y mantener una ventaja competitiva con características y delicadeza que nadie más puede producir con la suficiente rapidez son dos ventajas comerciales a las que contribuye un buen código e informan en gran medida la razón por la que queremos un mejor código en primer lugar.
Así que explícalo. "Queremos hacer X en nuestra base de código porque si no lo hacemos, impactará negativamente en el negocio debido a Y" o "... porque mejorará nuestra capacidad de seguir siendo competitivos al mejorar nuestra capacidad de cambiar nuevas mejoras y características más rápido ".
Y haga todo lo posible para tratar de obtener evidencia tangible de que las mejoras están funcionando. Si mejorar algún subconjunto de una aplicación resultó en una función / mejora más rápida, verifique cualquier herramienta de trabajo atrasado que pueda estar usando para evidencia de ello y apúntela en las reuniones apropiadas.
- Pon al equipo en la misma maldita página
Los egos son a menudo un problema. Una cosa que los equipos de ingeniería necesitan con urgencia es establecer el valor de tener algún tipo de enfoque consensuado para resolver ciertos tipos de problemas en lugar de que todos hagan su propia taza de Kool Aid d'jour porque saben más. Está bien creer que la preferencia del otro tipo es peor que la tuya, pero valora la coherencia en lugar de tener más razón si su enfoque es viable y es un argumento que no puede ganar. El compromiso por el bien de la consistencia es clave. Cuando las cosas son consistentes, es más difícil hacerlas mal, ya que la forma establecida y consistente también será la más rápida.
- Elige las herramientas adecuadas
Hay dos escuelas de marcos / conjuntos de herramientas / bibliotecas / lo que sea. "Configura el 99% para mí, así que tengo que saber / hacer muy poco" vs. "mantente fuera de mi camino cuando no te quiero allí, pero ayúdame a hacer bricolaje muy rápida y consistentemente con las cosas que realmente quiero para usar en el principio de zanahoria en lugar de palo ". Favorecer el segundo. La flexibilidad y el control granular nunca deben sacrificarse en el altar de un cambio rápido porque, por ejemplo, "no podemos hacer esto porque nuestras propias herramientas no nos lo permiten" nunca es una respuesta aceptable y la pregunta siempre surgirá Ingeniería de producto trivial / desechable. En mi experiencia, las herramientas inflexibles casi siempre se rompen de par en par o se solucionan de manera poco elegante y hacen un gran desastre gigante inmanejable. Más a menudo que no, las soluciones flexibles / más fáciles de modificar son igual o casi tan rápidas a corto plazo, independientemente. Rápido, flexible y fácil de mantener son posibles con las herramientas adecuadas.
- FFS, si los ingenieros no deciden, al menos obtenga información del ingeniero al elegir las herramientas
Tengo la sensación de que esta es una pregunta de perspectiva del desarrollador, pero he estado en demasiadas situaciones en las que las decisiones tecnológicas se tomaron con cero aportes del ingeniero. ¿Qué demonios es eso? Sí, en última instancia, alguien debe hacer la última llamada, pero obtener opiniones calificadas si es un gerente no técnico, no lo que dice un vendedor o un sitio de demostración sobre sus propios productos. Cualquier cosa prometedora para ahorrarle dinero porque las personas no necesitan ser tan inteligentes o porque protege a los desarrolladores de sí mismos es una mentira sucia y sucia. Contrata talentos en los que puedas confiar. Explíqueles lo que desea de una pila u otra solución tecnológica y tómese en serio sus aportes antes de decidir a qué carro tecnológico se subirá.
- Centrarse en el diseño sobre la implementación
Las herramientas son para la implementación y, como tales, pueden ayudarlo, pero la primera prioridad debe ser la arquitectura, independientemente del conjunto de juguetes que tenga para construir esa arquitectura. Al final del día, KISS y DRY y todas las excelentes filosofías que se extienden de esos asuntos más que si se trata de .NET o Java o tal vez algo que es gratis Y no apesta.
- Registra tus preocupaciones
Cuando el lado del negocio insista en que lo haga de la manera incorrecta, guarde ese correo electrónico, especialmente la parte donde dijo por qué le costaría. Cuando todas sus predicciones se hacen realidad y resultan serios problemas que dañan el negocio, es cuando tiene una gran cantidad de argumentos para tomar las preocupaciones de los ingenieros más en serio. Pero cronometra las cosas con cuidado. En medio del infierno ardiente es un mal momento para un "te lo dije" en el siguiente código de incendio. Apague el fuego y lleve su lista de preocupaciones previamente ignoradas a una reunión / conversación retrospectiva, e intente mantener el enfoque en las preocupaciones de ingeniería expresadas e ignoradas y el razonamiento que entendió por qué se ignoraron, no los nombres de las personas reales tomando la decisión de ignorar. Eres ingeniero Mantente en los problemas, no en las personas. " Expresamos preocupación por X porque temíamos que esto condujera a problemas con Y. Nos dijeron Z y posponer el trato con eso ".