Ventajas del desarrollo de proyectos basado en iteraciones

Para aquellos quienes han trabajado en proyectos de desarrollo de software mediante el uso de métodos tradicionales, el hecho de particionar el proyecto en pequeños ciclos y no en fases les pueda resultar extraño. Partir del hecho de tomar un grupo de características y someterlas a un mini proceso auto contenido de construcción, en el que se tiene como meta no enfocarse en un gran bloque o módulo, sino en un compromiso de concluir con un paquete de características, puede ser romper con ciertos paradigmas laborales.

Se trata de dividir un proyecto en pequeños ciclos, llamados por algunos como iteraciones o para quienes trabajan bajo SCRUM en Sprints, ofrece enormes ventajas para que nuestro cliente o promotor del proyecto, perciba avances sustanciables y controlados en la construcción de su sistema o producto, adicional que en términos generales genera enormes ventajas para la gestión del proyecto sobre todo para la mitigación de riesgos.

Antes de mencionar cuales son los beneficios es conveniente que nuestro cliente tenga claro cómo se trabaja bajo este enfoque de iteraciones ó Sprints, y la importancia de que una vez iniciado no es conveniente para las dos partes, tanto equipo como cliente, modificar el alcance del compromiso del mismo.

1.-Visión cercana de un paquete de características (Compromisos Acotados)

El cliente define un alcance de lo que requiere pero el equipo decide en cuanto tiempo lo puede tener listo. Lo anterior mencionado es una regla de oro en la cual también es importante recalcar que el alcance tiene que ser claro, en base a características que se puedan tener listas y funcionales en lapsos de tiempos cortos: 1, 2, 3 o 4 semanas y siempre partiendo desde aquello que le dé más valor al negocio.

2.-Construcción controlada e incremental

El equipo construye las características comprometidas para una iteración o sprint desde una perspectiva de agregar capas de funcionalidad, sobre las bases de lo que ya está construido de tal forma que el cliente puede ver en pequeños lapsos como el producto toma forma.

3.- Control de cambios y riesgos

Pasadas unas 3 o 4 iteraciones tanto el equipo como el cliente determinan si los esfuerzos realizados hasta el momento van enfocados en lo que se requiere, a lo que el negocio realmente persigue o si el producto resultante cubre con las expectativas de los usuarios, de no ser así se pueden hacer ajustes en el alcance y del mismo modo se controlan los riesgos, no desde un enfoque global sino desde un micro incremento de funcionalidades y características.

4.- Construcción enfocada en el negocio

Como ya se mencionó toda iteración inicia con un compromiso de características que el cliente considera que son esenciales o más importantes para el negocio, de tal manera que en determinados ciclos ya se puede tener un producto potencialmente usable, en el cual el retorno de la inversión puede darse antes de que oficialmente termine el proyecto.

5.-Mejora en el rendimiento del equipo

El equipo refuerza sus habilidades al orientarse a cubrir con los compromisos pactados durante la iteración, de tal forma que la velocidad de desarrollo es exponencial al número de funcionalidades base que se tengan ya implementadas en el producto; las nuevas funcionalidades solo van arropando a las anteriores y en cada ciclo el conocimiento se retroalimenta para mejorar la forma de trabajar.

Marco de Trabajo vs Metodología

“Un buen arquero no es juzgado por sus flechas si no por su puntería”

Thomas Fuller

Cuando se habla de metodologías se habla de un proceso definido para hacer las cosas, para hacer actividades que ayuden y den orden a un proceso de elaboración de un producto. El problema no está en las metodologías ni en los procesos, el problema está cuando se quieren llevar al pie de la letra en proyectos, y estos tienen diferentes características o diferentes entornos.

No existe mejor herramienta que una mente despierta

Personalmente prefiero el uso de marcos de trabajo porque considero que pueden ser usados como una caja de herramientas, y dichas herramientas pueden ser usadas cuando el entorno, la situación o la experiencia lo ameriten, sin estar sujetos a un paso a paso.

Las ventajas que ofrecen los marcos de trabajo es que permiten responder de manera oportuna a los cambios, ajustando las herramientas y líneas de acción de acuerdo al entorno del proyecto. El equipo de trabajo no necesita estar sujeto a un modelo de trabajo restrictivo especificado por una guía, sino más bien en un modelo adaptativo orientado en la experiencia recabada en las iteraciones del proyecto en ejecución o de proyectos anteriores.

