Todo el mundo afirma que en los negocios de hoy en día, nada
se puede hacer sin tecnología, pero son muy pocos los perfiles de negocio que
comprenden lo que es e implica un proyecto o implementación tecnológica,
dirigiendo la subcontratación de estos proyectos como si de de la obra del
nuevo local que van a abrir se tratase.
Hoy también, todos los clientes parecen conocer y ser unos
expertos para el lanzamiento de proyectos de TI, pero desde una perspectiva de
usuarios, explicando su proyecto como: una plataforma web "como la de
bookings", "como la de
infojobs" o "parecida a facebook, pero más pequeña", con un
total desconocimiento por su parte del proceso de producción software y de las
dimensiones de este tipo de proyectos en cuanto a Alcance, Tiempo, Costes,
Calidad y Riegos y pretendiendo los mismos en el menor tiempo y al mínimo
coste.
Con el sector de la automoción, por ejemplo, todo el mundo
sabe conducir, sin embargo nadie se plantea hacer un coche ni opinar tan
libremente sobre la mejor configuración de motor que mejor se ajuste a sus
necesidades. Sin embargo, con la industria de TI, tal vez por saber que con un
simple ordenador (del que todo el mundo dispone), se puede hacer cualquier tipo
de software, o porque todos podemos descargarnos apps para nuestro teléfono
móvil y utilizar todo tipo de plataformas en internet, nos consideramos también
capaces de diseñar y gestionar la producción de cualquier desarrollo software,
viéndolo como algo totalmente factible y hasta trivial, pero sin pasar nunca
del perfil de usuarios al de desarrolladores!
Esta falta de formación en tecnología (más allá del nivel de
usuarios), es la causa del fracaso de muchos proyectos en los que el cliente,
con una dependencia cada vez más elevada de la herramienta tecnológica para el
lanzamiento de sus proyectos y partiendo de unas expectativas (que no de
requerimientos de TI claros), subestima tanto la complejidad como la carga de
trabajo y los costes asociados a esa parte del proyecto, y produciendo
frustración, tanto en el propio cliente como en el equipo de desarrollo. Esta
situación es la que me encuentro muchas veces, sobre todo en emprendedores, con
modelos de negocio totalmente basados en internet o plataformas software, y en
los que las empresas o equipos de desarrollo software son vistos como
"commodities" de usar y tirar, tras extraer de ellos todo su jugo y
que lleva a los clientes a vagar de subcontrata en subcontrata, en busca del
comercial que comprenda su situación, sin darse cuenta de que a ese comercial,
con esos antecedentes del cliente, ya le tiemblan las piernas.
No me refiero con ello a tener que conocer lenguajes de
programación para revisar el código o algoritmos del desarrollo, o a conocer
los fundamentos de bases de datos, arquitecturas o herramientas de modelado
software, pero los perfiles de negocio (los MBA´s, emprendedores y en general
cualquier perfil de negocio hoy en día),
cuando menos debería acercarse a conocer las metodologías de gestión de
proyectos software y de TI, para disponer de una aproximación a la realidad de
estos proyectos, y dentro de estas, vaya mi recomendación por las metodologías
ágiles como Scrum o Extreme Programming, capaces de proporcionar de forma
rápida una comprensión de las particularidades de estos proyectos y de cómo
gestionar los mismos, muy diferente al de las metodologías tradicionales como
la del PMI (Project Management Institute) válida para todo tipo de proyectos.
Un factor clave para la buena marcha de un proyecto desde sus orígenes debería ser "sentar" al cliente y "ayudarle" a trasladar sus expectativas (en ocasiones vagas incluso para él) en una colección exhaustiva de requisitos de sistema. Ardua tarea, ¿verdad? ¿Alguna metodología/herramienta extrema para esto, Pais?
ResponderEliminarHola Jaime, existen varias herramientas y metodologías para la correcta gestión de los requisitos, prácticamente todas las metodologías de gestión de proyectos prestan mucha atención a este aspecto y en el campo de la "ingeniería de requisitos" podemos encontrar también bastante información y material. Pero no hay varitas mágicas ni bálsamo de fierabras para esta fase de los proyectos y más que de herramientas (todos las conocemos) creo que es más una cuestión de habilidades personales y de saber hacer las preguntas correctas.
EliminarComo la tarea es compleja, yo me siento más cómodo con metodologías ágiles como SCRUM, menos predictivas y no tan basadas en una exhaustiva planificación inicial, que luego difícilmente se ajustan a la realidad de los proyectos y que sí coartan la innovación y el permitir a los clientes y shakeholders hacer cambios para mejorar el proyecto sobre la marcha. Las metodologías tradicionales a veces parecen diseñadas parar proteger al equipo de desarrollo en detrimento de la satisfacción y orientación al cliente. Obviamente, estas metodologías se protegen en cuánto a requerimientos de clientes, pues estos quedan cerrados hasta la finalización del proyecto en el que se recogen las lecciones aprendidas, pero como yo creo imposible cerrar esas especificaciones de forma exacta, prefiero hacer uso de las metodologías ágiles, entregando funcionalidades revisables por el cliente de forma incremental e iterativa.