7 errores comunes en proyectos de desarrollo de software

Ya tomaste la decisión de desarrollar tu propia aplicación de Software y ya elegiste un proveedor, enhorabena, has dado un paso importante, por lo tanto ahora debes de concer los siguientes: 7 errores comunes en el desarrollo de Software.

1. Mala estimación de tiempos

¡Vaya!, Me dijiste que me costaría 5 y se tardaría 12… ¿Qué salió mal?. Si bien la estimación de tiempos y costo es un arte, también es un proceso que tiene técnicas para estimar y acercarse bastante a una buena cotización. Tener una mala estimación de tiempos y costo afecta a ambas partes, a ti como cliente y al proveedor. Lo que puedes revisar antes de aceptar una cotización que hace sentido a tu presupuesto, es verificar o indagar lo siguiente:

• ¿El proveedor tuvo reuniones conmigo para realizar un pre análisis?
• ¿Me pidió acercarse conmigo para resolver alguna duda?
• ¿Me pidió documentación que le ayude a estimar?
• Vino y me hizo una presentación de la cotización y del entendimiento de mis requerimientos?
• ¿Entendió y expresó lo que necesito?

Si al preguntar lo anterior, alguno de estos puntos no estuvo presente durante el proceso, puede ser un indicio de que tu proyecto tiene un alto riesgo de sufrir cambios durante su ejecución, estos cambios van relacionados directamente a tiempo y costo. Aún si con lo anterior no quedas convencido, estás en todo tu derecho de preguntar qué técnica de estimación utilizó para realizar tu cotización, algunas de ellas son:

• • Puntos por fusión
  • Casos de uso
  • Delphi
  • Juicio Experto
  • La combinación de algunas de las anteriores

Una mala estimación no detectada a tiempo hará que ambos vivan una experiencia no tan grata durante el proyecto.

2. Insuficiente administración de los riesgos

¿Qué es un riesgo en el desarrollo de proyectos de software? Un riesgo es un evento o condición incierta que, si sucede, tiene un efecto en por lo menos uno de los objetivos del proyecto. Hay distintos tipos de riesgos, aquí te proporcionamos las siguientes categorías en las que se pueden clasificar y puedas preguntar a tu proveedor qué hace para mitigarlos.

• • • 1. Riesgos asociados con los usuarios. Incluyen la falta de compromiso de la alta gerencia de la organización y la insuficiente participación de los usuarios. Estos factores no siempre están al alcance del líder del proyecto.
    • 2. Factores de riesgo asociados al líder del proyecto. La incapacidad para juzgar el alcance del sistema y con la pobre identificación de la funcionalidad requerida. Estos factores si deben ser controlados por el lider del proyecto.
    • 3. Factores asociados a la ejecución del proyecto, tales como personal inadecuado, metodología de desarrollo inapropiada, fallas en la definición de roles y responsabilidades, pobre planeación y control del proyecto. Estos factores generalmente si son considerados y controlados por el líder del proyecto.
    • 4.Factores de riesgo asociados al entorno, que se enfoca principalmente en los cambios en la gerencia organizacional y que podrían afectar al proyecto.

Los factores de las categorías 2 y 3 son los que afectan directamente a que los proyectos sean culminados en el tiempo y con el presupuesto previsto. De esta forma, los proyectos pobremente ejecutados o con un alcance inestable y requerimientos vagos, normalmente no son culminados exitosamente. Los factores de las dos categorías restantes no siempre afectan el éxito en los procesos de un proyecto.

3. Escatimar en el control de calidad

El aseguramiento de la calidad es una etapa primordial en tu proyecto de software, pues en esta etapa se permite validar todos los puntos de quiebre y cruciales en la operación de un negocio dado y hacia el cual está encaminado el software.

Es muy importante que se destine al menos un 30% del tiempo del desarrollo de tu proyecto para las pruebas que el departamento de calidad ejecuta, estimar un tiempo menor no es recomendable, pues según los expertos no se puede realmente garantizar que el software pueda realizar todo lo esperado de la manera correcta, aún siendo cuando la funcionalidad a validar ya sea por más conocida, pues cada proyecto tiene variables que los hace diferentes; se vale totalmente preguntarle a tu proveedor qué porcentaje está destinando al aseguramiento de la calidad y en qué momentos lo ejecutará.

Tú como cliente estás en todo tu derecho de pedir resultados (documentos que respalden su ejecución) de al menos las siguientes operaciones realizadas en esta fase, ya sea en proyectos de cascada o en SCRUM: plan de pruebas, diseño de casos de prueba, ejecución de ciclos de prueba, validación de pruebas integrales y pruebas automatizadas, este último es totalmente deseable tener, pues garantiza que la labor de prueba humana fue ejecutada correctamente, o bien ayuda a localizar errores a otro nivel.