Ejemplo de las diferencias entre las Metodologías y los Marcos de Trabajo en ejecución:

Metodología	Marco de Trabajo
Orientado en el proceso.	Orientado en las personas.
Centrado en las bases contractuales del proyecto.	Centrado en el producto y sus beneficios.
Ejecución casi obligatorio de Fases, roles y herramientas.	Ejecución adaptativa de las fases y herramientas.
Basado en especificaciones o guías oficiales.	Basado en la experiencia y retrospectivas de todo el equipo.
Basado en fases secuenciales de un proceso.	Basado en iteraciones y herramientas adaptativas.

Alguien dijo en una ocasión: No porque tengas un martillo en la mano le debes de ver a todo forma de clavo. Las metodologías tienen muchas ventajas competitivas porque nos dan un orden en la forma de trabajar, pero cuando el entorno y variables del proyecto son muy cambiantes, mucho de lo que se tiene se convierte más en una limitante que en una herramienta de apoyo para la obtención de los objetivos.

El sentido del proyecto no es el proyecto en sí, sino el resultado y su valor que genera a las personas. Sin importar que modelo se utilice, no existe mejor herramienta para la obtención de resultados que la experiencia y una mente despierta.

5 Claves prácticas para hacer planeación ágil sin morir en el intento

“El hombre que se prepara, tiene media batalla ganada".

Benjamín Franklin

A pesar que los métodos agiles están basados en no apegarse demasiado a un plan, sino más bien en una pila de trabajo, es recomendable tener una planeación inicial sobre la cual arrancar las labores de construcción del software. A continuación enlisto 5 claves prácticas que se pueden aplicar durante la planeación de un proyecto basado en un marco ágil:

1.-Tener una visión del proyecto

A pesar de que se puede tener la flexibilidad de ir clarificando los requerimientos del proyecto de forma evolutiva e ir adaptándose a los posibles cambios, es esencial iniciar con una visión de que se va a construir y por qué, no importa que se tenga a alto nivel, pero si es importante que todos los esfuerzos y requerimientos que se vayan identificando sobre el camino, estén apegados a dicha visión.

Tener una visión del proyecto evitara muchos dolores de cabeza y nos ayudara a no estar mezclando peras con manzanas.

Entregable resultante: un Documento de Visión o un documento que nos sirva como especificación de la visión del proyecto.

2.-Conoce a los involucrados y los resultados esperados

Es de suma importancia conocer los involucrados en el proyecto desde la perspectiva de cuáles son sus intereses y sus ámbitos de competencia, como podemos convertirlos en aliados para la ejecución del proyecto así como cuales son las vías de comunicación para trabajar con ellos. Es relevante también, determinar qué expectativas tienen del producto a construir; así como el rol que juegan dentro de la organización.

Teniendo definido los involucrados del proyecto y sus características, solo queda como punto final tener claro quien jugara el rol de promotor o Product Owner, el cual será nuestro enlace humano con los usuarios finales, quien validara los requerimientos y priorizara los intereses de la organización en relación con el proyecto.

Entregable resultante: Un documento de registro donde se especifiquen características de los involucrados.

3.-Conoce o define el core (núcleo) de la solución

Con la especificación de la visión del proyecto tendremos elementos para identificar cual será la columna vertebral del sistema, el core o núcleo de la solución, esto es muy importante porque a partir de este punto se sientan los cimientos de la solución.

Teniendo claro cuál es el core de la aplicación, una vez construido, será más fácil ir agregando capas de funcionalidad al software, de tal forma que la mayor parte de los cambios estarán en las funcionalidades que se cuelgan del núcleo.

Por las razones ya mencionadas es relevante que se dé especial atención al tiempo de análisis y desarrollo de las funcionalidades núcleo, con el objetivo de que en las primeras iteraciones quede lo más fortalecido, recordemos que es más fácil hacer modificaciones en las paredes y en el techo que en los cimientos de un edificio.

4.-Definir un mapa de funcionalidades

Es importante definir un mapa de funcionalidades en el cual se distribuyan de manera secuencial los requerimientos identificados en las sesiones previas de análisis, si los tenemos en historias de usuario mejor, mediante la definición de una secuencia lógica, como si fuera un proceso o una cadena de valor en la cual se presentan las características como si se tratara de un flujo de actividades.

