Innovación y sentido común

La tecnología avanza cada vez más rápido . Alrededor de ella, surgen nuevas formas de uso y según se va democratizando la tecnología más avanzada, con ella, nuevos modelos de negocio. La innovación no se puede parar, y parece que los cambios se suceden cada vez más rápido.  Las nuevas generaciones, están acostumbrados a los cambios, a los cambios rápidos . Durante la generación de mis padres, se popularizó la televisión, 22 años tardó esta tecnología en conseguir 5o millones de usuarios. En mi generación, surgieron los móviles, estos tardaron 12 años en alcanzar la misma cifra de usuarios. Ahora, juegos como Pokemon Go, han alcanzado esta cifra en 19 días. The VR, nos muestra en su blog, distintas tecnologías, ordenadas cronológicamente y el tiempo que tardaron en conseguir 50 millones de usuarios  http://www.thevr.io/blog/vr-ar-user-adoption-50-million/   Foto por:  thevradmin   http://www.thevr.io/blog/vr-ar-user-adoption-50-million/   Cambios...

  credits to  www.cerillion.com/Products/SaaS/Cerillion-Skyline Transformación digital es un termino que se utiliza desde hace algún tiempo para a agrupar un grupo de tendencias, todas ellas orientadas a poner en valor el uso de las nuevas tecnologías para aumentar la rentabilidad del negocio . Se puede resumir la transformación digital en 2 grandes tendencias si tenemos en cuenta como se aplican a las relaciones que se dan en el mundo: Digitalizar las relaciones internas de las empresas, o como usar las nuevas tecnologías para hacer los procesos internos más eficientes. Relaciones entre los empleados y la empresa Relaciones entre los propios empleados Relaciones entre departamentos Relación de los empleados con su trabajo Digitalizar las relaciones externas de las empresas, Estas relaciones están marcadas, sobre todo, por el uso de nuevos canales de comunicación: Relación con los socios Relación con los proveedores Relación con los clientes, junt...

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

Cuando nos enfrentamos a un proyecto, el equipo que lo compone es una pieza clave para poder gestionar el riesgo intrínseco del proyecto. De todos los factores que pueden influir en el desarrollo de un proyecto, es el propio equipo el que más variables aporta al mismo. Por este motivo, conocer bien al equipo, tanto sus habilidades como su experiencia, es una de las claves a la hora de gestionar el proyecto. Para la elección de un buen equipo se deben tener en cuenta, no solo los conocimientos técnicos y de negocio de los involucrados, sino sus capacidades, su personalidad y el rol que tomarán cuando se junten. Dependiendo de si nos enfrentamos a un proyecto de larga duración o uno de corta deberemos de dar más importancia a los conocimientos técnicos de todos los miembros del equipo. Si el proyecto va a ser uno de larga duración, se podrá buscar integrantes del proyecto, con menores conocimientos técnicos, ya que podrán adquirir el nivel deseado durante el desarrollo del mismo. S...

Todos sabemos, que cuando quieres llevar a cabo un desarrollo necesitas tener una buena planificación. Esto te permite identificar los posibles problemas que pueden surgir y tener preparadas medidas de contingencia. La planificación de los proyectos es crucial, y sin ella no se pueden llevar a cabo proyectos de gran envergadura. Al ser una de las tareas cruciales en un proyecto, es mejor invertir el tiempo necesario para hacerla de manera correcta, que acortar ese tiempo en favor de otras labores. Es en ese momento, cuando estamos sentando los cimientos del edificio que queremos construir, por lo que han de ser firmes para que sostenga toda la estructura. Dedicar parte de este tiempo, a la identificación de los riesgos del proyecto puede ahorrarnos sustos a posteriori. Pero hay veces que se malinterpreta esta planificación. Una planificación sólo es posible cuando se conocen todos los datos, es decir, sabemos lo que queremos y los impactos que provoca. Es inútil planifica...

A la hora de escoger una metodología para la gestión de proyectos en una organización, departamento o para un proyecto concreto, hay que tener en cuenta muchas cosas. Lo importante es que esta metodología responda a las necesidades. Como ya comenté en la entrada anterior, la metodología que se sigue, debería estar alineada con el negocio al que atiende. No se puede establecer una metodología que penalice los tiempos de desarrollo cuando se requiere agilidad, ni una demasiado flexible, cuando el objetivo que se persigue es garantizar la robustez del desarrollo. Actualmente hay varias metodologías de moda. Muchas organizaciones que quieren tener un “time to market” muy corto, están apostando por metodologías ágiles y SCRUM. Estas, bien implantadas, tienen la capacidad de agilizar los desarrollos, pero repito, bien implantadas. Las organizaciones más tradicionales usan derivados de  metodologías clásicas que hacen que el “time to market” aumente considerablemente. Estas meto...

Hay entornos, donde la rapidez en dar una respuesta es crucial. Esto es un hecho. Desde la gestión lo único que se ve es el tiempo que se tarda en dar la solución a un problema determinado. Muchas veces, este tiempo engloba una serie de tareas que en muchas ocasiones son transparentes para la capa de gestión del proyecto. Ya en varias ocasiones me he encontrado con comentarios como: -“¡No se puede tardar tanto tiempo en resolver una incidencia en producción!” Este tipo de comentario, habitualmente se refieren o van dirigidos a los equipos de desarrollo pero no siempre es el desarrollo el que genera estos tiempos. Como medida de contingencia, se suele aplicar presión a los desarrolladores. En muchas ocasiones se les llega a presionar hasta extremos en los que no se les da tiempo ni para pensar en la mejor solución, hacer las pruebas necesarias, o para asegurar el comportamiento normal de la operativa para la que se desea realizar el cambio o la corrección, o asegurar que los desarro...