S\u00e9 que este art\u00edculo es un poco superficial; simplemente pretendo compartir mi punto de vista <\/strong>basado en la experiencia de varios a\u00f1os en este mundillo. Incluso habr\u00e1 quien lo considere anticuado por entenderlo como programaci\u00f3n en cascada o simplemente quien no comparta algunas afirmaciones. Me encantar\u00eda poder recibir vuestros comentarios<\/strong> al respecto y aprender de vosotros. Al iniciar un proyecto, a veces se deja de dedicar esfuerzo en detectar los puntos clave<\/strong>, documentar por escrito e intentar aportar m\u00e1s valor de lo que solicita el cliente y tener visi\u00f3n para anticipar futuros problemas y\/o requerimientos. Este ejercicio, aunque puede demorar un poco el inicio de la programaci\u00f3n tiene beneficios<\/strong> a corto y medio plazo. Es conocido que el cliente no suele pedir lo que necesita, pide lo que \u00abcree\u00bb que necesita, habitualmente condicionado a las soluciones ya implementadas, centr\u00e1ndose \u00fanicamente en los defectos y limitaciones de estas, sin hacer el ejercicio de poner la mente en blanco, desaprender lo aprendido, pensar \u00fanicamente en su negocio y lo que realmente necesita.<\/p>\n Es por ello que la realizaci\u00f3n del an\u00e1lisis por parte de un externo<\/strong> (el analista), permite aportes frescos, nuevas ideas, algo as\u00ed como ir al psiquiatra, que es un perfecto desconocido pero te ayuda a ver las cosas desde otra perspectiva y aporta valor a las ideas preconcebidas.<\/p>\n Tambi\u00e9n es cierto que a veces el cliente es reticente<\/strong> a nuevas ideas, aquello que se llama \u00abmiedo al cambio\u00bb. Aqu\u00ed se debe jugar la carta opuesta a \u00absi funciona no lo toques\u00bb porque el cliente es consciente de que \u00abno funciona\u00bb y por eso es necesario darle la vuelta a la tortilla. Entender las necesidades (requerimientos) y encontrar respuestas siempre lo asocio al juego del ajedrez. Como analistas debemos ser capaces de anticipar a:<\/p>\n Corto plazo:<\/strong> lo que nos piden, la jugada inmediata, me como el caballo y punto<\/p>\n<\/li>\n Medio plazo: <\/strong>lo que el cliente sabe que pedir\u00e1, anticipar un par de jugadas para comerle la reina<\/p>\n<\/li>\n Largo plazo:<\/strong> lo que ni el cliente sabe pero que alg\u00fan d\u00eda llegar\u00e1, jaque mate. Nota:<\/strong> el adversario no es el cliente, es llegar a la mejor soluci\u00f3n para todos.<\/p>\n Con todo ello, debemos ser capaces de dise\u00f1ar los sistemas, componentes, procesos, bases de datos y todo aquello que cubra el corto plazo, pero preparado para el medio y el largo que hemos identificado. El esfuerzo <\/strong>no deber\u00eda ser mayor, solo es anticiparse y dejarlo todo preparado a futuro. Analizar, definir, documentar no tiene porque ser una foto est\u00e1tica, es m\u00e1s, puede convertirse en la herramienta para posteriores cambios pues ayuda a conocer las consecuencias, esfuerzos, riesgos de los cambios. A veces comparo la elaboraci\u00f3n de software con la construcci\u00f3n de un edificio<\/strong>, nadie entender\u00eda empezar a construir sin planos, los cimientos preparados para soportar cuantos pisos… \u00bfDebe haber parquing? \u00bfDe cu\u00e1ntas plazas? \u00bfAire acondicionado? Si no se tiene claro desde el primer dia, a medio trabajo estaremos rehaciendo todo, una monta\u00f1a de chapuzas, material desperdiciado, horas desperdiciadas, desprestigio, desmoralizaci\u00f3n<\/strong> y no hablemos del cliente.<\/p>\n En la elaboraci\u00f3n de software <\/strong>podemos aplicar la misma premisa, realizar un dise\u00f1o previo, completo y detallado de los componentes y sus iteraciones aporta:<\/p>\n Facilita la valoraci\u00f3n de tiempo y costes<\/p>\n<\/li>\n Evita riesgos (\u00a1\u00a1\u00a1sustos!!!) al anticipar soluciones antes que aparezcan<\/p>\n<\/li>\n Mejora la comunicaci\u00f3n entre el equipo y con el cliente<\/p>\n<\/li>\n Evita malentendidos \u00abt\u00fa me dijiste\u00bb, \u00abyo entend\u00ed\u00bb (\u00bfos suena?)<\/p>\n<\/li>\n Ayuda a distribuir las tareas<\/p>\n<\/li>\n Facilita la creaci\u00f3n de iteraciones<\/p>\n<\/li>\n Evita errores y duplicidades<\/p>\n<\/li>\n Facilita la gesti\u00f3n de cambios. La lista es muy larga, os dejo que la complet\u00e9is. Dependiendo del tipo de proyecto y el equipo involucrado, cada hora dedicada al an\u00e1lisis y especificaci\u00f3n puede tener un ahorro de decenas de horas de trabajo y desmoralizaci\u00f3n. Antes de empezar S\u00e9 que este art\u00edculo es un poco superficial; simplemente pretendo compartir mi punto de vista basado en la experiencia de varios a\u00f1os en este mundillo. Incluso habr\u00e1 quien lo considere anticuado por entenderlo como programaci\u00f3n en cascada o simplemente quien no comparta algunas afirmaciones. Me encantar\u00eda poder recibir vuestros comentarios al respecto y […]<\/p>\n","protected":false},"author":826,"featured_media":1458,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"","template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[1562],"tags":[1813,1644,1630,1717],"etiquetes":[],"categorias":[],"class_list":["post-17897","article_basic","type-article_basic","status-publish","format-standard","has-post-thumbnail","hentry","category-tecnologia","tag-open","tag-programacion","tag-projectes","tag-proyectos"],"acf":[],"yoast_head":"\n
\n <\/p>\n\u00bfEmpezamos a trabajar ya?<\/h2>\n
\n <\/p>\n\u00bfQu\u00e9 me est\u00e1s pidiendo?<\/h2>\n
\nAl psiquiatra vas<\/h2>\n
\n <\/p>\nVisi\u00f3n, visi\u00f3n, visi\u00f3n<\/h2>\n
\n
\n\t <\/p>\n<\/li>\n<\/ul>\n
\n <\/p>\n\u00abEspecificaci\u00f3n\u00bb no es sin\u00f3nimo de \u00abrigidez\u00bb<\/h2>\n
\n <\/p>\nLas ventajas de documentar formalmente<\/h2>\n
\n
\n\t <\/p>\n<\/li>\n<\/ul>\n
\n <\/p>\nConclusi\u00f3n… personal<\/h2>\n
\n <\/p>\nFoto de cabecera: Markus Spiske<\/a> \/ Unsplash<\/a><\/h5>\n","protected":false},"excerpt":{"rendered":"