Archivo

Archivo de la etiqueta: objetivos

Una situación muy común en las organizaciones o a menor escala en los departamentos de las mismas consiste en no tener definidos cuáles son sus objetivos. Esto provoca que el funcionamiento de los mismos esté a la deriva porque realmente no saben a dónde quieren ir y aprovechan, eso que abominan, que es estar apagando continuamente fuegos para evitar tratar este asunto incómodo.

¿Incómodo? Sí, porque definir objetivos implica tener una referencia y eso puede quitar muchas caretas.

Hay una situación todavía peor que no tener objetivos y es pensar que los hay. El ejercicio es muy sencillo, pide a varias personas de tu departamento o de tu organización que pongan en orden de prioridad cuáles entienden ellos que son los objetivos… Suerte.

Me parece muy interesante la siguiente cita de Peter Drucker: “La gestión por objetivos funciona… si conoces los objetivos. El 90% de las veces, no los sabes”.

¿Por qué la necesidad de la figura de un responsable funcional, de un Product Owner o de un Product Manager? Pues porque incluso teniendo la organización unos objetivos bien definidos, en diferentes departamentos se tendrán prioridades distintas en cada momento no necesariamente incompatibles con los objetivos de la organización.

Si la situación de partida es el de una organización sin objetivos definidos (entiéndase objetivos definidos si están por escrito y son conocidos por el conjunto de la organización) resulta más complicado todavía armonizar las tareas de los diferentes departamentos.

Ken Schwaber describe perfectamente esta situación en la siguiente reflexión: “Ventas y marketing quieren respuestas rápidas a cada oportunidad que llama a la puerta. Los desarrolladores necesitan centrarse en el desarrollo del producto. El caos en una empresa es a menudo causada por la incapacidad de resolver estos conflictos”.

Tomando como base ese ejemplo, cada departamento se centra en sus objetivos: ventas y marketing quieren conseguir ventajas competitivas, desarrollo llevar a cabo de manera adecuada el producto. ¿Cuándo se produce el conflicto? Cuando son varias las personas de ventas y marketing la que llaman a la puerta de desarrollo, para cada una de las cuales lo suyo es lo más urgente y prioritario.

Por ese motivo cada producto debe tener un responsable que establezca las prioridades en la evolución del mismo (haciendo las consultas pertinentes dentro de su departamento) y si existen varias líneas de producto y la capacidad del departamento de desarrollo no puede satisfacer todas las necesidades que se plantean, se necesita un responsable que priorice las actuaciones a realizar sobre el conjunto de productos.

Cuando en una organización, departamento o equipo de trabajo no existen objetivos, existiendo no se comunican o existiendo y comunicados son papel mojado porque nadie se encarga de medirlos, de hacer que se cumplan y se ignoran, llega el caos.

En esta situación de caos, cada uno hace la guerra por su cuenta y se deja a voluntad del individuo o de equipos concretos tomar decisiones que no solo puedan ser beneficiosas para un proyecto o tarea concreta sino también para otras personas, equipos y la organización. Es cierto que esa voluntad la tienen muchas personas pero también es cierto que otras muchas solo velarán por sus intereses y no solo relacionados con su rol en la organización, sino por sus propios intereses personales.

En el caos, el esfuerzo se fragmenta en diversas direcciones, en muchos casos opuestas y eso impide el progreso de la organización en su conjunto. Se pueden conseguir victorias individuales, tal vez ganar alguna batalla pero tarde o temprano la guerra se perderá ante rivales más organizados o que incluso teniendo tus mismos problemas sean más poderosos que tu.

La suerte está ahí a veces te llega sin buscarla, otras veces nunca te llega por más que trates de alcanzarla. La suerte es un recurso que no depende de ti por lo que si realmente quieres conseguir tus metas tienes que pasar a la acción.

Y la acción requiere un esfuerzo, un sacrificio. ¿Hasta dónde estás dispuesto a llegar?.

Andy Hunt realiza la siguiente reflexión: “Decide que quieres, decide que estás dispuesto a pagar por ello. Establece tus prioridades y pasa a la acción”.

Muchas veces perdemos el ánimo cuando vemos que otros consiguen objetivos similares a los nuestros sin exponer tanto como nosotros, sin tanto sacrificio. En muchos casos nuestra percepción no es real, ya que no conocemos de manera cierta el esfuerzo que han dedicado esas otras personas. En el caso de que realmente les haya resultado más fácil será consecuencia de un contexto que en este caso ha jugado a su favor, en estas situaciones hay que entender que la vida es una sucesión de contextos en el que se suceden cimas y valles y en donde un día el viento corre a favor y otro en contra.

Todos debemos tener sueños que sean nuestros guías invisibles en el día a día. No tener sueños es conformarte con lo que tienes y rendirte realmente a la rutina.

