Un Buen Proyecto (1)

Siguiente Post


En mis charlas de TDD (Test-Driven Development) comento algunas características de lo que tendría que ser un proyecto bien terminado. Algo ya comenté en TDD y Diseño de Implementación (1). Hoy quiero escribir (es decir, pasar en limpio, compartir, explicar un tema para ver si lo entiendo) sobre un tema más amplio: lo que considero un buen proyecto. Pensé inicialmente que bastaría un solo post, pero nones: éste va a ser el primero, y luego seguiré escribiendo.


Pongo algo de contexto. Voy a escribir sobre un proyecto:


- Profesional


- Con desarrollo ágil en equipo, con iteractiones, backlog, etc..


- Cliente externo, con un representante


- Para ejecutar en producción


Es decir, no necesariamente tiene que ser de código abierto (en mi caso en general no es), no es algo que armamos en nuestro tiempo libre (no, es un proyecto de nuestro trabajo de desarrollo de software), no es una demo, va a estar en producción y tendrá un ciclo de vida (no necesariamente apoyado por nosotros: el proyecto tiene una terminación y una entrega final). Igual admito que es difícil abarcar todos los proyectos profesionales. Pero creo que con lo que voy a describir varios proyectos serán incluidos en esta exposición.


Entonces, en este marco, ¿cuáles son las características que tendría que tener un proyecto terminado para que digamos: “es un buen proyecto”? En el sentido de sentir y pensar que lo que entregamos es bueno. Claro, depende de bueno ¿para quién? Como estamos en un proyecto profesional, lo principal es que sea bueno para el cliente (empresa) que nos contrata. Puede ser bueno para nosotros (“uy, aprendí un montón de MVC”), para el equipo (“nos integramos y conocimos”), para nuestra consultora (“uy, con lo que ganamos podemos comprar nuevas oficinas”, o “ahora podemos ser conocidos por haber trabajado en este gran proyecto”), para el mundo (“ahora hay un nuevo framework que todos podrían usar para ser más productivos, etc… “). Pero lo que importa es:


TIENE QUE SER BUENO PARA EL CLIENTE


Vean que más arriba escribí “cliente (empresa)”. Es decir, tiene que ser bueno para la empresa o sector de la empresa que nos contrata. No hay que medir (en principio) que sea “bueno para Charles”, por ser Charles nuestro contacto principal en la empresa. A no ser que sea Charles el que pague la factura, no es el “cliente”. Es un representante del cliente.


Para ponerlo en claro: no es QUE NO IMPORTA absolutamente que nosotros encontremos que el proyecto haya sido bueno para Charles, para el equipo, o para nosotros mismos. No, estoy tratando de encontrar cuál es lo MAS importante.


Pues bien, después de haber participado en este siglo en varios proyectos ágiles, y también viendo el resultado de otros varios más proyectos, con casos de éxitos y fracasos, lo mejor que puedo decir es:


Un proyecto es un buen proyecto terminado y entregado, SI SOLUCIONA EL PROBLEMA DEL CLIENTE


No nos piden simplemente “necesitamos el sistema X”, sino, “necesitamos el sistema X que solucione el problema P”. Otras veces, nos dan más libertad “necesitamos una solución S que solucione el problema P”, pero es menos frecuente el caso. Pero muchas veces (la mayoría de ellas) nos piden “necesitamos el sistema X” sin poner muy en claro el problema que tiene que solucionar.


Para poner un ejemplo. Supongamos que nos piden “Necesitamos un Sistema de Producción”. Puede ser que el contexto del cliente sea:


“Somos una empresa productora familiar, que en los últimos años, con la entrada de la tercera generación en la gerencia, ha podido expandir el mercado en el exterior”


Entonces, puede el problema a solucionar puede ser uno de éstos, entre tantos:


1 – “Se nos ha ido de las manos la producción, necesitamos un sistema que nos permita manejar mejor la asignación de las máquinas. Hoy las desaprovechamos”


2 – “Las máquinas las asignamos bien, pero tenemos problemas en el seguimiento de los insumos que necesitamos y cuándo los necesitamos. No queremos tener stock de esos insumos en estos tiempos de cambio”


3 – “Nuestros principales clientes del exterior nos piden trazabilidad norma (y aquí viene una sigla desconocida para nosotros) de acá a fin de año, sino perdemos nuestro principal contrato con China”


4 – etc


Vean que entendiendo el problema podemos poner distinto énfasis en lo que vamos a construir, y con el representante del cliente, podemos tener más en claro qué es lo que aporta más valor al cliente. En el caso 1, tendremos que poner mayor esfuerzo en un plan de asignación de máquinas, y no tanto en el stock de insumos. En el caso 2, es al contrario. Y en el caso 3, tendremos que estudiar qué es eso que piden de trazabilidad.


Pero vean a lo que voy: podemos entregar el mejor sistema de producción, que asigne con algoritmos de inteligencia artificial las máquinas de la mejor forma posible, escrito con todos los patrones encima, con la mejor UI para desktop, web, tablet, y hasta TV,  pero no es la solución del problema del cliente, si estamos en el caso 3.


ESO ES LO QUE HAY QUE ENTENDER PRIMERO.


A ver, de nuevo:


EL ENTREGABLE DEL PROYECTO DEBE SOLUCIONAR EL PROBLEMA DEL CLIENTE


Y acá entra la capacidad del representante del cliente para ponernos más en claro cuál es el problema real.


No quisiera terminar el post, sin comentar algo. Hay diferencia entre problema y solución. Como escribía arriba, muchas veces nos piden el sistema. Pero tenemos que esforzarnos, como profesionales, para ver si el sistema inicial pedido soluciona o no el problema, o si es el mejor camino para solucionar el problema. En general, eso ya se definió antes de llegar el proyecto a nuestro equipo. Pero igual deberíamos tenerlo en cuenta. Tal vez, en vez de hacer sistema S, podemos hacer sistema S’ que tenga algunas características sugeridas por nosotros que mejoren alcanzar la solución del problema.


Siempre recuerdo a Henry Ford, diciendo: “Si le hubiera preguntado a mis potenciales clientes qué querian, me hubieran pedido ‘caballos más rápidos’”.


Nos leemos!


Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in 10549, 3463. Bookmark the permalink.

One Response to Un Buen Proyecto (1)

  1. Me gustó la definición de BUEN PROYECTO, y respecto a que la definición ya este decidida antes de comenzar, como bien dijiste al final, en lugar de hacer un sistema S podemos hacer un S’, creo que eso es agregarle un valor adicional al proyecto, porque le estas dejando saber al cliente como podria hacerse mejor todavia. De la otra forma, serias un proveedor mas del monton :)

    Gracias Angel, un abrazo!
    Seba

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>