Si me exijo rendir cuentas de mi profesión y de mi rol en esta industria del software, y partiendo de una conciencia mínima de lo que es ejercer la arquitectura de sistemas, entonces también me obligo a mí mismo a intentar aportar más ante ese reto que todos compartimos: ¿cómo mejorar la calidad de los sistemas y el nivel de servicio hacia clientes y usuarios?
Estoy de acuerdo en que suele ser inútil imponer o exigir la transformación de los demás si a la par no exijo los cambios pertinentes de parte propia. Pero si tomamos la pauta de «no imponer» como principio profesional, entonces por consistencia habría que resolver la cuestión de por qué los clientes y usuarios tienen que padecer la imposición de un nivel de calidad aplicativa por debajo de sus expectativas.
Algunas personas cambiamos en la medida en que tomamos cuenta de que somos parte del problema. Esa conciencia, en ocasiones, llega a través del diálogo. Pero hasta para dialogar de manera efectiva se requiere preparación y no ignorar los básicos; por ejemplo, prestar atención a las razones del otro. En ese sentido, como sugerencia y como tan sólo una parte de la estrategia ante el reto de la calidad, si podemos indagar y enfrentar las razones de fondo en el proceso de desarrollo que ha producido el presente nivel de calidad, entonces sería como hacer “debug” a ese proceso. Tal “process debugging” representa una práctica aceptable en la profesión; ejemplos: Software Engineering Classics: Software Project Survival Guide / Debugging the Development Process / Dynamics of Software Development.
