Sin embargo, en muchos dominios, el cliente típico es:
- Interesado en preocupaciones operativas diarias: tácticas de corto alcance ... no estrategia;
- Solo preocupado por la solución inmediata;
- Generalmente pensadores unidimensionales, no abstractos;
- Principalmente interesado en "hacer el trabajo" en lugar de encontrar una solución duradera y de calidad.
Y para ser sincero, generalmente tienen buenas razones para pensar así. En primer lugar, están administrando un negocio, que debería generar ingresos hoy y mañana, no en un futuro lejano. En segundo lugar, no son expertos técnicos: no saben qué es posible y qué no, y cuáles son las consecuencias de las elecciones específicas de arquitectura / diseño / implementación. Esto es lo que sabemos.
Entonces la respuesta es, apenas sorprendente, la comunicación .
Deben comunicarse mucho, educarse mutuamente, hacerse entender el punto de vista de la otra parte, al menos a un nivel básico. Debe explicarles las consecuencias a corto y largo plazo de las posibles alternativas. Y necesitas usar un lenguaje que ellos entiendan .
- Si dices "esto sería un truco, lo que hace que el código sea menos legible y extensible" , dicen "sí, lo que sea" .
- Si dice "esto sería una solución a corto plazo, lo que haría más costoso el desarrollo y el mantenimiento a largo plazo y aumentaría el riesgo de introducir errores" , dicen "ja, consideremos" .
- Y si dice "esta solución le costaría $ 100 ahora, pero introduce $ 500 de deuda técnica que deberá pagar con intereses tarde o temprano; OTOH, esta otra solución le cuesta $ 400 ahora y no deja deuda técnica; elija la que usted quieren " , dicen " ¡ahora estamos hablando! " .
OTOH pueden enseñarnos una o dos cosas sobre la perspectiva comercial. El negocio quiere soluciones utilizables y lo suficientemente buenas , apenas perfectas .. Y probablemente saben mejor que nadie que "lo perfecto es enemigo de lo bueno". Por lo tanto, debe tener en cuenta que nuestro trabajo es proporcionar soluciones a los problemas de nuestros clientes, en lugar de producir un software técnicamente perfecto. A veces estos dos convergen en lo mismo, pero más a menudo no. Esto puede ser visto como triste por muchos, pero es una realidad empresarial. Para mí, si logré resolver el problema de mi cliente y veo que les hizo la vida visiblemente más fácil, estoy tan feliz como ellos. OTOH si logré implementar el diseño perfecto que tenía en mente, pero la empresa se declara en bancarrota la semana siguiente, difícilmente sea una victoria para alguien, ¿verdad?
Un propietario de negocios sensato comprenderá, si usted les explica que usan su propio idioma, por qué es importante mantener limpio el software, escribir pruebas unitarias, refactorizar, etc. A pesar de que estos no parecen contribuir directamente en el corto plazo, son esenciales para el mantenimiento a largo plazo. Y los clientes sensatos se preocupan por el mantenimiento a largo plazo de su negocio, por lo que seguramente están dispuestos a invertir en él cuando vean el valor que genera su inversión. Sin embargo, tanto sus recursos como su tiempo son limitados, por lo que debe priorizar y centrarse en las cosas más importantes. Pero es importante solo si es importante para ambos .
Es posible que desee refactorizar el módulo A porque el código allí es simplemente horrible, y tiene una idea estupenda de cómo refactorizar el código para que sea conciso, elegante y limpio, utilizando un patrón de diseño sobre el que acaba de leer. Sin embargo, si ese módulo no se ha tocado durante años, y funciona de manera confiable, lo más probable es que se concentre en el módulo B, que se extenderá la próxima semana con una nueva característica muy importante, y contiene toneladas de errores ya.