Proyectos - Los 20 mandamientos del profesional humano, feliz y productivo

1. Buscarás ser exitoso a nivel profesional y personal. Equilibrarás ambos mundos y encontrarás la forma de integrarlos en una sola vida.
2. No buscarás dinero o poder como el fin ultimo de tu profesión. Te preguntarás antes de hacer algo ¿Como mejorará esto la calidad de vida de otro ser humano?
3. Lo mas importante serán las personas y JAMÁS pasarás por encima de ellas.
4. Ganarás sin que el otro pierda.
5. Defenderás tu integridad y la de tu equipo por encima de los intereses empresariales, económicos o de poder.
6. Pondrás las técnicas y las teorías a tu servicio. Las adaptarás y moldearás a la necesidad y realidad actual.
7. Comprenderás que los problemas técnicos se solucionan con estudio, pero los problemas de actitud solo se solucionan con actitud.
8. Te orientarás al logro de metas. No a la realización de actividades
9. Confiarás en el equipo de personas con quien trabajas
10. Velarás por descansar todos los días. 
11. No trabajarás mas para lograr más. Te enfocarás mas para lograr mas.
12. Realizarás solo una actividad al tiempo y te enfocarás en algo diferente cuando la hayas terminado completamente.
13. Amarás la calidad por encima de todas las cosas (Laborales)
14. Trabajarás con personas no con recursos (los recursos se consumen y las personas se desarollan y son irreemplazables).
15. Disfrutarás plenamente cada cosa que hagas. No esperarás a lograr algo para sentirte afortunado y feliz y velarás porque el circulo de personas que te rodean sean conscientes de lo mismo.
16. Serás consciente de tu naturaleza humana e imperfecta y por lo tanto asumirás tus errores y los errores de quienes te rodean como una oportunidad de mejora.
17. Serás consciente que el poder del grupo es infinitamente mayor al poder del individuo y pondrás los objetivos del equipo por encima de las ambiciones personales.
18. No siempre tendrás la razón
19. Comprenderás que el conocimiento no te pertenece y por lo tanto enseñarás a todo aquel que lo necesite sin temor a verte desplazado.
20. Te reconocerás un ser humano incompleto y buscarás la ayuda de los demás cuando tu conocimiento sea limitado.

Proyectos - Scrum Master. El verdadero impedimiento.

El rol del Scrum master en la metodología SCRUM es radicalmente diferente a los cargos que tradicionalmente vemos en las empresas. Sus objetivos son principalmente asegurar que la metodología se cumpla, remover impedimentos que afectan la productividad de las personas, aumentar paulatina y progresivamente la velocidad del equipo y sobre todo VELAR PORQUE LAS PERSONAS SE SIENTAN BIEN.

¿Pero que pasa cuando este rol es asumido por alguien que se encuentra sumergido en el tradicional rol de director de proyectos?

La experiencia me ha demostrado que si alguien quiere ser Scrum Master primero debe desaprender todo aquello que haya vivido como director y para poder hacerlo debe asegurar que sus superiores están alineados con esto. Mas aún. Debe asegurar que la empresa lo vea como Scrum Master y le permita actuar como tal. Es muy complicado lograr cumplir con las responsabilidades del rol cuando los jefes simplemente ejercen presión y exigen resultados haciendo caso omiso a lo que piensa el equipo.

Incluso dentro del mundo de la tradicional gerencia de proyectos existen varias clases de personas:

• Aquellos que les gusta dar ordenes, pensar y decidir que es lo que debe hacerse.
• Aquellos que le dan la libertad a sus colaboradores para que decidan como van a cumplir con una meta.
• Aquellos a los que simplemente les interesa cumplir una meta e inspirar a los demás con el ejemplo, mas allá de las ordenes y la demostración de superioridad y poder.

De estos tipos de personas las que mas fácilmente se adaptarían a este nuevo rol son las dos ultimas, pero la primera es absolutamente perjudicial si se está trabajando con un grupo de profesionales que tienen el conocimiento y la capacidad de asumir retos y sacarlos adelante. Quien se encuentra en esta posición es un absoluto y gran autócrata o en otras palabras un absoluto y gran pendejo si cree que esta actitud le permitirá obtener mejores resultados de las personas con quienes trabaja. 

El poder es bastante seductor y quien se encuentra en esta posición no duda un solo instante en hacer gala de el y opacar a los individuos con quienes trabaja con el fin de verse siempre como aquel super héroe que salva la situación. No se da cuenta que el precio es demasiado alto. Todos los regímenes autocráticos tarde o temprano caen cuando las personas comprenden que tienen un poder mas allá de lo imaginable y que pueden lograr grandes y mejores cosas por si mismas trabajando en equipo.

