La fea verdad sobre el proceso de desarrollo de software

fuente de la imagen: perfectdigital.com

Conoces esta foto, ¿verdad?

Creo que demuestra muy bien que las grandes discrepancias y la falta de visión pueden aparecer en proyectos de desarrollo de software entre todos los participantes y personas implicadas. Los problemas suelen surgir desde el principio, cuando el cliente llega con una propuesta (teóricamente) definitiva. producto visión y la presenta al equipo. Luego vienen más malentendidos, malas interpretaciones y, finalmente, la proyecto va rápidamente por el camino equivocado del desarrollo.

Mientras analizo el gráfico anterior, presentaré paso a paso todas las posibles amenazas y sugeriré cómo combatirlas. ¡Manos a la obra!

1. ¿Cómo explicó el cliente la idea?

Habrá discrepancias en la visión del producto desde el principio. ¿Por qué? La razón es muy sencilla: cada uno interpreta la realidad a su manera, tiene una idea de algo en la mente y puede no presentar con precisión esta visión a la otra parte. Si usted describe con palabras un producto que le gustaría construir, hay una alta probabilidad de que el equipo de desarrollo entienda su visión de una manera diferente a la que usted pretendía.

Por supuesto, es posible evitarlo. Hay que empezar a visualizar cuanto antes y discutir los elementos individuales de las funcionalidades del producto basándose en bocetos. Curiosamente, los primeros bocetos no suelen tener nada en común con el producto final. En esta fase, sin embargo, lo más importante es que la visión sea coherente.

2. ¿Cómo lo entendió el jefe de proyecto?

¿Se pregunta por qué la primera y la segunda imagen son tan diferentes? El jefe de proyecto siempre se fijará más en la visión del producto. Sin embargo, es importante que dicha persona, esencialmente responsable de toda la desarrollo de software proceso, entiende perfectamente el problema y las necesidades relacionadas con el producto. El jefe de proyecto debe tener clara la "visión de conjunto". Como puede ver, ambas imágenes no difieren en cuanto a funcionalidad. Sólo tienen un aspecto diferente. Para entender mejor este punto, volvamos a la imagen número uno. Al principio del proyecto, no había bocetos y eso ya dio lugar a un malentendido. La funcionalidad del producto es correcta, pero el diseño es completamente diferente.

3. ¿Cómo lo diseñó el analista? y 4. ¿Cómo lo escribió el programador?

A veces, los analistas y desarrolladores desconocen las necesidades de los usuarios o los objetivos empresariales establecidos. Sólo ven la pequeña parte de todo el proyecto que capta su atención principal. No son capaces de mirar desde una perspectiva más amplia, y esto ocurre sobre todo en proyectos grandes, en los que trabajan muchos desarrolladores al mismo tiempo.

También podemos utilizar otro ejemplo. Puede ocurrir que el problema a resolver sea descrito incorrectamente, por ejemplo, por el propietario del producto. Esto implica proporcionar información incompleta sobre la que el desarrollador o el diseñador crean sus propias interpretaciones, y el producto se desvía cada vez más de la trayectoria de desarrollo prevista.

¿Cómo cambiar eso? Creo que una buena solución es asegurarse de que las personas clave para el proyecto tengan un conocimiento detallado del mismo, la llamada "visión de conjunto". En caso de malentendidos, les resultará más fácil llevar la proceso de desarrollo de software de nuevo en el buen camino. Por lo tanto, recuerda: si todo el mundo ve solo su pequeño fragmento de la funcionalidad desarrollada, los malentendidos en la visión se convierten en una amenaza probable.

5. ¿Cómo lo describió el asesor empresarial?

En este caso, la cuestión es sencilla. El producto debe vender. Tiene que destacar de alguna manera, para que, por ejemplo, un simple columpio para el jardín adquiera elementos extraordinarios. La idea es convencer al comprador potencial. Sin duda, el departamento de marketing y ventas hará todo lo posible para demostrar que el producto es único.

