![\"Swing](\"\/app\/uploads\/2024\/05\/swing-software.jpg\")
<\/p>\n<\/p>\n
fuente de la imagen: perfectdigital.com<\/em><\/p>\n Creo que demuestra muy bien que las grandes discrepancias y la falta de visi\u00f3n pueden aparecer en desarrollo de software<\/a> proyectos entre todos los participantes y personas implicadas.<\/strong> Los problemas suelen surgir desde el principio, cuando el cliente llega con una propuesta (te\u00f3ricamente) definitiva. producto<\/a> visi\u00f3n y la presenta al equipo<\/a>. Luego vienen m\u00e1s malentendidos, malas interpretaciones y, finalmente, la proyecto<\/a> va r\u00e1pidamente por el camino equivocado del desarrollo.<\/p>\n Mientras analizo el gr\u00e1fico anterior, presentar\u00e9 paso a paso todas las posibles amenazas y sugerir\u00e9 c\u00f3mo combatirlas. \u00a1Manos a la obra!<\/p>\n Habr\u00e1 discrepancias en la visi\u00f3n del producto<\/a> desde el principio. \u00bfPor qu\u00e9? La raz\u00f3n es muy sencilla: cada uno interpreta la realidad a su manera, tiene una idea de algo en la mente y puede que no presente con precisi\u00f3n esta visi\u00f3n a la otra parte. Si usted describe con palabras un producto que le gustar\u00eda construir, hay una alta probabilidad de que el equipo de desarrollo<\/a> entender\u00e1n su visi\u00f3n de un modo distinto al que usted pretend\u00eda.<\/p>\n Por supuesto, es posible evitarlo. Hay que empezar a visualizar cuanto antes y discutir los elementos individuales de las funcionalidades del producto bas\u00e1ndose en bocetos. Curiosamente, los primeros bocetos no suelen tener nada en com\u00fan con el producto final. En esta fase, sin embargo, lo m\u00e1s importante es que la visi\u00f3n sea coherente.<\/p>\n \u00bfSe pregunta por qu\u00e9 la primera y la segunda imagen son tan diferentes? El jefe de proyecto siempre se fijar\u00e1 m\u00e1s en la visi\u00f3n del producto. Sin embargo, es importante que dicha persona, esencialmente responsable de toda la<\/strong> software proceso de desarrollo<\/a><\/strong>, entiende perfectamente el problema y las necesidades relacionadas con el producto<\/strong>. El jefe de proyecto debe tener clara la \"visi\u00f3n de conjunto\". Como puede ver, ambas im\u00e1genes no difieren en cuanto a funcionalidad. S\u00f3lo tienen un aspecto diferente. Para entender mejor este punto, volvamos a la imagen n\u00famero uno. Al principio del proyecto, no hab\u00eda bocetos y eso ya dio lugar a un malentendido. La funcionalidad del producto es correcta, pero el dise\u00f1o es completamente diferente.<\/p>\n A veces, los analistas y desarrolladores desconocen las necesidades de los usuarios o los objetivos empresariales establecidos. S\u00f3lo ven la peque\u00f1a parte de todo el proyecto que capta su atenci\u00f3n principal. No son capaces de mirar desde una perspectiva m\u00e1s amplia, y esto ocurre sobre todo en proyectos grandes, en los que trabajan muchos desarrolladores al mismo tiempo.<\/p>\n Tambi\u00e9n 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\u00f3n incompleta sobre la que desarrollador<\/a> o dise\u00f1ador crean sus propias interpretaciones, y el producto se desv\u00eda cada vez m\u00e1s de la trayectoria de desarrollo prevista.<\/p>\n \u00bfC\u00f3mo cambiar eso? Creo que una buena soluci\u00f3n es asegurarse de que las personas clave para el proyecto tengan un conocimiento detallado del mismo, la llamada \"visi\u00f3n de conjunto\". En caso de malentendidos, les resultar\u00e1 m\u00e1s f\u00e1cil llevar la proceso de desarrollo de software<\/em> de nuevo en el buen camino. Por lo tanto, recuerda: si todo el mundo ve solo su peque\u00f1o fragmento de la funcionalidad desarrollada, los malentendidos en la visi\u00f3n se convierten en una amenaza probable.<\/p>\n En este caso, la cuesti\u00f3n es sencilla. El producto debe vender. Tiene que destacar de alguna manera, para que, por ejemplo, un simple columpio para el jard\u00edn adquiera elementos extraordinarios. La idea es convencer al comprador potencial. Sin duda, el departamento de marketing y ventas har\u00e1 todo lo posible para demostrar que el producto es \u00fanico.<\/p>\n La falta de documentaci\u00f3n es un problema muy com\u00fan. A veces, crear documentaci\u00f3n durante desarrollo de productos<\/a> parece una p\u00e9rdida de tiempo innecesaria. Esto es un error. Digo muy a menudo que los cambios se hacen m\u00e1s r\u00e1pido sobre el papel que en el c\u00f3digo<\/a>y hay algo de raz\u00f3n en ello. Adem\u00e1s, es m\u00e1s f\u00e1cil consultar la documentaci\u00f3n para hacer un seguimiento de los cambios. Cr\u00e9ame, un proyecto sin documentaci\u00f3n corre un riesgo muy alto de perder la visi\u00f3n.<\/p>\n Esta etapa se refiere a la colocaci\u00f3n del entorno en el servidor. Al igual que en el punto sobre los programadores y analistas, sin la plena datos<\/a> y con lagunas de comunicaci\u00f3n, puede resultar que s\u00f3lo se haya creado una parte del entorno necesario.<\/p>\n Es el resultado de una mala comunicaci\u00f3n, falta de UX<\/a> etc. La aparici\u00f3n de errores aumenta el tiempo de desarrollo. Y el tiempo es oro, \u00bfverdad? Mi sugerencia es dirigir el proyecto de acuerdo con Agile<\/a><\/strong>Mantenga los m\u00e1s altos niveles de comunicaci\u00f3n y unas directrices presupuestarias claras. No me cabe duda de que as\u00ed evitar\u00e1s estos problemas.<\/p>\n Con frecuencia, los clientes se centran \u00fanicamente en crear un producto y terminar con \u00e9l. Sin embargo, vivimos una \u00e9poca de muchos cambios e innovaciones tecnol\u00f3gicas, por lo que es necesario mantener un soporte t\u00e9cnico constante. La idea es evitar una situaci\u00f3n en la que algo deje de funcionar de repente al quedarse anticuado y el producto pierda su valor. Tampoco hay que olvidar este aspecto.<\/p>\n Hemos llegado al \u00faltimo punto. F\u00edjate en la discrepancia entre el primer gr\u00e1fico y el \u00faltimo. Al fin y al cabo, ambos se refieren a la perspectiva del cliente. \u00bfPor qu\u00e9 ocurre esto? Todo el mundo lo ve as\u00ed de sencillo \ud83d\ude42 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 SINCERIDAD<\/strong>sino m\u00e1s bien de la forma en que creen que deber\u00edan responder. B\u00e1sicamente, no quieren exponerse a la valoraci\u00f3n negativa de los dem\u00e1s. He aqu\u00ed una peque\u00f1a pista para usted: mencione en las instrucciones que no hay respuestas buenas ni malas.<\/p>\n \u00bfD\u00f3nde m\u00e1s 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\u00e1s tarde en realidad s\u00f3lo utilizan, digamos, 3.<\/p>\n \u00bfC\u00f3mo resolver este problema? Adem\u00e1s de preguntar a los usuarios qu\u00e9 quieren y necesitan, perm\u00edtales probar el producto, preferiblemente con art\u00edculos aut\u00e9nticos para mantener la credibilidad. Cuantas m\u00e1s pruebas se realicen durante la creaci\u00f3n de los productos, mayor ser\u00e1 la probabilidad de que el resultado sea exacto.<\/p>\n Si alguna vez se convierte en miembro de una desarrollo de software<\/a> proyecto, recuerda mis ejemplos y saca conclusiones para no copiar los errores anteriores. Y recuerda, estos conceptos son muy importantes en la construcci\u00f3n de un producto (aplicaci\u00f3n) desde cero:<\/p>\n - una buena experiencia de usuario y pruebas, para saber qu\u00e9 necesitan realmente los usuarios,<\/p>\n - comunicaci\u00f3n dentro del proyecto, de modo que las personas clave del proyecto dispongan de una comprensi\u00f3n profunda del problema y las necesidades,<\/p>\n - desarrollar el producto de acuerdo con \u00c1gil<\/a>,<\/p>\n - no te olvides del soporte t\u00e9cnico.<\/p>\n M\u00e1s informaci\u00f3n:<\/strong><\/p>\n - \u00bfC\u00f3mo gestionar eficazmente a los desarrolladores remotos? La gu\u00eda para CTO<\/a><\/p>\nConoces esta foto, \u00bfverdad?<\/h2>\n
1. \u00bfC\u00f3mo explic\u00f3 el cliente la idea?<\/strong><\/h2>\n
2. \u00bfC\u00f3mo lo entendi\u00f3 el jefe de proyecto?<\/strong><\/h2>\n
3. \u00bfC\u00f3mo lo dise\u00f1\u00f3 el analista? y<\/em><\/strong> 4. \u00bfC\u00f3mo lo escribi\u00f3 el programador?<\/strong><\/h2>\n
5. \u00bfC\u00f3mo lo describi\u00f3 el asesor empresarial?<\/strong><\/h2>\n
6. \u00bfC\u00f3mo se document\u00f3 el proyecto?<\/strong><\/h2>\n
7. \u00bfQu\u00e9 operaciones se instalaron?<\/strong><\/h2>\n
8. \u00bfC\u00f3mo se factur\u00f3 al cliente?<\/strong><\/h2>\n
9. \u00bfC\u00f3mo se apoy\u00f3?<\/strong><\/h2>\n
10. \u00bfQu\u00e9 necesitaba realmente el cliente?<\/strong><\/h2>\n
Resumen<\/strong><\/h2>\n