Finalmente, nosotros recomendamos validar que el proveedor seleccionado cuente con un área de QA (Quality Assurance) que se responsabilice de seguir una metodología, pues realmente afecta negativamente en los resultados del software, ya que los defectos y errores “saltan” hasta que el producto no está en operación, y muchas de la veces en este punto la corrección de los mismos es mucho más costosa por el esfuerzo que representan los ajustes tanto en la parte operativa como en la parte de los datos; Es totalmente correcto solicitar a tu proveedor información al respecto, ellos no deben de negarse a dar información sobre su área de QA.

4. Diseño inadecuado

Si bien es realmente cierto que sin un buen análisis no se puede tener un buen diseño, por ser actividades que por lo regular van de la mano no todo es totalmente dependiente del análisis, pues se puede tener el mejor de los análisis, pero un diseño deficiente.

Siempre recomendamos a los clientes que estén muy pendientes de los entregables de esta fase, que por lo regular los más comunes son un prototipo o wireframes de lo que será la interfaz de usuario, sin embargo, tu como cliente, puedes ir más allá y pedir que se te haga llegar un diagrama entidad-relación de la base de datos junto con su diccionario de datos y diagrama de clases, al menos, pues de esta manera se podrán dar cuenta que lo que se comunicó en la fase de análisis es lo que se está construyendo como el esqueleto de su proyecto.

Es muy fácil interpretar estos entregables, pues en realidad hoy en día la programación en general y sobre todo la orientada objetos es una representación muy parecida o igual de la realidad, y debe de solucionar y ajustarse perfectamente a lo que se solicitó; entonces no temas que puedas leer y validar estos documentos, pues al contrario, incluso podrías cuestionar a tu proveedor y hacer “caer en cuenta” de posibles errores u omisiones.

Ten muy en cuenta que el diseño es el “esqueleto” de tu proyecto, cualquier error importante no detectado, o bien, detalles no contemplados podrían llevar a tu proyecto a transformase en un “Frankenstein”.

5. Confiar demasiado en tecnologías-herramientas no exploradas previamente

“Mas vale bueno por conocido que malo por conocer”, no siempre aplica en el gremio del desarrollo de software.

Las buenas tecnologías o herramientas siempre tienen su momento de despliegue, algunas se quedan y otras simplemente deciden partir. Es muy importante que al momento de que tu proveedor decida la herramienta o tecnología para la construcción de tu proyecto te lo comunique y te haga saber las razones por las cuales la ha seleccionado, tu labor es estar básicamente de acuerdo en costos que pueda generar por licenciamiento (en caso de que aplique), soporte que el proveedor pueda ofrecer, aceptación de la misma, compatibilidades, etc.

Es importante que te documentes por tu cuenta y que tu proveedor haga una tabla comparativa con alguna otra tecnología que tu propongas o bien que ellos ya hayan previamente evaluado.

También es sumamente bueno ver la aceptación en el mercado, nivel de conocimiento, etc., pues esto indica la factibilidad de que más adelante puedas realizar ajustes o mejoras.

En definitiva puedes decidir ser un conejillo de indias y acceder a que tu proveedor desarrolle tu proyecto con nuevas herramientas que no han sido tan usadas y de reciente creación, en muchas de las ocasiones son muy buenas y despliegan, pero en otros casos simplemente no llegan para quedarse.

6. Motivación débil

Cuando de equipos de trabajo se trata, la motivación es un aspecto crucial a tener en cuenta y cuidar en los miembros de un equipo.

Cuando el personal está totalmente motivado garantiza en gran medida el éxito del proyecto, pues las tareas a realizar se ejecutan con total plenitud, hacen “suyo” el labor y por consecuencia dan lo mejor de sí, obteniendo un producto estable y de calidad.

Uno como líder de proyecto se puede dar cuenta fácilmente de la motivación de su equipo, si y sólo si conoce bien la personalidad de cada uno, pues es importante aprender a leer todas las señales, incluso el lenguaje corporal, que también habla y mucho.

Aquí, tú como cliente no tienes mucha inferencia, lo único de lo que sí te puedes asegurar es preguntar a tu proveedor sobre los mecanismos que usarán en el equipo de trabajo asignado para lograr la motivación suficiente, qué harán para hacer ver el proyecto lo suficientemente retador y que valga la pena realizarlo de la mejor manera, de tal forma que puedan aprender algo nuevo o bien aplicar conocimientos nunca practicados.

