Durante la semana pasada el tema recurrente con el que me he visto involucrado es: ¿En verdad lo que estoy desarrollando genera algún valor?, ¿Cuánto tiempo va ser útil lo que se entregue del proyecto?
Lo anterior son una serie de preguntas que en la mayoría de los casos, toman relevancia en los momentos finales del proyecto, en la entrega del resultado o más aun cuando nuestro cliente dice: “Esto que están entregando no es lo que esperábamos”, clásico pero muy cierto y recurrente.
Casi siempre se tienda a caer en ambigüedades como querer emplear tecnologías “tan innovadoras” y “tan de moda” llenas de términos “rimbombantes” con tal de impresionar al cliente, es decir un típico escenario de proyecto “buzzword compliance”: “Si implementamos SOA 2.0 vamos a apuntalar a los equipos de trabajo y capitalizaremos en valor de la empresa”, “Deberíamos subir nuestros servicios a la nube para así migrar todas las aplicaciones para que sean RIA al 100% y sean compatibles con Web 2.0“.
Otro escenario común es cuando en un proyecto nos asignan una pieza “compleja” un: “Generador de notificaciones asíncronas mediante scheduler para ambiente mutithreading”, el cual debe de finalizarse el 2500 horas, donde dicha pieza fue definida en la etapa de arquitectura del proyecto por el “master architect” de soporte a pre-venta. Después de leer la especificación uno le indica al “manager”: Oye pero el requerimiento indica que el programa solo debe de mandar un correo al administrador cuando llegue un nuevo registro en la base de datos, que no basta con definir un job y ahorrarnos ese tiempo?….les parece familiar? o como decimos por acá, “para que tanto brinco estando el suelo tan parejo”.
Existen aspectos “primordiales”, antes de diseñar o codificar una pieza de software que es importante reflexionar:
a) ¿Cuál es la finalidad del funcionamiento de esta pieza y quienes la van a utilizar?
b) ¿Es necesario esta pieza dentro del “todo” del proyecto?
c) ¿Están definidos y son claros los contratos de los componentes?
d) ¿Es necesaria TODA la funcionalidad que estoy pensando implementar?
De tal forma que cuando se entregue nuestra pieza esta permita ser medida en función de los requerimientos e integración con los demás componentes, así como la funcionalidad comprendida sea única y estrictamente necesaria, recordar el YAGNI, y de paso ahorrar tiempo de corregir nuestros errores, perdón mejor dicho “refactoring del código para mejorar performance” suena mejor.
En resumen es importante siempre entregar un resultado que al final genere un “valor” y que cumpla con las expectativas de nuestros usuarios o clientes finales, que los haga sentirse conformes con su inversión y lo consideren como algo “valioso” y “útil” o simplemente “vale la pena su costo”, es importante tener en cuenta que en términos de software es difícil cuantificar su valor.
Geek, Software, Tips & Tricks | Heinsk | 
December 10, 2009 3:09 am | 
Comments (0) 
Subscribe