Mediante esta actividad tendremos un mapa inicial de nuestra solución, e identificar posibles dependencias entre funcionalidades o requerimientos. Como se mencionó en la clave anterior ubicar también el core o núcleo de la solución como un elemento central de nuestro mapa.

Entregable resultante: Mapa de módulos de la solución, flujograma de proceso o un Story Mapping (Mapa de Historias).

5.-Definir tiempos tentativos para construcción y raleases (Lanzamientos)

Con el mapa de funcionalidades resultante, se puede iniciar con la definición de posibles iteraciones en las cuales se pueden estar construyendo los requerimientos; así mismo determinar en cual número de sprints podrían estar listos los releases para que los usuarios finales puedan usar la solución.

Entregable resultante: Product Backlog clasificado con los requerimientos clasificados por sprint y a su vez estos clasificados por release.

Es recomendable que durante la planeación se involucre a todo el equipo de trabajo, para dar diferentes puntos de vista y ayudar en la identificación de riesgos iniciales (tanto administrativos como técnicos) que muy difícilmente el Líder de proyecto podría visualizar solo.

Una historia dice más que mil palabras (Cont. 1)

Gestión de requerimientos y compromisos.-Haciendo mejores requerimientos mediante historias de usuario.

Como se ha podido ver en la entrada anterior, las historias de usuario pueden ser una técnica muy práctica al momento de identificar y concretar requisitos, tratando siempre de especificar detalles muy claros de lo que necesita y como lo requiere el usuario aplicado en el software.

Para determinar si estamos haciendo buenas historias de usuario que nos ayuden a tener información obtenida realmente útil para la construcción de las funcionalidades en el sistema, es importante recordar que las historias de usuario nos sirven para a iniciar una conversación centrada en requisitos muy particulares y las características de los mismos; así mismo permiten facilitar el camino de la exploración de requisitos, ayudando a que el usuario especifique los que requiere y como lo quiere (Criterios de Aceptación), pero solo el uso frecuente de esta técnica nos permitirá ir puliendo la forma de llevar una conversación más provechosa en la obtención de mejores requerimientos.

Para evaluar de forma inicial si nuestra historia de usuario es hasta cierto modo factible o correcta, es importante conocer sus características desde la visión del modelo INVEST: Independet, Negotiable, Valuable, Estimable, Small y Testable (En Inglés), que  transformado al español quedaría de la siguiente manera:

*Independiente: La historia de usuario no debe ser dependiente de otra, aunque para esta característica podemos hacer ciertas excepciones.

*Negociable: Puede ser negociable en el caso de que puede ser ejecutada durante una iteración; así como ser reemplazada por otra del mismo tamaño para su construcción.

*Valiosa: Debe generar valor al proyecto, negocio o los usuarios finales.

*Estimable: Puede ser estimada en tiempo y esfuerzo, dejando el mínimo de incertidumbre al programador para su construcción.

*Pequeña (Small): Debe ser lo más pequeña que se pueda, para poder cumplir con la característica anteriormente señalada.

*Testeable: Debe tener las características de presentación o comportamiento para ser testeada o en consecuencia que tenga criterios que determine que está terminada.

Ahora bien para detallar de forma un poco más completa la manera de mejorar nuestras historias de usuario, veamos como las características basadas en el modelo INVEST nos permiten ir filtrando los buenos requisitos de los ambiguos. Las características fueron ordenadas mediante una secuencia lógica de construcción y agregación de valor a la historia de usuario:

1.-Valiosa: La historia de usuario tiene que ser de utilidad y para saber esto recordemos que en la misma estructura de la historia, se especifica el “para que” es requerida. Mediante este sencillo prefijo conoceremos si genera valor para el usuario o está fuera del alcance.

2.-Pequeña: La historia de usuario debe ser lo más compacta posible, al referirnos a esto debemos buscar que siempre auto contenga solo una funcionalidad o satisfaga una sola necesidad a la vez; por ejemplo: Como responsable de ventas quiero realizar la consulta del índice de ventas semanal por región comercial para conocer cual tiene el mayor y menor índice de ventas, como se observa la especificación es muy concreta en lo que se requiere hacer y por lo tanto pequeña. No se entra en ambigüedades de alguna funcionalidad adicional.

