¿Cómo te irá en tu nuevo trabajo? (II)
¿Cómo te irá en tu nuevo trabajo?
En nuestro artículo de diciembre del 22, explicábamos que lo más importante de una oferta de trabajo es también lo más difícil de averiguar en una entrevista. La relación con tu nuevo jefe determinará el 70% de tu experiencia de empleado.
En el artículo de enero del 23, llegamos a la conclusión de que la mejor fuente de información sobre tu nuevo jefe son tus futuros compañeros, y explicamos qué preguntas hacerles. Lamentablemente no siempre vas a tener acceso a ellos.
En este artículo de febrero del 23, explicamos qué puedes preguntar durante una entrevista de trabajo a tu futuro responsable, para averiguar cómo será vuestra relación antes de estampar tu firma en el contrato.
¿Cuáles son las tres mejores preguntas que puedes hacer al líder del proyecto?
Vamos con las tres preguntas que, a nuestro entender, os aportarán mayor información, sin poner incómodo a vuestro futuro jefe.
1. ¿Qué funciones haces como líder del equipo?
Empezamos con una pregunta trampa, para dejarle que se luzca y que hable de si mismo.
Eres un profesional, solo quieres conocer el rol de tu nuevo jefe y la cultura de la organización.
Es el Product Owner
Si su respuesta es:
- Yo no soy un técnico, solo resuelvo las dudas funcionales de los consultores.
- Priorizo las actividades del sprint
Tu nuevo líder es un Product Owner. La empresa ha alcanzado un buen grado de madurez en metodologías ágiles y Scrum.
El cambio de trabajo es una apuesta segura.
Es el Jefe de Proyecto
Si responde algo así como:
- Me aseguro de que haya un buen ambiente de trabajo en el equipo.
- Negocio con el cliente para ajustar la carga de trabajo y que el equipo no se queme por exceso de horas extras.
Es un Jefe de Proyecto que tiene claras sus funciones.
Un buen comienzo de una nueva relación laboral.
Es el Líder Técnico
Si está orgulloso de decir:
- Explico a cada consultor qué es lo que tiene que hacer y cómo hacerlo.
- Superviso que están efectivamente haciendo aquello que les he pedido y les ayudo si están atascados.
Es un Líder Técnico. Su experiencia puede ayudarte a crecer profesionalmente, pero si nadie bloquea la presión del cliente, el proyecto tarde o temprano se transformará en un infierno.
Ten cuidado.
Es un Analista/Programador
Si tiene aspecto cansado y su respuesta es:
- Soy el consultor más veterano del grupo.
- Además de mi trabajo técnico, te ayudaré a irte poniendo en marcha.
Es un Analista/Programador. Esta figura es garantía de problemas.
Para empezar, tiene que elegir entre realizar su trabajo técnico y liderar al equipo. Haga lo que haga, el rendimiento general será bajo, así que la presión del cliente será elevada. Y no hay nadie para bloquearla.
Ten cuidado.
El rol del líder aporta mucha información sobre el grado de madurez de la organización.
2. ¿Qué KPIs utilizas para medir el desempeño?
Me encanta porque es una pregunta de aspecto inocente. Aparentemente quieres conocer los criterios que más valora porque quieres hacer un gran trabajo.
En realidad le estás preguntando por su cultura X (Fixed Mindset) vs Y (Growth Mindset).
Aquí no hay respuestas mejores o peores. Lo importante es conocerte a ti mismo, y que tu cultura sea compatible con la suya.
"No uso KPIs, intento motivar a mis consultores con formación y proyectos que son un desafío tecnológico"
Posiblemente estás hablando con un Líder Técnico con una cultura de tipo Y. En general todos los programadores también tienden a tener cultura Y.
Si tu también crees que al trabajador hay que motivarle todos los días mediante formación, desafíos tecnológicos, feedback positivo y un gran ambiente de trabajo, tu cultura es Y. Os llevaréis genial.
"Los KPIs que utilizo para medir el desempeño de los consultores son..." o "Los criterios para establecer nuestros bonus por objetivos son...".
Seguramente estás hablando con un Jefe de Proyecto de cultura X o Fixed Mindset.
Si tu también crees que los profesionales deben venir formados y motivados de casa, que el bonus por objetivos es la mejor forma de motivar a un consultor, y que al trabajo se viene a trabajar y no a tomar café, tu cultura también es X. Tendrás una buena relación profesional con él. A lo mejor hasta os hacéis amigos.
Recuerda, X no es mejor que Y. Lo importante es que tu cultura coincida con la del líder del proyecto.
3. ¿Cómo gestionáis los picos de trabajo?
Eres un profesional. Sabes que eventualmente habrá picos de trabajo por incidencias en planta o por deadlines. Forma parte de nuestra actividad y lo asumes. Solo quieres conocer cómo se gestionan esas situaciones.
Hay varias respuestas posibles, de nuevo de mejor a peor.
"Aquí no hay presión porque hacemos SCRUM. Las historias de usuario que no se completan durante el sprint, se devuelven al backlog"
Es posiblemente la mejor respuesta.
Tu nuevo jefe es un Product Owner. La organización tiene un elevado grado de madurez en la metodología Scrum y no comete los errores típicos de los principiantes.
Posiblemente te mostrará el tablero canvan con los epics e historias de usuario del backlog, y el progreso de las tareas en el sprint actual. Incluso es posible que te presente a tus futuros compañeros.
Un diez.
"Intento que no haya presión, pero de vez en cuando hay momentos de crisis. Entonces hablo con el equipo y ellos se organizan para solucionarlo".
Otra buena respuesta.
Estás ante un Jefe de Proyecto que entiende que su principal misión es bloquear la presión del cliente.
Pero eventualmente son necesarios esfuerzos puntuales. El hecho de que el equipo sea capaz de autogestionar estas situaciones indica que hay un buen ambiente de trabajo. Posiblemente se ha formado un equipo de alto rendimiento.
Un nueve alto.
"Hay bastante presión al final de cada sprint para acabar todas las historias de usuario planificadas"
La organización está haciendo la transición hacia metodologías ágiles.
Cometen los errores típicos del comienzo del proceso, pero eventualmente se convertirán en un buen sitio para trabajar.
Un seis.
"Cuando hay momentos de crisis, hablo con el equipo y les pido un sobreesfuerzo para lograr los objetivos".
Cuando exiges a todo un equipo un sobreesfuerzo, siempre hay alguien con hijos que no puede mantener el ritmo. El conflicto está servido. Adiós al ambiente de trabajo.
El liderazgo es débil y no consigue bloquear la presión del cliente. Es cuestión de tiempo que esos momentos de crisis se conviertan en el día a día.
Un cuatro y medio.
"Llevamos tres meses haciendo un sobreesfuerzo, por eso te contratamos"
Es sin duda la peor de las respuestas.
El proyecto acumula varios meses de retraso, el cliente está muy nervioso y el líder del proyecto no sabe como bloquear la presión. Posiblemente han entrado en una dinámica de lluvia ácida...
El líder del proyecto desconoce los conceptos básicos de gestión de proyectos tecnológicos:
- El 70% de los proyectos a nivel mundial multiplica por tres su plazo de ejecución o se cancela. El caos es el estado natural de los servicios tecnológicos.
- A más presión, menos talento. Incrementando la presión, el líder del proyecto está destruyendo el talento justo cuando más lo necesita.
Un dos.
En resumen
Un cambio de trabajo no debería ser un acto de fe, pero en demasiadas ocasiones damos este paso a ciegas.
Para cubrir ese vacío, arrancamos esta serie de artículos hace ya tres meses a partir de un #ThinkingBreakfast con el equipo de novanotio. Esperamos que estas reflexiones os sirvan de guía durante toda vuestra carrera profesional.
Nos vemos de nuevo en el artículo de marzo de 2023.
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áles son las verdaderas funciones de un Jefe de Proyecto?
Las desconocidas tareas que debe realizar en realidad un Jefe de Proyecto
Dentro de la ingeniería informática hay un importante desconocimiento sobre las funciones del jefe de proyecto.
Se le atribuye la responsabilidad sobre el «resultado del proyecto», pero esta definición abarca la negociación de la propuesta, el diseño de la solución y el control de la ejecución. No es de extrañar que en ocasiones realicen las tareas del Key Account Manager y del Líder Técnico.
Las funciones de un jefe de proyecto las podemos resumir en tres, de menor a mayor importancia:
Control económico.
¿Cuánto vamos a ingresar por el proyecto? ¿Cuánto llevamos gastado? ¿Qué equipo técnico puedo permitirme y por cuánto tiempo?
El control económico parece una cuestión de sumas y restas; ingresos es lo que facturamos, costes lo que gastamos en licencias, servidores y en las nóminas de nuestros consultores.
La mejor receta para optimizar el coste es que todos los miembros del equipo estén en la misma sala y trabajen en exclusiva para el proyecto. Mucho mejor si ya han trabajado juntos anteriormente. De esta manera, la aparición de vínculos emocionales acelera el proceso de desarrollo.
Otro aspecto a tener en cuenta para el control de costes es el tamaño del equipo. La ley de Brooks establece que Plazo x Esfuerzo (en meses hombre) = Constante. Es más eficiente un grupo pequeño y un plazo de desarrollo mayor. El tamaño óptimo de un equipo es de entre 5 y 9 consultores. Por encima de esa cifra tus costes se multiplicarán.
Control del alcance.
¿Qué funcionalidades vamos a desarrollar? ¿Cuándo lo vamos a hacer? y por encima de todo ¿Cuándo dejamos de trabajar en el proyecto?
El control del alcance es crítico porque las especificaciones son infinitas. Los proyectos informáticos nunca terminan. Para conseguir beneficios, tendremos que finalizar el proyecto cuando todavía quedan muchas actividades por realizar.
Por eso es importante priorizar junto con el cliente las tareas. Las menos importantes podrían no ejecutarse nunca.
Muchos jefes de proyecto, en lugar de priorizar los desarrollos, optan por presionar a sus equipos, exigiéndoles horas extras y plazos imposibles. Es un error de principiantes. La presión destruye los equipos y ralentiza los trabajos.
Gestión de la motivación y las relaciones.
¿Cuál es el estado de ánimo del equipo? ¿Cómo se llevan entre ellos?
La gestión de la motivación y las relaciones es sin duda la función más importante de un jefe de proyecto. Y también la menos conocida.
Después de un macroestudio entre miles de profesionales en USA y Europa, la consultora Gallup determinó que el factor más importante para la productividad es el compromiso de los consultores. Y el 70% de este compromiso es responsabilidad directa de su responsable inmediato. Así que tu capacidad como jefe de proyecto determina el 70% de la productividad de los desarrollos.
Es una responsabilidad abrumadora. Un buen punto para empezar son estas trece técnicas para convertir a tus programadores en un equipo de alto rendimiento.
Quizás también te interese conocer los comportamientos que debes evitar. Los jefes de proyecto tardan de media seis meses en desmotivar a sus nuevos consultores. Esta es la lista de cosas que no debes hacer.
Novanotio Certified
Todos los consultores de novanotio reciben el proceso de mentoring ‘Novanotio Certified’. Esto que has leído es solo una de las sesiones. ¿Habría sido distinta tu carrera profesional si hubieras recibido esta formación?
Te animo a que revises nuestras ofertas y descubras si hay alguna perfecta para ti. Te esperamos para que disfrutes una experiencia novanotio.
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!
Fundamentos de SCRUM
Fundamentos de SCRUM
Es importante que domines los fundamentos de SCRUM si quieres implementar con éxito esta metodología.
Seguramente ya has leído libros y blogs que explican los diferentes procesos de SCRUM. El desarrollo en sucesivas iteraciones o sprints, el daily, el Sprint Planning, la retrospective, etc.
Si no conoces los fundamentos de SCRUM, lo mas probable es que cometas los mismos errores que la mayor parte de las organizaciones. Acabarás por implementar SCRUM como si fuera una religión y apenas conseguirás mejorar la productividad.
En novanotio defendemos que hay cuatro sencillas reglas que ayudan a gestionar con éxito los proyectos tecnológicos. Es una buena idea que revises nuestro artículo sobre las cuatro leyes antes de continuar con esta lectura.
En esta entrada vamos a analizar las relaciones entre las cuatro reglas básicas y los procesos de la metodología. Una vez que comprendas los fundamentos de SCRUM, estarás mejor preparado para implementarla en tu organización.
Relación entre SCRUM y la 1ª ley.
Las especificaciones son inciertas, imprecisas e infinitas.
La primera ley nos advierte tres cosas:
– Que el cliente no puede saber lo que quiere. El tiempo invertido en especificar suele ser tiempo perdido.
– Que una especificación redactada en lenguaje natural (castellano, inglés, alemán, etc.) es interpretable.
– Que no es posible finalizar los trabajos. Siempre queda algo por hacer.
¿Cómo responde Scrum a estos tres desafíos?
– El diseño es muy liviano; los requisitos se capturan en Epics, Features e Historias de Usuario, cuya extensión es de un párrafo.
– Para interpretar la especificación, se incorpora al squad un representante del cliente, el Product Owner,
– El Product Owner prioriza los trabajos para que el Retorno de Inversión sea el mayor posible, dentro del presupuesto.
Relación entre SCRUM y la 2ª ley.
One Project, One Team, One Site.
La segunda ley dice que para mejorar la productividad, todo el equipo de trabajo, incluido el cliente, debe estar en una única oficina y dedicarse en exclusiva al proyecto. La convivencia construye vínculos emocionales y relaciones de confianza que son imprescindibles.
¿Cómo construye Scrum los equipos?
En Scrum, los squads de desarrollo están formados por entre cinco y nueve consultores, cuyos puestos de trabajo están próximos entre sí. El Product Owner, que es el representante del cliente, es un miembro más del equipo.
Relación entre SCRUM y la 3ª ley.
Presión x Talento = Constante.
Talento y presión son antagónicos. Cuando uno crece, el otro disminuye.
La tercera ley nos recuerda que en el desarrollo de software debemos priorizar el talento sobre la presión. La velocidad de desarrollo depende del número de buenas ideas, no del número de horas de la jornada.
¿Cómo fomenta Scrum el talento?
Para eliminar la presión, en Scrum no es obligatorio completar todas las Historias planificadas para el sprint. Algunos desarrollos no superan los test y vuelven al backlog.
Relación entre SCRUM y la 4º ley.
El triángulo de Acero.
La cuarta ley nos enseña que Alcance, Plazo y Calidad están relacionados de tal forma que, si fijas dos de ellos, el tercero se degrada.
Tradicionalmente un contrato fija el alcance y el plazo. ¿El resultado? El 80% de los grandes proyectos son un fiasco.
Así que, como cliente, debes elegir entre:
– Sacrificar el Alcance. Ciertas funcionalidades no se construirán.
– Sacrificar el Plazo (y multiplicar el coste). El sistema se entregará muuucho mas tarde de lo planificado.
– Sacrificar la Calidad. El sistema tendrá errores en producción y será complejo de operar.
¿Qué variable sacrificamos en SCRUM?
La metodología SCRUM determina que la variable sacrificada es el Alcance.
La gran aportación de SCRUM es modificar la definición de éxito de un proyecto. Ya no tenemos que cumplir un alcance dentro de un plazo y con una buena calidad. Cosa que, por cierto, es imposible.
Éxito es conseguir el mayor retorno de inversión posible, dentro del presupuesto y en un plazo acotado.
¿Puedo mejorar la eficiencia sin usar Scrum?
Si conoces los fundamentos de Scrum, puedes utilizar los principios básicos de gestión de proyectos y mejorar el rendimiento de tus proyectos sin necesidad de implementar la metodología.
Pero SCRUM es la palabra de moda. ¡Aprende a implementar esta metodología y tu valor para el mercado se multiplicará!
Cómo orientar tu carrera profesional usando el test de Gallup
Cómo orientar tu carrera profesional usando el test de Gallup
En el entorno tecnológico es fácil tener una primera promoción
Estás haciendo un gran trabajo como programador, y como premio te han propuesto cambiar de actividad. Quizás te han pedido que lideres a un grupo de consultores. O tal vez que asistas a una reunión de ventas.
En el entorno tecnológico es fácil tener una primera promoción. Descubrirás que hay roles que te son tan naturales cómo respirar y otros en los que, a pesar de tu esfuerzo, sólo recibes disgustos. ¿Cómo saber si la jugosa manzana que te ofrecen está envenenada?
El test de fortalezas de Gallup
Vamos a estudiar cómo orientar tu carrera profesional usando el test de fortalezas de Gallup. Si todavía no lo has hecho tienes el enlace aquí. Considera estos veinte dólares como una de las mejores inversiones de tu vida.
Este test te descubre tus principales fortalezas, es decir, los tipos de talento que has desarrollado de forma natural. Gallup distingue entre treinta y cuatro fortalezas que se agrupan en cuatro ámbitos:
- Fortalezas de ejecución. ¿Qué es lo siguiente que tengo que hacer? Si tu única recompensa es un trabajo bien hecho o no puedes dejar una tarea a medias, eres un auténtico ejecutor.
- Fortalezas de pensamiento. ¿Cuál es la mejor forma de hacer las cosas? Si no puedes dejar de estudiar o tienes una potente capacidad analítica eres todo un pensador.
- Fortalezas de relación ¿Cómo construyo relaciones? Si rápidamente sabes cómo son las personas, o para ti lo más importante es el ambiente de trabajo, tienes este tipo de fortalezas.
- Fortalezas de influencia. ¿Cómo consigo convencer a los demás? Si siempre tienes en la boca la palabra adecuada considérate un influencer.
¿Qué fortalezas ayudan a desempeñar los distintos roles tecnológicos?
No todos los roles tecnológicos precisan de las mismas fortalezas. Según el resultado de tu test de Gallup, te sentirás más cómodo en unos u otros puestos.
Si tus fortalezas son de pensamiento y relación
En los primeros test de Gallup que realizamos, descubrimos que los mejores programadores combinaban fortalezas de pensamiento y relación.
Pronto nos dimos cuenta que, para programar, los vínculos emocionales son muy importantes, porque facilitan la construcción de las especificaciones y la coordinación de las tareas.
En resumen, si tus principales fortalezas son de relación y pensamiento, la programación se te dará bien de forma natural.
Si tus fortalezas son de pensamiento
Sin embargo, si la mayoría son de pensamiento, estarás más cómodo en roles con más complejidad y menos relación, como la administración de sistemas o la ciberseguridad.
Si tus fortalezas son de relación
Si tus fortalezas son sobre todo de relación, busca trabajos donde tengas que estar en contacto con el cliente. Los roles de soporte combinan una parte de conocimiento técnico y mucha relación con los usuarios de las aplicaciones y sistemas.
Si tus fortalezas son de relación e influencia
Si a las fortalezas de relación se suman las de influencia, tu sitio está en el área de ventas. Aquí tu misión es crear un vínculo con el cliente y convencerle de que ponga una firma. ¡Como pueden pagar esas comisiones por un trabajo tan sencillo!
Si combinas fortalezas de pensamiento e influencia
La combinación de pensamiento e influencia es interesante para liderar equipos. Te sentirás cómodo en las posiciones de Líder Técnico, Jefe de Proyecto o Gerente.
Si tus fortalezas son sobre todo de influencia
Cuantas más fortalezas de influencia aparezcan en tu test de Gallup, más cómodo te sentirás con cada ascenso. Director de Operaciones, CIO, CTO… El cielo es el límite.
Si la mayoría de tus fortalezas son de influencia, tu sitio está en la alta dirección. Algunos te llamarán trepa o pisacuellos. Bueno, quizás no has sido el mejor técnico, pero siempre sabes lo que tienes que decir. Y esas fortalezas te empujarán a los roles que empiezan por C.
¿En qué organizaciones encajarás mejor?
Si tus fortalezas son sobre todo de pensamiento, estarás más cómodo en organizaciones con cultura Growth Mindset.
Por el contrario, si son de ejecución o influencia, busca empresas de tipo Fixed Mindset.
En este artículo de nuestro blog analizamos las diferencias entre ambos tipos de liderazgo.
Alinea tu trayectoria con tus fortalezas
Cuando tu trayectoria profesional está alineada con tus fortalezas, te pagan por hacer lo que se te da bien de forma natural. En el caso contrario también puedes hacer un trabajo brillante, aunque a costa de un mayor esfuerzo y desgaste personal.
¿Quieres saber que actividades son mas adecuadas para ti? Envíame el resultado de tu test de fortalezas y te daré algunas ideas para orientar tu carrera.
Carreras profesionales. El analista programador
Carreras profesionales. El Analista Programador.
El Analista Programador es la primera promoción dentro de las carreras profesionales tecnológicas. Y esconde una trampa que debes conocer.
Con un poco de paciencia, en tres o cuatro años serás el programador más veterano de un pequeño grupo de consultores, lo que te convierte de facto en su líder técnico, el Analista Programador.
Aquí te vas a enfrentar a tu primer problema de liderazgo. ¿Dedico mi precioso tiempo a realizar mi trabajo técnico, o a formar a los consultores recién incorporados?
Existen tres posibles estrategias:
Estrategia 1. Priorizas la formación de los nuevos consultores
Tu primer intento será priorizar la formación de los nuevos consultores, para que puedan trabajar con autonomía.
Hemos representado en la gráfica el resultado de esta estrategia con una línea verde. ¿Te das cuenta de que a corto plazo es la solución menos eficiente? Esto significa dos cosas. Que tu lista de tareas pendientes amenaza con llegar al infinito. Y que tu cliente y tu Jefe de Proyecto están muuuy nerviosos.
Si consigues soportar la presión, a medio plazo construirás un Equipo de Alto Rendimiento.
Pero lo normal es que resbales a la estrategia número dos.
Estrategia 2. Priorizas tu trabajo técnico
Cedes a la insoportable presión del cliente y dedicas la mayor parte de tu tiempo a esa lista de tareas críticas pendientes.
Estás tan concentrado que hasta te molesta que te consulten dudas. Los jóvenes consultores se aburren y se frustran porque aprenden muy despacio. Hasta es posible que alguno de ellos se vaya. ¡Justo ahora que empezaba a tener algunos conocimientos!
Hemos representado en rojo los resultados. A corto plazo superas a la estrategia uno, pero sigues muy lejos de las expectativas del servicio. Ya sabes, tensas reuniones con el cliente y con tu Jefe de Proyecto.
Así que, agotado, caes a la estrategia número tres.
Estrategia 3. Haces tu trabajo técnico y además formas a los nuevos consultores.
Esta estrategia supone un enorme desgaste por el volumen de horas necesario. Es una muestra de compromiso hacia tu empresa y tu cliente. ¡Estás sacrificando tu vida personal y familiar! Lo menos que esperas es que alguien te de las gracias.
Y si te fijas en la línea amarilla, tus resultados superan a las estrategias uno y dos. Pero lamentablemente sigues por debajo de las expectativas. ¿Sabes lo que eso significa? Si. En lugar de agradecimientos, mas tensas reuniones con el cliente y con tu Jefe de Proyecto.
¿Ves como se desploma la línea amarilla? Ese es el punto en que presentas la baja voluntaria o la baja por depresión.
A corto plazo, ninguna de las estrategias alcanza las expectativas
Como puedes ver, a corto plazo ninguna estrategia ofrece resultados acordes con las expectativas, lo que se traduce en presión. Retrasos, tareas pendientes y discusiones.
Entonces ¿Cuál de ellas elegir?
Pues, teniendo en cuenta que las estrategias dos y tres nunca alcanzan la productividad deseada, la decisión no es difícil.
Nuestro consejo es apostar por las personas y elegir la primera de las opciones. Aprenderás a gestionar la presión y aprenderás a crear equipos de alto rendimiento. Y si la presión te supera, es un buen momento para dar un paso atrás y retomar el camino del Especialista Tecnológico.
En próximos artículos veremos cómo la estrategia número uno consigue a largo plazo superar las expectativas del cliente. Y veremos también los nuevos desafíos que eso genera.
No olvides volver de vez en cuando y revisar las nuevas entradas.