Desarrollo de software. Las expectativas importan

Gestionar las expectativas es fundamental en nuestra profesión y es algo que no solemos hacer bien y que es causa de pérdidas de confianza, desgaste y de minusvaloración del trabajo realizado (nosotros mismos lo hacemos pequeño cuando intentamos “vender” algo más grande de lo que realmente es).

¿Por qué fallamos en esto? Los motivos pueden ser muy diferentes: no terminamos de ver (o no queremos ver) el problema y por lo tanto no lo transmitimos o lo hacemos demasiado tarde, tenemos miedo de la reacción de la otra parte o simplemente no le damos importancia a las expectativas que pueda tener el usuario (algo muy peligroso porque un proyecto surge de unas necesidades y de la expectativa de darles una solución).

No es sencillo transmitir al área usuaria que no se va a poder cumplir lo que se tenía pensado inicialmente y lo que hasta este momento parecía que se iba a poder conseguir, ¿por qué no es sencillo? pues porque se pedirán explicaciones (y es natural que así sea porque le estamos cambiando la imagen mental que tenían del proyecto) y las mismas no siempre se van a entender, seas sincero o no (mejor sincero).

¿Qué hacer? Lo importante es explicar qué ha llevado a esta modificación en las expectativas y qué ventajas supone hacer un ajuste a las mismas, ¿ventajas? perseguir quimeras en el proyecto no solo supone engañarnos a nosotros mismos sino que además supone inflingirnos un castigo en forma de esfuerzo desbocado que se traducirá probablemente en unos resultados deficientes.

Esto no es un alegato al incumplimiento de las planificaciones sino de intentar exponer mi punto de vista sobre una realidad: es muy complicado acertar en los plazos y presupuestos del proyecto para el alcance que se defina, es posible que ese alcance cambie o que funcionalidades que se esperan más simples sean más complejas y, además, a lo largo del proyecto pueden ocurrir infinidad de circunstancias que impidan un desarrollo lineal del mismo.

Teniendo en cuenta esa realidad gestionar las expectativas de manera adecuada resulta fundamental para alcanzar los objetivos marcados en el proyecto. ¿Cómo cumplir objetivos si se ajustan las expectativas? Generalmente las expectativas incluyen funcionalidades no imprescindibles o con mayor complejidad de la necesaria, ahí es donde podemos trabajar para seguir manteniendo el pulso al cumplimiento de objetivos.

A veces el ajuste no será suficiente y se requiere un mayor aporte presupuestario y/o un mayor plazo para la ejecución del proyecto. ¿Qué pasa cuándo no se puede o cuándo no se llega a un acuerdo? Problemas para todos (cliente y proveedor), mi recomendación es que lo mejor es intentar llegar a un acuerdo satisfactorio y eso pasará también porque las partes asuman su responsabilidad en que se haya llegado a esa situación (que no necesariamente tiene que deberse a un mal desempeño en el proyecto sino que puede darse el caso de que el problema partiera con la estimación inicial de presupuesto (principalmente) y plazos).

Peter Drucker. La importancia de conocer los 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”.

La efectividad en la transmisión de la información y el conocimiento

El desarrollador, el responsable funcional, en general, cualquier figura que interviene en un proyecto necesita de información (o conocimiento si ya se encuentra procesada) para poder realizar sus tareas y tomar decisiones.

Esa información se necesita para un determinado momento, ya que a partir de él la tarea se paraliza o se tiene que realizar con información incompleta, lo cual presenta el riesgo de hacer algo que no se ajusta a las expectativas del usuario o a lo que las circunstancias requieren.

Por ese motivo es fundamental solicitar la información con suficiente antelación para ser recepcionada en el momento y formato en el que se necesita.

Y es en el formato precisamente donde nos encontramos con uno de los principales problemas. Si la comunicación se orienta prácticamente y de manera exclusiva a documentos, los cuales, además, deben seguir unas reglas formales poco flexibles, se tendrá que solicitar la información con mucho tiempo de margen y eso no va a ser siempre posible, produciéndose los problemas mencionados anteriormente, teniendo en cuenta además que por muy bien que se documente, habrá detalles que se escapen.