Tal vez no se dé mucho el caso, pero incluso la motivación por parte de los involucrados por parte del cliente es lago crucial, pues son las personas más interesadas en sacar adelante el producto, en definitiva si desde el lado del cliente no hay la motivación suficiente no se puede pedir motivación del otro lado, recordemos que los “cuerpos no mienten” y será totalmente incongruente pedir motivación y ánimo en el equipo de trabajo que está para apoyarnos y crear el mejor producto, pero todo en base a lo que el cliente refiera y exprese. Pregunta a tu proveedor cuanto tiempo tiene en la organización el equipo de trabajo que será designado en tu software, de ser posible que te proporcione el CV de los integrantes y los puedas conocer.

7. Añadir más personal a un proyecto atrasado

Conocer quién es el equipo de trabajo asignado a tu proyecto debería de ser un requisito que todo cliente debería de pedir a su proveedor, pues si bien no estarás todo el tiempo en contacto con ellos, sí son las personas sobre las cuales recae directamente el desarrollo de tu proyecto, ellos son quienes reportan el avance y hacer crecer el proyecto.

Cuando uno de los elementos tiene que salir o simplemente es necesario incluir a otros miembros, ya sea por cuestiones de atraso o de complejidad, definitivamente le agrega una dinámica un tanto peculiar al resto de equipo, así como al aseguramiento del éxito del proyecto.

Es recomendable que la persona que se agregue llegue a realizar actividades en particular que puedan ser directas y no tan dependientes de las del resto del equipo, pues se debe de considerar la curva de aprendizaje de la lógica de negocio, posterior a esta curva de aprendizaje se le puede entonces incluir al mismo ritmo y dinamismo que ya tiene el equipo entero; Desde luego las habilidades y conocimientos técnicos es algo que no de debe de obviar al momento de la elección de dicha persona.

Es muy importante que a ti como cliente se te informe de este tipo de eventos que desde luego sí llegan a pasar por “n” tipo de situaciones y que muchas de las veces el proveedor absorbe el costo que esto representa por ser una tema ajeno al cliente pero que sí le atañe 100% a su proyecto.

Como podrás notar, son solo algunos criterios importantes que si los tomas en cuenta podrás tener éxito en tu proyecto sin tantos tropiesos por el camino, si tienes dudas o requieres de una asesoría completa sobre como Northware puede ayudarte como un socio de negocios que ayude a cumplir tus expectativas, contáctanos, estaremos encantados de platicar contigo.

PLUS +1.

¿Te han contado la historia ? Otro error común en ambas partes es “No contar la historia”, ¿a que nos referimos con esto?, pues bien, resulta bastante útil  desde un inicio enfrentar lo que comúnmente pasará a lo largo de la vida de tu proyecto, es decir que el proveedor te cuente y te mire a los ojos.

• Nos vamos a enfrentar que la mayoría de los proyectos van a representar atrasos, algunos por motivos del proveedor y otros tuyos como cliente, no significa que al final no vaya a ser exitoso.
• Va a ver ocasiones en que te vas a cansar de que te pregunten y cuestionen repetidamente el detalle de los requerimientos, pero es importante para minimizar dejar cabos sueltos.
• Te vas a molestar  que te inviten a participar en muchas de las juntas si ya les comentaste todo lo que tienen que saber.
• Y mas aun te vas a molestar que en esas juntas salgan requerimientos nuevos y te comenten que no están dentro del alcance original y esto demande costos y tiempos adicionales
• Pero si lo anterior no se comunica y se acepta, después habrá molestia porque vas a comentare al proveedor que esto parece eterno y nunca termina.

“Somos la mejor opción para acompañar a tu Organización durante su Transformación Digital. Más de 20 años colaborando con empresas nacionales e internacionales.

Si estás próximo a arrancar un proyecto de migración a La Nube, Desarrollo de Software o Aplicaciones Móviles Empresariales y tienes dudas sobre este tema, te invito a que nos contactes”.

Somos una Empresa de Desarrollo de Software, especialista en Desarrollo de Aplicaciones Web, Desarrollo de Apps Empresariales, Microsoft Dynamics 365 y Fábrica de Software. Desarrollamos software basado en Microsoft .NET, y aplicaciones nativas en iOS o Android; para aquellas empresas que sólo requieren la contratación directa de especialistas, brindamos asesoría especializada de acuerdo a las necesidades de nuestros clientes con experiencia en las tecnologías más avanzadas para apoyar tu estrategia en desarrollo de sistemas y desarrollo de app.