Es difícil negar que el concepto
de proyectos de tecnología asusta a las compañías, presidentes, inversionistas,
y ni se diga a los propios tecnológicos que tienen que ejecutarlos. Y es que es
más sencillo mantenerse con lo que la empresa ya tiene, bien que mal ya
funciona, a embarcarse en un proyecto que puede durar años, costar millones de
dinero y de cabezas y en muchas ocasiones dejarse a la mitad, sin terminar. Los
proyectos de tecnología suelen costar puestos, hasta áreas enteras. ¿Pero
porque es tan difícil hacer que un proyecto de tecnología sea exitoso? Desde mi
perspectiva, el problema principal radica en como abordamos los problemas, en el
por qué abordamos proyectos de tecnología sin considerar variables que si
consideramos en otro tipo de proyectos. Pensemos por un momento en la construcción
de una casa, tardamos tiempo identificando si tenemos esa necesidad de
construir una vivienda, analizamos el terreno, la distribución, los planos, las
tuberías, probamos cada componente, nos aseguramos de tener buenos cimientos, analizamos
todo antes de iniciar la construcción.
¿Porque entonces cuando hacemos
un proyecto de desarrollo saltamos a codificar sin hacer algunos de estos análisis?
Desde mi experiencia, en esta
entrada, quiero compartirles algunos tips a considerar al momento de iniciar un
proyecto de tecnología:
1. Iniciar siempre con las preguntas adecuadas
y cuestionar las respuestas: Algunas compañías me han contactado para
ofrecerme participar en distintos proyectos tecnológicos, implementaciones de soluciones,
un ERP, CRM, un bus de servicios etc. Mi pregunta inicial siempre es, ¿Por qué han
decidido implementar un producto de este tipo?
Si pudiera
tabular las respuestas que he recibido, un 60% de las compañías me dirán que
consideran que este sistema solucionara algún problema existente, mientras que
otro grupo, también mayoría, seguro paso por un proceso de consultoría que
entrego esa necesidad como sus recomendaciones de cierre. ¿Ninguna de las dos
respuestas satisface suficientemente mi objetivo inicial de hacer el proyecto,
la razón? Ninguna de las dos respuestas deja ver que la compañía en realidad
ejecuto un análisis que la llevo a determinar cómo esa iniciativa apalancara su
estrategia.
Cuando lo que se
desea es solucionar un problema, el análisis debe ir mucho más de un software,
y debe involucrar los procesos corporativos, las personas involucradas y la
cultura organizacional. Con todo eso solventado, un software solo mejorara la
productividad, pero ya no existirán problemas, el problema se puede solucionar
con un papel y la automatización no es cura para ese mal, ¿o entonces las
empresas antes de la tecnología no tenían problemas?
Cuando el análisis
es de un consultor, esto es aún peor. Puedo estar disparándome en el pie pues
he sido consultora en el pasado, pero debo decir en defensa de muchos
consultores que conozco que no todos somos iguales. Pero la mayoría, los
grandes, suelen aplicar plantillas de análisis y respuestas a todas las
compañías, sin tomarse el tiempo real de analizar las características específicas
de cada corporación, esto al final deja muchas recomendaciones que la compañía de
cliente no sabe cómo ejecutar, en qué orden, ni porque, este tipo de procesos
terminan convirtiéndose en miles de dólares tirados a la basura por las
empresas que buscan transformarse.
2. Aléjense de la moda: Para explicar este
punto usare una de las modas más recientes, la adopción de nube. Y esto no es
solo de ahora, sucedió en el pasado, con SOA, SCRUM, BigData, DataWarehouse, BI,
Mobile.. etc, etc. Claro, yo me dedico principalmente a innovar los ambientes tecnológicos
y culturales de las compañías usando tecnologías novedosas y métodos de trabajo
innovadores, pero, no todo aplica para todos.
Siento temor
cuando un proveedor ya trae la respuesta sin saber la pregunta, cuando me pide
que nos reunamos para mostrarme un producto para solucionar un problema que ni
siquiera sé si tengo, ese cuidado debemos tenerlo con las tendencias. No todo
necesariamente debe estar en la nube, y solo montar todo sobre AZURE o Amazon
no significa que adoptaras nube. No todas las empresas deberían de hacer SOA,
es más esta arquitectura está viendo su fin, y algunas empresas siguen
embarcadas en proyectos de hace más de cinco años para implementarlas, y sin
hablar de las inversiones asociadas. Antes de decidir adoptar alguna de estas
tendencias es importante hacer un análisis riguroso, entender pros y contras y
valorar si es algo que realmente su compañía necesita. De lo contrario puede
hacer una implementación de película, su proyecto no será exitoso.
3. Definan una arquitectura: Esta
fuertemente asociado con el punto anterior. La práctica de arquitectura esta
tan desgastada por personas que se llaman a sí mismas arquitectos, por dominios
de alguna tecnología, porque llevan siendo programadores muchos años y porque universidades
con currículo alejada de la real profesión de un arquitecto los engañan sobre
el alcance del arquitecto, el arquitecto es mucho más de eso.
No puedo ni
mencionarles cuantas compañías he conocido que llaman arquitectura a sus
diagramas de servidores y redes, en una era en la que, como sabemos, el software
lo define todo. La práctica de arquitectura debe existir dentro de las
organizaciones y debe ser quien analice las variables y cree las cartas de navegación
de las compañías, el arquitecto es por encima de todo, un estratega tecnológico,
a veces esta habilidad es mucho más importante que sus dotes sobre humanos de programación.
Para tener proyectos exitosos los arquitectos deben crear los planos tecnológicos
que permitan identificar cual es el camino que la empresa recorrerá por medio
de los proyectos, en donde la dejara cada uno de ellos y como se verá su futuro
en un plano tecnológico y de negocio.
4. Apliquen métodos agiles de administración y
entrega de valor: Cuidado, que cuando menciono métodos agiles no estoy
hablando de ninguna metodología/framework en particular. Simplemente recomiendo
siempre que para ejecutar proyectos exitosos debemos de asegurar entregas de
valor rápidas. ¿Por qué? Porque como mencionaba al principio, esto debe de
seguir las mismas reglas de cualquier otro tipo de proyecto, no me imagino a un
ingeniero civil que inicie la construcción de su casa y solo espere para
probarla hasta que está terminada. Probará capa por capa para asegurar que el
producto cumpla la mayoría de lo deseado por el ciento, no lo cumplirá todo,
pero si estará cerca. Adicionalmente, porque eso permitirá mantener el interés y
la dedicación del equipo involucrado y porque finalmente, solo los resultados
reales pueden dar testimonio de los avances del equipo. Para tener proyectos de
software exitosos debemos acostumbrarnos a buscar feedback constante del avance
del proyecto, de lo que hemos conseguido, de hacia dónde nos dirigimos. De lo
contrario podemos estar construyendo un barco para una ciudad que desde la última
vez que la vimos se convirtió en desierto.
5. Impacto del proyecto en la estrategia:
Finalmente pero no menos importante, entendamos desde el principio, el impacto
que tiene el proyecto sobre la estrategia, y primero asegurémonos que esto
alguien lo haya validado y considerado. Y no solo sobre la estrategia, sobre la
cultura, las personas, los roles, los procesos.
Recordemos que un sistema nuevo de tecnología por sí solo no servirá de
nada, si todas las demás variables no se trabajan con igual o más cuidado,
construiremos el mejor sistema que no será usado por nadie. Siempre asegurémonos
de entender el impacto y transformación estratégica que traerá nuestro proyecto
a la empresa y a las personas laborando en ellas.
Y finalmente como siempre digo, disfrutémoslo,
sino estamos disfrutando nuestro trabajo de ejecutar proyectos tecnológicos, de
innovar, entendiendo que eso conlleva consecuencias que debes afrontar como ser
disruptivo, soportar a los agentes negativos de cambio y ser águila en épocas de
borregos, si no estas disfrutando toda esta rebeldía con causa que trae la innovación
tecnológica y la ejecución de proyectos, NO lo estás haciendo bien y NO será exitoso,
