Desarrollo de software: Deseo VS necesidad

En ocasiones es complicado alinear al cliente referente a los requerimientos del sistema, mostrándole que es una necesidad real en su producto, y que es un deseo. Para iniciar mostrare la definición tal cual nos la da la real academia de la lengua española:

Necesidad: Aquello a lo cual es imposible sustraerse, faltar o resistir.

Deseo: Anhelar que acontezca o deje de acontecer algún suceso. 

Partiendo de las anteriores definiciones, y trasladándolo a desarrollo de software es importante conversar con el cliente el porque es relevante basar su producto en las necesidades reales de su empresa y operaciones como primer lugar, y posteriormente agregar los deseos expresados que podrían agregar un plus al sistema o producto a desarrollar.

La mayoría de las metodologías hoy en día nos instan a generar un primer MVP (Most Valuable Player), lo que en español significa producto mínimo viable, esto debido a que es importante ayudar a madurar el producto con lo esencialmente necesario para ser lanzado al mercado y tomar métricos de retorno con la finalidad de saber si vamos por buen camino o es necesario virar en otro sentido en caso de que las el producto no este retornando lo que se esperaba (eso será tema de otro post), ya que, quien marca "el buen camino" es el cliente/ mercado y no el Stackholder, el Project Manager o los libros.

Teniendo las piezas armadas, deseos y necesidades separadas es importante dirigirse a revisar que metodología se utilizara y cual es el camino a seguir, les dejo un post anterior donde hablo acerca de ello. 

Si tienen alguna duda para ampliar el tema, puede dejarlo sobre los comentarios o mandarme un correo electrónico. 

Como se inicia en la carrera como Project Manager, o Administrador de proyectos

Ser PM o Administrado de proyectos, en mi caso fue cuestión de suerte o como dicen en mi pueblo "Estar en el tocadero, para que me toque"(algo redundante), ¿Porque?, por la simple razón de que se me dio la oportunidad de incursionar en el área.  

Realmente como profesional me fue necesario picar piedra, iniciar desde cero, y siempre dar la mejor versión de mi mismo. Soy egresado de la carrera como Ingeniero en Sistemas Computacionales del Instituto Tecnológico de Ciudad Guzmán (esto quedo al sur de Jalisco),  como quizás muchos de ustedes les paso, tuve empleos esporádicos mientras estudiaba, inclusive empleos donde era necesario trabajar durante las noches. Al ingresar a trabajar dentro de mi ramo inmediatamente inicie como ingeniero de pruebas,porque en ese momento era la única vacante que existía hasta el momento. Después de permanecer en el área de pruebas solicite con insistencia se me promoviera a desarrollo, estando en dicha área, la vacante como PM que fue liberada para mi, en buen momento, debido al trabajo que venia desempeñando, defendiendo mi proyecto al que fui asignado, era suficiente para que se me otorgara una  propuesta para ser el Administrador de proyectos de la empresa (evidentemente no me lo esperaba, pero me puso feliz). 

La realidad es que en lo particular creo que para ser administrador de proyectos es necesario tener ciertas actitudes y aptitudes que permitirán desenvolverte en el área, por ejemplo la mayoría de los ingenieros tienen problemas para expresarse, muchos fuimos quizás educados a ser solo receptores de información para desembocarlo a un producto final, inclusive a eso puede que nos reduzcan en algunas ocasiones en ciertas empresas. Pero el punto de todo esto es aprender, porque cada empresa de igual forma tiene sus procesos, sus metodologías, a mi parecer ninguna mejor que otra porque al final de cuentas por un camino u otro es que llegamos a entregarle un producto final a nuestro cliente ya sea interno o externo, la clave es ese producto con que calidad lo entregamos y cuanto tiempo acorde a la fecha planeada. 

Los puntos que me gustaría destacar para que un proyecto sea exitoso son:

