¿Acabaremos todos los consultores tecnológicos siendo freelance?
¿Acabaremos todos los consultores tecnológicos siendo freelance?
Evaluando nuevos modelos de negocio en tecnología
¿Acabaremos todos los profesionales de la tecnología siendo freelance?
Haciendo I+C (Investigación y Copia) de los modelos de negocio de nuestros competidores, nos han llamado la atención las "plataformas de freelance".
En este modelo, las empresas que necesitan contratar consultores suben a una plataforma toda la información sobre el proyecto, que incluye el trabajo a realizar, la duración estimada del mismo y el importe que están dispuestas a pagar. Los freelance se dan de alta en la plataforma y reciben una notificación cuando un proyecto se adapta a sus conocimientos e intereses.
Solo puede quedar una plataforma
Para aquellos que estéis en el mundo del emprendimiento, hay algo que seguro ha hecho sonar una campana.
Es el típico caso del "efecto red", donde la utilidad de la plataforma crece con el cuadrado del número de usuarios. Este efecto también se conoce como "The Power Law". Es algo que los inversores valoran enormemente, porque a largo plazo solo puede quedar un ganador, que se beneficiará de su posición dominante durante diez o quince años.
Por lo tanto, en los próximos meses veremos una dura batalla entre diferentes plataformas de freelance, financiadas cada una de ellas con cientos de millones de euros.
Soluciona algunos problemas de nuestro mercado
Este tipo de plataformas soluciona algunos de los problemas habituales de nuestro mercado de consultoría tecnológica.
El creciente coste de selección
Los costes de selección se están incrementando debido al enorme esfuerzo necesario para atraer a los candidatos, lo que se traduce en equipos de selección más grandes y herramientas más costosas.
Sin embargo, para estas plataformas el coste de selección es casi nulo. El algoritmo selecciona a qué consultores notificar cada propuesta y suelen responden suficientes profesionales como para hacer una buena criba de CVs.
El "recruiting pull" basado en un algoritmo es mucho mas eficiente que el "recruiting push" de un equipo de reclutadores.
El banquillo
Otro de los problemas tradicionales de la consultoría tecnológica es el banquillo, ese sitio donde te sientas desde que acaba un proyecto hasta que te asignan al siguiente.
Y es que, hay tal dispersión de tecnologías, que puedes pasar semanas sin actividad mientras tu empresa busca desesperadamente consultores de otro perfil.
Y para terminar de complicar las cosas, mientras estás en el banquillo recibes continuamente ofertas para trabajar en otras empresas.
Con el modelo de freelance este problema no existe. Una vez acabado un proyecto, los consultores quedan libres para empezar el siguiente en una nueva organización.
Los proyectos cortos
Los proyectos cortos también son un dolor de cabeza para las consultoras. Si no tienes el equipo disponible, tienes que contratar consultores que podrían quedarse sin carga de trabajo en unas semanas.
No es solo el riesgo económico. Los consultores conocen esta situación y no se arriesgan a cambiar de empresa si la duración estimada del proyecto no es "indefinida" o al menos superior a un año.
De nuevo, el modelo freelance ofrece la solución. Mientras la demanda de consultores se mantenga elevada, puedes arriesgarte a hacer proyectos cortos e interesantes con la seguridad de que siempre habrá nuevos proyectos esperándote.
El talento extranjero
Un freelance es una microempresa que tiene capacidad para trabajar desde su casa para cualquier parte del mundo. A través de estas plataformas de freelance, puedes acceder al talento de otros países sin tener que preocuparte de la normativa laboral local.
El modelo de freelance también tiene algunas ventajas para los consultores
Los consultores freelance disfrutan de una flexibilidad que no tienen los trabajadores por cuenta ajena. Pueden decidir su jornada de trabajo, cuántos días de vacaciones van a disfrutar durante el año o cual es su remuneración por hora trabajada.
También tienen mas facilidad para cambiar de empresa porque no les retiene una posible indemnización.
En definitiva, una refrescante sensación de libertad y control sobre su carrera profesional.
Pero tiene algunos inconvenientes
El papeleo, las obligaciones tributarias, y el riesgo jurídico.
Sin duda uno de los grandes inconvenientes. El papeleo, el pago de impuestos, una legislación cambiante, las inspecciones y multas. Ni siquiera contratando un buen asesor jurídico puedes estar seguro de estar cumpliendo con todas tus obligaciones legales.
Y recuerda que siendo autónomo, respondes de tus deudas con todos tus bienes presentes y futuros. Un virus que se cuela en tu código o un IVA fuera de plazo pueden crearte un severo problema.
La discontinuidad de los ingresos
La cara oculta de la libertad para tomarse vacaciones es que no son remuneradas.
Uno de los problemas tradicionales de los freelance es la discontinuidad en los ingresos. Aunque de momento en nuestro sector parece un riesgo inexistente, una crisis económica podría acabar con esa seguridad.
Los casos de enfermedad grave y jubilación
Los casos de enfermedad grave, minusvalías o el acceso a la jubilación si pueden ser un problema, por la sospecha de fraude que siempre se cierne sobre el colectivo de los autónomos.
Una enfermedad grave puede dejarte sin ingresos y con un duro trámite legal por delante para que se reconozca una incapacidad o invalidez.
Respecto a la jubilación, la normativa actual es tan ambigua que ni siquiera los asesores fiscales tienen claro cómo calcular la cuota de autónomos.
La gran ventaja de ser freelance es que nunca te pones enfermo.
El riesgo tecnológico
En uno de nuestros primeros artículos, veíamos que buena parte de los proyectos multiplica por dos y por tres su coste de ejecución. De hecho, los proyectos de desarrollo no terminan nunca; siempre quedan errores que corregir y mejoras que hacer.
Al igual que en las empresas consultoras -los freelance son microempresas consultoras-, la única forma de ganar dinero es que el cliente asuma el riesgo tecnológico y el consultor reciba un pago periódico. Si aceptas el riesgo tecnológico y firmas un proyecto "llave en mano", además del trabajo técnico tienes por delante muchas horas de negociación.
Las empresas usuarias de estas plataformas están intentando trasladar el riesgo tecnológico a los freelance, porque no pueden controlar el esfuerzo que están realizando. ¿Cómo saber si están trabajando para varios clientes a la vez? De momento, los consultores freelance en su gran mayoría no lo están aceptando.
Aquí es donde se juega el futuro de estas plataformas. El que gane la batalla del riesgo tecnológico conquistará la rentabilidad. ¿Serán esta vez los trabajadores?
El riesgo de "uberización"
Cuando Uber comenzó a prestar servicios, aportaba al mercado de trabajo esa refrescante sensación de libertad de la que hemos hablado. Pronto aparecieron multitud de plataformas basadas en el modelo "gag economy", donde podías trabajar de vez en cuando para obtener unos ingresos extra.
Pero al cabo de pocos años, el modelo evolucionó a una suerte de esclavitud autoimpuesta, donde era necesario dedicar 70 u 80 horas semanales para conseguir unos ingresos de subsistencia.
En estas plataformas de freelance tecnológicos, el riesgo de "uberización" aparece por dos vías.
La primera, por el modelo clásico de oferta y demanda. Si se reduce la demanda de estos profesionales, las tarifas colapsarán como ocurrió en Uber.
La segunda es a través del riesgo tecnológico. Como hemos visto, quien asume ese riesgo puede acabar trabajando a pérdidas.
¿Acabaremos todos los consultores tecnológicos siendo freelance?
Nuestra conclusión es que no.
Varias de las contrataciones que estamos haciendo en los últimos meses son freelance que quieren dejar de serlo. La libertad que aporta el modelo puede estar bien durante un tiempo, pero a largo plazo estás asumiendo riesgos de manera innecesaria.
Especialmente los derivados de enfermedades graves. ¿Tantos años construyendo un estado del bienestar para después salirse voluntariamente?
Por no hablar del riesgo jurídico, la posibilidad de que hacienda se quede con todo lo que has construido durante años.
Por último, la lucha por no asumir el riesgo tecnológico, que de momento están ganando los consultores, pero con un final todavía incierto.
Demasiados riesgos frente a la seguridad del empleado por cuenta ajena, en un sector con buenos salarios y donde las empresas se pelean por contratarte.
Estas plataformas de freelance tienen su relevancia y aportarán una parte del talento que necesita nuestro sector, pero no creemos que lleguen a ser la opción por defecto para todos los consultores tecnológicos.
El peor escenario para un proyecto informático es la lluvia ácida
El peor escenario para un proyecto informático es la lluvia ácida
El peor escenario para un proyecto informático no es que vaya con mucho retraso. O que multiplique por tres el coste presupuestado. O que el cliente esté muy enfadado.
Eso ocurre en el 80% de los proyectos, tal como anticipa Pareto y nos confirma The Standish Group en sus informes 'Chaos Report'
El peor escenario para un proyecto informático es la lluvia ácida. Y el Jefe de Proyecto es el único responsable.
Bienvenido a una sesión de méntoring de novanotio.
La lluvia ácida
Pero, ¿Qué es la lluvia ácida? Es la situación en que la resolución de incidencias interrumpe continuamente los trabajos de desarrollo.
Por supuesto, siempre hay incidencias en los entornos de producción. Por eso hay equipos de operaciones encargados de monitorizar los procesos, levantar las aplicaciones o corregir entradas inconsistentes en las bases de datos.
Cuando el equipo de operaciones no es capaz de restablecer el servicio, se produce una incidencia crítica que el equipo de desarrollo debe atender de manera urgente.
De la atención de incidencias a la lluvia ácida
Todos los desarrolladores hemos tenido que atender incidencias de producción en algún momento.
El problema aparece cuando esas incidencias son tan frecuentes que fagocitan el tiempo del equipo de desarrollo. He visto grupos dedicar mas del 70% de su jornada a solucionar incidencias.
Cómo se origina la lluvia ácida
La lluvia ácida tiene la misma dinámica que la bola de nieve que rueda ladera abajo. Crece y crece hasta convertirse en un monstruo ingobernable.
Es sencillo entender el hilo de pensamientos del Jefe de Proyecto que desemboca en esta situación:
- Quiero que mi cliente esté satisfecho.
- Y necesito que el proyecto no se retrase todavía mas.
- Así que, tenemos que solucionar rápidamente esta incidencia de producción.
- Y, además, hay que cumplir la planificación que hemos acordado.
Es una línea argumental con la que todos estaríamos de acuerdo, salvo por dos importantes detalles:
- Hagas lo que hagas, el 80% de los proyectos multiplicarán por tres su plazo y su coste. Lo predice Pareto. Lo confirman año tras año las estadísticas de nuestro sector. No puedes escapar del principio de Pareto como no puedes escapar de la ley de la gravedad.
- La cuarta ley nos advierte que alcance, plazo y calidad están interrelacionados, de forma que si fijas dos de ellos el tercero se degrada. Si mantienes el plazo y amplías el alcance (todo lo planificado más la resolución de las incidencias), la calidad se degrada.
La lluvia ácida aparece cuando sacrificas la calidad
El origen de la lluvia ácida es un Jefe de Proyecto que, presionado por su cliente, sacrifica la calidad.
Ese código desarrollado a toda prisa y que se pone en producción sin apenas pruebas, va a generar nuevas incidencias en producción, que poco a poco, van a consumir el tiempo disponible para el desarrollo.
Por eso, introduciendo presión en el equipo de desarrollo, no aceleramos los trabajos, sino todo lo contrario.
Por no hablar del incremento de la rotación, que aparecerá como un nueva causa de retrasos del proyecto.
Cómo soluciona Scrum el problema de la lluvia ácida
Scrum soluciona el problema de la lluvia ácida mediante dos mecanismos.
- El primero consiste en planificar dentro de cada sprint un cierto tiempo para atender incidencias en producción.
- El segundo es obligar a que sólo se entreguen al cliente los desarrollos que superen las pruebas funcionales.
Scrum asume que hay que atender incidencias y que no se van a completar todos los trabajos planificados para el sprint. Pero se asegura que aquello que se entregue esté convenientemente probado.
Scrum evita la aparición de la lluvia ácida asegurando la calidad.
Y para asegurar la calidad sacrifica el alcance . Es decir, aplica la cuarta ley de gestión de proyectos informáticos.
Resumen
La posición de Jefe de Proyecto no es sencilla. Con independencia de tu experiencia o la de tus desarrolladores, el 80% de tus proyectos van a sufrir importantes retrasos y sobrecostes.
Si intentas acelerar los proyectos metiendo presión a tus equipos, vas a empeorar la situación.
No solo ralentizarás los desarrollos porque los programadores están cansados. Aparecerán efectos de segunda ronda como la lluvia ácida y la rotación, que dilatarán todavía más tu planificación.
Si has seguido las sesiones de méntoring de novanotio, ya sabes cómo evitar la aparición de la lluvia ácida:
- Garantiza la calidad, sacrifica el alcance (4ª ley de gestión de proyectos informáticos).
Y además:
- Quita presión a tus equipos de trabajo (3ª ley de gestión de proyectos informáticos).
- Prioriza los desarrollos que mas valor aportan (Principio de Pareto).
- Y gestiona las expectativas de tu cliente (1ª ley de gestión de proyectos informáticos).
La metodología Scrum puede ayudarte a conseguir todos estos objetivos.
Gracias por compartir el artículo si te ha parecido interesante y nos vemos en la próxima sesión de méntoring de novanotio.
Scrum y el principio de Pareto
Scrum y el principio de Pareto.
El principio de Pareto
El principio de Pareto, también conocido como la regla del 20 - 80, describe el fenómeno estadístico por el cual, el 20% de la población posee el 80% de las tierras de una región.
Esta regla fue enunciada en 1.896 por el matemático italiano Wilfredo Pareto. Desde entonces se ha aplicado a múltiples áreas de las ciencias, la economía y la organización empresarial.
- El 20% de tu ropa la usas el 80% de las veces.
- Con el 20% de tiempo de estudio, consigues el 80% de la calificación.
- El 20% de tus clientes aportan el 80% de tu facturación.
- El 20% de tus productos suponen el 80% de tus ventas.
En resumen, con el 20% del esfuerzo, consigues el 80% del rendimiento.
Este principio es, como veremos, muy importante para el desarrollo de sistemas informáticos. Aunque no lo encontrarás en el Manifiesto Agile, es uno de los pilares fundamentales de Scrum.
Bienvenido a una sesión de formación de novanotio.
Porcentaje de éxito en el desarrollo de sistemas informáticos
Ésta es la primera pregunta que hacemos a todos nuestros consultores en su primera sesión de méntoring. ¿Cuál es el porcentaje de éxito en el desarrollo de los sistemas informáticos?
La respuesta la obtenemos de los análisis que año tras año realiza The Standish Group en su informe 'Chaos Report'. Aproximadamente un 20%.
A pesar de todos los esfuerzos del sector para construir nuevas herramientas y desarrollar nuevas metodologías, el 80% de los proyectos tienen importantes problemas o se cancelan.
Es una aplicación más del principio de Pareto. El 20% de los proyectos aportan el 80% del valor. Organizaciones y estados han invertido miles de millones para escapar a esta regla sin conseguirlo.
No es posible tener éxito en los proyectos
La definición tradicional de éxito es: 'Completar el alcance que se ha acordado en la especificación, en el plazo establecido, con el coste presupuestado y con una buena calidad'
La cuarta ley de la gestión de proyectos informáticos nos avisa de que es imposible conseguir el éxito así definido. Alcance, plazo y calidad son tres parámetros que están interrelacionados, de forma que si fijas dos de ellos, el tercero se degrada.
No es posible alcanzar el éxito según la definición tradicional porque fija alcance, plazo y calidad. Obligatoriamente uno de esos parámetros debe degradarse.
El 80% de los proyectos quedan atrapados por la gravedad de la cuarta ley. Los pocos que consiguen el éxito suelen ser proyectos pequeños sin un alcance demasiado preciso.
Scrum no cambia el porcentaje de éxito, cambia la definición de éxito
Scrum no cambia el porcentaje de éxito de los proyectos. La cuarta ley no desaparece solo por dividir el desarrollo en sprints de cuatro semanas.
Scrum cambia la definición de éxito.
Y es que buena parte del software desarrollado nunca se utiliza. En concreto, aplicando la regla de Pareto, el 20% de la funcionalidad se utiliza el 80% de las veces.
Si conseguimos desarrollar ese 20% que más valor aporta, podemos construir casi todo el sistema con una fracción del esfuerzo.
Así que esta es la nueva definición de éxito que Scrum nos proporciona: 'Usar el presupuesto para construir la mayor cantidad posible de funcionalidad, empezando por aquella que se utiliza con más frecuencia y aporta más valor, con una buena calidad'
Ahora si es posible conseguir el éxito y escapar de la cuarta ley, porque en esta definición se fijan plazo y calidad, pero el alcance queda indeterminado.
Conclusión
El desarrollo de software seguirá siendo complejo a pesar de las nuevas herramientas y metodologías. Los proyectos seguirán retrasándose y fracasando, especialmente aquellos más grandes y complejos.
Afortunadamente Pareto nos indica el camino a seguir. ¡Busca junto con tu cliente ese 20% de la funcionalidad que aporta el 80% del valor!
¿Cuál es la jornada laboral más adecuada para el sector tecnológico?
¿Cuál es la jornada laboral más adecuada para el sector tecnológico?
El debate sobre la jornada laboral
La pandemia y la escasez de talento en el sector tecnológico han reavivado el debate sobre la jornada laboral y el teletrabajo.
Esta discusión corre paralela a los cambios que están experimentando las sociedades occidentales, con la progresiva desaparición de los empleos industriales.
Es una paradoja. Mientras en nuestro sector lo que faltan son profesionales y el problema es cómo retenerles, en todos los demás lo que escasea es el trabajo, así que el problema es cómo redistribuirlo. Distintos casos, ¿una única solución?
En este artículo vamos a analizar cual sería la jornada laboral más adecuada para el sector tecnológico, usando las mismas técnicas de gestión de proyectos que enseñamos a todos nuestros consultores.
Bienvenido a una sesión de formación de novanotio.
La jornada laboral y la segunda ley
La segunda ley de gestión de proyectos dice 'One Project, One Team, One Site'.
Esta ley pone de manifiesto la importancia de las relaciones personales en el mundo de la tecnología. Esto es especialmente cierto en el desarrollo de software, pero aplica por igual al resto de ámbitos de nuestro sector.
Para completar tu trabajo, necesitas la aportación de otros consultores que tienen una lista interminable de tareas pendientes. La mejor -la única- forma de que te atiendan rápido es que seáis buenos amigos. Y estos vínculos emocionales solo se forjan con el contacto directo y cotidiano.
En resumen, el trabajo presencial es muy importante.
La jornada laboral y la tercera ley
La tercera ley de gestión de proyectos dice Presión x Talento = Constante.
¿No os ha ocurrido que un problema que no podéis resolver en ocho horas, a la mañana siguiente lo resolvéis en cinco minutos?
Eso es talento.
Y Putnam, después de muchos años de investigación para el gobierno americano, llegó a la conclusión de que los proyectos sólo avanzan con esos 'Momentos de Talento'.
La tercera ley constata que cuantas más horas trabajes, más cansado vas a estar, menos momentos mágicos vas a tener y más despacio van a avanzar tus proyectos.
Desde este punto de vista, una jornada continua de cinco o seis horas al día sería la ideal.
La jornada laboral y el estado de flujo
En nuestro sector, el máximo rendimiento se consigue en estado de flujo, esa agradable sensación que experimentas cuando estás totalmente concentrado en tu trabajo y pierdes la noción del tiempo.
En las condiciones adecuadas puedes conseguir tres o cuatro horas diarias de concentración ¿Cómo podemos maximizar ese tiempo?
- Necesitas silencio y un entorno sin distracciones, algo que se ha perdido con las praderas abiertas y los dispositivos móviles.
- Además, si tienes que ir a la oficina, desperdicias la hora más productiva del día conmutando.
- No tiene sentido madrugar, porque si estás cansado no te concentras (tercera ley).
- Es imposible concentrarse después de comer, porque la sangre está en el estómago ayudando a la digestión y no en el cerebro.
Podemos sacar dos conclusiones: El teletrabajo es mejor que la jornada presencial, porque puedes levantarte más tarde, estás en un entorno más silencioso y, sobre todo, no tienes que ir y volver de la oficina. La jornada continua es mejor que la jornada partida.
La jornada óptima teórica para nuestro sector
Aplicando todo lo anterior, la jornada perfecta para el sector tecnológico sería una combinación de actividad presencial y teletrabajo, en una jornada continua de treinta horas.
En teoría, la jornada continua de 30 horas es preferible sobre la jornada de cuatro días semanales. Si solo puedes concentrarte unas tres horas al día, con la jornada de cuatro días pierdes el 20% de tu tiempo productivo.
Ambos esquemas de jornada reducida (jornada continua y jornada de cuatro días) te ofrecen más tiempo para descansar. Los días de trabajo presencial favorecen la coordinación y la formación de vínculos emocionales. El teletrabajo te aporta días de mayor concentración.
Olvídate del café. Las nuevas herramientas de mejora de la productividad individual son el descanso, la risa, el silencio, la meditación y los deportes de riesgo.
Los problemas de la jornada continua de 30 horas
Hemos visto que la jornada que mejor se adapta a nuestro sector es la jornada continua de 30 horas con teletrabajo parcial. Varias empresas han intentado adoptar este esquema, pero los intentos han fracasado. Paradigma Digital lo intentó en 2016 pero tuvo que volver a la jornada normal en 2018. ¿A qué se debe esto?
En todos los casos, la adopción de la jornada continua mejoró la productividad individual y la satisfacción de los trabajadores. ¿Qué fue entonces lo que empujó a las empresas a dar marcha atrás? ¿Por qué esa mejora de la productividad individual no se tradujo en una mejora de la competitividad empresarial?
Varios factores pueden explicarlo:
Gestión de los esfuerzos puntuales.
Con una jornada reducida, ¿Qué sentido tiene hacer sobreesfuerzos? ¿No estamos montando todo este esquema para tener mas tiempo libre?
Ante una crisis puntual, es sencillo prolongar la jornada tradicional hasta las 50 o 60 horas semanales. Pero en la jornada continua, la comida marca una frontera muy clara entre trabajo y descanso.
Uno de los requisitos para el éxito de cualquier jornada reducida es que los clientes no sufran impacto en la calidad del servicio. Es inadmisible que no se puedan atender crisis por las tardes porque no queda nadie trabajando.
Esto puede explicar el éxito relativo de los esquemas de cuatro días frente a los de jornada reducida. Igualmente se reducen las horas semanales, pero es más sencillo gestionar incidencias y crisis. Solo tienes que pedir a la mitad del equipo que trabaje de lunes a jueves, y a la otra mitad que lo haga de martes a viernes.
Capacidad del equipo de management
La principal función de la dirección y los mandos intermedios es el control y seguimiento de los procesos mediante interminables reuniones. Si la plantilla no está operativa, no se pueden reunir con nadie.
Este es uno de los problemas que las empresas reportan de forma recurrente. Con la jornada continua de 30 horas, los gestores pierden buena parte de su capacidad de dirección. La lista de problemas pendientes crece hasta hacerse ingobernable.
Aquí también funciona mejor la jornada de cuatro días. Los gestores siempre tienen al menos a una parte de la plantilla disponible para reuniones.
Apoyo tecnológico a compañeros y otros equipos
Este punto es parecido al anterior, pero aplicado a los expertos tecnológicos.
Como hemos visto, una hora de la persona que mejor conoce el problema puede ahorrar semanas de esfuerzo a todo un equipo. Aquí es donde hay que buscar los incrementos de productividad. Si solo haces tu labor técnica sin relacionarte con nadie, puede que seas muy productivo individualmente, pero la empresa pierde competitividad.
Las horas de baja productividad son la ocasión perfecta para ayudar a los compañeros, formar a los recién incorporados o aportar tu conocimiento en otra de esas aburridas reuniones con jefes de proyecto.
Resumen
El trabajo técnico tiene muchas facetas:
- Tu trabajo técnico.
- Atención a crisis e incidencias puntuales.
- Apoyo a los compañeros.
- Creación y clarificación de la especificación.
- Desarrollo de vínculos emocionales.
- Apoyo a la dirección.
- ...
El desafío es encontrar un esquema que permita desarrollar todas ellas disminuyendo la carga de horas semanales.
En teoría debería funcionar la jornada continua de 30 horas, combinando teletrabajo y actividad presencial. En la práctica se están consiguiendo mejores resultados con la jornada de 4 días.
¿Acabaremos teniendo fines de semana de tres días?
SCRUM es más productivo que los proyectos a precio cerrado
SCRUM es más productivo que los proyectos a precio cerrado
Un poco de historia
Desarrollar un sistema a partir de unas especificaciones es igual que caminar sobre las aguas. Solo hay que congelarlas.
Leí esta frase a mediados de los años noventa. Eran mis primeras experiencias profesionales y devoraba cada libro de gestión que caía a mi alcance. Me pareció una receta graciosa que escondía algo de verdad. Como todo buen programador junior, me dolía cada vez que teníamos que rehacer buena parte del código por una nueva ocurrencia del cliente.
Encontré también el caso de un jefe de proyecto que se hizo famoso por un cartel en su escritorio que rezaba "He dicho que NO". Así dejaba claro que, una vez firmado el contrato, no estaba dispuesto a cambiar una coma. Era la aplicación práctica de la congelación de especificaciones. Lamentablemente el artículo no mencionaba la reacción de los clientes cuando les entregaban lo que habían firmado y no lo que necesitaban.
Pasaron años hasta que entendí, de la mano de Brooks, DeMarco y Putnam, qué se escondía tras todos esos artículos. El cliente no puede saber lo que quiere. No existe un lenguaje para describir de forma precisa los sistemas informáticos. El desarrollo es un proceso iterativo de prueba y error. En general, al tercer intento, construyes lo que el cliente en realidad necesita.
De manera inexplicable, las principales teorías de gestión de proyectos informáticos eran desconocidas para el sector cincuenta años después de publicadas. Para que os hagáis una idea de lo perdidos que estábamos, hacia el año 2.000 la metodología de moda era CMM, basada en más y mas y mas documentación. Absurdo.
Entonces apareció SCRUM
Afortunadamente, en EEUU un grupo de líderes técnicos empezó a desarrollar, a partir de las ideas de Brooks, una nueva forma de organizar los desarrollos, más centrada en las personas y menos en la especificación. El 12 de febrero de 2001 se presentó el manifiesto ágil, un nuevo paradigma para construir sistemas informáticos que ha ido ganando impulso desde entonces.
Curiosamente, se parecía mucho a la forma de trabajar de Ceselsa (ahora Indra) en los años 90. Sus clientes la definían como una organización 'perfectamente desorganizada', lo que da una idea de su metodología, informal y centrada en las personas. Y funcionaba muy bien. Durante años consiguieron una productividad espectacular y una rotación mínima, a pesar de que los salarios no eran brillantes.
Pero una cosa es el manifiesto Agile y otra muy distinta llevarlo a la práctica. Cincuenta años de gestión de proyectos a precio cerrado producen unas inercias que dificultan su implantación.
Hay, por ejemplo, dificultades de tipo organizativo. Estamos acostumbrados a la figura del jefe de proyecto, que negocia con el cliente y prioriza las actividades de desarrollo. Las organizaciones son reacias a delegar la priorización de tareas en el cliente. En buena parte de los proyectos presuntamente SCRUM, o sigue existiendo el jefe de proyecto, o el Product Owner pertenece a la empresa desarrolladora.
Otra barrera, quizás la más determinante, es de tipo comercial. En SCRUM no se pacta un alcance entre cliente y consultora. No es que el precio no esté cerrado, es que no se define cual será el resultado del proyecto. El contrato es un acto de fe, donde el proveedor se compromete a entregar 'lo mejor que se pueda construir con ese presupuesto'. Eso dificulta cualquier tipo de control. ¿Cómo saber si la empresa desarrolladora ha hecho un gran trabajo o me está engañando?
SCRUM es más productivo que los proyectos a precio cerrado
Aunque no sea posible medirlo, Scrum es más productivo que los proyectos a precio cerrado porque genera importantes ahorros, tanto para el cliente como para el proveedor.
El primero es, sin duda, el ahorro de costes de seguimiento. Según el Chaos Report que elabora la consultora The Standish Group, el 30% de los grandes proyectos se cancela, el 50% multiplica por tres coste y plazo y de media solo se entrega el 50% de la funcionalidad acordada... En resumen, el resultado -si lo hay- no se parece en nada a lo firmado.
Si cada uno de esos cambios implica una compleja negociación entre cliente y proveedor, ¿Cuál es el coste de gestión necesario para unas modificaciones tan dramáticas? Estamos hablando de miles de horas de trabajo de ambas organizaciones, para identificar desviaciones, proponer modificaciones y justificar cambios de precios y plazos. Por no hablar de las horas perdidas por los equipos de desarrollo, que no pueden proseguir su actividad hasta que se alcance un nuevo acuerdo.
Otro de los motivos por los que Scrum es más productivo es porque se ahorra buena parte de la fase de diseño. ¿Para que emplear cientos de horas de analistas para construir una especificación que, de todas formas, va a sufrir importantes alteraciones?
Tampoco podemos olvidar el ahorro de los desarrollos que no se hacen por ser los menos usados. Si el Product Owner conoce bien su negocio, en los primeros sprints se desarrollarán y se pondrán en funcionamiento los módulos más utilizados. Recordad la regla de Pareto, con el 20% de los desarrollos consigues el 80% de la funcionalidad del sistema. ¿De verdad es productivo desarrollar el resto?
Desde precio cerrado y Scrum hacia Time & Material
Time & Material es el modelo de trabajo en el que el cliente lidera el proyecto y solo necesita programadores, testers, y administradores de sistemas, pagando un fee mensual por cada uno de estos profesionales.
De forma natural, los proyectos largos y complejos suelen evolucionar hacia Time & Material, con independencia de que hayan comenzado en la modalidad de precio cerrado o de Scrum.
El proceso es simple, el cliente identifica y contrata a los consultores clave, aquellos con mayor conocimiento funcional y técnico. De esta forma les fideliza y se asegura de que trabajen a su favor.
Y una vez que tiene en su plantilla a los líderes del proyecto, ya no necesita una empresa consultora, solo buenos programadores.
Con Time & Material obtienes eficiencias similares a las de Scrum, con la ventaja de que puedes pedir los programadores a varias empresas. Así el proceso de reclutamiento de consultores es más rápido, una ventaja importante en un entorno donde cada vez es mas difícil encontrar programadores.
Como conclusión, Time & Material es posiblemente el modelo más eficiente para construir sistemas informáticos, por delante de Scrum y a años luz de los proyectos a precio cerrado. Por eso es todavía uno de los modelos más empleados a nivel mundial.
Factores del éxito en los proyectos informáticos
Factores del éxito en los proyectos informáticos
¿Cuáles son los principales factores que influyen en el éxito en los proyectos informáticos?
La metodología por si misma no basta para explicar el éxito o el fracaso de los mismos. Hemos participado en muchos proyectos exitosos que no seguían ninguna metodología formal. También en proyectos con fuertes retrasos y sobrecostes gestionados con diferentes metodologías; CMMI, Waterfall, ITIL y también Scrum.
¿Cuáles son entonces los principales factores que influyen en el éxito de un proyecto informático?
Desde nuestra experiencia, y por orden de importancia:
- Experiencia previa en el proyecto. Los proyectos de mantenimiento evolutivo tienen una tasa de éxito muy superior, porque tanto el equipo de desarrollo como el de gestión conocen los requisitos funcionales.
- Tamaño del proyecto. Los proyectos pequeños son más exitosos porque pueden abordarse con un equipo reducido. Esto facilita la coordinación de los participantes y acelera la construcción de los requisitos funcionales.
- Liderazgo. Si el Jefe de Proyecto domina los fundamentos de la gestión de proyectos, no sólo mejora la productividad. Puede cambiar la precepción de éxito o fracaso del mismo.
- Metodología. Los proyectos gestionados con SCRUM tienden a ser más exitosos. Sobre todo porque SCRUM, como los buenos líderes, cambia la definición de éxito de un proyecto.
La experiencia previa y el tamaño del proyecto vienen impuestos por las circunstancias y no podemos gestionarlos.
Sin embargo, liderazgo y metodología son factores clave para el éxito de los proyectos informáticos que si están dentro de nuestra esfera de influencia. Por eso los estudiamos en nuestro méntoring Novanotio Certified.
Liderazgo
Los cuatro principios básicos de la gestión de proyectos informáticos se condensan en cuatro sencillas frases. Son todo lo que necesitas conocer para liderar equipos:
1ª ley. Las especificaciones son inciertas, imprecisas e infinitas.
2ª ley. One project, one team, one site.
3ª ley. Presión x Talento = Constante.
4ª ley. Alcance, Plazo y Calidad. Si fijas dos de ellas, la tercera se degrada porque es la variable de ajuste
Estas 35 palabras son el credo de todo buen Jefe de Proyecto. En este artículo explicamos con más detalle su contenido y cómo utilizarlas.
Metodología
La metodología elegida para gestionar el proyecto también es importante.
Últimamente cobran especial relevancia las metodologías ágiles, con SCRUM a la cabeza. Hay cientos de libros y artículos sobre SCRUM que seguramente ya habrás leído. Solo añadiremos algunas reflexiones que consideramos importantes:
Las empresas cometen una y otra vez los mismos errores al implantar Scrum. Esta lectura de tres minutos evitará que caigas en las mismas trampas para novatos.
Es importante que conozcas los fundamentos de Scrum para implantarlo con éxito en tu organización. Si no entiendes estos fundamentos, vas a implantar Scrum como si fuera una religión. Y tus proyectos no mejorarán.
¡Mucha suerte en la gestión de tus proyectos!
10 formas de destruir un equipo de trabajo
10 formas de destruir un equipo de trabajo
En este artículo vamos a explicar cómo el comportamiento del Jefe de Proyecto puede destruir un equipo de trabajo.
Y la mala noticia es que todos empezamos siendo Jefes de Proyecto mediocres. Llegar a ser un buen líder requiere muchos años de práctica, y dominar unos conocimientos que no nos enseñan en las facultades de ingeniería.
Estos son los diez errores que vas a cometer con más frecuencia la primera vez que consigas una promoción:
1. Enfadarte y gritar.
Es la forma más rápida de destruir la motivación de un equipo. Educa tu amígdala, el autocontrol es fundamental para el liderazgo.
2. Feedback negativo
Si la anterior es la más rápida, ésta es la más frecuente. Dar feedback a tus consultores sólo cuando algo sale mal destruirá su confianza y su motivación. El feedback positivo es LA HERRAMIENTA de los líderes.
3. Presión
Un sobreesfuerzo prolongado destruye la motivación y dispara la rotación. ¿Cuando tu cliente te exija resultados inmediatos, qué otra cosa puedes hacer?
4. Productos de baja calidad
Los consultores quieren sentirse orgullosos de su trabajo. ‘Hay que entregar lo que sea’ no estimula el compromiso.
5. Consultores que trabajan para dos proyectos
La tentación es grande. En su proyecto no tiene mucha carga de trabajo, podría ayudar también en otro que va retrasado…
Tarde o temprano tendrá tareas urgentes en ambos, y tendrá que desatender uno de ellos.
6. Consultores que están separados físicamente
¿Qué puedes hacer?, la mitad del equipo que te han asignado está en otra ciudad…
Para que se formen vínculos emocionales son necesarias las interacciones personales. Si no hay contacto frecuente no se desarrollan las relaciones de confianza. Y el proyecto se retrasará.
7. Más consultores
¡Estamos creciendo! ¡Necesito más consultores!
Las nuevas incorporaciones pueden destruir tu equipo. Si no alcanzan el ritmo de los demás, o están quemados por su experiencia pasada en la empresa, establecerán el nuevo estándar de rendimiento.
8. Falta de confianza en tu equipo
Hay muchas formas de demostrar falta de confianza:
- Ocultar información al equipo. Es absurdo, tarde o temprano se van a enterar y perderás tu credibilidad como líder.
- Micromanagement, revisar minuciosamente todo su trabajo o imponerles cómo hacer cada tarea.
- Supervisión visual. Controlar qué hacen en cada momento.
9. Reuniones de ego
Son ceremonias en las que, uno a uno, los técnicos te rinden cuentas en presencia de todos los demás. Es una pérdida de tiempo que demuestra tu nerviosismo.
10. Burocracia
¡Hay que seguir los procedimientos! Y un procedimiento significa:
- Una vez pasó algo y no queremos que se repita.
- Los que sabemos ya hemos pensado en esto.
- Esta es la mejor forma de hacer las cosas
- Te pagamos para que trabajes, no para que pienses.
- No confiamos en tu criterio.
Es mejor utilizar las buenas prácticas, formas de hacer el trabajo que han demostrado su validez, pero que eres libre de adaptar a tu estilo
Conclusión
Cuando te promocionen a Jefe de Proyecto harás varias cosas de esta lista. Es normal, forma parte del proceso de aprendizaje y esperamos que poco a poco mejores como líder.
Para acelerar el proceso, a todos nuestros consultores les damos nuestro curso ‘Novanotio Certified‘, para que esa transición de jefe mediocre a líder sea lo más rápida e indolora posible. Esto que has leído es una de las sesiones de nuestro curso. Y una de las más divertidas, porque todos han sufrido en primera persona alguno de estos comportamientos.
Si en el futuro deseas liderar un equipo, puede ser una buena idea vivir una experiencia novanotio, ser parte de nuestra plantilla y formarte con uno de nuestros coordinadores. Aquí te dejo el enlace a nuestras ofertas, espero que encuentres alguna perfecta para ti.
Las cuatro leyes de la gestión de proyectos tecnológicos
Las cuatro leyes de la gestión de proyectos tecnológicos.
Estas cuatro sencillas reglas son la base de la gestión de proyectos tecnológicos.
Son solo 35 palabras, pero necesitarás algunos años para dominarlas y aplicarlas correctamente. Si deseas convertirte en un buen Jefe de Proyecto, serán tu credo. Apréndetelas de memoria y practícalas cada día.
1ª ley. Las especificaciones son inciertas, imprecisas e infinitas.
La primera ley es la responsable de que fracase el 80% de los grandes proyectos informáticos en todo el mundo. Esta cifra se mantiene estable desde los años 60 hasta hoy. Las nuevas herramientas de desarrollo y las diferentes metodologías no han conseguido mitigar este desastre.
Nos avisa de que el cliente no puede saber lo que quiere. Los sistemas informáticos son demasiado complejos. La especificación siempre estará incompleta. Por eso son inciertas.
Nos advierte de que no existe un lenguaje de alta precisión para comunicar las instrucciones técnicas. Los arquitectos disponen de los planos, un lenguaje de muy alta precisión. Los ingenieros informáticos sin embargo usamos el lenguaje natural, que es interpretable. Por eso son imprecisas.
Nos alerta de que un proyecto nunca termina. Siempre quedan errores que corregir y mejoras por implementar. ¿Alguna vez has puesto la última línea de código de un programa? Por eso son infinitos.
Cómo usar la primera ley:
- Especifica menos y haz más prototipos.
- Relaciónate más con tu cliente.
- No discutas el significado de un párrafo.
- ¡Haz que abone las facturas cuando todavía queda mucho por hacer!
2ª ley. One project, one team, one site.
Como el cliente no puede saber lo que quiere, y no disponemos de un lenguaje de alta precisión, las relaciones personales cobran especial relevancia.
La especificación se construye según avanzan los desarrollos, y los vínculos emocionales son la clave para distribuir ese conocimiento.
La segunda ley nos indica cómo construir esos vínculos. Los analistas funcionales, programadores, testers e incluso el cliente deben estar en la misma sala. Y mucho mejor si cada consultor trabaja en exclusiva para el proyecto.
Las software labs, las organizaciones matriciales y los equipos distribuidos son ineficientes.
Un apunte de Franz Hassmann, CTO de BBVA Next. Mejor si los equipos son pequeños, de entre 5 y 9 componentes.
3ª ley. Presión x Talento = Constante.
Durante miles de años hemos dirigido organizaciones gestionando la presión. Con el nacimiento de la informática necesitamos, por primera vez en la historia, gestionar el talento.
La tercera ley anticipa que si incrementas la presión de trabajo, disminuye el talento y los desarrollos se retrasan.
Así que olvídate de los bonus por objetivos y de exigir horas extras. Esas son herramientas de gestión de la presión.
Debes gestionar el talento. Ofréceles retos. Usa el feedback positivo. Bloquea la presión del cliente y deja que el equipo encuentre su ritmo de trabajo.
4ª ley. Alcance, Plazo y Calidad. Si fijas dos de ellas, la tercera se degrada porque es la variable de ajuste.
Recuerda, las especificaciones son infinitas.
Así que algo tienes que sacrificar. Puede elegir entre el alcance (entregar menos producto), el plazo (retrasar las entregas) o la calidad (entregar algo sin apenas pruebas).
La cuarta ley nos propone que alcance, plazo y calidad están interrelacionados. Si fijas dos de ellos, el tercero se degrada.
Nunca, nunca, nunca sacrifiques la calidad. Nunca fijes alcanzo y plazo.
SCRUM por ejemplo fija plazo y calidad, el alcance queda indeterminado. Se factura por cada sprint.
TIME & MATERIAL, los servicios profesionales de toda la vida, fijan alcance y calidad, y es el plazo el que queda indeterminado. Se factura mensualmente por el esfuerzo dedicado.
Si haces PROYECTOS CERRADOS, perderás dinero en el 80% de los contratos.
Enlaces de interés
Son solo cuatro reglas sencillas de aprender. Sin embargo, muchas organizaciones todavía preparan extensos documentos funcionales, deslocalizan parte de los equipos y trasladan la presión del cliente a sus desarrolladores.
Os dejo los enlaces a las fuentes de las cuatro leyes. Si comprendéis los fundamentos de cada una de ellas, os será más sencillo adaptarlas a vuestra organización.
La primera ley tiene su origen en ‘The mythical man-month’ de Brooks. Quizás el primer libro sobre ingeniería del software. Escrito a finales de los sesenta y una referencia obligada a día de hoy. Se complementa con ‘Introducción a la PNL’ de Seymour, un libro sobre psicología del lenguaje.
La segunda ley procede del fantástico libro ‘Peopleware’ de DeMarco. Posiblemente el primer ensayo sobre programación y productividad. Muy entretenido.
La tercera ley procede de un clásico sobre la motivación. ‘Drive’ de Daniel H. Pink. Igualmente divertido y ágil.
La cuarta ley procede tanto del libro de Brooks como de ‘Agile Software Requirements’ de Dean Leffingwell. No son fáciles ninguno de los dos, pero merece la pena el esfuerzo.
Te animo a compartir con todo nuestro sector tus experiencias en los proyectos en los que has participado. ¿Se han cumplido las cuatro leyes? ¿Añadirías alguna más?
¡Suerte en tu carrera de gestión de proyectos tecnológicos!
La burocracia destruye los equipos de alto rendimiento
La burocracia destruye los equipos de alto rendimiento.
Construir Vs destruir
La burocracia destruye los equipos de alto rendimiento.
Construir equipos de alto rendimiento (EAR) es una tarea compleja. Existen varias aproximaciones para que personas con diferentes intereses trabajen con confianza y consigan resultados sobresalientes. Pero ninguno de estos métodos garantiza el éxito.
Sin embargo, destruir equipos de alto rendimiento es una tarea sencilla que las empresas suelen dominar. Existen al menos diez efectivos EARicidas. Y la burocracia es uno de los más poderosos.
Desde la primera edición de Peopleware, en el año 1.987, sabemos cómo la burocracia afecta a los grupos de desarrollo. Os recomendamos leer el capítulo Teamicide, que describe los efectos de dedicar tu tiempo a empujar papeles.
Un procedimiento tiene cinco significados
Con cada procedimiento la empresa nos transmite cinco mensajes:
- Una vez pasó algo, que tuvo un impacto negativo en la empresa, y no queremos que se repita.
- Los más listos de la empresa, es decir, la dirección, hemos ideado este procedimiento. Es definitivamente la mejor forma de hacer las cosas.
- No te pagamos para pensar, te pagamos para que trabajes. Sigue el procedimiento.
- No confiamos en ti.
- Porque no tienes talento.
Algunos ejemplos de Burocracia en acción
Estos son algunos casos que he conocido de primera mano.
Hace unos años, un consultor se quedó con el equipo informático cuando cambió de trabajo. Ahora todos los consultores deben firmar un recibí cada vez que les entregamos material. Una vez pasó algo y no queremos que se repita.
Antonio necesitaba pagar con tarjeta de crédito un servicio web de 50 € al año. Su empresa le explicó el procedimiento. Debía tramitar un pedido a través de la plataforma de compras, pedir tres ofertas y los pagos se hacen a noventa días mediante transferencia. Ya hemos pensado la mejor forma de hacer esto. (Por supuesto lo pagamos nosotros y resolvimos el problema en diez minutos).
Carlos necesitaba una mochila para transportar su ordenador portátil. La bandolera que le había proporcionado su empresa le hacía daño en la espalda. Prepararon un procedimiento ad-hoc para su caso, debía aportar un justificante médico. No confiamos en ti.
Pablo necesitaba urgentemente un entorno de pruebas, pero había un procedimiento: Debía solicitar a la central de Alemania una máquina virtual con una configuración estándar. No podía instalar nuevo software ni hacer pruebas para optimizar el rendimiento. No te pagamos para que pienses.
Jorge tenía problemas para avanzar con el desarrollo. Las especificaciones eran imprecisas y algunas sentencias SQL no tenían sentido. Solo necesitaba hablar unos minutos con el cliente, pero había un procedimiento: El Solutions Architect trasladaba la consulta al Account Manager, y el Business Analyst se reunía con el cliente. Tu no tienes talento.
La burocracia incumple la tercera ley
Hemos hablado en varias ocasiones de las cuatro leyes, esas 35 palabras que guardan casi todo lo que debes saber para gestionar proyectos informáticos.
La tercera ley dice Presión x Talento = Constante. Es decir, debes elegir entre maximizar la presión o maximizar el talento.
Mientras en buena parte de las actividades empresariales es conveniente gestionar la presión, en el ámbito de la tecnología necesitas maximizar el talento.
Y la burocracia, ¿mejora la presión o mejora el talento? Si has leído con atención hasta aquí, la respuesta es sencilla. La burocracia genera una carga de trabajo innecesaria (presión) porque asume que no tienes talento. La burocracia es por tanto similar a los bonus por objetivos o a los incrementos de jornada laboral. Formas de presión que destruyen el talento.
Las Buenas Prácticas
Sin embargo, no es económicamente viable reinventar la rueda cada vez que realizamos una actividad. Es necesario un mecanismo que busque la eficiencia pero que se apoye en el talento de los profesionales. Y la respuesta son las Buenas Prácticas.
Las Buenas Prácticas tienen el siguiente enunciado: ‘Ésta forma de hacer las cosas se ha demostrado que funciona y recomendamos su uso. Eres libre de buscar formas más eficientes de hacer el trabajo porque no eres tonto y confiamos en tu talento. Junto con nuestra confianza te damos el derecho a equivocarte de vez en cuando y la obligación de trasladar tu conocimiento al resto de la organización‘.
Este enfoque persigue el mismo objetivo que los procedimientos, realizar el trabajo de forma homogénea y eficiente. Sin embargo refuerza la tercera ley porque se apoya en el Talento de los consultores.
Las fuentes
Si te interesa el tema, te aconsejo acudir a las fuentes. Además del mencionado Peopleware, te recomendamos ‘El japonés que estrelló un tren para ganar tiempo’ de Gabriel Ginebra y ‘Rework’ de Jason Fried.
Si quieres ayudar a la comunidad IT, puedes comentar algunos de los procedimientos de tu empresa y cómo te afectan en tu trabajo.