A continuación una serie de elementos que me han hecho la vida imposible en los proyectos SCRUM de los que he participado. 

• Tiempo: El valor ganado no avanza de forma directamente proporcional al esfuerzo invertido. Un Scrum Master que todos los días cuestione el trabajo realizado por el equipo y simplemente critique el hecho de que el Burn down chart no baja a diario, es un gran dolor de cabeza.

• Interferir con el equipo: No confiar en el grupo de personas con quienes se labora y todo el tiempo cuestionar la forma de trabajo y las decisiones tomadas.

• Decidir lo que debe hacerse: Con la excusa de que conocen mejor la empresa o el negocio todo el tiempo interfieren y asignan el trabajo de las personas, sin darle la oportunidad al equipo de actuar por si mismo.

¿Como podría un niño no depender de su padre, si este no lo deja caerse, tropezarse y tomar sus propias decisiones?. La excusa siempre es el tiempo. "Si no les digo que hacer ustedes tardarán mas tiempo en descubrirlo y no le podremos entregar valor al negocio". La verdad es que: "Siempre existirá excusas."

• Culpar: Siempre es mas fácil culpar a los demás de nuestra incapacidad. No se puede pretender que el equipo logre grandes cosas si no se le da una gran autonomía. 

• No es suficiente lo que se logra: Pocas cosas tan desmotivantes como terminar las historias de usuario comprometidas para un Sprint y que el Scrum master diga. "La velocidad realmente no fue tanta porque considero que le asignaron demasiados puntos a ciertas historias de usuario que eran muy simples".

• No velar por que la metodología se cumpla: Esta es una labor propia del rol. Si él mismo incentiva a no seguirla con el fin de entregar a como dé lugar, tenemos grandes problemas

• No seguir ciertas practicas porque no hay tiempo: No permitir usar practicas como TDD, pair programming o pomodoros porque implican tiempo adicional y se debe entregar rápidamente al usuario. ¿Será que cuando estallen los problemas el producción, el tiempo invertido en pruebas unitarias no se justifica?.

Un Scrum master de estas características cumple un solo papel dentro de un proyecto. SER EL ÚNICO Y GRAN IMPEDIMENTO. Un impedimento que debe ser removido si se quieren lograr grandes cosas.

La labor del Scrum master no es simple ni todos estamos capacitados para serlo. Primero debemos vencer al mayor enemigo si queremos tener las cualidades necesarias. Nosotros mismos. 

Proyectos - Un inicio ágil bastante lento.

Un inicio ágil bastante lento

Un cambio de metodología va mucho mas allá del conocimiento de la misma pues conlleva a asumir una filosofía que no todos estamos dispuestos a seguir. Las metodologías ágiles parten de planteamientos bastante admirables, y dado su poco nivel de prescripción, iniciarse en ellas sin la ayuda de un experto con experiencia puede ser bastante complejo.

A continuación una serie de dificultades que nos encontramos tratando de iniciar un proyecto con SCRUM:

• Falta de alineación: Suena a frase de cajón pero esta es la principal dificultad al iniciar cualquier proyecto. ¿Que es lo que quiere lograr el negocio?, ¿El producto owner está alineado 100% con lo que quiere lograr y las prioridades definidas son un reflejo de tal alineación?

• Incapacidad para priorizar: El negocio siempre quiere tenerlo todo. La consecuencia es que termina teniendo nada.

• Falta de herramientas: Pareciera ser un ítem bastante trivial pero la metodología plantea el uso de muchos elementos (Post-its, marcadores, tablero, tarjetas de estimación de poker, tarjetas de escritura de historias de usuario, entre otros) que en ausencia de ellos entorpecen el proceso. 

• Visión del proyecto: Todos los miembros del equipo deben tener la misma visión del objetivo que debe lograrse. Pida a varios miembros del equipo que explique las metas que deben alcanzarse y le beneficio que se entregará al completar el proyecto. Muchos probablemente no conocen estos datos.

• Demasiado tiempo en el arranque: Quedarse mucho tiempo definiendo planes, herramientas, haciendo consensos o cualquier otra cantidad de cosas, puede ser contraproducente. ¡JAMAS ESTAREMOS LISTOS PARA ARRANCAR!, de modo que es mejor dedicar un tiempo corto y limitado a esta labor y ajustar todo los que sea necesario en los primeros sprints. Lo importante es que se maneje la expectativa y no se esperen grandes resultados pues el equipo apenas se estará organizando.