Se puede entender que una organización tenga sus procesos (aún siendo discutibles y mejorables), pero los mismos deben evolucionar si suponen un freno a los proyectos y un coste adicional que no se traduce en una mejora de la calidad general de los desarrollos y de los mecanismos de control que se quieran establecer.

La economía de la intención

El desarrollo de software debe buscar la satisfacción de las expectativas del cliente. De lo que nos aproximemos a ese hito, será lo cerca o lejos que estaremos del cumplimiento de los objetivos.

Hablo de objetivos relacionados con la calidad del producto. La calidad técnica, es importante, muy importante, pero para el usuario está en un segundo plano, respecto a si el producto hace lo que espera y le permite trabajar de manera productiva.

Por ese motivo se dice que la calidad tiene dos puntos de vista, el del usuario y el del desarrollador. Es cierto que existe esa dualidad pero también que no se debe entender la una sin la otra.

Un producto software siempre es susceptible de ser evolucionado. Habrá un motivo para ello y el resultado debería ser un incremento del valor del mismo siendo proporcional al esfuerzo (coste) invertido para conseguirlo. De aquí surge otro objetivo: conseguir el mayor valor posible invirtiendo el menor esfuerzo posible.

Si conseguimos ganar valor, ahorrando esfuerzos, tendremos la posibilidad de seguir evolucionando el producto para así conseguir generar más valor. Es algo que debemos tener siempre presente, pero que no debe llegar a obsesionarnos porque llegado a un punto puede dar lugar a situaciones en las que se ponga muchos reparos a especular en el desarrollo, algo que a veces es inevitable porque el usuario no siempre tiene claro lo que quiere y necesita ver ejecutada su especificación para valorar si su idea es buena o si por el contrario necesita ajustes.

Tener presente ese rendimiento de la inversión obliga a tener en cuenta la calidad técnica en los desarrollos (y por ahí es donde se puede y se debe trabajar este asunto con el cliente), rematar las tareas, cumplir los compromisos, reducir la tasa de errores y desarrollar con intención.

Con la intención se pretende minimizar el número de iteraciones. Es cierto que intención y especulación son dos términos que no se llevan bien, pero no son incompatibles, de hecho no se utilizaría el término intención si se tuviera la certeza de que todas las decisiones que se toman son correctas. Se trata, por tanto, de trabajar con el usuario, para incrementar la probabilidad de éxito: historias de usuario con prototipado de pantallas tomando como referencia versiones ya liberadas del producto, de las funcionalidades más prioritarias seleccionar aquellas que se tenga más clara su operativa de uso, etc…

Desarrollo de software. Terminar lo que se empieza o descartarlo

Una circunstancia que afecta a la productividad y rendimiento del proceso de desarrollo son esas tareas que se quedan a medias, a casi terminar o que una vez finalizadas se quedan en un cajón esperando el momento adecuado para implantarlas.

No siempre que se dejan las cosas así, se terminan tirando a la basura o se implantan dedicando un importante esfuerzo adicional (con respecto al esfuerzo que se hubiera empleado si se hubiera realizado justo en el momento en que se necesita), pero lo normal es que pase eso.

Tenemos por tanto tres costes evitables: el que se ha empleado para realizar tareas que se terminan descartando, el que se requiere para adaptar a la solución la tarea que, en su momento, se quedó a medias (con el coste adicional de ponernos al día en la misma, que será mayor si la ha realizado otro y/o si la calidad del código no es buena) y el coste de mantener y tirar hacia adelante con esas tareas mientras no se descarten.

¿Es un asunto de extremos?, es decir, en el momento en que tengamos dudas de que algo no va a servir, ¿se debe descartar?, dar una respuesta categórica a eso es complejo, como siempre recomiendo hay que analizar la situación y en función de los tres costes indicados en el párrafo anterior, tomar una decisión, teniendo en cuenta que nuestro objetivo es que la mayor parte del esfuerzo dedicado en el proceso de desarrollo sea productivo.