3.-Independiente: Debemos procurar que nuestras historias sean independientes unas de otras de tal forma que puedan ser construidas sin impactar en labores de construcción de otra. Como vimos en la característica anterior, entre más auto contenidas sean las funcionalidades más independencia le daremos a la historia de usuario, pero en ocasiones para esta característica es conveniente hacer ciertas excepciones, puesto que en algún momento tendremos historias de usuario que inevitablemente tendrán relación con otra (dependencia), ejemplo:

·     Historia de usuario inicial: Como responsable de ventas quiero realizar la consulta del índice de ventas semanal por región comercial para conocer cual tiene el mayor y menor índice de ventas.

·         Historia de usuario dependiente: Como responsable de ventas quiero enviar comentarios o sugerencias vía correo electrónico a la región comercial con el menor índice de ventas.

4.-Estimable: Al tener en nuestra historia de usuario las características de ser pequeña e independiente, es más fácil dar al equipo de trabajo, y en un caso muy especial al programador, los elementos necesarios para que pueda determinar el esfuerzo (días de trabajo) que tiene que hacer para la construcción de ese requerimiento.

Para lograr una estimación más certera es conveniente que se divida la historia de usuario en tareas técnicas, las cuales nos especifican que se tiene que hacer para construir la funcionalidad, ejemplo: adecuación a una tabla en base de datos, codificación de una vista o procedimiento almacenado, configuración de un archivo o clase, diseño de formularios, etc.

5.-Negociable: Cuando una historia de usuario tiene una estimación razonable del esfuerzo requerido para su construcción, es más fácil tener argumentos para poder negociar ante los usuarios o el product owner (promotor del proyecto), para aquellos casos cuando se quiera cambiar el enfoque del requerimiento o se pretenda sustituir por otro durante una iteración que ya se tiene en ejecución.

6.-Testeable: La historia de usuario debe tener una serie de especificaciones que permitan determinar cómo debe ser testeada, tanto en su funcionalidad como en completitud, esto se logra mediante la especificación de criterios de aceptación, concepto el cual mencionamos en la entrada anterior. Al ser una funcionalidad auto contenida debe dar cierta facilidad ejecutar las pruebas, basado tanto en lo visual como en lo funcional.

Como podemos observar profundizar y armar las características de la historia de usuario bajo la secuencia de pasos anterior, del modelo INVEST, nos permite tener una guía para comprender que puntos debemos considerar al momento de obtener y armar mejores requerimientos basados en esta técnica.

Una historia dice más que mil palabras

Potenciando el desarrollo de software mediante el uso de historias de usuario.

Las historias de usuario son una técnica para representar una necesidad o requisito por parte de un usuario, y si es utilizado de manera ingeniosa puede servir también, para que el levantamiento de requerimientos sea de mayor provecho al arrojar detalles que durante una entrevista no tan fácil lograría satisfacer.

Antes de entrar en materia sobre sus posibles usos es conveniente conocer un poco más sobre las historias de usuario. Las historias de usuario como tal deben ser pequeñas y prácticas de tal manera que cuentan, de manera muy corta, una necesidad y su valor que aportan al negocio. Una historia de usuario debe permitirnos ser escrita en una pequeña tarjeta, nota o post-it de tal forma que evita la tediosa actividad de escribir una gran especificación de requisitos.

La sintaxis para escribir una historia de usuario puede ser la siguiente:

As a (User Role) Iwant to (Do this) so that (Achive that), que en español sería: Como (Rol de Usuario) Quiero (Hacer esto) Para (Alcanzar o lograr esto).

En términos más prácticos si nuestro proyecto estuviera orientado en el desarrollo de un sitio web para la venta de productos electrónicos, en lugar de hacer especificaciones completas como casos de uso tendríamos los siguientes ejemplos de historias de usuario.

1.-Busqueda por Nombre

Como Cliente quiero poder hacer una búsqueda de artículos por nombre para encontrar más rápidamente el producto que deseo comprar.

2.-Selección de varios artículos para agregarlos  al carrito de compra

Como Cliente quiero realizar una selección de diferentes artículos para agregarlos a mi carrito de compra.

3.-Realizar pago en línea de la compra

Como Cliente quiero realizar el pago en línea de mis artículos para concluir con mi compra.

Como nos damos cuenta, la forma de redactar una historia de usuario es completamente sencilla y especifica una necesidad usando el lenguaje de los usuarios, evitando la necesidad de especificar a gran detalle elementos de software.