6. ¿Cómo se documentó el proyecto?

La falta de documentación es un problema muy común. A veces, crear documentación durante desarrollo de productos parece una pérdida de tiempo innecesaria. Esto es un error. Digo muy a menudo que los cambios se hacen más rápido sobre el papel que en el códigoy hay algo de razón en ello. Además, es más fácil consultar la documentación para hacer un seguimiento de los cambios. Créame, un proyecto sin documentación corre un riesgo muy alto de perder la visión.

7. ¿Qué operaciones se instalaron?

Esta etapa se refiere a la colocación del entorno en el servidor. Como en el punto sobre programadores y analistas, sin datos completos y con lagunas de comunicación, puede resultar que sólo se haya creado una parte del entorno necesario.

8. ¿Cómo se facturó al cliente?

Es el resultado de una mala comunicación, falta de UX, etc. La aparición de errores aumenta el tiempo de desarrollo. Y el tiempo es dinero, ¿verdad? Mi sugerencia es dirigir el proyecto de acuerdo con AgileMantenga los más altos niveles de comunicación y unas directrices presupuestarias claras. No me cabe duda de que así evitarás estos problemas.

9. ¿Cómo se apoyó?

Con frecuencia, los clientes se centran únicamente en crear un producto y terminar con él. Sin embargo, vivimos una época de muchos cambios e innovaciones tecnológicas, por lo que es necesario mantener un soporte técnico constante. La idea es evitar una situación en la que algo deje de funcionar de repente al quedarse anticuado y el producto pierda su valor. Tampoco hay que olvidar este aspecto.

10. ¿Qué necesitaba realmente el cliente?

Hemos llegado al último punto. Fíjate en la discrepancia entre el primer gráfico y el último. Al fin y al cabo, ambos se refieren a la perspectiva del cliente. ¿Por qué ocurre esto? Todo el mundo lo ve así de sencillo 🙂 Los resultados de las encuestas siempre difieren de las necesidades reales de los encuestados. Al responder a la pregunta del investigador, los usuarios quieren mostrar su mejor cara. Por lo tanto, A MENUDO NO RESPONDEN CON SINCERIDADsino más bien de la forma en que creen que deberían responder. Básicamente, no quieren exponerse a la valoración negativa de los demás. He aquí una pequeña pista para usted: mencione en las instrucciones que no hay respuestas buenas ni malas.

¿Dónde más aparecen las diferencias? A menudo, la gente no sabe lo que realmente quiere. Muy a menudo, los usuarios dicen inicialmente que necesitan 10 funcionalidades en el producto, y más tarde en realidad sólo utilizan, digamos, 3.

¿Cómo resolver este problema? Además de preguntar a los usuarios qué quieren y necesitan, permítales probar el producto, preferiblemente con artículos auténticos para mantener la credibilidad. Cuantas más pruebas se realicen durante la creación de los productos, mayor será la probabilidad de que el resultado sea exacto.

Resumen

Si alguna vez se convierte en miembro de una desarrollo de software proyecto, recuerda mis ejemplos y saca conclusiones para no copiar los errores anteriores. Y recuerda, estos conceptos son muy importantes en la construcción de un producto (aplicación) desde cero:

- una buena experiencia de usuario y pruebas, para saber qué necesitan realmente los usuarios,

- comunicación dentro del proyecto, de modo que las personas clave del proyecto dispongan de una comprensión profunda del problema y las necesidades,

- desarrollar el producto de acuerdo con Ágil,

- no te olvides del soporte técnico.

Más información:

– ¿Cómo gestionar eficazmente a los desarrolladores remotos? La guía para CTO

– Python vs. Ruby? ¿Qué tecnología debería utilizar para el desarrollo de productos?

– Una guía rápida para crear y desarrollar su propio mercado. ¿Qué merece la pena saber?