Los sueños deben abstraerse a objetivos y estos deben enmarcarse en un marco temporal. Es una forma de acotar algo que en esencia no tiene límites pero que de no hacerlo así corremos el riesgo de que siempre se queden en eso, en sueños.

Así lo ve Andy Hunt: “Los objetivos son sueños con fechas límite”.

Alcanzar los sueños implica cumplir todos los objetivos necesarios para ello y eso requiere pasar a la acción y la misma debe sustentarse en un marco temporal aunque solo sea para controlar si efectivamente estamos más cerca o no de alcanzar los objetivos.

Al final todo se reduce a la acción, a no esperar impasibles a que otros nos pongan en bandeja lo que queremos porque probablemente eso nunca pasará.

El desarrollo de software es acción, en el día a día, en la adaptación al cambio, en las relaciones con los demás, en el tratamiento de los problemas y todo ello para alcanzar unos objetivos. Estos objetivos a veces coincidirán o no con el sueño de alguien pero lo que sí es cierto que de manera directa o indirecta afectará a los tuyos porque un factor común a muchos de nosotros es querer evolucionar como persona y como profesional.

Es fundamental saber hacia dónde se quiere ir, cuáles son los objetivos y esto es extensible tanto a las personas como a las organizaciones.

De lo contrario, al no tener referencias, se vive en un continuo cortoplacismo en el que los árboles te impedirán ver el bosque incluso en circunstancias que puedan resultar evidentes.

El cortoplacismo y la ausencia de referencias son muy peligrosos ya que en estas circunstancias te encuentras como un barco a la deriva.

Supongamos que tenemos objetivos, ¿qué tal si planificamos todas las acciones necesarias para alcanzarlo?. Pues que probablemente hayamos ganado en conocimiento de la situación por el análisis necesario para realizar la planificación y hayamos perdido tiempo ya que buena parte de lo planificado no servirá de nada una vez que el contexto previsto en el que se van a ejecutar las acciones varíe (y variará).

Comenta Ron Jeffries que (traducción libre): “Cómo podemos saber lo lejos que podemos llegar si normalmente no vamos tan lejos”.

Tiene razón y es uno de los riesgos de la planificación: plantear acciones sobre escenarios abstractos sobre los que no se tiene un conocimiento o un dominio concreto y sobre los que no se tiene un control.

Es por eso que resulta más adecuado el concepto de plan (planteo las acciones a realizar en mi contexto actual) y el concepto de evolución centrado en los objetivos (sé a dónde quiero llegar, probablemente no conozca el camino, pero si mido bien los pasos estaré más cerca de la meta).

Es absolutamente necesario en todo Departamento de Informática de una organización el conocimiento y comunicación de sus objetivos adecuados al contexto y circunstancias en las que se encuentra, de lo contrario, los distintos departamentos que la componen definirán sus propios objetivos o prioridades ajenos a una visión global del servicio que se tiene que ofrecer y dando la espalda a cualquier posibilidad de sinergia.

Y como decía sin olvidar contexto y circunstancias. Lo mismo las posibilidades actuales pasan exclusivamente por dar una buena atención orientada al puesto de trabajo de los usuarios e intentar dar supervivencia a los sistemas de información más críticos o prioritarios de la organización. Si no tenemos en cuenta donde nos encontramos probablemente no consigamos llegar a ningún sitio y enfoquemos los esfuerzos en aspectos secundarios que hagan que nos quedemos con la bolsa vacía.

Y no, no son tan obvios los objetivos de un departamento si no se definen o discuten. Los objetivos deben ser explícitos y recitados casi a modo de mantra por los que se tienen que encargar de alcanzarlos. Darlos por conocidos, sin reflejarlos en ningún sitio, sin hacer un seguimiento medianamente objetivo, es lo mismo que dejar las puertas abiertas al caos, a la definición de prioridades y objetivos singulares y a los reinos de taifas.

Es más, es posible que el que conozcas o que el que se defina en un análisis de un sistema de información no te lleve a ella. Es más, es posible que tengas que coger diferentes rutas para alcanzarla, que muchas de ellas se descubran por el camino, que incluso tengas que desandar parte de lo avanzado o que tal vez, tengas que conformarte con un objetivo más acorde al contexto en que se ha desarrollado el proyecto. Y en otras muchas ocasiones te termines quedando en el camino.

Eso es el desarrollo de software, saber a dónde se quiere ir, aceptar la incertidumbre y estar lo más preparado posible para adaptarse al cambio y que dicha adaptación requiera el menor esfuerzo posible.

En estos caminos habrá obstáculos, eso es seguro, unos serán sorteables (no sin esfuerzo), a veces nos encontraremos con otros que obligarán a abandonar parte del equipaje y no podremos llegar tan lejos como quisiéramos y en otros los obstáculos no nos permitirán llegar siquiera a un destino aceptable o nos dejarán tirados en medio del camino o de la nada.

