Planificación estratégica de construcción de un producto software

Hace unos días hablaba con un manager de desarrollo sobre las estimaciones, cómo hacerlas y para qué usarlas. Tras compartir diferentes opiniones al respecto, el punto clave llegó cuando hablamos de la necesidad de disponer de esas estimaciones. Él me decía que necesitaba saber cuándo va a estar terminado un proyecto. Desde luego, a priori, tiene sentido. La sorpresa vino cuando le pregunté “para qué quieres saber eso”. Y ahí terminaron las respuestas fáciles.

Planificación estratégica tradicional

Hace tiempo critiqué un Gantt, no por malo, sino por lo que nos llevaba a hacer. Es usual que, según las metodologías tradicionales, tras una planificación de tiempos (reflejada en un diagrama Gantt) haya también una planificación de recursos necesarios para afrontar un proyecto software. Y ahí veo dos problemas básicos: a qué denominamos recurso (tiene sus consecuencias) y dónde ponemos el foco.

Las personas como recursos

Cuando denigramos un ser humano al nivel de recurso estamos dejando en evidencia nuestras carencias. Pasar por alto todo el conocimiento alrededor de las diferentes maneras de mejorar la productividad personal y de los equipos de trabajo, bajo mi punto de vista, no es admisible para alguien que se considere responsable de alguno de estos grupos o personas.

Un ejemplo, por desgracia típico, es aquel proyecto en el que entran personas según se van liberando de otros proyectos. Pido perdón a todos aquellos que se puedan sentir ofendidos por haber escrito personas. Efectivamente, aquí las sinergias y el aumento de productividad por el simple hecho de, entre todos, generar un ecosistema sostenible son protagonistas por su manifiesta ausencia.

Por último, si tengo un recurso de backend, puede hacer su parte y después desaparecer, aunque a continuación llegue otro de frontend para explotar ese backend y no tenga todo cuanto necesite o no entienda lo que hay, ya existirá por ahí un maravilloso documento que no se lee nadie más que el pobre que no tiene otra opción que conformarse con eso. Tiene todo el sentido del mundo.

Dónde ponemos el foco

Cuando nuestro objetivo es cumplir una planificación dejamos de lado lo que realmente importa. Una empresa existe porque ofrece un producto o servicio en un mercado en el que concurren demandantes con una necesidad claramente identificada y que es satisfecha por ese producto o servicio. ¿Alguien ha dicho proyecto? Que yo sepa, en ningún libro de economía  aparece el término proyecto como algo a ofertar en un mercado. ¿Qué valor tiene para nuestros clientes un proyecto? Salvo que seamos un arquitecto civil o similar, poco. En la industria del software, nada.

Lo que de verdad marca la diferencia entre el éxito o el fracaso de una empresa es el conjunto de necesidades de nuestros clientes que somos capaces de solventar a través de nuestro producto. ¿Cuántas veces has oído hablar de esto a alguien que se denomina Project Manager? ¿Cuántas veces hemos visto en una empresa IT un Product Manager con un equipo de desarrollo creando un producto?

Es el pan nuestro de cada día que, con el foco puesto en cumplir unas fechas y un alcance determinado por una única persona y no por quien lo tiene que construir, lo que se resiente siempre es la calidad del producto ofertado. Y aquí tenemos, como Neo, dos únicas opciones: seguir siendo partícipes del cuento o no, abrir los ojos y reaccionar o seguir como hasta ahora.

Vamos a planificar

Bajo esta perspectiva tiene todo el sentido del mundo que necesitemos saber cuándo vamos a acabar un proyecto. Lo importante es el proyecto y ver cuándo se van liberando los recursos para asignarlos a otros proyectos. Y bueno, si lo que queremos es saber cuánto nos va a costar desarrollar un producto… ¿seguro que es tan importante conocer ese dato? En las ocasiones en que así sea, ¿podemos aceptar con un mínimo grado de confianza una estimación de coste basada en un conocimiento superficial del problema? ¿Nos es realmente útil?

Existen otros modelos

Aunque a muchos no nos lo hayan contado en la universidad ni en una factoría de software, hay otras formas de plantear estrategias en las organizaciones o departamentos de IT.

Si lo necesitas, hazlo

Si necesitas un producto, hazlo. Todo lo que te ahorras en reuniones poco o nada útiles y hacer una planificación al milímetro y totalmente irreal reinviértelo en hacer un producto de calidad. He visto ya demasiadas ocasiones en las que un departamento ha necesitado un producto, hemos identificado sus necesidades clave y se ha optado por otra solución que, sin satisfacer esas necesidades clave, ha sido simplemente algo más barato, en el mejor de los casos.

Si un producto de consumo interno nos va a conseguir reducir la ventana de lanzamiento de una campaña de marketing de 3 días a 2 horas, quizá no haya mucho más que discutir. Eso nos da flexibilidad, y en un mercado tan sensible al marketing y a la comunicación como el mercado de venta online, esa flexibilidad puede suponer una ventaja competitiva impresionante.

Si necesitas ajustar un presupuesto, hazlo

Si nuestro problema es que hay que ajustar un presupuesto, bien, defínelo. Fija tu budget y, desde ahí, construye el mejor producto que puedas. Construiremos hasta que nos quedemos sin dinero, invirtiendo cada partida presupuestaria, siempre, en lo más importante. Y como más importante quizá debamos señalar aquellas características que nos permitan tener un retorno de la inversión mayor para así, quizá, reinvertir y aumentar ese budget inicial.

Si inviertes mucho capital y hasta el final no puedes validar las ideas de negocio iniciales, lo más probable es que tengas una bomba a punto de estallar. Existe un camino alternativo que nos permite generar hipótesis, construir y validar para conocer el grado de aceptación de nuestra idea inicial.

No hay una única solución general

Creo que es la conclusión más clara. Cada necesidad nos llevará a plantear un esquema de actuación distinto. No pretendamos emplear el mismo para cualquier situación. Lo que sí existe es algo básico, el derecho a que se nos reconozca como lo que somos, seres humanos, personas. Y, además, existen demasiadas evidencias sobre lo que somos capaces de lograr cuando trabajamos cohesionados como para dejar pasar esas ventajas. A partir de estos dos pilares, construye como quieras, y no pierdas de vista a quien va a pagar tus facturas: tus clientes finales.

Anuncios

Acerca de juanmagomez

Acerca de mí tengo un teléfono, mi portátil, el ipad y esas cosas.

Publicado el octubre 1, 2013 en Agile, Desarrollo de Software, Scrum. Añade a favoritos el enlace permanente. Deja un comentario.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: