Agile: Definición del problema.
Antes de construir o tan siquiera escribir una sola línea de código debes estar bastante seguro de que problema buscas resolver. La definición de un problema representa un porcentaje alto del avance del requerimiento mismo. Esto es debido a que construir cualquier cosa que no resuelve tu problema es generar desperdicio y no avanzar. Es común, y pasa demasiado seguido, armas soluciones en tu cabeza luego de la primera reunión con el cliente, sin aterrizar la problemática en un documento o realizar un análisis de la cual es el problema. Justo en la definición del problema que armas en tu mente va la solución, como si una estuviera creada para vivir una con la otra, pero, ¿la solución es la óptima?, ¿cuál es la problemática de usuario?, tu solución es la mejor solución, ¿o solamente quieres que lo sea?. Dedica el tiempo suficiente a definir un problema, esto no es perdida de tiempo, cualquier error que cometas en la hoja de papel va a ser más barato que tirar lo que se construye a partir de una definición errónea. No hay una receta para escribir la definición perfecta, pero los siguientes consejos pueden ayudarte a redactar mejores definiciones del problema. Te los menciono:
Define el problema sin hacer referencia a la solución.
Este es un error muy común, y muy constante, yo llegue a cometerlo por años. Si defines un problema y luego propones la solución, no estás definiendo el problema, estás imponiendo tu solución por arriba de la propuesta de otros. Hay que redactar el problema y solo eso. Por ejemplo, si planteas la problemática como: Se necesita un nuevo sistema de seguimiento de tickets. Ese es el problema o tu solución, digamos que existe un sistema de seguimiento de tickets que tiene caídas, no se sabe el porqué. Bueno, tampoco importa encontrar el porqué, ya se emitió la solución. El problema de la caída del sistema de seguimiento de tickets puede deberse a la red, infraestructura o cualquier otro motivo que no necesariamente involucran codificación, pero desgraciadamente estos síntomas jamás serán objetos de estudio por la definición del problema que viene con una solución adjuntada. Una mejor definición del problema podría ser: El sistema de seguimiento de tickets sufre caídas constantes y no se sabe el motivo. No hay solución, solamente un problema a resolver.
La definición del problema debe de ser corta, pero no demasiado.
El problema que se busca resolver debe ser explicado de manera breve. No es necesario especificar todos y cada uno de los aspectos a detalle. Eso va en las historias de usuario, casos de uso, requerimiento o el documento que uses para ese propósito. Trata de que sea de una o máximo dos cuartillas.
El problema debe de estar escrito desde la perspectiva del usuario.
El problema debe estar presentado desde la perspectiva del usuario que operara la aplicación, este es un tema complicado porque no siempre vas a tener acceso a un usuario real del sistema. En caso de no tener contacto con el usuario, trata de buscar a la persona más empapada en la problemática. Es importante siempre buscar ponernos en los pies del usuario que operara la aplicación, ya que esto incrementa las posibilidades de ofrecer la solución correcta. No siempre el que paga por el sistema es el que opera el sistema, tenlo en cuenta.
El problema debe estar presentado en el lenguaje de usuario.
Nunca emplees tecnicismos o jerga técnica para definir el problema. Subir el nivel del lenguaje en la definición del problema puede llevar a ambigüedades o malos entendidos. Tu definición del problema va a pasar por muchas manos antes de ser aprobada, muchas de esas manos no van a ser de programadores. Las buenas definiciones de los problemas son como los chistes, los buenos no necesitan dar explicaciones. Si en un chiste tienes que dar una explicación de un concepto o idea antes o después de contarlo no es chistoso, así es igual con tus definiciones del problema, aplica el principio KISS.
El coste de definir un problema incorrectamente.
La etapa del diseño es crucial en tu proyecto, es el momento donde tus errores cuestan menos y puedes tirar trabajo a la basura. Tomate el tiempo necesario para definir tus problemáticas, si no estas seguro pregunta, si sientes que no posees la suficiente información detente y busca ayuda o comunica que se detuvo tu trabajo. Lo que no te recomiendo es construir a partir de definiciones de problema vagas, incompletas, deseos de los usuarios o problemáticas que vienen con una solución adjuntada.Todo eso, es un desperdicio de tiempo y puede lisiar al proyecto o dejarlo completamente inoperable. Siempre hay que buscar ofrecer el producto correcto y un buen producto.
Autor imagen: Stock Catalog
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20