El proceso de preventa

Pocas veces (más bien ninguna), cuando hablamos de calidad en el mundo del desarrollo software, nos acordamos de la preventa. Parece que todas las metodologías arrancan cuando está firmado el contrato, y terminan tras el despliegue (con suerte, tras el mantenimiento).

El problema es que se debe tener en cuenta también la preventa. Es decir, el proyecto realmente debemos gestionarlo desde que decidimos presentarnos a una propuesta, o cuando decidimos ir a llamar al cliente, etc.

Muchos os preguntaréis ¿pero esto de la venta también tiene que tener metodología? Pues claro. Y por varios motivos:

• Como toda actividad de gestión, debe haber un procedimiento habitual de trabajo, donde se definan responsabilidades, roles, actividades y entregables.
• Debe hacerse un seguimiento. Normalmente la alta dirección querrá saber periódicamente datos de: posibles acciones de preventa, acciones en marcha, acciones realizadas, nivel de éxito de dichas acciones, etc. Esto nos lleva a las inevitables métricas, informes, etc.
• Y lo que es más importante: debes estimar. Y no es cualquier estimación, es la primera, y precisamente la que se hace cuando tienes menos información de lo que hay que hacer. Por eso requiere de unas herramientas y técnicas distintas de las usadas para estimar cuando estas a mitad del proyecto.

Al final, no deja de ser como un pequeño proyecto:

• Tiene sus fases: por ejemplo podría hablarse de "Oportunidad", "Análisis", "Diseño y ejecución de la oferta", "Revisión y presentación de la oferta"
• Tiene asociado una gestión: durante las fases anteriores, deberá haber una planificación, una estimación de esfuerzo (¿si debemos presentar una oferta antes del día x...llegamos?), etc. También habrá que registrar las horas invertidas, para controlar el tiempo dedicado.
• Tiene sus entregables: el material que usemos para hacer la venta, presentación, etc. Si por ejemplo es una propuesta para un concurso público, ahí entraría toda la documentación a presentar. Otro entregable o documento a controlar podría ser el contrato, la estimación,....
• Tiene sus roles y responsabilidades: alguien se responsabiliza de preparar el material, otra persona lo supervisa, otra (o la misma) presenta la oferta...etc

Lo que no hay que perder de vista, es que la labor comercial, como cualquier otra...tiene un coste. Y como todo coste, sería una irresponsabilidad no darle un seguimiento y tener un mínimo control.

Además, cuando hablamos de metodologías, parece que cuando el equipo de desarrollo comienza (bien con el análisis, diseño, o el propio código), es el PRINCIPIO DEL MUNDO. Es como el big-bang, el principio de la creación. No hay nada anterior, y si lo hay..."no queremos saberlo". Y no es así. No sólo hay que controlar esas acciones, sino que están relacionadas con el propio desarrollo:

• ¿Se conoce la fecha de entrega? Pues claro: anda, léete el contrato.
• ¿Y los requisitos me los invento? Pues tampoco: anda y léete la propuesta. A veces ahí están detallados los requisitos a un nivel impresionante.
• ¿Y porqué esto está estimado así? Pues revísate la plantilla de estimación.