Entrevista a Edgardo Sepulveda

Edagardo Sepulveda es academico de la Universidad de Santiago de Chile y a desempeñado diversos roles en distintas empresas informaticas a lo largo de su carrera

¿Qué importancia le asigna usted a la forma en que se toman requerimientos?

en el desarrollo de proyectos informáticos no podría decir que hay una fase mas importante que otra, por ejemplo decir que la toma de requerimientos no es tan importante como el diseño, eso no es así, son todas etapas complementarias y que no pueden dejar de hacerse, siempre considerando que el nivel de profundidad al que puedo llegar dependerá del conocimiento que tenga del problema y de su envergadura, me explico, podría encontrarme ante un problema pequeño que no posea tantos requisitos y que ya domino, por lo tanto la toma de requisitos no es tan fundamental, por otro lado, existen situaciones muy complejas, por ejemplo transantiago, primero debemos interiorizarnos en este gran problema y afinar los requerimientos tomaría mucho tiempo, aquí la toma de requerimientos se hace fundamental, pero no disminuye la importancia de las otras fases.

Durante su experiencia ¿Que errores ha cometido durante la toma de requerimientos?

Buena pregunta, a veces uno subestima a los usuarios, uno cree que los usuario no saben del tema y saben, otro error que se comete es entrevistar a usuarios que no son los que toman realmente las decisiones o no saben realmente del tema, a veces el usuario que mas habla y que mas comenta en las reuniones y uno se reúne con el, pues piensa que es el que mas sabe, no es el que realmente entrega los requerimientos de mejor manera, quizás es el que mejor se “vende” pero no conoce tanto del tema.

Otra cosa que no se si es necesariamente una falla, pero a veces uno trata ante cualquier situación o sistema nuevo, asemejarlo a sistemas existente, esto esta mal, pues en el caso de los informáticos, los paradigmas son tan dinámicos que uno debe tener la capacidad de asumir nuevos escenarios, nuevas características.

A veces los artefactos que uno utiliza, como un modelo de datos o un diagrama de clases son muy técnicos, por ejemplo si le muestro a un usuario un diagrama de secuencia, que es muy “computin”, pues uno esta acostumbrado a hablar de los bits y los bytes y a lo mejor el usuario no entiende nada, la idea es acercarse mas al lenguaje del cliente y no producir esa barrera que se produce entre el usuario y el informático que va trabando la comunicación. Otro error que es muy común, que he tratado de evitarlo por las practicas que tengo en este tema es la documentación, es decir, he visto muchas veces que se va a entrevistas con los usuarios y no se documenta, me refiero a que durante las entrevistas se debe, anotar, anotar, anotar y anotar, terminada la entrevista realizar un resumen formalizado y consultar con el usuario de forma de crear un consenso, para no olvidar lo que se hablo y evitar que el producto final no sea lo que el usuario final esperaba.

Un error que cometo, o mas que un error, una característica no adecuada, es que soy, por llamarlo de una forma, muy “autista” para el desarrollo, me refiero a que voy a hablar con el usuario, recorro todas las vistas del negocio, pero no uso interlocutores para conversar las decisiones que tomo, esto podría significar una situación problemática, esto me pasa pues soy mas productivo trabajando solo que con un equipo de trabajo, pero esto es ya un problema de índole personal.

¿Qué recomendaciones daría a una persona que recién esta comenzando para tomar buenos requerimientos?

Primero, que no empiece sola, que parta con un equipo y ve como lo realiza el jefe de proyectos y su equipo, en primera instancia uno debe acompañar a los que saben del tema. Otra cosa que se podría recomendar es tener siempre una visión mental de lo que se quiere conseguir, por ejemplo, al realizar una entrevista pensar que espero de esa entrevista, plantearse ¿necesito la lista de requisitos? , no, primero debo establecer una comunicación con el cliente, hacerme “amigo” del usuario, dialogar cosas generales primero, para luego en una segunda o tercera entrevista, empezar a extraer los requisitos finamente, no deben esperar que en la primera reunión salga todo inmediatamente. Una recomendación general que le daría a todos los informáticos, es no pensar nunca en el programa computacional, en la plataforma, las comunicaciones, en la base de datos, piensen en los procesos de negocios, es lo primero que se debe captar, pues el usuario no habla en términos computacionales, como Web, cliente servidor, java, etc. El usuario habla de su proceso de negocio, donde el recibe los pedidos de los clientes, productos, servicios, etc. Y es eso lo que debo entender primero, luego recién puedo aterrizar eso, pero si parto pensando en la plataforma computacional, me olvido del problema real.

para descargar el audio de esta entrevista, presione el siguiente link: bajar entrevista