Así es el desarrollo de software.

Otro enfoque que se puede aplicar es una variante del anterior y que podría suponer un modelo híbrido entre el modelo con presupuesto y plazos cerrados y el modelo con presupuestos y plazos abiertos (pago por iteración), para ello:

1) Se contrataría la realización del catálogo de objetivos y requisitos, pero centrándose en la obtención de aquellos que sean esenciales para obtener una versión mínima del sistema que sea operativa en producción, es decir, que sea utilizada por usuarios en circunstancias reales.

2) Se contrataría el desarrollo de esa versión y se aplicarían los criterios indicados en el artículo anterior sobre los aspectos que deben quedar fijados en el contrato.

Este desarrollo podría comprender más de una iteración.

3) Con la aplicación usándose en un contexto real el feedback cobra más relevancia. En este caso se podría abordar la contratación de incrementos del producto, ya sea mediante pago por iteración o con un enfoque más amplio, mediante un contrato de mantenimiento evolutivo que se podría articular de diferentes formas:

- Volver a aplicar la estrategia de contrato de catálogo de objetivos y requisitos + contrato de desarrollo.

- Directamente realizar la contratación del mantenimiento evolutivo y mediante órdenes de trabajo se encargarían las diferentes iteraciones a realizar sobre el producto.

La primera posibilidad que vamos a estudiar implica dejar muy claro a nivel contractual lo siguiente:

- Catálogo de objetivos y requisitos marco, debidamente priorizados por el cliente y con una valoración de esfuerzo realizada por el proveedor. Este catálogo de objetivos y requisitos, debe tener un nivel de detalle adecuado para poder ser evaluado de manera objetiva por el cliente y también para que pueda ser valorado por el proveedor.

Acertar con el nivel de detalle es importante, ya que no se pretende realizar un análisis en profundidad del sistema (de lo contrario estaríamos desarrollando en un híbrido entre la cascada y un enfoque iterativo incremental en la construcción), pero debe ser suficiente para que la valoración sea lo más acertada posible y para que no existan solapamientos entre requisitos o confusiones sobre su alcance real.

Es muy importante hacerle entender al cliente que resulta fundamental acertar con las prioridades, ya que permitirá obtener antes una versión del producto con sus aspectos más críticos ya implementados y tendrá margen de maniobra presupuestaria para poder hacer los ajustes que considere necesarios.

Lo anterior debe ser recordado al cliente durante todo el proceso de desarrollo.

Además se deberá presupuestar los costes de gestión por parte del proveedor al final de cada iteración: replanificación del proyecto en función de los cambios sobre el plan inicial o sobre el plan establecido hasta el momento, realización de un primer análisis y valoración de nuevos requisitos, revaloración de requisitos ya establecidos, etc…

Este catálogo de objetivos y requisitos, debe ser contratado aparte y antes de comenzar el proceso de desarrollo.

- Compromisos por parte del proveedor respecto a su participación en el proyecto: Esto podrá variar en función de la metodología utilizada, en algunos casos será suficiente su participación al principio de cada iteración (detallar los requisitos) y al final de la misma (evaluación de los resultados obtenidos y definición del alcance de la siguiente iteración), en otros casos requerirá que además de lo anterior, tengan participación dentro del propio equipo de desarrollo o tener un nivel de disponibilidad absoluto ante consultas o peticiones realizadas por los desarrolladores.

- Marco para el cambio del catálogo de objetivos y requisitos inicial y para la gestión de conflictos. Para reducir o evitar los conflictos es importante que quede claro y por escrito, cómo tratar las situaciones más comunes que se pueden producir en el proceso de desarrollo:

Cambio de prioridades. No tendría coste imputable al cliente.

Corrección de defectos. No tendría coste imputable al cliente.

Cambio de un requisito por otro nuevo, ampliación del alcance de un requisito ya existente y reajuste de un requisito ya implementado. Se tendría que evaluar el coste del cambio e intercambiarlo por requisitos todavía no implementados que tengan en suma un coste equivalente (sin pasarnos nunca del presupuesto restante para el proyecto).

Reducción del alcance de un requisito y eliminación de un requisito. Se generaría un “crédito” a favor del cliente que podría ser utilizado para los cambios indicados anteriormente.

Costes de gestión. Si los costes de gestión no superan el presupuesto establecido en cada iteración, pasarían a formar parte de ese “crédito” a favor del cliente. Si los superan y existe circunstancias motivadas para ello (cambios de enfoque en el proyecto, etc…) tendrá que compensarse el coste por créditos existentes o por requisitos.

Cumplimiento de plazos y de la calidad del producto. Siempre y cuando no existan circunstancias externas al proveedor, se debe garantizar por parte de éste un acuerdo de nivel de servicio que podría tener clausulas de penalización y también clausulas de excelencia.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.198 seguidores