{"id":1,"date":"2014-12-07T07:27:48","date_gmt":"2014-12-07T06:27:48","guid":{"rendered":"https:\/\/www.integratecnologia.es\/la-innovacion-necesaria\/?p=1"},"modified":"2023-12-26T17:30:18","modified_gmt":"2023-12-26T16:30:18","slug":"toma-de-requisitos-10-razones-por-las-que-puede-fallar-un-proyecto-de-bi","status":"publish","type":"post","link":"https:\/\/www.integratecnologia.es\/la-innovacion-necesaria\/toma-de-requisitos-10-razones-por-las-que-puede-fallar-un-proyecto-de-bi\/","title":{"rendered":"Toma de requisitos: 10 razones por las que puede fallar un proyecto de BI"},"content":{"rendered":"

\u00bfA alguien se le ocurre no mirar el plano de una vivienda antes de que comiencen a construirla? \u00bfUn ingeniero de caminos aceptar\u00eda el cambio de un puente, cuando ya est\u00e1n terminando las obras? Si tienes claro que la respuesta es no, es hora de plantearse por qu\u00e9 esto s\u00ed ocurre a menudo con los proyectos software<\/em>.<\/p>\n

Un fallo en la fase inicial de todo proyecto Business Intelligence (BI), la fase de captura de requisitos<\/strong>, puede condicionar el \u00e9xito del proyecto y la futura utilidad del producto. Estas son las 10 razones por las que un proyecto BI puede empezar mal y c\u00f3mo evitarlo:<\/p>\n

\u00bfAn\u00e1lisis? A m\u00ed no me pongas de eso<\/strong><\/p>\n

El primer error grave que puede surgir es que en la planificaci\u00f3n no se considere o se infravalore el tiempo a invertir en esta fase. Todo proyecto de BI tiene que asumir que un porcentaje importante del proyecto debe estar asignado a la captura de requisitos. No es exagerado decir que la captura de requisitos y el an\u00e1lisis pueden conllevar un 30% del esfuerzo del proyecto.<\/p>\n

\u00a1Contad! Tenemos todo el tiempo del mundo<\/strong><\/p>\n

En la mayor\u00eda de proyectos de Business Intelligence, cuando se comienza la fase de requisitos, el presupuesto ya est\u00e1 cerrado, lo que indica que no puede crecer indefinidamente. Muchos proyectos no finalizan bien porque crece desmesuradamente el alcance de lo inicialmente acordado.<\/p>\n

Hay algo que es obvio, una buena medida del tama\u00f1o del proyecto va a ser el tiempo que nos cueste contarlo. El n\u00famero de sesiones de captura de requisitos deber\u00eda venir limitado en el alcance del proyecto: \u201cvamos a desarrollarte el proyecto de BI que seas capaz de contarme adecuadamente en 7 sesiones de captura de requisitos\u201d. Desde luego, este mensaje har\u00e1 que las sesiones sean m\u00e1s productivas.<\/p>\n

Con las manos en los bolsillos<\/strong><\/p>\n

un error habitual es que las sesiones no se preparen adecuadamente y que, en el momento de la reuni\u00f3n, no se tenga muy claro lo que se necesita. Las reuniones de requisitos de un proyecto Business Intelligence NO son el punto adecuado para redefinir un modelo de negocio. Si no tenemos claro nuestro propio modelo de negocio, debemos aclararlo internamente y acudir a la captura de requisitos con las ideas claras.<\/p>\n

Reuniones multitudinarias<\/strong><\/p>\n

Las reuniones donde muchos usuarios discuten por el alcance final del proyecto suelen confundir al analista y hacen que la sesi\u00f3n de captura de requisitos se alargue m\u00e1s de lo necesario. Lo id\u00f3neo es escoger al mejor interlocutor para que lleve la idea del proyecto, previamente consensuada con el resto de usuarios\/departamentos de la organizaci\u00f3n.<\/p>\n

Rienda suelta<\/strong><\/p>\n

Muchas sesiones acaban sin ser productivas porque no se dirigen adecuadamente. Dentro de un ambiente cordial, un participante debe adquirir el rol de \u201cmoderador\u201d y redireccionar la reuni\u00f3n hacia los objetivos cuando alguien se desv\u00ede innecesariamente. Un orden del d\u00eda puede ayudar mucho a concentrarnos en los puntos a tratar.

Las curiosidades<\/strong><\/p>\n

A menudo se pierde mucho tiempo valioso contando las curiosidades, las excepciones de la l\u00f3gica de negocio. Lo anecd\u00f3tico, lo que nunca pasa pero una vez pas\u00f3 en el 2003, no suele ser importante. Es preferible invertir tiempo en contar los problemas que con m\u00e1s probabilidad va a tener que resolver la soluci\u00f3n de BI. No significa que lo espec\u00edfico no tenga que ser tenido nunca en cuenta, pero se debe resolver cuando nos hayamos asegurado de que el sistema aporta resultados a nuestros problemas m\u00e1s habituales. La regla debe ser: contar las cosas de las m\u00e1s habituales a las m\u00e1s espec\u00edficas, hasta donde el contrato permita (recordad el segundo de los consejos).<\/p>\n

Sesi\u00f3n continua<\/strong><\/p>\n

El analista no puede asistir a una reuni\u00f3n de requisitos sin haber consolidado lo hablado en la anterior. Se debe buscar una correcta alternancia entre las horas de la propia sesi\u00f3n (m\u00e1s de 4 horas no suelen ser productivas) y el trabajo de oficina donde pongamos en orden las notas, las transformemos en conceptos (entidades, caracter\u00edsticas, procesos) y los documentemos. Esta documentaci\u00f3n inicial tiene que sentar las bases sobre las que hablar en las siguientes sesiones.<\/p>\n

El tel\u00e9fono roto<\/strong><\/p>\n

Es un grave error dar por hecho que todo lo que se ha hablado en una reuni\u00f3n ha sido bien expresado por el usuario y ha sido bien comprendido por el analista. La \u00fanica forma de verificar esto por ambas partes son los documentos, la palabra escrita. Aunque sea una labor pesada, es muy importante que los usuarios lean los resultados de las sesiones anteriores plasmadas en un documento, una especie de acta, para verificar que ambas partes entienden lo mismo.<\/p>\n

Lo entender\u00e9 cuando vea la aplicaci\u00f3n<\/strong><\/p>\n

Uno de los mayores errores que se puede cometer en un proyecto es obviar el an\u00e1lisis y solicitar los cambios cuando la aplicaci\u00f3n est\u00e1 en construcci\u00f3n. El documento de an\u00e1lisis debe tener un car\u00e1cter contractual y es antes de la firma de este documento cuando se deben solicitar todos los cambios y resolver todas las posibles indefiniciones. Sobre el papel es m\u00e1s f\u00e1cil cambiar el dise\u00f1o o la l\u00f3gica de una aplicaci\u00f3n BI, sobre un proyecto empezado no es tan sencillo. Aunque a veces resulte una medida severa, no se deber\u00eda empezar un desarrollo hasta que el an\u00e1lisis est\u00e9 aprobado por todas las partes.<\/p>\n

Quiero hacer un cambio\u2026es que en el an\u00e1lisis no me di cuenta<\/strong><\/p>\n

Los cambios se deben minimizar una vez haya comenzado la construcci\u00f3n del sistema BI. Cada cambio con el proyecto en construcci\u00f3n es una incertidumbre a\u00f1adida y tiende a desequilibrar el dise\u00f1o global establecido. Los cambios en fases tard\u00edas tienden a acabar siendo parches sobre el dise\u00f1o original.<\/p>\n

Recordad que la inversi\u00f3n en la fase de an\u00e1lisis tiene que dar como resultado un documento que especifique de forma clara, concisa y sin ambig\u00fcedades el futuro proyecto, para que usuarios y equipo de desarrollo entiendan lo mismo y sean capaces de hablar en los mismos t\u00e9rminos.<\/p>\n\n

Art\u00edculo redactado por Pablo Gallardo<\/p>\n","protected":false},"excerpt":{"rendered":"

\u00bfA alguien se le ocurre no mirar el plano de una vivienda antes de que comiencen a construirla? \u00bfUn ingeniero de caminos aceptar\u00eda el cambio de un puente, cuando ya est\u00e1n terminando las obras? Si tienes claro que la respuesta es no, es hora de plantearse por qu\u00e9 esto s\u00ed ocurre a menudo con los […]<\/p>\n","protected":false},"author":92,"featured_media":8342,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"om_disable_all_campaigns":false,"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[396],"tags":[52,13],"class_list":{"0":"post-1","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-iot-data-ai","8":"tag-analitica","9":"tag-business-intelligence","10":"entry"},"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.integratecnologia.es\/la-innovacion-necesaria\/wp-json\/wp\/v2\/posts\/1","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.integratecnologia.es\/la-innovacion-necesaria\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.integratecnologia.es\/la-innovacion-necesaria\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.integratecnologia.es\/la-innovacion-necesaria\/wp-json\/wp\/v2\/users\/92"}],"replies":[{"embeddable":true,"href":"https:\/\/www.integratecnologia.es\/la-innovacion-necesaria\/wp-json\/wp\/v2\/comments?post=1"}],"version-history":[{"count":0,"href":"https:\/\/www.integratecnologia.es\/la-innovacion-necesaria\/wp-json\/wp\/v2\/posts\/1\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.integratecnologia.es\/la-innovacion-necesaria\/wp-json\/wp\/v2\/media\/8342"}],"wp:attachment":[{"href":"https:\/\/www.integratecnologia.es\/la-innovacion-necesaria\/wp-json\/wp\/v2\/media?parent=1"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.integratecnologia.es\/la-innovacion-necesaria\/wp-json\/wp\/v2\/categories?post=1"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.integratecnologia.es\/la-innovacion-necesaria\/wp-json\/wp\/v2\/tags?post=1"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}