Los cambios constantes en el mundo de los negocios y el mercado móvil determinan no solo las tendencias sino también las reglas del desarrollo de software. Una de estas reglas dice que los requisitos estables para un producto de software es algo así como la perfección en general: siempre intentamos aspirar a él, pero siempre hay un camino por recorrer. Y sería realmente perfecto para todos si los requisitos del proyecto de software fueran estables y resueltos. Esto evitaría muchos problemas y malentendidos. Pero esa no es la experiencia que puede tener lugar hoy en día.

¿Por qué no podemos tener requisitos firmes para comenzar?

Es ingenuo pensar que todo lo valioso se captura desde el principio. La comprensión detallada del software y cómo funciona, las condiciones del negocio del cliente, todo esto trae nuevos requisitos y un nuevo valor para el software.

Cualquier documento relacionado con los requisitos refleja el momento en que está escrito. Pero los proyectos más grandes no están terminados en un día o en una semana, mientras que las cosas cambian tanto en tecnología como en el mercado. Eso es especialmente difícil debido a las constantes actualizaciones de software y tecnología: cualquier cambio externo, que apenas se prevé, puede causar un problema. Por un lado, cada pequeño cambio difícilmente puede ser aceptado; Por otro lado, los requisitos no pueden permanecer estancados. Tampoco es bueno sobrecargar y sobrecargar la aplicación. Mirar y pensar hacia adelante es un buen consejo, pero no es tan fácil en el aspecto técnico del mundo móvil. Como resultado, ahora una de las líneas más frecuentes en la lista de méritos de cualquier compañía de software es respuesta rápida a los cambios & ;.

¿A qué se refieren estos cambios?

Se puede pasar por alto un requisito. Puede entenderse que algo que fue planeado, en realidad ya no es necesario. Un competidor puede lanzar repentinamente un producto que tiene características superiores; puede haber una necesidad urgente de ideas nuevas. Estos pueden ser cambios técnicos, aplicados debido a nuevas actualizaciones de hardware / software / plataforma. Estos pueden ser cambios requeridos por el negocio del cliente, por ejemplo, agregar nuevos productos, servicios y ofertas al software de marca.

Los cambios en los requisitos pueden variar de aquellos que se pueden completar en menos de un día a otros mucho más complejos, que pueden ocurrir después de que comience el desarrollo. Todos los trabajos de mantenimiento, como varias correcciones, no ocupan una gran parte de los cambios, en comparación con los funcionales.

¿Cual es la solución?

Para los desarrolladores (una empresa de desarrollo) es mejor tratar estos cambios como desafíos. Por lo tanto, pueden hacer que el software sea mejor y competitivo dentro del entorno dinámico del mercado móvil. Los desarrolladores deben ser flexibles y estar listos para estos cambios para tener éxito con el proyecto.

Para el propietario del software, es necesario comprender y prever que los posibles cambios de los requisitos aprobados pueden causar demoras y gastos extra en el presupuesto. Pero esa es la manera de hacer un gran producto de software que ningún competidor podrá copiar. Hay varios desafíos que van de la mano con las ventajas: la incertidumbre en los costos finales, por ejemplo. Sin embargo, el propietario del software de todos modos tiene control sobre el presupuesto, el alcance y el cronograma, es el propietario del software quien toma las decisiones sobre la financiación del proyecto y establece prioridades.

El desarrollo iterativo es una de las soluciones para el problema. Si el cliente está listo para enfrentar estos cambios en términos de presupuesto, plazos y tiempo para comunicarse con el contratista, es más probable que el resultado final sea realmente útil, en todos los sentidos. No es que el cliente deba simplemente gastar más dinero en nuevas funciones inútiles, eso no es una receta para un producto exitoso. Cada iteración es la etapa donde los requisitos son generalmente estables.

Por eso es por eso que el título de este artículo dice acerca de el problema & ;, no & ;el problema' de requisitos cambiantes. Deben gestionarse adecuadamente para no hacer del desarrollo un gran problema. La opinión de que los cambios son malos, que deben evitarse, no es tan correcta. Los cambios relevantes no tienen que ver con agregar gastos y retrasar el lanzamiento: el producto de software adquiere cierto valor y la ventaja competitiva para el propietario del software. La relevancia del producto supera estos inconvenientes, y es una de las claves para el éxito del producto.

Dejar respuesta

Please enter your comment!
Please enter your name here