Ahora para aquellos quienes tienen experiencia realizando análisis de sistemas mediante Casos de Uso o especificaciones de requerimientos, se preguntaran —¿Bueno y con esto puedo empezar a construir algo? —, la respuesta es que no del todo, con la especificación de la historia de usuario acotamos el alcance de una necesidad. El detalle lo especificamos con los llamados “Criterios de Aceptación”.

Los Criterios de Aceptación no son otra cosa que aquellas especificaciones mediante las cuales podemos determinar que un requerimiento está completamente terminado, aporta detalles para la programación del mismo, define las fronteras de lo que se va a construir y también ayuda a los testers a verificar que puntos de la implementación tiene que probar.

Tomemos uno de los ejemplos anteriores:

1.-Busqueda por Nombre

Como Cliente quiero poder hacer una búsqueda de artículos por nombre para encontrar más rápidamente el producto que deseo comprar.

Y sus criterios de aceptación podrían quedar de la siguiente manera:

•     Verificar que el texto introducido se pueda encontrar en cualquier parte del nombre del producto a buscar.
•       Verificar que la lista de artículos encontrados los ordene de menor al de mayor precio.
•          Verificar que los artículos presentados, por artículo, tengan los siguientes datos:

o   Imagen del artículo

o   Nombre Completo

o   Descripción

o   Precio

Como podemos observar los criterios de aceptación dan un poco más de luz al programador para que conozca exactamente que tiene que construir y también ayudan tanto a los usuarios, como al equipo de trabajo a delimitar el esfuerzo y complejidad del requerimiento.

Como se mencionó anteriormente la historia de usuario puede ser escrita en una pequeña tarjeta, nota o post-it, de acuerdo al tamaño de nuestra historia y sus criterios de aceptación, decidiremos el material que usaremos:

1.-Uso de post-it

2.-Uso de tarjetas

También para dar mayor soporte a las historias de usuario se puede reforzar con información adicional que los usuarios nos proporcionen para darle solides al requerimiento, como se muestra en el siguiente ejemplo:

Todo aquello de vaya relacionado con el requerimiento como prototipos en papel, información en archivos de Excel, reglas, cálculos, etc. puede ser entregado al programador como un paquete del requerimiento para su construcción.

Es conveniente que las historias de usuario sean escritas durante las entrevistas con los usuarios o durante un taller para la obtención de requerimientos e involucrar a los mismos sobre la importancia y el porqué de esta técnica, para apoyar en la mejor comprensión de la problemática ya que nos enfoca en conocer que parte del sistema aporta el mayor valor al negocio.

Por qué RUP también puede ágil…

Agilidad es una de las tendencias en boga durante los últimos años dentro de los entornos de desarrollo de software como una  propuesta innovadora ante el eterno problema para generar valor a los usuarios, poder hacer ajustes ante ambientes cambiantes y controlar riesgos en los proyectos; muchos son los equipos que se han visto beneficiados ante el hecho de aplicar practicas agiles creando división entre las corrientes tradicionales y los agilistas, para lo cual marcos de trabajo como RUP han sido duramente atacados por promover procesos excesivamente pesados y burocráticos que se convierten más en obstáculos que medios para mejorar el trabajo.

Haciendo reflexión sobre las características de SCRUM así como las de RUP lleguo a la conclusión de que el problema no se encuentra en los métodos si no en las personas, desde el momento en que nos casamos con llevar un conjunto de buenas prácticas como técnicas que se tienen que llevar al pie de la letra y no como lo que son, “buenas prácticas”, nos convertimos en esclavos de las recomendaciones que alguien más definió o estableció y no como técnicas que pueden ser usadas en un contexto o en otro.

RUP se encuentra fundamentado en 6 principios clave los cuales son:

• Adapt the process
• Balance stakeholders priorities
• Collaborate across teams
• Demonstrate value iteratively
• Elevate the level of abstraction
• Focus continuously on quality

Si verificamos el primer principio: “Adapt the process – Adaptar el proceso”, se puede entender cómo adaptar el proceso al contexto del proyecto,  adaptarlo a las necesidades del cliente, ajustarlo a la naturaleza de los requerimientos y del negocio e identificar que sí puede ser aplicado y que no, tanto en roles, artefactos, herramientas así como en “buenas practicas, en resumen si el proyecto tiene un cierto nivel de incertidumbre y los requerimientos pueden ser cambiantes, ajustar RUP para que pueda ser ágil y efectivo ante este entorno podría ser adecuado, sin romper con la esencia del método.