Peter Drucker. Lo que no se dice

Me parece muy sabia la siguiente reflexión de Peter Drucker: “El aspecto más importante de la comunicación es escuchar lo que no se dice”. Y no se refiere a lenguaje no verbal, sino a interpretar realmente lo que nos están comentando porque no debemos olvidar que somos personas, estamos llenos de emociones, también de miedos y no siempre trasladamos la realidad de una situación o de un problema a palabras bien porque no queremos, no sabemos o no podemos.

El objetivo de las relaciones entre las personas en un ámbito profesional y colaborativo debe ser la transparencia, pero no deja de ser un fin, no digo una quimera, pero sí algo que es más complicado de lo que parece porque hay que ser muy valiente para no guardarte nada y exponerlo todo. Además de valentía se requiere confiar en la otra parte y la confianza cuesta mucho construirla y consolidarla.

Pero hay que intentarlo. En un contexto como el del desarrollo de software en el que la comunicación y la interacción entre las personas es esencial, es la base para establecer una relación de confianza entre todas las partes, algo que resulta fundamental para que el proyecto se desarrolle sobre un contexto propicia (independientemente de que después las cosas salgan mejor o peor).

Poco a poco, mientras tanto tocará interpretar lo que se dice pero también lo que no.

Desarrollo de software. Mejor en lo que sabes

Si estamos tratando de desarrollar un producto y la incorporación de una nueva tecnología no aporta ninguna ventaja competitiva o el acceso a un segmento de mercado nuevo, es mucho más productivo desarrollar en lo que ya sabes, reutilizando todo lo que sea posible (siempre que sea adecuado al proyecto).

No se trata de no evolucionar en tus conocimientos, sino de ser efectivo. Si quieres aprender o probar cosas nuevas, ya tendrás tiempo para hacerlo, pero en proyectos reales con dinero de por medio, todo lo que sea aplicar soluciones con intención termina ahorrando costes: tienes controlados la mayoría de los problemas relacionados con la tecnología, sabes cuál es tu ritmo de desarrollo, tienes más facilidad para encontrar la solución más simple, etc…

Cuando no controlas la tecnología es como si estuvieras caminando en un campo de minas, encontrándote, cada día o cada semana con nuevos problemas que afectan al desarrollo normal del proyecto y al cumplimiento de los compromisos que se vayan fijando. Esas contingencias suponen un esfuerzo desaprovechado que llegado a un punto ya no se puede recuperar por muy efectivo y productivo que se sea, salvo que se resienta el producto, tu propio tiempo (overtime) o la cuenta de resultados.

Infrautilización de las personas

El desarrollo de software requiere un importante esfuerzo intelectual por parte de las personas que participan en él. La efectividad depende de que el talento y experiencia de cada persona esté enfocada en el trabajo, tarea o proyecto que mejor se adapte a esa capacidad y que, además, le motive.

Dado que no se trabaja solo, resulta muy importante que las personas que conforman los equipos encajen.

Obtener el máximo rendimiento de las personas no es tarea fácil, ya que son muchos los factores que pueden influir en el mismo, para empezar sus propias circunstancias.

Sabiendo que no es sencillo y que es utópico pensar que el 100% del tiempo se va a tener un rendimiento óptimo de las personas y de los equipos, sí que existen una serie de aspectos a tener en cuenta, porque el hecho de que sea difícil no significa que no se intente, es más, es necesario dedicar el esfuerzo necesario para intentar aproximarnos lo máximo posible a ese límite:

- Fomenta la autogestión de las equipos. Los que viven el día a día del proyecto saben mejor que nadie cómo deben organizarse, quién se organiza tiende a ser más responsable con el resultado de su trabajo. Eso no quiere decir que los desatiendas, ya que muchas veces desde fuera se ven cosas que no se ven desde dentro y porque hay información ya sea del cliente o de la propia organización que llega a través de ti. Por otro lado, si respetas el espacio de tu equipo, ellos respetarán el tuyo y las retrospectivas sobre el trabajo que se está realizando serán más provechosas.

