Sobre la estimación de proyecto por horas

Este es uno de los aspectos que menos me gustan de las diferentes actividades que están dentro de mis responsabilidades.

Estimar el esfuerzo que hace falta para generar un proyecto es un arte en sí mismo, y en software, me atrevería a decir que peor aún. A continuación voy a enumerar algunas de las razones e incertidumbres por las que yo prefiero trabajar en proyectos a muy largo plazo (que van a durar posiblemente años) o productos que, en cualquier caso, tienen un ciclo de vida más largo.

En esta otra entrada, hace un tiempo comenté las ventajas e inconvenientes de trabajar en productos o proyectos, entendiendo por proyectos aquellos encargos que comienzan en una fecha, terminan en otra y se cotizan con un presupuesto cerrado.

De entre mis responsabilidades, forma parte la necesidad de estimar las horas que hacen falta para desarrollar un nuevo proyecto comenzado desde cero o bien crear un nuevo evolutivo para uno ya en producción; en más ocasiones de las que me gustaría, te encuentras en la situación de necesitar una bola de cristal para acertar lo mejor posible ya que el cliente espera que puedas fijar el trabajo que te quiere encargar a un precio fijo y tú lo único que puedes estimar es aproximadamente las horas necesarias para su realización: si aciertas, perfecto, si cotizas menos horas de las finalmente necesarias, entonces se pierde dinero en el proyecto o baja su rentabilidad, si se acaba en menos horas de las utilizadas finalmente, ésta aumenta.

Suelo comentar con mis compañeros desarrolladores que llevarán el peso del trabajo su opinión al respecto, para así tener más información que contrastar.

Sé que existen técnicas de estimación que, en cualquier caso, tratan de minimizar el peor escenario posible: que se tarde mucho más tiempo del esperado en finalizar un proyecto, incurriendo así en costes extras no cotizados para el cliente y desviaciones económicas (esto es, que se pierde dinero, vaya).

No se trata de la experiencia que tengas desarrollando proyectos o dirigiéndolos, aún conociendo muy bien la tecnología a usar o el universo del negocio relacionado con los mismos e incluso conociendo con detalle las capacidades de los desarrolladores que estarán más implicados en el trabajo.

Inevitablemente, siempre hay ciertas incertidumbres que escapan a tu control y aspectos contra los que poco puedes hacer: el cliente no tiene claro ciertas funcionalidades de lo que necesita desarrollar (los va definiendo a medida que comienza a ver algo en marcha, algo también comprensible), el cliente no quiere esforzarse demasiado en consensuar un documento de especificación (y tú, puesto que quieres que te encargue el proyecto, tampoco eres demasiado pesado para afinar los detalles al máximo, o sea, que te ves un poco entre la espada y la pared), como el que compra una caja de material de cualquier tipo, el cliente quiere un precio cerrado y un tiempo de desarrollo, salvo que tengas mucha disciplina y una mano muy amable para conseguirlo, intentas minimizar las reuniones al máximo (en donde se van muchas horas), si en el mismo proyecto existen dependencias de terceros, éstas van a condicionar también el esfuerzo necesario, aunque al principio, cuando estás cotizando, no tienes ni idea de cuánto.

En pocas palabras, incertidumbre + incertidumbre + incertidumbre...

Esto es, muchas veces, vas en cierta medida a ciegas, lo que no deja de ser un contrasentido cuando el cliente quiere un precio cerrado y tú manejas una incertidumbre de más menos el 30% en el tiempo (por decir algo).

O peor aún, y algo típico en compañías grandes: esa estimación no la ha realizado nadie relacionado con el equipo técnico, sino alguien de otro departamento sin experiencia suficiente.

Y todo puede emperoar aún más porque para el cliente no eres el único proveedor candidato: mi experiencia me muestra (y ojalá que no sea la misma para todo el mundo), que en última instancia, variables como el compromiso, confianza y calidad, se supeditan irremediablemente al coste final, o lo que es lo mismo, te eligen por el precio/hora como única variable de selección.

Ya sabemos que la productividad de los desarrolladores depende de muchos factores, no únicamente del talento o experiencia que tenga cada uno. Sobre todo en pequeñas compañías, es habitual que un mismo desarrollador tenga que hacer frente al mismo tiempo a más de un proyecto o el día menos pensado hay que apagar algún fuego, añadiendo así una pérdida de tiempo al cambiar de contextos y terminar tareas de un proyecto u otro diferente (tiempo imposible de estimar).

Por otra parte, también sientes la presión añadida de que el cliente quede con un grado alto de satisfacción para que así recurra a ti o tu compañía en otra ocasión, algo en ocasiones difícil de gestionar con clientes difíciles.

Por si no te habías dado cuenta hasta ahora, existen clientes buenos y malos (y no siempre los puedes elegir, me temo): los primeros se ajustan más a lo especificado y se esfuerzan mucho para permitir que tú trabajes lo mejor posible porque te ven parte de su equipo (están comprometidos con el proyecto), los segundos esperan que les leas la mente y se toman el derecho de cambiar especificaciones en cualquier momento haciendo que el equipo pierda horas al modificar lo ya realizado (tiempo no cotizado) o no comprenden que cuando se entrega un proyecto, tu parte termina ahí a no ser que exista un acuerdo para el mantenimiento del mismo. Estos últimos tan solo están implicados en el proyecto, y tú, como responsable del mismo, tienes que actuar en ocasiones como paraguas para evitar que el cliente cambie demasiadas cosas en reuniones con cierta tensión.

