¿Cómo hacer programas efectivos?

Todo está en saber captar la necesidad.

Bien, en mis tiempos como programador (debo confesar que hace algún tiempo que no programo al menos no a nivel comercial ya que tengo varios años dedicado a la parte de infraestructura) una de los problemas frecuentes que enfrentaba es la interpretación de la necesidad.

Los usuarios/clientes cuando desean un programa te dicen su supuesta necesidad

Necesito un programa que haga esto, aquello y me diga lo otro.

El problema es que el programador hace lo que entiende y luego el usuario/cliente te dice que no era eso, o que faltaba más.

Una forma en que muchos programadores (incluso ITIL V3) te sugiere que hagas las cosas es validar el acuerdo por escrito antes de la ejecución. Eso está bien, y debe hacerse, pero mi mayor preocupación sinceramente es no caer en discusiones con mis usuarios/clientes.

Algo que aprendí durante la práctica es que el cliente te dice lo que quiere pero no te dice las "Necesidades Ocultas", ¿y que son las necesidades ocultas? simple, son las necesidades que el cliente considera triviales (o a veces da por sentada que las inferimos o el mismo las desconoce) y que al final se convierten en el dolor de cabeza, porque generalmente esas trivialidades implican modificaciones muy fuertes al código o incluso al modelo de la base de datos.

Como comenté al principio se puede hacer uso de un documento firmado, pero la idea es no llegar a usarlo, entonces ¿qué hacer?

No hay que tener cualidades cuasi místicas para saber que hacer, solo hay que recordar que un sistema en su esencia más básica es: Entrada->Proceso->salida.

Dicho lo anterior, pues sucede que los programadores se centran en el diseño de la aplicación, a veces en su funcionalidad y estas son cosas que el cliente no valora (al menos no directamente) esto ocurre básicamente por algo: "Un sistema es tan útil como los son sus salidas".

Me encontré con clientes que tenían programas extremadamente antiguos, y una cantidad de interfaces para otros programas creadas para poder hacer compatible el programa con nuevas tecnologías, y aunque era obvio que tenia que haber una migración del sistema, pues bien para el cliente esa idea era impensable, se aplicaba la máxima de:

Si esta funcionando no lo toques.

Lo anterior ocurre básicamente porque aunque el programa era extremadamente viejo daba las salidas necesarias para apoyar la toma de decisiones, realizar seguimiento o control sobre los procesos de las empresas.

Las siguientes son tácticas útiles que se pueden usar:

• Pregunte al cliente cuales son los reportes que necesita bien sean impresos o en pantalla (o cualquier otra interface que tenga el sistema).
• Pregunte al cliente si tiene algún modelo de los reportes actuales y sobre ellos mismos en mano alzada pídale al cliente que resalte los cambios (si los hubiese).
• Invierta tiempo con el cliente en diseñar los reportes necesarios hágale saber lo importante que es saber cuales son los reportes.

Bien, otra cosa que debemos saber igual de importante es al momento de la programación:

Si los reportes son tan importantes para saber que quiere el cliente son igual de importantes para diseñar un sistema.

Comience a diseñar el sistema en orden inverso, además aunque parezca un cliché, lo primero que se debe diseñar es el modelo de entidad relación, pero háganlo partiendo de los reportes, siempre hay que pensar de atrás, desde los reportes.

Bien, espero que estos pequeños tips sean útiles.