- Intenta minimizar los cambios de contexto. El fraccionamiento de las personas en múltiples proyectos es ineficiente para las personas y para los proyectos. Hay determinados tipos de perfiles donde no queda más remedio, en ese caso, trata de ajustar la capacidad de trabajo que puede absorber a su límite real.

- Trata de evitar los parones en los proyectos. Esto es algo que no dependerá de ti en la mayoría de los casos, pero sí que puedes intervenir para tratar de prevenirlo. Esto requerirá una atención tanto al proyecto como a la información que te haga llegar tu equipo.

- Las personas no son robots, ni sus aptitudes son las más adecuadas para todos los contextos, por tanto, no les trates como máquinas, conoce sus puntos fuertes y sus puntos débiles, dedica tiempo a saber qué le motiva y con qué grupo de personas puede encajar mejor. Si existen diferentes alternativas, pregúntale cuál se le apetece más, a cuál cree que puede aportar más y por qué. No es lo mismo que tu empujes a una persona a dar un paso a que sea ella misma quién lo decida, ya que el nivel de implicación no será el mismo.

La organización debe tratar de no ser rígida en la promoción profesional, centrándose exclusivamente en promociones verticales y en un itinerario establecido. Las personas son diferentes, plantea diferentes itinerarios.

- Buscar el rendimiento óptimo de las personas basado en mecanismos de recompensa, no suele proporcionar buenos resultados a la larga porque en el momento en el que por el motivo que sea esas recompensan menguan o desaparecen, la motivación se irá con ellas.

Es importante premiar a quién lo hace bien y eliminar de la organización la idea del “nunca pasa nada” aunque se falle estrepitosamente en una serie de proyectos, pero orientarlo más que a un hecho concreto a una trayectoria (lo cual no quita que puedan existir logros excepcionales con recompensas también excepcionales), esto implica la existencia de una carrera profesional, en donde buenos resultados se terminen consolidando en tus ingresos.

- Adapta la cantidad de trabajo que puede asumir un equipo a su capacidad real, lo contrario da lugar a situaciones de bloqueo y de pérdida de calidad que influyen directamente en los resultados. Es posible que el overtime consiga solventar estas dificultades durante un tiempo, pero poco después, la cantidad de trabajo real que se pueda sacar será menor que con el horario normal (fruto del cansancio y de modular tus fuerzas a la jornada laboral), a lo que habrá que sumar el sobrecoste de una mayor deuda técnica y tasa de fallos.

- Siempre hay trabajo que hacer, si hay una persona o un grupo de personas desocupadas y te interesa mantenerlas en la organización, crea un proyecto o proyectos internos, haz que actúen de soporte en proyectos que estén en marcha (siempre y cuando su entrada no rompa el ritmo de trabajo) y/o realicen tareas de testing, utilízalos de apoyo para tareas comerciales, etc…

En estas circunstancias, además, se puede saber si una persona está motivada o no por seguir en la organización, ya que quien quiere trabajar, se inventará el trabajo y si le preguntas te expondrá muy probablemente diferentes alternativas en las que poder ayudar.

Lo peor que se puede hacer es dejar a estas personas sin hacer nada porque muy probablemente afectarán directa o indirectamente a las personas que sí están implicadas en proyectos.

Desarrollo de software. La sobreproducción

La sobreproducción se entiende como la realización de trabajo de más que no resulta necesario en estos momentos. Tiene las siguientes implicaciones:

- Esfuerzo realizado que tal vez no sirva para nada, ya que una vez que el cliente evalúe lo que realmente necesita puede modificar total o parcialmente todo el conjunto de funcionalidades de más que se han realizado.

- División de la atención entre lo realmente importante y lo que no lo es. Ese esfuerzo que se dedica a lo que no es prioritario puede afectar a la calidad, al grado de terminación y a la tasa de errores de lo que sí lo es.