Balance stakeholders priorities (Balancear las competencias entre los involucrados) y Collaborate across teams (Colaboración entre equipos), que se pueden interpretar o ligar al manifiesto ágil cuando se refiere a “Individuos e interacciones, por encima de los procesos y las herramientas” así como “Colaboración con el cliente por encima de negociación contractual”, balancear las necesidades, colaborar, comunicar, crear sinergias entre los individuos, etcétera; todo aquello que permita tener un adecuado flujo de interacción y comunicación dentro del proyecto.

Demonstrate value iteratively (Demostrar valor iterativamente), que al confrontarlo nuevamente con el manifiesto ágil encontramos  “Software que funciona, por encima de la documentación exhaustiva” entendiendo que valor al cliente en la filosofía ágil es el software funcional o productivo; así que en ambos lados de la moneda para los usuarios finales todo aquello que genere valor debe ser entregado al final de cada iteración o al final de cada sprint: software funcional, software funcional + documentación, documentación para cumplimiento contractual, etc.

En los 12 principios agiles tenemos el onceavo principio especificando lo siguiente: “La simplicidad como arte de maximizar la cantidad de trabajo que se hace, es esencial” y al contraponerlo con el quinto principio de RUP Elevate level of abstraction (Elevar el nivel de abstracción) se puede entender a este principio como enfocarse en lo esencial, lo más básico, lo más simple del problema, el proyecto o de los requerimientos; lo más mínimo funcional que satisfaga las necesidades de los usuarios finales; los detalles no prioritarios que refuercen al producto pueden venir después.

Focus continuously on quality (Enfoque continuo en la calidad) tomando en consideración que la agilidad y SCRUM proponen que el software entregado debe estar libre de errores para lo cual continuamente tendremos que estar haciendo entregas de calidad y el código debe estar en constante mantenimiento.

Creo fielmente que ambos marcos de trabajo tienen los mismos cimientos, pero al final el propósito de este pequeño recorrido comparativo es dar un poco de luz en donde considero convergen, se unen o fracasan las “buenas practicas” y es en el momento de querer implementarlas como un paso a paso y no como procesos adaptativos y ajustables en el momento de omitir los valores y principios que dan origen a una técnica u otra.  Considero que RUP se convirtió en excesivamente pesado desde el momento que fue llevado a la práctica como una maquinaria cerrada más que como una caja de herramientas adaptativa que se usa según la naturaleza de los problemas.

Las 6 habilidades que todo líder de proyecto debe desarrollar

Más que conocer las buenas prácticas en gestión de proyectos así como sus técnicas y herramientas, indistintamente de que metodología se use o se pretenda poner en práctica, todo administrador de proyecto debe desarrollar ciertos “Skills” que por lo general no vienen en las guías, manuales o tutoriales:

1.-Dominar el negocio

"Siempre es importante conocer el entorno y sus reglas en el más corto tiempo posible".

Es básico que dentro del proyecto se conozca en el más corto  tiempo todas las aristas que intervienen en el mismo (desde el marco teórico) pasando por las reglas de negocio, políticas y restricciones así como los actores y sus perfiles tanto personales como profesionales.

No se requiere forzosamente que convertirse en un experto del área, pero si es conveniente que asimilar en el más corto tiempo posible la mayor cantidad de detalles que permitan tomar decisiones más certeras identificando factores de éxito, restricciones, posibles riesgos y amenazas.

Un líder de proyecto que hable el mismo lenguaje de los usuarios y clientes inspira empatía y confianza anotándose puntos valiosos para que cuando sea necesario resolver conflictos o proponer mejoras.

2.-Se practico

"Se debe ser práctico en la toma de decisiones y resolución de conflictos".

Ser practico en la gestión de proyectos significa aprovechar de la mejor manera lo se tiene a la mano, incluso una circunstancia negativa puede ser un recurso valioso. Dentro del ciclo de vida del proyecto, en más de una ocasión; y para no evitar sobresaltos en etapas finales; es conveniente que las decisiones estén encaminadas en obtener los resultados más óptimos y rápidos para satisfacer las necesidades de los clientes.

Los recursos son limitados: tiempo, dinero, mano de obra, incluso el conocimiento; durante la ejecución es efectivo procurar que cada decisión tomada cumpla o satisfaga con el alcance del proyecto.

