martes, 3 de septiembre de 2013

Necesidad de formación en TI para perfiles de negocio.

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.

2 comentarios:

  1. 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?

    ResponderEliminar
    Respuestas
    1. Hola 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.

      Como 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.

      Eliminar

Con la tecnología de Blogger.