sábado, octubre 15, 2011

La escultura, el escultor, la técnica de esculpido o la marca del martillo

Era común que Miguel Angel, Da Vinci, Dalí y Rodín generaban gran parte de su dinero realizando obras por encargo, ¿qué hubieran pensado si sus clientes les impusieran la técnica de esculpido o las marcas y formas de las herramientas que usaban? El ego artístico hubiera sido profundamente herido.

Dependiendo del contexto con el que analicemos una obra artística, por ejemplo una escultura, nos puede importar más la obra en sí, el escultor, la técnica o las herramientas que utilizó el artista para labrar la piedra y develar la obra de arte que vivía dentro de ella. En un punto de vista práctico, la escultura ocuparía el interés de la mayoría de las personas.

En este marco de referencia, muchas veces nuestros clientes se preocupan por cosas que no necesariamente están relacionadas con su entregable final que es el sistema funcionando, sino que su principal enfoque va hacia dentro de la organización, sobre detalles de cómo debería realizarse su proyecto. Compartimos la importancia de asegurarse que la producción de sistemas se haga en un entorno de procesos definidos, personal entrenado y un ambiente que promueva la discusión y creatividad; desgraciadamente para el cliente no educado en el contexto de creación de sistemas de información, su involucramiento en piezas finas normalmente entorpece el desarrollo en tiempo de entrega y calidad de su producto.

Siendo pragmáticos en esta situación, podemos pensar en las siguientes preguntas:
¿Cuándo me debe interesar predominantemente el resultado de un sistema?
Cuando mi interés está centrado en contar con un programa operando y no cuento con tiempo y/o conocimiento acerca de temas relacionados a la tecnología. En menos palabras: tengo un problema, tengo que solucionarlo y no tengo necesidad de clavarme en temas relacionados a cómo o con qué hay que hacerlo.

¿Cuándo me debe interesar el recurso humano que realizará o implementará mi sistema?
Si busco una solución más profunda del problema y quiero reducir al máximo mi riesgo de fracaso. Si tengo un problema complejo a solucionar, requeriré talento amparado por recurso humano acreditado, experiencia y alto nivel de de involucramiento en el equipo de trabajo.

¿Cuándo me debe interesar el proceso de desarrollo?
Si deseo reducir aún más el riesgo de fracaso y asegurarme de tener una solución bien diseñada elaborada por un equipo de trabajo cuyos resultados son predecibles. Los pasos formales que lleva a cabo un equipo de trabajo para producir una pieza de software es una parte importante dentro de la ecuación del éxito.

¿Cuándo me deben interesar las herramientas de desarrollo?
Cuando cuento con una plataforma ya elaborada y requiero que se le hagan adaptaciones sin que se note un cambio de contexto; en este caso, es muy probable que la labor se deba realizar sobre la misma tecnología con la que cuento actualmente.

Las preguntas anteriores trabajan alrededor del “¿cuándo si?”; pero analizar el “¿cuándo no?” puede resultar también enriquecedor. Seamos más prácticos en los siguientes puntos:
· No me debe interesar el recurso humano, en particular, si estoy depositando mi proyecto en una organización de probada experiencia así como acreditada en sus procesos y resultados.
· No me deben interesar las herramientas de desarrollo si no pretendo continuar yo mismo con el trabajo o si no me interesa que la nueva funcionalidad esté altamente acoplada con un sistema actualmente existente.

Inclusive intentar cambiar la tecnología, herramientas de trabajo o procesos de un equipo ya establecido, probado y operante puede resultar en algo completamente contraproducente en función de la velocidad, certeza y resultado final del proyecto; normalmente las organizaciones cuentan con tecnología y procedimientos establecidos para garantizar el mejor resultado posible, cosechar un éxito es tan simple como dejarlos trabajar.

¿En dónde sí debo tener un involucramiento activo como cliente de un equipo de desarrollo?
En la definición, priorización, validación de alcances y validación de entregas. La mejor oportunidad para un proyecto de asegurar el éxito es vivir un proceso de diseño con la profundidad suficiente que permita descubrir su propia versión más simple y enfocada a la mejor oportunidad. Aquí está el lugar donde tu, como cliente, puedes ejercer control sobre un equipo competente de desarrollo.

Para concluir podemos discutir un punto que genera tendencias más basadas en la emoción o la costumbre que en un razonamiento lógico: ¿qué tecnología es mejor?. Podemos exponer con certeza que, acotándonos a los sistemas de información, una solución en .NET, Java, PHP, Ruby, Python, entre otros, puede ser igualmente buena ya que todos son lenguajes robustos y altamente probados alrededor del mundo.

En un muy particular punto de vista: una buena o mala ejecución de un proyecto de desarrollo de software reside completamente en los procesos y el talento humano que materializa un sueño, tanto del lado del cliente como de la casa desarrolladora.