Errores más comunes al contratar un desarrollo a la medida

A continuación te mostramos una lista de los errores más comunes que comenten las empresas al contratar un desarrollo a la medida.

1.- Casos de uso no contemplados: Las sesiones para recabar los requerimientos del cliente suelen ser solo al inicio del proyecto, y en la mayoría de los casos las empresas no cuentan con documentación de sus procesos, y mucho menos de las excepciones a éstos. Ello complica y limita el alcance del proyecto dejando fuera los casos atípicos del alcance del proyecto.

Solución: La empresa desarrolladora debe solicitar al contratante documentación de casos típicos, y de la misma forma los casos atípicos. La documentación mencionada debe servir como escenarios de pruebas al realizar las revisiones periódicas del avance del proyecto que permitan validar el cierre (Vo.Bo.) de etapa.

2.- Plataformas que no reflejan los procesos del cliente: Existen plataformas que no cumplen con las reglas del negocio a raíz de una pobre alta de requerimientos, y/o a una falta de documentación de éstos. El problema se vuelve más grave cuando se encuentran estos errores al final del proyecto, o en una etapa posterior a la entrega del mismo.

Solución: Se debe solicitar a la empresa que desarrolladora que utilice alguna metología de desarrollo ágil (no de cascada/waterfall), que les permita tener sesiones más frecuentes con el contratante bajo el fin de detectar errores en las reglas del negocio en una etapa temprana. Así mismo, es responsabilidad del contratante entregar documentación con el mayor nivel de detalle de sus procesos.

3.- Plataformas que si reflejan el alcance del proyecto en pruebas, pero no en la práctica: Muchas veces ocurre que los desarrolladores realizan plataformas que cumplen con lo especificado en el alcance del proyecto, pero ya en el uso de la misma no reflejan la necesidad del cliente. Es común contar con un responsable del proyecto, pero éste no necesariamente puede validar los alcances del proyecto. Ello debido a que el responsable puede no tener el mismo contexto que el usuario final de la plataforma.

Solución: La validación del alcance del proyecto con los usuarios finales de la plataforma, antes de lanzar el proyecto. Es importante destacar que el contexto del usuario final, debe ser retroalimentado con el responsable del proyecto y con la empresa desarolladora.

4.- Una plataforma rígida: Refiere a la falta de escabilidad natural de la plataforma debido a una arquitectura rígida de la misma. Ello es resultado de la falta en experiencia de la empresa desarrolladora, o la limitación auto-aplicada por esta al realizar una plataforma que cumpla con los objetivos sin planear el crecimiento a futuro.

Solución: En caso de disponer de un departamento de TI, solicitarle revisar la arquitectura de la plataforma propuesta bajo objetivos claros. Dentro de dichos objetivos se debe encontrar el crecimiento de la plataforma sin actualizaciones, en otras palabras "escalabilidad". Si no se cuenta con un departamento de TI se pueden realizar preguntar, al desarrollador, tales como "¿Y si necesito crear más _______?" o "¿Puedo contar con flujos dinámicos en _______?" .

Toda plataforma, sin lugar a dudas, deberá pasar por actualizaciones que son reflejo de un crecimiento orgánico de la misma así como una verdadera solución al problema que pretendía cubrir el contratante. Una plataforma que no pasa por actualizaciones, suele ser por la falta de uso de la misma que culmina con el abandona de ésta.