- El usuario, cuando se le presenta la solución en su conjunto (en su versión actual), también pierde el enfoque pudiéndose perderse en detalles que están lejos del objetivo principal de la versión.

- Incremento de la complejidad del sistema tanto a nivel técnico (deuda técnica) como de la usabilidad.

Trabajo de más es resistencia de más para poder adaptarnos al cambio, ya que nos resta flexibilidad. A lo anterior hay que sumarle el coste que se ha invertido en desarrollar funcionalidades que lo mismo nunca se llegan a utilizar o deben ser sensiblemente reajustadas, por lo que disminuye la proporción entre valor y esfuerzo.

Pull u orientación a la demanda

¿Qué se necesita?, ¿esto?, es lo que desarrollamos. Cualquier elemento de más es sobreproducción y corremos diferentes riesgos: que no podamos recuperar su inversión, que nos genere costes adicionales: en el caso de la producción de elementos físicos tenemos un ejemplo en los costes de almacenamiento y en el de los elementos lógicos lo tenemos en una mayor deuda técnica, complejidad funcional, etc… (además de haber desviado la atención de otras funcionalidades o tareas más prioritarias).

El concepto es sencillo, ¿lo es su implementación?. Vamos a centrarnos en el mundo de los proyectos de desarrollo de software:

- Requiere que el cliente o área usuaria estén implicados, de manera que se centren en priorizar de manera adecuada lo que necesitan, ajustándose a la capacidad de producción que tiene en cada momento el equipo de desarrollo.

- Requiere que el equipo de desarrollo respete el compromiso al que se ha llegado con el cliente, realizándose ajustes siempre por consenso entre las partes.

¿Cuáles son los riesgos?

- Que no exista una previsión sobre valles de producción, lo que puede dar lugar a que se desarrollen funcionalidades de más (algunas de ellas no prioritarias, otras no necesarias y otras que podrían cambiar por su dependencia con funcionalidades todavía no maduras), con tal de no tener a parte del equipo parado. Si se prevén, es posible hacer una gestión adecuada del equipo, de manera que se pueden dedicar a realizar actividades en otros proyectos (o incluso otras actividades en el mismo proyecto que seleccionadas sin la improvisación de tener que dar trabajo pueden ser beneficiosas: refactorización, mejoras de rendimiento, en la infraestructura de desarrollo, etc…).

- Que no exista una previsión sobre cimas de producción, lo que puede provocar que no se pueda atender a la demanda del cliente.

- Que el alcance de los trabajos sea de gran magnitud, ya que la probabilidad de que se hayan desarrollado funcionalidades que no se necesitan (o que incluso no deban aparecer en la versión del producto que se entrega) es mayor, además es muy posible que sea necesario perfeccionar muchas de ellas a través del feedback y la dependencia que puede existir entre ellas puede provocar el mantenimiento en cadena de varias de ellas.

Esto hace que una estrategia interesante sea reducir los tiempos entre versiones o lo que es lo mismo, las iteraciones no deben ser de gran duración. Esto permite, además, que los problemas que puedan producirse durante el desarrollo del sprint sean más sencillos (por regla general) de tratar.

- El cliente puede tener nuevas necesidades y la cadena de producción (sprint) está ocupada con otras tareas. Tendrá que esperar a que termine la iteración o aplicarse otras medidas en el caso de que no se pueda esperar. El hecho de no alterar los trabajos ya iniciados tiene su ventaja en el hecho de que el equipo está centrado en una serie de actividades, lo que le permite ser más productivo.

En el caso de que el desarrollo quede bloqueado, la aplicación de esta estrategia de trabajo, una vez que está interiorizada por el equipo y por la organización, hará que se centren los esfuerzos en desbaratar ese bloqueo, ya que de lo contrario no se podrá atender a nuevas demandas, ya que la capacidad de trabajo está comprometida en una serie de tareas que todavía no se han completado.