• Una planificación y presupuesto realista a la complejidad del proyecto.
• Un equipo con los conocimientos necesarios para atender el proyecto, se vale decir no puedo o no cuento con lo que se necesita.
• Controlar los riesgos, ya que es imposible controlar todo el proyecto para que salga de A a B sin complicación, la magia consiste en saber atrapar y resolver las eventualidades.
• Empaparse del proyecto desde su inicio hasta la entrega del mismo.
• Ser un líder de proyecto no un jefe, "hay que comprometerse no solo involucrarse".
• Lo mas importante, la comunicación hacia dentro y fuera de la empresa, debo decir que es necesario en ocasiones ser hipercomunicativo.

Existen mas puntos, pero creo que debería abordarlos en otro articulo, en caso de que coincidan, no coincidan conmigo o exista alguna duda que pueda resolverles pueden comentarlo. 

El contenido que leerás en cada una de mis entradas al blog, son puntos de vista personales. 

¿Por qué es importante el cliente en el desarrollo de su producto?

Generalmente el cliente es quien tiene el conocimiento exacto de lo que quiere (en ocasiones no sabe lo que quiere y es necesario le enfoquemos), esto ayuda al equipo de trabajo en especial al analista de requerimientos a mapear las necesidades que serán atendidas por medio del producto de software que desarrollaremos para el cliente.

Todo parte de una idea, un concepto, una necesidad o un detonante que empuje al cliente a automatizar sus procesos, y brindar al cliente final un mejor servicio.

El cliente tendrá interacción en las siguientes actividades del desarrollo del software:

• Levantamiento de requerimientos macro: El cual es cuando de manera general el analista toma las necesidades del cliente con la finalidad de hacer un bosquejo macro.
• Entrevistas para levantamiento de requerimientos: En estas entrevistas se toman los requerimientos mapeados de manera macro para tomarlos como base e indagar a detalle si existe algo ya definido, si es un proceso o sub-proceso nuevo, ayudando siempre al cliente a distinguir cual es la necesidad de su empresa y cual seria un deseo.
• Validación de requerimientos: El cliente en conjunto con el analista debe ayudar a validar los requerimientos que se hubieran mapeado de manera correcta en la historia de usuario o cualquier otro artefacto (esto variara dependiendo si es desarrollo en cascada, Agile o alguna otra metodología).
• Proveer infraestructura de su proyecto: Este punto es variable dependiendo de como se vendió el proyecto con o sin infraestructura, esto quiere decir si la empresa que desarrollara el software proveerá hardware necesario, licencias del software, servicio de Internet y soporte, o en su defecto lo proveerá la empresa que contrata los servicios. Las características de la infraestructura deben ser definidas por el equipo técnico de la empresa que desarrolla el software, ya que será lo mínimo necesario para un buen funcionamiento y preparación del ambiente donde se hospedara el software con la finalidad de no tener contratiempos con las fechas de entrega.
• Validación en sitio del producto de software: Generalmente se construye un checklist con los criterios de aceptación del software, en conjunto el cliente y el analista de requerimientos, cuando el sistema se tiene en ambiente de pruebas e idealmente en el ambiente donde el sistema finalmente se hospedara entonces se realiza un recorrido punto por punto con el checklist en mano para corroborar que el sistema cumple con lo solicitado por el cliente.
• Firma de acta de entrega: Es donde el cliente plasma su firma. El acta de entrega según  la empresa varia, ya que prácticamente el cliente firmara de conformidad que está recibiendo su producto tal cual lo pidió, o parcialmente como lo pidió según los acuerdos finales, esto debido a que un proyecto por diversas situaciones entre ellas económicas, desacuerdos entre ambas empresas (de desarrollo y el cliente) o por la necesidad, el acta se ajusta para que contenga los puntos a aceptar con la firma del cliente.

Prácticamente los puntos antes mencionados serian las actividades del cliente en la ejecución de un proyecto. En esta entrada mencione al cliente, pero el a su vez puede asignar a alguien de su confianza que es "ungido" como el responsable de tener el conocimiento necesario para llevar a cabo las sesiones de levantamiento de requerimientos y validación de los mismos, en estos casos, el cliente pasa a ser el sponsor del proyecto y el ungido será el proveedor valido de requerimientos, en Agile se le llama stakeholder normalmente.