Manual de Buenas Prácticas

Este manual surge como orientación y ayuda hacia los ingenieros informáticos para que puedan realizar una captura de requerimientos que cumpla con las características (atributos) que hacen que ésta esté bien elaborada.


Uso de diagramas de flujo de datos

Ayudan a clarificar el ordenamiento y la secuencia de acciones de la aplicación del proyecto, es decir, gracias a la visualización de éste se pueden detectar tempranamente requisitos que quedan expuestos al desarrollar un diagrama de flujo de datos del proyecto.


Afinidad con el cliente

Lograr una afinidad grata con el cliente, se hace de gran utilidad ya que así el cliente tendrá una mejor disposición y además la comunicación tendrá mayor fluidez otorgando mayor información y permitiendo interiorizar de mejor forma con lo que reamente desea con el proyecto deseado. En el caso contrario (no lograr una afinidad grata con éste), se puede dar una realización de ‘malas ganas’ del proyecto pudiendo ocasionar una deficiente toma de requerimientos y a largo plazo un resultado de proyecto que no es deseado por el cliente.


Realizar reuniones de manera informal

Entre las ventajas que trae encontrarse en una situación informal están: la conversación se daría en forma espontanea, se logra un ajuste a una situación formal (obtención de información más detallada), permite un desarrollo integral para ambos involucrados. Un ejemplo de algunos encuestados es: juntarse en un parque, tomando un refresco y conversando acerca de los requerimientos que tendrá el proyecto.

Saber decir que no

Muchas veces el cliente va a desear muchas cosas para la aplicación, pero como generalmente no tiene conciencia de lo que está pidiendo, el ingeniero debe ser capaz de poder evaluar estas peticiones y decir que no cuando es necesario, también debe considerar factores de tiempo, económicos, etc.

Anticiparse a los problemas

En el momento en que el cliente efectúa una petición, el ingeniero debe explicarle lo que es necesario para en el futuro poder implementar dicho requerimiento. Existen veces que el cliente no admite que ciertos asuntos son necesarios y no quiere incluirlo en las listas de problemas. Es buena idea efectuar ese trabajo igual, ya que tarde o temprano el cliente va a requerirlo de todas maneras, y en el caso de que no sea requerido, el equipo ya estaba preparado para el contratiempo.

Comenzar la reunión con preguntas humanas ajenas al tema de la reunión

Es muy importante recordar que el cliente es una persona antes que un cliente. Por ésto es muy buena práctica, comenzar las reuniones con preguntas sobre su estado, su familia, su trabajo, etc. Ésto ayuda a crear un clima más favorable para el desarrollo de toda la reunión, haciendo que las personas se sientan más a gusto.

Que el cliente sienta que el ingeniero es una ayuda

Es cierto, el cliente es ambiguo al hacer sus requerimientos, pero esa es la manera en que debe ser, para eso están los ingenieros que tienen que ser capaces de poder ayuduar al cliente cuando éste no puede obtener lo necesario para implementar un requisito. Cómo el ingeniero conoce mejor lo que sirve o no sirve, debe brindar ayuda al usuario a encontrar lo necesario y no dejarlo sin guía, argumentando que su trabajo es simplemente escucharlo.


Comunicarse apropiadamente con el cliente en las reuniones

En las reuniones, aunque parezca obvio es necesario hablar. Existen ingenieros que acuden a las reuniones y no dicen nada en gran parte de ella. Como consecuencia de ésto, indirectamente están aceptando problemas, o más trabajo, sólo por el hecho de no establecer su punto de vista. Ésto ocurre con las personas que son muy introvertidas, o que son tímidas para exponer ante un gran número de personas. Es necesario que el ingeniero se prepare a si mismo para éste tipo de situaciones y exponga adecuada y claramente.

Respaldar en algún tipo de registro los acuerdos tomados en cada reunión

Cuándo existan los típicos problemas de responsabilidades, de quien iba a quedar cargo de hacer que tarea, se puede recurrir a un respaldo de lo acordado en cada reunión, ésto es aplicable tanto para la relación entre ingeniero y cliente o entre el equipo de ingenieros.


Saber cuándo es conveniente aplazar o suspender una reunión.

Para el cliente es un trabajo extra el hecho de tener que explicar al ingeniero lo necesario para implementar el sistema. Esto genera un estrés y acumulación de carga de trabajo. Además considerando de que se está tratando con personas, es probable que llegado el día una reunión, él tenga problemas personales, estrés y carga de trabajo. el ingeniero debe ser capaz de darse cuenta de esta situación, ser flexible, y ofrecer un horario conveniente al usuario para la siguiente reunión, eso es ponerse en el lugar del otro.

3 comentarios:

Patricio Sebastián dijo...

Muy bueno el manual, pero este esta pensado sólo para ingenieros que recien comiencen en la captura de requerimientos, o en general para los ingenieros que posean años de experiencia?. Si es que fuese para todo tipo de ingenieros, se debe seguir este listado de memoria, o se debe acomodar a la realidad de cada analista en requerimientos?.

PeponeRock dijo...

Me parece un buen manual, salvo por el punto de Saber decir que NO. Creo que el ingeniero no debe negar funcionalidades al cliente. Creo que con eso ustedes se refieren al tema de la factibilidad. En ese caso, es un deber como ingeniero evaluar factibilidad de un sistema a construir.

Anónimo dijo...

Tambien me parece un buen manual, tiene varios puntos en comun con el propuesto por mi. Creo que es fundamental establecer una buena comunicación con el cliente.