• Orientación a generar valor al negocio: En todo proyecto de desarollo lo común es que se realicen actividades orientadas a generar la base de desarollo que permitirá construir la funcionalidad requerida por el negocio. En SCRUM es vital que en cada iteración se entregue valor aún cuando sea mínimo y encontrar este equilibrio no es fácil. ¿Como decirle al usuario que en 8 días no pudimos hacer nada porque configurar la aplicación fue muy complejo o porque no alcanzamos a definir el plan de GCS?. Esto es inaceptable.

• Justificar la tecnología de implementación: Algunas veces el tiempo y el costo de implementación pueden variar considerablemente por la inclusión de una nueva tecnología. Justificar el ¿Por que? al negocio es una labor compleja si no se explica en sus términos. De hecho siempre se debe buscar el beneficio de esta ante el usuario, ya sea de cara a una mejoría en la aplicación o en temas de proyecto como tiempo o costo, en el mediano o largo plazo.

• Expectativa: Muchas veces el negocio espera mucho mas de lo que le podemos ofrecer con el tiempo y el presupuesto disponible. Alinear expectativas es importante al inicio de modo tal que no se lleven una gran desilusión. Esto suele ser una labor ardua.

• Pretender hacer planes al inicio: Los planes deben estar el servicio del equipo por lo tanto este es quien los diseña de acuerdo a sus necesidades. Muchas veces se pretende definir formas de trabajo (TDD, ATDD, DDD, BDD, etc) pero es la realidad del proyecto la que determinará la mejor combinación. Es importante sentar una base común al inicio. Por ejemplo, el plan de gestión de la configuración podría diseñarse previo al desarollo pero esto no impide que cambie durante el proyecto.

• Intermediación: Para solucionar un problema se pasa por varios intermediarios hasta llegar al responsable. Esto dilata demasiado el tiempo de resolución del problema.

• Impedir la autogestión del equipo: El rol del scrum master no se asume plenamente y se ve viciado por elementos de las metodologías tradicionales de gestión de proyectos, rayando en algunas ocasiones con el seguimiento, control y la interferencia en la toma de decisiones.

• Falta de foco: Es muy común que cada miembro del equipo se concentre en una historia de usuario y al final queden varias empezadas. Sobre todo al inicio cuando el equipo no conoce su velocidad es preciso enfocarse solo en ciertos items de modo que se garantice la entrega de algo aún cuando sea poco. Solo los items completos que dan valor al negocio generan avance.

• No tener en cuenta a los stakes holders: Dada la velocidad con la cual se generan entregables en SCRUM, es muy importante que todas las áreas que intervienen de manera directa o indirecta en el ciclo de vida del producto hasta que llega a producción, se tengan en cuenta. Si requerimos permisos en la estación de trabajo, configuraciones en los servidores previo al paso entre ambientes, configuraciones de bases de datos,  o cualquier otro tema que dependa de otros, debe identificarse a quien acudir y tenerlos en cuenta desde el inicio. Si cualquiera de ellos no ofrece la ayuda adecuada en el momento justo, probablemente no generemos valor en muchos sprints.

De todos los aspectos mencionados el mas impactante es el ultimo. Los stake holders afectan de una manera impresionante todo el proceso. Durante el primer sprint del proyecto objeto de análisis no se entregó absolutamente nada por lo siguiente:

• Una de las estaciones de trabajo tenía problemas y la dependencia con soporte tecnológico impedía avanzar en este frente
• No se tenía acceso como administrador a la estación de trabajo por lo que no era posible instalar el software requerido para iniciar labores.
• Se requerían accesos servidores y aplicaciones existentes dentro de la compañía cuyos responsables tenían un acuerdo de servicio demasiado amplio para un proyecto SCRUM.

Los errores cometidos nos son muy diferentes a los que se presentan en proyectos gestionados de forma tradicional. La diferencia radical es que bajo esta metodología se falla rápidamente. Muchos de estos problemas los aprende a manejar el equipo en el tiempo conforme adquiere autonomía y el apoyo de los stakes holders. Esto se evidenció después del primer sprint en el cual se pudo generar valor. 

Solo un poco pero se generó valor¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡.

Estimación - El bello arte de estimar el software

El bello arte de estimar el software

Pocos proyectos tan difíciles de estimar como los proyectos de software. ¿Por que?. Porque contrario a lo que muchos creen, la construcción del software es un arte y por lo tanto no puede concebirse una fabrica que automatice su construcción. La construcción de un producto de software es un reflejo directo del conocimiento de quien construye. Dos personas pueden llegar a un mismo resultado con diseños totalmente diferentes con el agravante de que ambos pueden considerarse buenos diseños en contextos diferentes. Entonces. ¿Como ser certeros en las estimaciones que entregamos?.