Es posible que te identifiques claramente con el escenario anterior: te piden que cotices y construyas un edificio pero no te dicen cuántas plantas se tiene, el tamaño de las ventanas te lo dicen después y ya veremos si lleva garage o no, y eso sí, la fecha de entrega es inamovible.

Siento si te estás agobiando al leer hasta aquí, pero todo lo anterior forma parte de la dinámica muy común de muchas compañías cuyo modelo de negocio consisten únicamente en contratar proyectos, a precio cerrado, con fecha de inicio y de fin, y que al tratar de manejar toda la incertidumbre anterior, al final de la cadena, se tiene a desarrolladores estresados, haciendo rápido lo que requiere de mucho más tiempo de dedicación y haciendo que las cosas en producción no se caigan en cualquier momento.

Es cierto que siempre existe cierta indeterminación cuando se especifica, de ahí que el enfoque ágil sea una herramienta maravillosa para reducir esa incertidumbre, pero la cuestión es que casi siempre, terminas infracotizando el esfuerzo real por uno u otro motivo.

Por muy bien que apliques las buenas prácticas de diseño, preparando tu proyecto software para el cambio, con una buena arquitectura y una calidad de código excelente, no se va a poder amortiguar toda esa incertidumbre fácilmente.

Siendo así las cosas, se explica perfectamente que en ocasiones se entreguen proyectos con un diseño deficiente y mucha deuda técnica, por falta del tiempo necesario para hacer iteraciones de mejora o exigencias de tiempo del cliente imposibles de abordar. Sencillamente, a veces es imposible cuadrar el círculo.

No siempre se tiene el margen suficiente para elegir los proyectos que tienes que desarrollar o dirigir, puesto que el negocio manda y hay que rentabilizarlo para pagar gastos, nóminas, etc.

Por todo esto, cuando me encuentro algún proyecto con graves deficiencias, nunca apunto a los desarrolladores que lo hayan realizado, sino más bien a las condiciones en las que lo han hecho. Y, sorpresa, casi siempre hay detrás una dinámica de trabajo en la que todo tiene que estar para antes de ayer, sueldos reducidos o proyectos infracotizados y mal especificados.

Para evitar el máximo esta dinámica desagradable, yo siempre trato de identificar a la persona coordinadora por parte del cliente y lo implico al máximo para que valide lo que se avanza en iteraciones pequeñas (de una a dos semanas), pero la experiencia también me muestra que los proyectos se cogen al principio con muchas ganas y poco a poco, ese esfuerzo recurrente de validación, ese coordinador termina viéndolo como una tarea pesada más (porque tiene otras que atender de su propia organización, claro).

¿Cuál es tu papel entonces como director de proyectos como es mi caso?

A mí no me cabe la menor duda: no soy ni el jefe y no me gustan las jerarquías ni tampoco me gusta ordenar como un general que manda a los soldados como carne de cañón. Yo tengo claro que mi papel asume toda la responsabilidad en el buen desarrollo del proyecto y su entrega con la suficiente calidad y que mi principal misión es favorecer las condiciones en las que los desarrolladores trabajan, lo que también implica que el cliente haga su papel (en ocasiones no es sencillo).

Como ya sabemos, un trabajo creativo requiere de ciertas condiciones para su realización, y éstas es responsabilidad de todos los miembros de una compañía para conseguirlas, también del cliente.

¿Y entonces? ¿Es posible escapar de la dinámica anterior de trabajar en proyectos infracotizados la mayoría de las veces (igual a presión)? ¿Cómo asegurar entonces la rentabilidad de cada proyecto?

No me cabe la menor duda: por esta razón desde hace muchos años, prefiero el desarrollo de productos que van a evolucionar constantemente durante muchos años, o startups que están probando una idea y se pueden permitir pivotar los desarrollos las veces que hagan falta, o proyectos a muy largo plazo (como Hub de Libros). En esos contextos puedes tener margen suficiente para crear proyecto de calidad con poca o nada de deuda técnica, con iteraciones de mejora y un crecimiento del proyecto ordenado.

Como desarrollador de software, prefiero mil veces estar implicado en un producto (que se va a comercializar entre decenas, cientos o miles de clientes) que en proyectos cotizados por horas.

Manejar la incertidumbre tal y como he comentado más arriba y tratar de acertar en el esfuerzo de desarrollo, es para mí el peor aspecto de mi profesión como desarrollador profesional de software.

Por supuesto existen trucos para reducir el impacto negativo de todo lo anterior: hay veces que interesa atraer a un nuevo cliente y manejar márgenes pequeños para que así conozca la calidad de tu trabajo (esperando realizar más contrataciones para el mismo cliente más adelante y fidelizarlo, ampliando entonces los márgenes), utilizar frameworks propios en los que basar tus proyectos para así realizarlos con buena calidad y en menor tiempo, esforzarte un poco más en los proyectos ad-hoc que realizar para los clientes de modo que se puedan reutilizar en cierto modo en otros proyectos, etc.