¿Qué nos pasa siempre que empezamos un proyecto? ¿Les parece conocida esta conversación? la misma se da entre un cliente que tiene una distribuidora de artículos para el hogar y una empresa de desarrollo certificada en todos modelos de desarrollo y calidad que se les vengan a la mente. Al cliente lo llamaremos «Cliente» y a la empresa de desarrollo «Desarrollo INC.»
Cliente: Necesito un «programita» para control de inventario de mi negocio.
Desarrollo INC: Nosotros le ofrecemos un desarrollo a medida para sus necesidades en la última tecnología, cumpliendo todos los estándares de desarrollo junto a la documentación correspondiente, asegurando un producto de calidad y con la información de seguimiento correspondiente.
Cliente: ok, ok, pero, yo lo necesito urgente.
Desarrollo INC: ok, le proponemos realizar el relevamiento y documentación del alcance para generar el plan de proyecto correspondiente.
Cliente: ok, empecemos lo antes posible.
…..
2 meses más tarde, luego de reuniones de relevamiento y presentación de la documentación correspondiente se realiza una nueva y tensa reunión.
Cliente: bueno, ya han pasado 2 meses y aún o pude ver el sistema. ¿Pueden explicarme la situación?
Desarrollo INC: ya tenemos todo el alcance definido. ahora podemos comenzar a mostrarle prototipos del sistema para ir validando que lo construido está acorde a lo solicitado.
Cliente: prototipos? ya tendría que tener el producto terminado y solo tengo documentos que no entiendo. Necesito el sistema, así que por favor arreglemos esto porque no pienso alargar más el proyecto.
Desarrollo INC: ……?????!!!!@@@

Esto es algo que lo vemos todos los días, por eso la pregunta es: documentación o desarrollo, como hacemos para hacer ambos?

Como expertos en soluciones debemos atender y concentrarnos en la necesidad del cliente que termina siendo el producto. por eso el mecanismo que nos da resultado en un 95% de los casos (comprobado por experiencia) es el siguiente:

1. Identificación de la necesidad del cliente primario. ¿Qué resultados espera del producto?
2. Identificación de las necesidades del usuario. ¿Cómo se desea utilizar la aplicación?
3. Con menor prioridad. Identificación de las necesidades de las áreas de control de la empresa. ¿Qué documentación se requiere?

Con estos 3 puntos les aseguro que el panorama del proyecto será muy claro para la definición del objetivo principal: el producto.

Ahora entramos en la parte del equipo de trabajo. ¿Cuáles son los puntos más importantes que nos harán llegar a buen puerto? y créanlo funciona!!!
1. Contarle al equipo que se espera del producto.
2. Priorizar sobre todas las cosas la camaradería y compañerismo.
3. Todos participan de todo aunque sean partes del producto que no desarrollen.
4. Impulsar la colaboración para la solución de problemas y participar a todos de los logros.
5. Por último, desarrollar, documentar código y probar.
6. Premisa, siempre estar junto al equipo de trabajo, charlar es mejor que documentar. Los pasos correctos son: charlar, definir, documentar.

Se preguntarán, ¿y con el cliente cómo nos manejamos para que esté contento? esto no es un tema menor, sobre todo con clientes «complicados» o empresas «normalizadas», con esto ultimo quiero decir, empresas cuyos sectores horizontales (auditoría, control de gestión, seguridad, etc.) les importará más los documentos asociados, la trazabilidad de la información y que se esté haciendo lo que el cliente quiere pero de acuerdo a su punto de vista.

1. El cliente quiere ver lo que se imagina como solución. Por eso debemos ser inteligentes e ir mostrándole pantallas funcionales de lo que espera, OJO, no hablo de prototipos que luego debemos tirar. Sino que debemos presentar pantallas reales de la solución.
2. Si en una etapa temprana no disponemos de las pantallas, le mostraremos bosquejos (utilizamos el Balsamiq Mockups), de esta forma no se centrarán los comentarios en la estética, sino en la distribución del contenido.
3. Premisa: siempre informar fechas reales de entrega, no adelantar las mismas ya que cualquier funcionalidad no terminada será mal vista y generará malos precedentes.
4. Documentar en forma gráfica y clara. Tener en mente que la documentación orientada al cliente final, no es la misma que la orientada a desarrollo. Es un error muy común querer generar documentación para ambos espectadores y terminan siendo documentos interminables, que dicen mucho para unos y poco para otros.
5. nunca decir que no al cliente. lo mal pre dispone, siempre un «lo vamos a analizar» cae muy bien.

Ahora si, manos a la obra con «Desarrollo»
¿Cuantas metodologías conocen? RUP, Scrum, todo lo que tiene que ver con metodologías ágiles, el clásico cascada, y blah blah. Todas son útiles y todas tienen 2 puntos en común:
• el tiempo es secuencial, por lo que por más que paralelicemos, siempre hay puntos que dependientes de otros.
• las personas. el expertise del equipo y colaboración son la piedra fundacional del desarrollo.
Dicho esto, les cuento nuestro mecanismo de Desarrollo

Partiendo de la base que ya se tiene la solicitud del cliente se sigue el siguiente ciclo de trabajo:
1. Se pre analiza la solución y se define la tecnología en base a la infraestructura del cliente y a las personas del equipo de trabajo.
2. Se arma el equipo de trabajo en base a experiencia y afinidad. Muchos se quejarán de los equipos Elite, pero no hay nada más cierto que uno trabaja mejor en cuanto a afinidad, que muchas veces está dada por la experiencia y conocimientos de cada miembro.
3. Se profundiza el análisis y se distribuyen las tareas. Siempre comenzando por la definición de la base de datos.
4. Se definen las convenciones de programación, fundamental para que todos los miembros del equipo puedan comprender el código de los demás.
5. Se comienza el desarrollo por funcionalidades cerradas. Esto quiere decir que la funcionalidad debe ser conocida en detalle y comprendida por los desarrolladores. Esto puede acompañarse con bosquejos de pantallas y/o diagramas del flujo de la información. OJO, no estoy hablando de especificaciones complejas que incluyan diagramas de clases, ni de secuencias, etc. Estoy hablando de gráficos que hasta pueden hacerse en mano alzada de la secuencia de pasos que debe seguir la información.
6. El analista u otro desarrollador verifica la funcionalidad desarrollada y da el ok para continuar con el resto o integrarla con otra.
7. Este último punto es el que itera haciendo crecer nuestra solución.
8. Cada fecha de entrega se muestra lo desarrollado y se relevan los ajustes a incorporar. Estos se realizan inmediatamente después de recibidos.
9. En paralelo el analista va generando la documentación comprometida con las demás áreas (casos de pruebas, DER, diagramas de clases, etc.)
Como se darán cuenta, no es ningún invento, es solo compartirles nuestra experiencia y remarcar que lo principal de todo proyecto es el equipo de trabajo y la colaboración entre los mismos. Los documentos son solo papeles que muchas veces molestan o entorpecen el proyecto. Los bosquejos, diálogos y partes funcionales del producto son los verdaderos entregables y objetivos del proyecto.

En otro momento les cuento la experiencia del seguimiento y gestión de proyectos.

Charlen y desarrollen, en forma individual, de a pares o todos juntos detrás de una máquina, les aseguro que el proyecto saldrá mucho mejor que trabajando cada uno en islas.

Gracias!!!!