Es mortal usar recursos en prácticas que no generen mucho valor al alcance del proyecto como realizar reuniones con tiempos excesivos y para temas vánales, recursos destinados a cubrir requerimientos de poco valor o destinar presupuesto en actividades fuera del enfoque principal, etc. son solo algunos ejemplos.

3.-Visión, adelantarse a los hechos

"Anticípate a los golpes que te van a dar como a los que no has recibido".

Cualquier actividad desempeñada en el equipo como solicitudes de cambio o variantes en la temperatura del proyecto debe ser efectivamente detectada y analizada en frio, incluso antes de que se den los resultados ya ayuda a identificar por donde vendrán los golpes. Como administrador del proyecto encontraremos que esa intuición, conocimiento previo o sexto sentido, sobre lo que pudiese ocurrir, nos evitara de muchos dolores de cabeza y/o conflictos con los clientes o usuarios.

Debemos comprender que las circunstancias pueden tomar diversos flujos alternos y que en cada flujo puede generarse un impacto positivo o negativo para lo cual es razonable tener un plan B para cualquier acción preventiva así como correctiva y tomar la mejor decisión posible que se tenga a la mano.

4.-La Comunicación como un recurso estratégico

Para cumplir con los objetivos del proyecto es básico que se tenga un adecuado canal de comunicación con el cliente y los miembros del equipo. Uno de los recursos más valiosos y un aliado muy efectivo será la habilidad de comunicarse tanto como sea posible con el cliente, usuarios o el equipo de trabajo, sobre acuerdos, cambios solicitados, entregas o comunicados de interés para todos los involucrados.

5.-Promover y desarrollar la habilidad social

"Crear aliados estratégicos en todas las áreas del proyecto".

Al cliente no solo le interesan los resultados si no también que el ciclo de vida del proyecto sea lo más ameno posible y sin sobresaltos. Somos animales con habilidades sociales para lo cual podemos utilizarlas tanto para obtener la mayor cantidad de información posible como para la resolución de conflictos y/o diferencias.

Fomentar un ambiente ameno en la forma de trabajo en el cual se demuestre cierta flexibilidad y efectividad que permita al líder de proyecto y el equipo derribar barreras de comunicación o diferencias interpersonales; así como sortear obstáculos cuando se trate de trabajar en entornos socialmente complejos o con clientes muy difíciles.

Es fundamental tomar en consideración el hecho de no confundir amistad con el trabajo, lo principal siempre será entregar resultados en el más corto tiempo posible y en forma.

6.-Desarrollar la habilidad de decir “No”, pero con sutileza.

“El fracaso de la política consiste en tratar de quedar bien siempre con todos.”

François Mitterrand.

Aunque estemos en la posición de que somos un  producto que brinda un servicio para satisfacer una necesidad, no significa que todo lo que se solicite o se crea posible, es posible en el proyecto. Siempre, siempre se debe tratar de que nuestro cliente o usuarios tengan presente el alcance y objetivo del proyecto. Es común que conforme el equipo avanza y entrega resultados los involucrados solicitan mejoras emergentes las cuales pueden ser alcanzables, pueden ser requerimientos no identificados inicialmente o solicitudes que le dan valor al proyecto pero que no son un factor de éxito.

Es conveniente no movernos demasiado a los caprichos del cliente, aquí es conveniente mucha habilidad de negociación para que de manera muy sutil, en algunos casos, se les dé un sí, pero en otros casos se les dé un “No” y se justifique el porqué de forma razonable.

Toda solicitud nueva tiene que evaluarse desde la perspectiva de que estamos bajo cinco ejes de restricción: tiempo, alcance, presupuesto, recursos humanos y calidad. Involucrar al promotor del proyecto o al rol que aprueba los nuevos requerimientos o solicitudes de cambio es muy positivo y hacer de su conocimiento que todo evento en el proyecto tiene un impacto tanto para bien como para mal.

Al final de proyecto si algo sale bien o sale mal una gran parte, si no la mayoría, será responsabilidad del administrador del proyecto. La manera de negociar de forma transparente y con honestidad la ejecución de cambios drásticos de alcance, así como también hacer responsables a los clientes de sus peticiones necesidades, será de gran utilidad para no desviar el alcance del producto final.

Las habilidades anteriormente mencionadas seguramente no son las únicas, seguramente en el andar gestionando proyectos se podrán descubrir muchas más que se considere serán de utilidad para ser usadas como parte de la caja de herramientas en el día  a día.