Descarga la entrevista en audio
1. Identificación del problema
1.1 ¿Cuáles son los principales problemas que posee el proceso y de dónde provienen dichos problemas.
Primero, yo diría, desde la perspectiva del ingeniero que toma los requerimientos puede haber una desconocimiento del proceso de negocio que está analizando. Entonces recomiendo en ese caso que, previo a una toma de requerimientos, el ingeniero encargado analice el problema, el proceso de negocio y después vaya a hablar con los usuarios habiendo interiorizado las cosas.
En segundo lugar, tiene que investigar respecto de las dificultades que hay en el proceso de negocio, no necesariamente con los usuarios, tiene que ver el mercado, tiene que ver en la misma empresa, hablando con otras personas cómo ven ellos el proceso de negocios. Una vez que ya se tiene claro el proceso de negocio, desde la perspectiva del ingeniero que va a levantar requerimientos, recién en ese momento tiene que establecer la relación con el usuario a quien va a pedir su requerimiento.
Ahí hay otra situación, que es, por un lado, la disponibilidad del usuario. Es común que uno de repente le dice al usuario: “oye, mira, juntémonos mañana para analizar este tema” y que es lo que ocurre, el usuario dice: “ya, perfecto, a las once y media, doce de la mañana” y se pierde un día completo, a veces, donde no se pudo entrevistar a un usuario. Entonces, la toma de requerimientos que uno había pensado que iba a durar dos días, tres días, una semana, a veces puede pasar mucho tiempo para poder concretarla.
Otra situación que se produce, otra situación problema, es el conocimiento del usuario. De repente uno espera o supone que el usuario conozca muy bien su proceso de negocio y en la práctica no siempre es así. A veces los usuarios no conocen su proceso de negocio. Te voy a comentar un caso real que me pasó a mi con un usuario de manejo de costos, donde yo le decía: “a ver, ¿cómo manejas tú los costos?” – “ee, mira, de esta forma”- “¿qué variables vamos a costear?” – “en realidad ahí no está clara la cosa todavía”. Qué es lo que pasa, que no se pudo lograr con ese usuario cuales eran las variables de costos que había que considerar. ¿Por qué?, porque hay usuarios que son muy reacios o le tienen miedo a la toma de decisiones, porque en la toma de requerimientos una de las cosas que son fuertes son las decisiones, por que cuando yo estoy planteando requerimientos, estoy decidiendo. Imagínate que yo fuera el director del departamento y me dijeran: “oye, vamos a hacer un sistema de atención de alumnos, ¿cuales son sus requerimientos?” entonces yo diría “aa, pucha, es que a lo mejor, si yo planteo requerimientos, quizás no tengo claro el problema, a lo mejor estoy pidiendo algo que puede ser difícil, etc”. Por lo tanto me cuesta tomar decisiones: “¿y que pasa si meto las patas?, si pido esta cuestión y no sirve”, entonces hay mucho usuarios que tienen miedo a hacer requerimientos. Entonces es difícil extraer requerimientos.
En resumen yo diría que el tema fuerte aquí es, por el lado del ingeniero, tener claro el problema, por el lado del usuario, tener claro también su negocio y tener la capacidad de decisión. No saco nada con entrevistar a un bodeguero, lo importante es entrevistar a un jefe de bodega o entrevistar a las personas claves.
- ¿Cree que una adecuada planificación ayuda a la toma de requerimientos?
¿Planificación de qué?
- Para hacer las preguntas, las encuestas por parte del ingeniero.
Si, yo diría más que una adecuada planificación, una adecuada preparación. Imagínate que si me voy a una compañía de seguros y me dicen: “oye, necesitamos hacer un sistema para manejo de pólizas de vivienda”, entonces me tengo que interiorizar de lo que dice la ley, que dicen las normativas de superintendencia de seguros, averiguar el mercado de cómo operan las compañías de seguros, ver como son las pólizas, ponerme en distintos escenarios y recién en ese momento ir a hablar con el usuario. Entonces yo diría más que una planificación, una preparación. Ahora, durante la entrevista en sí, están las herramientas que se aplican, qué instrumentos aplico. Yo me acuerdo que, cuando estudié estos temas, siempre me decían: “mire, usted tiene que preparar una encuesta, con preguntas claras, etc.”. Mira en la practica uno pone grandes lineamientos, pero en la practica ocurre que durante la conversación, van derivando cosas, es decir, uno no puede llegar con cien preguntas, de repente una pura pregunta puede significar dos horas de conversación, porque la pregunta te va llevando a otras cosas. Yo diría que es importante ahí tener una visión estructurada del problema. Si voy a estudiar el caso de las pólizas, yo no saco nada con decir: “oye, ¿ustedes incorporan datos de los vehículos?” y después: “oye, y para los vehículos ¿ustedes utilizan también el color del vehículo como una variable importante para asegurar el vehículo?”. Son preguntas muy puntuales. Entonces uno va estructuradamente, es decir, primero uno pregunta cual es tu negocio, cuales son tus procesos principales, quien hace la generación de pólizas y ese caballero por qué actúa de esa forma, qué tipos de pólizas existen y por qué se hace esta cosa, pero no entrar en cosas muy puntuales. Tú te pierdes en lo básico y te olvidas de lo medular.
Lo otro que yo recomiendo es, en la medida que uno está entrevistando al usuario, ir mentalmente estructurando casos de uso, ir mentalmente estructurando un modelo de procesos, ir mentalmente estructurando un modelo de datos. Ahora, si puede ir recogiéndolo en papel, mucho mejor. Lo ideal, pero es bien ideal, es, terminada una entrevista con un usuario, uno tiene dibujado un caso de uso. Ojo, un diagrama de caso de uso. Y si fuera posible, diagramado unos procesos de negocios y también, más ideal todavía, tener una lista de las identidades principales. Terminar un prototipo. Para la próxima reunión, llegar con cosas mucho mas finas y así entonces voy de a poco acercándome al detalle del problema.
Otra herramienta que yo he aplicado en la práctica, es, como me he interiorizado en el problema, uno adelanta requisitos. Por ejemplo, en el caso de la póliza uno pregunta: “esto va a ser Web o no Web”, entonces: “¿sabe?, yo recomiendo que sea Web”, “señor usuario, ¿qué le parece a usted también que generemos informes de pólizas caducas o de siniestros del último período?”, entonces el usuario dice: “aa ya, bueno”. Así uno va llegando a un nivel de detalle súper fino. También hay que tener presente para los requerimientos, ¿cual es la cantidad de requisitos? No hay un número de requisitos, entonces yo puedo enumerar requisitos generales del sistema y después entrar a detallar. A un nivel detalle alto, la cantidad de requisitos podría superar los mil, es decir, preguntar cual es al cantidad de requisitos adecuada para un sistema, yo te podría decir: miles. Lo que si, puedo agrupar requisitos, pero la cantidad es grande. ¿Por qué necesito hartos requisitos?, porque cuando vaya a probar el sistema, tengo que probarlo en base a los requisitos.
2. Definición de actores sociales
2.1 ¿Cuáles son los actores (personas/unidad) fundamentales en el funcionamiento del proceso de captura de requerimientos?
Como decía, el ingeniero o analista o diseñador, que es el que va a tomar los requerimientos, el usuario, y dentro del usuario hay varios tipos de usuario. Usando la terminología que se usa en SAP, primero está el Key User, el usuario clave, que es el usuario responsable de los requisitos, que es el que define los requisitos y es el que firma la lista de requisitos y es el que puede tomar decisiones en un momento determinado. Y están los otros usuarios que hacen uso, directa o indirectamente, del sistema. Por eso que te decía que es bueno tener un diagrama de casos de uso decir: este es el sistema y estos son los usuarios del sistema. Entonces yo debería entrevistarlos a todos pero el Key User es el más importante. Ahora, el tema está en detectar quienes son realmente esos usuarios, porque a veces, pasa en la realidad, los verdaderos usuarios están medios ocultos o los que conocen el tema. A veces uno va a la estructura organizacional de la empresa y dice: “este sistema apoya a esta función” y luego identifica que esta función está soportada por estos procesos que están aquí, por estas unidades y estas personas, y así uno se enfoca en esas personas y resulta que en la oficina del lado esta la persona que mas sabe del tema. Entonces uno tiene que tener la capacidad de ver quien realmente le aporta información.
2.2 ¿Quién o Quiénes regulan el proceso de captura de requerimientos y su actividad?
Primero, está el ingeniero capturador. Él se deja llevar a veces por sus ideas, su conocimiento, etc. y es difícil que el diga que están bien los requerimientos. Entonces tiene que haber un jefe de proyecto que debiera tomar la lista de requerimientos y validarla y hacer todas las verificaciones. En la práctica yo no he visto una separación entre un jefe de proyectos, un tomador de requerimientos y un diseñador. Normalmente en las tomas de requerimientos está el jefe de proyectos acompañado de dos analistas, entonces la toma se hace en conjunto. De hecho, te voy a contar una experiencia que me pasó a mi, una práctica que hice en la toma de requerimientos. Una vez estudié el problema completo, después me junté con los técnicos informáticos y les dije: “este es el problema, ¿que les parece?, ¿es así?”, entonces yo les expliqué la metodología. Les dije que vamos a ir donde el usuario y les vamos a explicar esto. Entonces, como que nos adelantamos a los requerimientos. Nosotros ya sabíamos del negocio y cuales eran los requerimientos, por lo tanto la presentación ante el usuario no fue como “oye, explícame el proceso de negocio y dime lo que quieres”, no. Yo lo que hice fue preparar un power point con el modelo de procesos de negocio e inclusive una interfaz gráfica de como sería un sistema de apoyo al usuario, y una lista de requisitos previos y casos de uso. Entonces, cuando partió la reunión con el usuario, yo le dije: “mire señor usuario, nosotros estamos viendo un sistema para usted”, obviamente ya habíamos hablado con usuarios en pasillo pero no habíamos entrado a estudiar requerimientos y dije: “así estamos viendo el tema”, y le mostré el caso de uso. Ahi le mostré donde esta él y que cosas puede hacer. Entonces el usuario inmediatamente dice:” mira, me parece bien, pero yo no hago eso, eso lo hace otra persona” – “a, perfecto” – “y me gustaría poder hacer esto otro” – “ok, se anota” y en la misma reunión se va corrigiendo el caso de uso, ¿te fijas?. Entonces, terminada la reunión, ya yo tengo un caso de uso detallado y bien afinado; y tengo un modelo de datos aproximado. En las primeras reuniones ya tienes bastante avanzado.
3. Rich Picture
3.1 ¿Cree que el proceso es burocrático o expedito?
No es burocrático. Burocrático sería un proceso donde se le diga al usuario que se van a tomar los requerimientos y de acuerdo a la metodología usted tiene que llenar esta planilla y después de llenarla hay que ir a entrevistar y después de la entrevista vamos a hacer tal y tal cosa y después va a ser iterativo esto, etc. Yo creo que ahí podría ser burocrático. Para mí el proceso de toma de requisitos no es burocrático. Yo lo miraba burocrático al principio, pero hoy en dia me he dado cuenta que es súper importante no hacer burocrático el proceso, porque es un proceso casi de aprendizaje.
3.2 ¿Cómo es la relación entre las personas con las que usted tiene comunicación directa en el trabajo?
Yo he estado con un jefe y como jefe, por lo tanto es clave la comunicación y el conocimiento aplicado. En otras palabras , si estoy metido en un proyecto y mi jefe no tiene idea de como se hace el proyecto o no me está guiando respecto del proyecto, obviamente que no va a haber espíritu de cuerpo dentro del equipo y la cuestión no va a funcionar bien.
3.4 ¿Existen problemas que tengan que ver con contradicciones, poca claridad en los requerimientos o desconocimiento de los mismos?
Eso es muy común. Por ejemplo, en un caso de un sistema de costos, el usuario dice: “mira aquí manejamos todos los costos de producción y nos interesan todos los costos.”, entonces yo hago un modelo previo para discutir como se manejan los costos y digo yo: “a ver, las maquinas van a usar electricidad, van a usar vapor, petróleo, se va a usar mano de obra, etc” y digo que esos serán todos los costos involucrados. Entonces voy donde otro usuario que es gerente y me dice:”no, olvídate de la mano de obra. Eso es gasto” y me da todas las explicaciones razonables y al final esta ok. Voy donde el otro usuario y empiezan las discusiones y dificultades de que uno tiene que ser de mediador. Hay situaciones complicadas, hay un usuario A que es gerente y el usuario B es el que mete las manos todos los días y es el que sabe realmente. Es el que conoce lo problemas que hay, entonces uno tiene que ser tan sutil que debe decirle al gerente: “lo que pasa es que en la practica esto funciona así”. Es complicada esa situación, de equilibrar distintas visiones de un mismo problema. Entonces un requisito partió de una forma A y terminó de una forma B.
4. Sistemas sociales y políticos
4.2 ¿Qué es lo que debe resaltarse positivamente del servicio que usted entrega?
Primero, el tener experiencia de cómo relacionarse con los usuarios. Yo he leído harto respecto de eso y lo he encontrado burocrático. Lo que he leído lo he encontrado burocrático. “Mire, usted, cuando atienda a un usuario haga una lista de requisitos y atiéndalos de esta manera y no mas de dos horas y las preguntas tienen que ser de este estilo”. Disculpa lo que voy a decir, pero... las pinzas. La cosa en la práctica, y a mi me resulta, es totalmente diferente. En la práctica uno tiene que entrar en un dialogo normal con los usuarios de igual a igual. Si tu eres el encargado de algún proceso, si tú eres contador de la empresa y yo soy el analista informático, ahora tengo que ser contador y empiezo a hablar de igual a igual contigo, como contador y en los mismos lenguajes tuyos. Entonces yo te digo que un factor crítico es que uno tiene que conocer de los procesos del negocio, que es lo que te dije al principio de la entrevista.
4.3 ¿Se rige su trabajo particular por algún reglamento externo o interno?, ¿Cuál es ese reglamento y dónde se encuentra?
No existen reglamentos en informática. Lo que si existen son normas o estándar de trabajo. Yo nunca he visto en una empresa “reglamento”. He visto la norma ISO, que se aplica en algunos lados, que te dice que formulario se aplica en una entrevista, las minutas de reuniones son asi, aqui debe firmar el usuario, etc.
5. CATWOE, HAS
5.1 ¿Cuáles serían las mejoras que realizaría para mejorar el funcionamiento del proceso? y ¿Por qué éstas no se han realizado?
Educar a los informáticos en los procesos de negocio. Es decir., no saco nada con tener muchas técnicas, muchas herramientas, muchas metodologías, muchas normas estándar, etc., si el caballero que tomará los requerimientos no tiene idea de lo que es contabilidad, lo que es producción, lo que es el área comercial. Para mí, los procesos de negocio son importantes.
- O sea que todo va por parte de los tomadores de requerimientos.
Claro, porque al usuario no lo vas a cambiar. Ahora, los usuarios han ido cambiando en el tiempo. Se han ido acercando a la informática, se han ido adecuando a las metodologías, etc., pero es el informático es el que tiene que adecuarse.
5.2 ¿Quién o quienes poseen la atribución de modificar la operatividad del proceso de captura de requerimientos si lo desean?
Cuando se utiliza una metodología, con las normas que se aplican y los documentos que se utilizan, los instrumentos que se utilizan son siempre cuestionables. Yo no puedo cerrar los ojos y decir: “esta es la norma de la empresa” y por lo tanto la aplico a toda costa. Yo tengo que estar constantemente cuestionando la metodología. Yo soy partidario de mirar la metodología, aplicarla y en el camino ir adaptándola, siempre, siempre. Yo no puedo usar la misma metodología, no puedo usar las mismas técnicas de entrevista o de captura de requerimientos ante situaciones distintas, escenarios distintos. Ahora, las normas de la empresa dirán: “ojo, usted tiene que terminar la reunión, hacer una minuta y dejarla en el directorio tanto el proyecto”. Bueno, eso tengo que cumplirlo igual, pero a lo mejor, la minuta tiene un nombre, se llama proyecto-minuta-003. Yo podría decir:”cambiemos la denominación de minutas”, porque en realidad no sirve para nada esa denominación, es mas como esto otro, o en el formato de la minuta aparece, a veces, información que es irrelevante: “cambiemos ese formato”. Entonces, es todo cambiable en el tiempo. Insisto, esa es la calidad. La calidad se ve como si fuera contínua. La calidad se definió y quedó para siempre ahí. Yo tengo que estar permanentemente analizando.