la respuesta es muy simple. NO SE PUEDE SER CERTERO. Es absolutamente imposible. Es mas, las certeza va en contra de la definición de estimación "Aprecio y valor que se da y en que se tasa y considera algo. RAE". Máximo podríamos llegar a un valor aproximado que permita calcular la fecha de finalización del proyecto. Pero mas allá no tiene sentido. ¿Y como lograr esa aproximación?

Lo mas importante a la hora de estimar radica en entender lo que debemos lograr y que debemos hacer para lograrlo. 

A continuación describo una serie de actividades que suelo realizar cada vez que debo estimar. No son nada del otro mundo, incluso pueden verse como tareas derivadas de la aplicación del sentido común (El menos común de los sentidos).

El proceso se puede dividir en 4 fases.:Entender la necesidad, entender como vamos a satisfacer la necesidad, identificar las actividades que se requiere ejecutar para lograr el objetivo y estimar cuanto tiempo tardaremos para lograrlo.

ENTENDER QUE ES LO QUE SE NECESITA

• Entender el contexto de la necesidad: Se sugiere leer toda la documentación sin preocuparse por conocer cada aspecto de forma detallada, el contexto es suficiente para orientar la forma como se solucionarán las inquietudes.

• Break: Dependiendo del tamaño y cantidad de in formación que deba revisar para entender el contexto, es preferible se tome un descanso y preferiblemente cambie de actividad. Esto le permitirá cuando retome el tema tener la mente mucho mas despejada.

• Estructurar los objetivos, necesidades y requerimientos: La documentación que recibimos normalmente viene dispersa o agrupada por diferentes temas que no tienen sentido para nosotros. Ordenarla y estructurarla será la base para entender en detalle lo que nos solicitan.

Figura 1. Objetivos, necesidades, y requerimientos estructurados

Es importante durante la estructuración, escribir todas las inquietudes que tengamos sobre la definición, de modo que podamos reunirnos con el experto para aclararlas.

Durante esta actividad podríamos empezar a identificar ciertas tareas que deben realizarse y que servirán como insumo a la estimación. Aunque el siguiente paso será precisamente el de identificarlas, se puede hacer a lo largo del ejercicio de modo que no sean olvidadas.

• Reunión con el usuario: Es importante tener una reunión con la persona que tiene la necesidad que estamos analizando. Se sugiere que el experto empiece contando una visión global de lo que requiere y las razones por las que lo solicita. Esto permitirá aclarar mas el contexto. Luego se puede entrar en el detalle y empezar a discutir puntualmente las inquietudes descubiertas en el paso anterior.

ENTENDER COMO VAMOS A LOGRAR LO QUE NOS SOLICITAN.

• Realizar un diseño conceptual: Es imposible estimar si no tenemos una idea medianamente clara de como vamos a lograr lo que nos están pidiendo. El éxito de este paso depende de la experiencia que tengamos solucionando problemáticas o necesidades similares. Si nos piden construir una carretera, probablemente un zootecnista no sea la persona mas adecuada para hacer un diseño de la forma como se va a construir. En el mundo del software es muy conveniente cubrir este paso con un diseño de arquitectura, teniendo en cuenta los drivers arquitectónicos (Restricciones técnicas, de negocio, atributos de calidad, necesidades funcionales) que estén disponibles al momento de su realización. El nivel de detalle que se logre dependerá del grado de incertidumbre y del nivel de riesgo que se está dispuesto a asumir.

Diseño

IDENTIFICAR QUE ACTIVIDADES DEBEMOS EJECUTAR PARA HACERLO POSIBLE.

• Construir el WBS o EDT (Work Break Down Structure o Estructura de Desglose de Trabajo): Se puede tomar como insumo el artefacto descrito en la figura 1. La idea es que sea estructurado de manera realista teniendo en cuenta la información entregada por el usuario en la reunión. 

El objetivo de realizar el WBS es principalmente identificar las actividades que deben realizarse para completar el producto, por esta razón es importante equilibrar el nivel de detalle al que se quiere llegar y esto depende de dos aspectos principalmente: El nivel de confianza que se requiere de la estimación y el tiempo disponible para realizarla. 

Si realizamos un desglose muy detallado, es posible que logremos un nivel de confianza mayor (Aunque esto hará que se extienda mucho el tiempo de planeación y aún así lo mas probable es que se realicen asunciones que en el transcurso del proyecto se desvirtúen e invaliden la estimación.), pero también es posible que sobre estimemos (Podríamos desglosar actividades muy pequeñas que realmente requieren menos tiempo del planteado). 

