Iniciamos la serie que prometimos. Y empezamos por el principio... (aunque esto parezca obvio, seguramente, muchos profesionales del sector de las Tecnologías acaban de perfilar una sonrisa en su cara).
El primer paso es Especificar. La idea es tan tonta que parece que nadie en su sano juicio podría obviarla; pero puedo asegurar que la mayoría de los problemas (en cuanto a plazos, calidad de desarrollo, adecuación a las necesidades del cliente, etc...) se solucionarían si en los proyectos de desarrollo software existieran especificaciones. Si fueran detalladas y completas habría fiesta...
El proceso de construcción de una aplicación de negocio suele ser comparado (lo que denominamos metáfora) con el proceso de construcción (genérico, el que nos permite hacer una casa). Sus similitudes son muchas y, como la mayoría de las personas tiene una idea (aunque sea general) sobre cómo construir una casa, nos ayuda a explicar lo que denominamos ciclo de vida del desarrollo.
Las personas tenemos la necesidad de disponer de una vivienda; algunos van a vivir solos o en pareja y no prevén aumentar sus miembros. Otros, en cambio, son varios miembros de la unidad familiar. Unos tienen una importante capacidad económica mientras que otros disponen de pocos recursos. En cada caso existen unas necesidades determinadas que pueden cubrirse con unos medios concretos. Siempre puede existir el caso de una pareja que adquiera una vivienda de varios cientos de metros cuadrados con muchas habitaciones y sus asociados cuartos de baño; salvo en el caso de que tengan previsto la visita continuada de otras personas, nadie entendería esa adquisición como adecuada a sus necesidades. Las empresas pueden equiparse con estos grupos humanos buscando una vivienda; cada organización tiene sus necesidades y unos medios concretos para cubrirlas. Lo normal es adecuar las necesidades a la solución elegida teniendo los costes como limitación.
Nadie en su sano juicio permitiría que su familia viviera en una vivienda que se haya realizado sin planos; ni estaría contento con disponer de un piso en un edificio de varias plantas cuando necesita criar gallinas… Es decir, lo normal es especificar las necesidades que se tienen y resolverlas adecuadamente bajo las limitaciones que se definan. En la construcción de viviendas se parte desde unos planos generales (que definen la estructura de la vivienda) hasta terminar el planos detallados que especifican por dónde se realizan las canalizaciones de agua o electricidad. Cuando queremos comprar una vivienda no tenemos que entender los planos detallados y nos vale con ajustar nuestras necesidades (normalmente número de habitaciones necesarias, altura del inmueble, gustos varios y, sobre todo, coste) a la información suministrada por el vendedor con un lenguaje entendible.
En el sector del desarrollo de aplicaciones nos encontramos normalmente con que las especificaciones (los requisitos del usuario) suelen ser documentos vacios sin ninguna o escasa concreción; a partir de estos documentos (si existen) generales difícilmente se puede continuar definiendo el detalle (los planos de canalizaciones de agua, por ejemplo). La consecuencia es que se pierde un alto porcentaje del tiempo en “marear la perdiz” hasta que un programador empieza a tomar decisiones de negocio que le llevan a “quitarse el muerto de encima”. Luego ya le venderemos al cliente que eso es lo que él necesita...
Entonces empecemos por hacer las cosas bien: especifiquemos los requisitos del usuario. Las ventajas son obvias: aclararemos dudas en papel (suele ser más barato que sobre código de ordenador) y sobre todo, sabremos lo que queremos y podremos exigirlo al final del proceso de construcción. Además, dentro de las buenas prácticas en el desarrollo de software existen multitud de estándares de documentos (los más genéricos son las normas IEEE) que nos permiten disponer de una plantilla de documento de requisitos con aclaraciones sobre su contenido.
Si eres una empresa que necesita una aplicación de negocio para optimizar sus procesos y no eres capaz de plasmar en un documentos tus requisitos, tienes un problema; posiblemente que no sepas lo que quieres. Incluso que no necesitas nada o que no necesitas lo que crees. Si no te ves con fuerzas para documentarlo, solicita la ayuda de un profesional (los denominamos consultores de negocio) que tenga tanto la visión de tu negocio (podrá hablar contigo en tu “dialecto”) como los conocimientos técnicos necesarios para plasmarlo en un documento (en el dialecto de los técnicos de desarrollo).
Si eres un desarrollador de software que tiene en sus manos un proyecto que no dispone de especificaciones (suele notarse por las muchas horas que pasas en la oficina sin saber qué hacer y por las preguntas del tipo ¿cómo vas? que te hace tu responsable) tienes un problema. La próxima vez, antes de empezarlo, di que no; estarás comportándote como un profesional.
Entonces empecemos por hacer las cosas bien: especifiquemos los requisitos del usuario. Las ventajas son obvias: aclararemos dudas en papel (suele ser más barato que sobre código de ordenador) y sobre todo, sabremos lo que queremos y podremos exigirlo al final del proceso de construcción. Además, dentro de las buenas prácticas en el desarrollo de software existen multitud de estándares de documentos (los más genéricos son las normas IEEE) que nos permiten disponer de una plantilla de documento de requisitos con aclaraciones sobre su contenido.
Si eres una empresa que necesita una aplicación de negocio para optimizar sus procesos y no eres capaz de plasmar en un documentos tus requisitos, tienes un problema; posiblemente que no sepas lo que quieres. Incluso que no necesitas nada o que no necesitas lo que crees. Si no te ves con fuerzas para documentarlo, solicita la ayuda de un profesional (los denominamos consultores de negocio) que tenga tanto la visión de tu negocio (podrá hablar contigo en tu “dialecto”) como los conocimientos técnicos necesarios para plasmarlo en un documento (en el dialecto de los técnicos de desarrollo).
Si eres un desarrollador de software que tiene en sus manos un proyecto que no dispone de especificaciones (suele notarse por las muchas horas que pasas en la oficina sin saber qué hacer y por las preguntas del tipo ¿cómo vas? que te hace tu responsable) tienes un problema. La próxima vez, antes de empezarlo, di que no; estarás comportándote como un profesional.
No hay comentarios:
Publicar un comentario