Antes de hablar de planificación estratégica de sistemas de información y de gestión de porfolio de proyectos (PPM) me gustaría abordar un problema más sencillo (pasos de bebe): como hacer un solo nuevo proyecto en una empresa, cuando no tenemos capacidad y queremos subcontratar.
Imaginemos que trabajamos en una empresa y tenemos a 6 «programadores» (palabra comodín que deberíamos dejar de usar alegremente) para dar soporte a las áreas de negocio ¿qué hacemos si negocio pide más que lo que el equipo actual puede hacer? pongamos que es necesario hacer un proyecto urgentemente que requiere otras 4 personas durante pongamos 6 meses.
El modo tradicional de abordar el problema es que tecnología diga que no es posible. Pero negocio lo necesita y no se va a parar por ello.
Probablemente negocio tire por la vía del medio, defina vagamente el proyecto y se lo asigne a una consultora para que se lo construya (lo máximo posible por el menor coste) y que luego su equipo se encargue de mantenerlo, que es lo que aporta valor (que harto estoy de escuchar esto… cada vez que lo dice un gestor, muere un gatito).
Ya hace la friolera de 8 años escribía sobre las curvas de aprendizaje.. https://adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=heuristica donde hay un concepto sencillo que entender: tienes que dedicar un tiempo mínimo a algo para ser productivo en ello. Si alguien del equipo actual, llamemos de mantenimiento, no participa activamente en el proyecto durante todo su ciclo de vida, va a ser harto difícil que luego lo pueda absorber con facilidad y mucho menos que lo sienta como suyo.
Bueno, se puede plantear una solución, que alguien que lo ha construido se quede posteriormente durante «una temporada» para hacer ese mantenimiento y luego transfiera el conocimiento poco a poco.
Vamos, no se si veis este modelo óptimo, pero me da que no, pero veamos por qué:
- Si ya en el primer post de esta serie (https://adictosaltrabajo.com/detalle-noticia.php?noticia=388) decimos que los técnicos tienen que aprender el negocio.. si habitualmente ya les suena poco a los que llevan trabajando años en una organización, imagínate lo que les tiene que sonar al que venga, que parte de cero.
- Un técnico externo te va a dejar una «joyita» que otro se va a tener que encargar de mantener luego.. que probablemente no va a ser él. Por tanto, puede ser más atractivo clavar las últimas tecnologías del mercado (estén maduras o no) para aprender por el camino.
- Como no suele estar bien definido, habrá tiros al final y la calidad se sacrificará. La mantenibilidad de lo que se haga será problema del que se queda. Además, cuanto más difícil sea de mantener parece que hay más negocio después ¿no?. Con una política férrea de pedir más dinero por los cambios, superada una fase inicial del proyecto se saca la rentabilidad del proyecto, siendo la oferta del precio más bajo.
- El equipo de plantilla ve que las novedades se las dan a otros y que las oportunidades de aprender/estar en la onda relevante de la compañía, desaparecen. Al cabo de unos años así, tenemos a las plantillas completamente desactivadas.
Tal vez parecería más lógico hacerlo de otro modo, aplicando los principios ágiles de amplificar el aprendizaje, desarrollar a las personas, entregar tan pronto como sea posible, etc.
Si damos por hecho que la empresa va a tener más necesidades técnicas en el futuro, parecería sensato desarrollar al personal interno para preparar la situación. A lo mejor tenemos que tragar con como se hace con el proyecto actual pero podemos proponer cambios para que el próximo ya se haga de otro modo:
- Alguien debería abandonar el día a día de la compañía y empezar a preocuparse de la calidad/arquitectura.
- Si es sólo una persona, probablemente sería razonable subcontratar a otra que ocupase su lugar. Con mucha ayuda inicialmente y menos a medida que pase el el tiempo, esa persona se podría hacer independiente.
- A la persona que se ha liberado le podrían formar (con consultoría externa puntual) para que mejorase los propios procesos de la compañía de gestión de la configuración, arquitectura, paso entre entornos y calidad. La persona externa es importante porque todos sabemos que cuando alguien externo dice algo se le tiene más en cuenta que cuando lo hace un interno. La ideas es que sea poco tiempo (bolsas de horas) porque así tiene que quedarse con la copla en interno.
- Durante un tiempo, se debe mejorar la calidad de lo que se hace y para adquirir nuevas habilidades. También hay que romper estructuras tradicionales de equipos actuales. Si los 6 programadores de plantilla están muy especializados por técnica (el de javaScript, el de html5, en de Java, el de Scripts de base de datos, el que pasa a producción) o funcionalmente, el que lleva el registro, el que lleva la parte transaccional, el que lleva los informes, etc.. pues claramente tenemos un problema. No se podrá sacar a nadie del día a día porque todos son únicos e imprescindibles. Tendrán que adquirir una formación más amplia todo el mundo haciendo que trabajen por parejas (no cambiar todo a la vez.. sino sólo desordenar una pareja durante un tiempo). Uno se saca la carrera de ingeniero en 3 años.. no me vale ninguna excusa para no adquirir habilidades suficientes en todas las disciplinas.
- Con ello, empezamos a ganar elasticidad. Elasticidad para sacar a otra persona del día a día y pasarla a proyectos nuevos.
Imaginemos que hemos conseguido este escenario, y nos habrá costado 6 meses y obtener más «recursos». Tendríamos una persona que ya salió del día a día, que ha ayudado a mejorar la técnica del equipo y otra que trabaja con un compañero por lo que sería relativamente fácil contratar a otro externo para que se ponga a rueda con su compañero. Con ayuda inicial al principio (por conocimientos funcionales e históricos de la organización) entre 3 persona pueden dar un servicio sin mucho ruido.
Ahora bien, con dos personas liberadas del día a día, si la empresa quiere abordar un proyecto estratégico, puede contratar a una empresa que, de un modo ágil, trabaje con ellos en el nuevo proyecto. Prestando esta empresa un par de persona experta en métodos ágiles y arquitectura e integrando a las dos personas de plantilla en el equipo (ya tenemos los 4), tienen contratado un primer periodo de tiempo (pongamos 3 meses) para hacer entregas cada 2 semanas: para entregar el máximo de software que funciones a la compañía que les está pagando, ya teniendo claro criterios de arquitectura y calidad.
En 3 meses, y con los mecanismos de las metodología ágiles, ya no hay luchas de que entra o no entra. Con metodologías ágiles el equipo está en mantenimiento evolutivo desde la segunda iteración, por lo que el equipo de plantilla va adquiriendo las habilidades de hacerlo sólo desde un principio. El proveedor se tiene que ganar que el cliente quiera que continue y forzará a una entrega de valor alta.
Si el modelo funciona correctamente, tienes a gente con conocimiento del proyecto para mantenerlo ahora y en el futuro. Tienes medida de velocidad. El personal del proveedor se sentirá poco diferenciado del cliente y creará una relación personal con él. Se podrá incluso, en base a las historias pendientes, acordar costes fijos para las etapas restantes, en base a la velocidad media y con un conocimiento mejor de los proyecto.
En este modelo el personal del proveedor tiene que ser bueno, tiene que ser polivalente … y esto ya no son horas de gente no especializada en otro edificio con entregas cada varios meses. Así es una posible vía donde los artesanos tendrán un hueco de valor en el mercado y se dejará de jugar a ver quién trata de sacar más a quién: asociaciones productivas http://manifesto.softwarecraftsmanship.org
4 personas cualificas y motivadas hacen maravillas: contrata parejas hasta establecer una relación de confianza plena.
Si los proyectos son más grandes y tienes muchos en paralelo ¿cómo lo hacemos? por pasos … que ya va un post muy largo.
Enlaces de interes: