Si me preguntan, “¿cuál es el proceso de un desarrollo de software a la medida?” realmente tengo opiniones muy variadas, sin embargo, casi todos los proyectos tienen un comienzo muy similar: Los nuevos clientes suelen llegar solicitando primero “algo sencillo”. La diferencia aquí radica en si quiere resolver solo un problema o más bien, ve la tecnología como un aliado que le ayudará a crecer.
Teniendo como referencia lo anterior, desde mi punto de vista, el proceso depende de dos tipos de inicio de proyecto muy diferentes:
- El cliente con urgencia es el primer comienzo con el que te encuentras, y el más común, pues llega herido de muerte solicitando ayuda inmediata.
- El cliente sin urgencia, con paz interior y con una mentalidad de invertir para hacer crecer su negocio. No pide ayuda porque se esté desangrando económicamente.
El proceso.
Validar y concientizar. No todos los clientes saben cuáles son los precios reales de un desarrollo a la medida, los cuales implica costos por realizar un software y costos de mantenimiento.
Un desarrollo a la medida no siempre es la mejor opción. ¿Puede un software empaquetado (una solución ya hecha en el mercado como Aspel, COI, Compaq, Soft Restaurant, etc, no personalizable) resolver su problema? Es muy importante analizar junto con nuestro cliente esta pregunta, pues es un paso que le resultaría mucho más económico de aplicar, ya que nos saltaríamos el proceso de desarrollo para ir directo a la implementación de dicho software.
Desarrollar un USM (User Story Map). Si llegamos a la conclusión, junto con nuestro cliente, de que si es necesario un desarrollo a la medida, entonces el siguiente paso es ejecutar un ejercicio de User Story Mapping.
USM es una técnica visual que nos ayuda a organizar las solicitudes de los usuarios, a las que llamamos historias, en un modelo útil para comprender la funcionalidad de un sistema, identificar agujeros y omisiones en la lista de funcionalidades pedidas por cliente, y planificar de manera efectiva lanzamientos de software que brinden valor a los usuarios y a las empresas.
Al inicio del proyecto estaremos empleando dicha técnica, momento en el que será necesario que estén presentes todas las personas involucradas en los procesos que se pretenden cubrir con el desarrollo del software a la medida. De esta manera, plasmaremos en conjunto todas las actividades y acciones que se tienen que realizar dentro del sistema, y así, ambas partes (cliente y equipo de desarrollo) tendremos un entendimiento común sobre las problemáticas que buscamos resolver y cómo las queremos resolver.
Algo muy importante de lo que nos daremos cuenta durante esta etapa, es que tanta disposición hay de parte del personal de las áreas (de la empresa de nuestro cliente) por querer resolver sus problemas internos. Primeramente, que las personas indicadas se presenten al desarrollo del USM, y segundo, que le dediquen el tiempo necesario.
Estimación y PMV (Producto Mínimo Viable).
Una vez que plasmamos todas las funcionalidades en un USM, ahora es nuestro turno para realizar una estimación. Dicha estimación estará basada en un sistema de puntos por historia, donde cada punto tendrá un valor monetario cotizado en base a la tecnologías necesarias a implementar en el proyecto y la complejidad del mismo, y donde cada historia es una funcionalidad solicitada por el cliente.
La estimación que se entrega contiene cuántos puntos se requieren para tener todo el sistema funcionando, además de un precio transparente del costo por punto de historia, lo cual ayuda a tener claro para ambas partes, el costo total del proyecto si lo quisiéramos desarrollar por completo.
Por otro lado, también es importante la propuesta de un Producto Mínimo Viable, lo cual es la funcionalidad mínima que necesita el cliente para poder operar y que consideramos que le entregará el mayor valor posible.
Ejemplo de un caso: Si se le comentó al cliente que se requieren 300 puntos de historia para hacer el sistema en su totalidad, seleccionamos las historias que generen más valor de negocio en el menor tiempo posible, lo cual brindará la funcionalidad mínima necesaria para tener un Producto Mínimo Viable.
Este PMV debería estar listo en un tiempo no mayor a 3 meses, pues supongamos que tiene una estimación de 60 puntos de historias de usuarios (lo cual requiere un costo menor para arrancar) para iniciar el desarrollo y se ponga en producción. Así, conforme se vayan viendo los resultados del PMV, se pueden ir desarrollando las siguientes partes del sistema.
Proceso de desarrollo.
Ya que tenemos un plan para el desarrollo del PMV, el equipo de desarrollo realizará iteraciones cada 2 semanas.
Esto quiere decir que en ese periodo de tiempo estaremos entregando funcionalidades para que el cliente y su personal comience a probarlas y utilizarlas, pues cuando se entregan funcionalidades finalizadas, es necesario que los usuarios de cada parte del sistema carguen información en ambientes de pruebas con la finalidad de encontrar errores para que los desarrolladores hagan las correcciones lo más pronto posible. De esta manera, también estaremos validando constantemente que estamos construyendo lo que el cliente realmente necesita, de forma correcta.
También es sumamente importante resaltar que durante el proceso, es necesario que los usuarios realmente ayuden al equipo de desarrollo a validar lo anterior, ya que de no dedicar el tiempo necesario para probar el software, los errores se acumulan hasta la fase de producción, provocando que el proyecto se vuelva mucho más complicado, urgente y caro de resolver.
Este resultado trágico, al no realizar las etapas de pruebas y validaciones con usuarios finales, sucede frecuentemente por que las empresas (recordemos) tienen un gran desorden interno, pues generalmente todos están saturados con urgencias, tareas de su día a día y problemas internos por resolver. Es aquí donde se necesita más que nunca del apoyo de los jefes para recordarles a los involucrados la importancia de dedicar un tiempo a la revisión del software.
Implementación y salida a producción.
Este es el momento donde la realidad alcanza al software, donde todos los escenarios no previstos comienzan a brotar como palomitas recién hechas, y en el que, por ejemplo, se empieza a evidenciar que los usuarios nunca abrieron el sistema en su ambiente de pruebas para ayudar a desarrollo a detectarlo cuando aún el detalle era fácil de resolver.
Durante el proceso de implementación, el equipo de desarrollo está en estado de alerta esperando a que surjan todas las situaciones no previstos para resolverlas lo más rápido posible. A esta etapa le llamamos proceso de estabilización, la cual dura aproximadamente un mes.
Los primeros días de la implementación son un real apocalipsis, muy estresantes. Pero conforme pasan los días y las semanas, el sistema comienza a estabilizarse y ser confiable. Al finalizar el proceso de estabilización, el cliente decidirá si desea continuar con el desarrollo de las otras funcionalidades o se queda con su versión actual de software.
Mantenimiento de software.
Por último, y no menos importante, el mantenimiento posee prácticamente 2 variantes:
- El cliente abrirá su propia área de sistemas. Si las cosas marchan bien y el software comienza a hacer cada vez más relevante en la empresa, lo más seguro es que se cree un área de informática dentro de la misma donde el sistema ya no esté a cargo de un proveedor externo. Su mantenimiento y desarrollo continuará por parte del área de informática del cliente.
- Contratación externa. La empresa no tiene, ni quiere abrir su propia área de sistemas, por lo que tendrá que contratar un proveedor que pueda brindarle los servicios de mantenimiento de software, administración de servidores, soporte de segundo y tercer nivel, etc.