Si realizamos un desglose de muy alto nivel lo mas probable es que subestimemos (Podríamos perder de vista actividades importantes que harán que el esfuerzo requerido sea mayor).

Siempre es importante tener en cuenta el grado de incertidumbre con el que se debe convivir en el momento de la estimación (Conforme avanza el tiempo esta se va reduciendo hasta llegar a 0 en el momento de la entrega del producto). Este será el factor que nos permitirá determinar que tanto esfuerzo invertir en el desglose. A mayor grado de incertidumbre, menor debe ser el esfuerzo invertido.

Figura 2. Cono de la incertidumbre

• Retroalimentar el WBS con lecciones aprendidas: Es importante revisar algún repositorio en el que se encuentren tareas que son repetitivas en todos los proyectos tales como planeación, aseguramiento de la calidad, arquitectura de software, gestión del proyecto (Reuniones de seguimiento, gestión de riesgos, gestión de la calidad, control, cierre), despliegues, pruebas o actividades que hace el cliente en cada entrega y que puedan afectar la fecha de finalización del proyecto. Todo esto con el fin de no perderles de vista y tener en cuenta el esfuerzo que requieren en la estimación. Este repositorio debería actualizarse constantemente cada vez que se cierren los proyectos con el fin de aprender de experiencias previas.

ESTIMAR CUANTO TIEMPO TARDAREMOS PARA LOGRARLO.

Solo resta colocar un número. Esta es la tarea mas sencilla de todas ¿Por que?. Porque cualquier número que se coloque será solo una percepción aún si viene de un repositorio de datos históricos, o si lo estimó mas grande sabio del planeta. Una percepción que jamás será acertada.

Es muy recomendable en este punto diferenciar estos tres términos: Tamaño, Esfuerzo, Tiempo. 

El tamaño como su nombre lo indica pretende dimensionar que tan grande es el software que vamos a construir. Se puede dar en las siguientes medidas: Function points, Story points, o cualquier otra unidad que quiera utilizar. Lo realmente importante es que el valor obtenido tenga algún significado para usted. 

El esfuerzo dependerá de quien ejecute las tareas. Una persona puede tardar 4 Horas realizando un CRUD a una tabla de una base de datos, mientras que otra menos experimentada tardará 8 Horas. El esfuerzo es la cantidad de horas que una persona invierte para completar una unidad de tamaño. SCRUM por ejemplo traslada el esfuerzo al Sprint. ¿Cuantos puntos de historia podemos completar en este Sprint?, las metodologías tradicionales asignan el esfuerzo a la tarea misma.

Los valores de tamaño y esfuerzo podrían ser obtenidos a través de ciertas técnicas:: Function points, Planning poker, Deal and Slide, Mark II function points, analogía, Wideband delphi, entre otras. Ninguna ofrecerá un valor mas acertado que la otra pues al final en cualquier caso se terminará usando Juicio Experto dado que los valores que reciben como insumo estas técnicas serán subjetivos.

Otra alternativa es utilizar datos históricos pero esto tampoco le dará mas precisión a la estimación. Es mas. Una simple suma puede ser mas efectiva que la aplicación de una gran formula matemática muy compleja. En cualquier caso seguirá siendo una estimación.

El tiempo dependerá de otros factores como los días festivos, las vacaciones, la cantidad de personas involucradas en la realización de una tarea, etc. En estos casos es útil utilizar técnicas como la ruta crítica, o Gantt para tomar en consideración estos factores.

Recomendaciones:

• No utilizar la unidad de medida Horas en todos los casos. A mayor incertidumbre mayor debe ser la unidad de tiempo utilizada. Por ejemplo. En etapa comercial la unidad mínima de medida deben ser meses, semanas o días  A medida que reduce la incertidumbre puede reducir la unidad de media usada pero mínimo debe darse en Horas. Los minutos o medias Horas dan una falsa sensación de precisión. Si una funcionalidad es tan pequeña que no se demora al menos una hora, entonces agrúpela con otras tareas que pueden realizarse en esa unidad de tiempo.

• Utilice la analogía: Es muy útil siempre comparar actividades que se han llevado a cabo de forma similar en otros proyectos para comparar la estimación. Esto permitirá identificar trabajo adicional o ciertos riesgos para los cuales debe realizarse reservas de gestión. Por ejemplo. Si se está estimando la integración con un sistema externo y previamente otros proyectos lo hicieron, revise que pasó y cuanto tardaron realmente.

Conclusión: Es mejor ser fiel al Décimo primer mandamiento "No estimarás"