Innovación y sentido común

He hablado mucho en el blog, sobre la planificación de los proyectos y la gestión de los equipos, pero quizá he dado por supuestas muchas cosas. Dada mi experiencia laboral, he dado por supuesto que siempre se define que se quiere hacer en un proyecto. Sin embargo, últimamente he visto, que esto no siempre es así. Definir que se quiere hacer en un proyecto, es una parte imprescindible del mismo. Esta definición nos ayuda: Acordar con el cliente el objetivo del proyecto y acotarlo de forma clara. Conocer el fin último del proyecto tanto por cliente como por proveedor. Planificar la ejecución del proyecto, ya que se conoce de forma clara las funcionalidad a desarrollar. Definir que se quiere hacer en un proyecto, entraña varias fases, que involucran a distintos roles. Por un lado tendremos la oferta o contrato hecho por el comercial donde se habrá hecho un análisis de preventa, para estimar los recursos necesarios para llevar a cabo este proyecto. Normalmente, en el contrato,...

"La potencia, sin control, no sirve de nada", es una frase que me encanta, y que se puede aplicar como metáfora para la estrategia en IT que usan muchas entidades, sobre todo aplicable a la administración pública. He tenido el placer de trabaje en una administración pública, y ver como se gestionan las nuevas tecnologías allí. Mi conclusión es, falta de planificación y control. En este caso no me refiero a una mala gestión de proyectos, sino a un nivel más alto, falta de estrategia. Realizar proyectos de desarrollo de nuevas herramientas, implantar nuevo software, cambiar el hardware o usar nuevas tecnologías, no ha de hacerse sin seguir un camino con un objetivo. Es habitual, que en muchas instituciones, se decida que se quiere implantar una nueva tecnología, porque está de moda, el vecino la tiene, o quiero dejar mi huella en este sitio. Todos estos son planteamientos erróneos, que abocan a un gasto innecesario de dinero, que no genera ningún beneficio. Antes de plantear...

Cuando se lleva a cabo un proyecto en el sector IT, hay un factor clave que se tiende a olvidar, LOS USUARIOS. Este olvido, es capaz, por sí solo, de hacer fracasar un proyecto. Puedes haber desarrollado la mejor herramienta del mundo, que si los usuarios a los que va dirigida, no la usan, acabará muriendo. Este prole genera muchas perdidas económicas tanto en el sector privado, como en el público, donde los usuarios suelen ser más reacios a los cambios. Este problema se puede prevenir y evitar, solo hay que usar el sentido común, y actuar con un poco de estrategia. La gestión del cambio, es clave para la adopción de nuevas herramientas por parte de los usuarios, pero es una buena estrategia ir un paso más lejos. Durante mi experiencia profesional he observado un hecho relevante que afecta de manera positiva, a evitar el rechazo de las nuevas herramientas por parte de los usuarios. Si se involucra a un grupo representativo de estos usuarios durante el proceso de desarrollo, estos...

La control del presupuesto de un proyecto es posible. Para conseguirlo, lo mejor es ver cuales son las causas que causan un aumento del coste. Estas causas pueden ser muchas y dependerá de cada proyecto y no podemos actuar sobre todas, sin embargo, algunas de ellas son comunes a muchos proyectos, y está en nuestra mano tomar acciones para evitarlas. Establecer unas fechas realistas, y explicar al cliente, el motivo de las mismas. Es obvio que, determinadas tareas de un proyecto, llevan su tiempo y reducir estos tiempos de forma arbitraria para alcanzar fechas imposibles, revertirá de forma negativa en la calidad del entregable. Esto a la larga, generará un coste extra para conseguir el entregable pactado. Seleccionar los recursos de forma minuciosa. Analizar las necesidades concretas del proyecto, y con ello seleccionar los perfiles adecuados para el mismo. A pesar de que en un principio, la selección de determinados perfiles de alto nivel pueda aumentar los costes del proyecto, ...

Para conseguir que un proyecto de IT sea exitoso, no es suficiente implantar un software que funcione. El uso que los usuarios hacen del mismo, es un indicador de si el proyecto ha sido un éxito. En la mayoría de los casos, las herramientas IT no son el fin del proyecto, sino el medio para conseguir mayor eficiencia en otros sectores. Podemos poner por ejemplo, una herramienta para la gestión de contratos, el fin último de esta será ayudar a los usuarios a realizar su trabajo de una forma más productiva. De esta forma vemos, que si gestionamos un proyecto para desarrollar e implementar una herramienta de este tipo, el éxito del proyecto se medirá en base al uso que los usuarios hacen de él, y si efectivamente este ha conseguido una mayor productividad. En varias ocasiones he visto, como se consideran exitosos proyectos de desarrollo, simplemente por implantar una herramienta, sin ver lo que pasa después. He visto como usuarios, se sienten desesperados, por tener nuevas herramien...

Durante los últimos meses, varios amigos que no pertenecen al mundo IT, me han pedido asesoramiento sobre proyectos IT en los que están involucrados. Tras hablar con ellos, me ha sorprendido descubrir que en su equipo tiene un jefe de proyecto. Esta sorpresa viene derivada, de que tras nuestra charla, me confesaban, que eran ellos mismos los que acababan hablando directamente con el programador, no sólo para resolver las dudas, lo cual es fundamental, sino, para explicarles el proyecto y corregir los fallos o incluso pedirles estimación del tiempo de desarrollo. Siendo así, ¿para qué está el jefe de proyecto en ese equipo? El jefe de proyecto, no es sólo la persona que estima tiempo y recursos necesarios para todas las fases, sino que es la persona que debería servir como canal de comunicación con el cliente. Por este motivo, debería ser, junto con el propio cliente, quien mejor conociera las necesidades del negocio, el objetivo del proyecto, las características claves del mismo...

Una de las causas más frecuentes del fracaso de un proyecto, es la comunicación entre el negocio y los desarrolladores. La comunicación es una parte esencial durante un proyecto. Negocio ha de comunicarle a los desarrolladores, que quiere que hagan. Esta comunicación ha de ser bidireccional, un dialogo, no un monologo. Los desarrolladores, han de exponer al negocio, como ven el proyecto desde su lado. A menudo, la relación entre el negocio y los desarrolladores, se limita, a que negocio les diga, lo que han de hacer. Estos requisitos, a menudo, so vagos, o no son todo lo específicos que deberían ser desde el punto de vista técnico. Esto deriva en que en la fase de desarrollo, los desarrolladores tomen decisiones, basándose en la eficiencia técnica. Estas decisiones, aunque desde el punto de vista puramente técnico, tienen sentido y buscan la eficiencia de los desarrollos, es posible, que imparten a la operativa y al modelo de negocio. Como resultado, obtenemos productos, no s...