Entrevista al Ingeniero Edgardo Seplveda

1. Identificacin del problema

1.1 Cules son los principales problemas que posee el proceso y de dnde
provienen dichos problemas.
Primero, yo dira, desde la perspectiva del ingeniero que toma los requerimientos puede
haber un 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 despus 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 cmo ven ellos el
proceso de negocios. na vez que ya se tiene claro el proceso de negocio, desde la
perspectiva del ingeniero que va a levantar requerimientos, recin en ese momento
tiene que establecer la relacin con el usuario a quien va a pedir su requerimiento.
!h hay otra situacin, que es, por un lado, la disponibilidad del usuario. Es com"n que
uno de repente le dice al usuario# $oye, mira, %untmonos 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 da completo, a veces, donde no se pudo entrevistar a un
usuario. Entonces, la toma de requerimientos que uno haba pensado que iba a durar
dos das, tres das, una semana, a veces puede pasar mucho tiempo para poder
concretarla.
(tra situacin que se produce, otra situacin problema, es el conocimiento del usuario.
)e repente uno espera o supone que el usuario conozca muy bien su proceso de
negocio y en la prctica no siempre es as. ! veces los usuarios no conocen su proceso
de negocio. *e voy a comentar un caso real que me pas a mi con un usuario de
mane%o de costos, donde yo le deca# $a ver, +cmo mane%as t" los costos,' - $ee, mira,
de esta forma'. $+qu variables vamos a costear,' - $en realidad ah no est clara la
cosa todava'. /u es lo que pasa, que no se pudo lograr con ese usuario cuales eran
las variables de costos que haba 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. 0magnate que yo fuera el director
del departamento y me di%eran# $oye, vamos a hacer un sistema de atencin de
alumnos, +cuales son sus requerimientos,' entonces yo dira $aa, pucha, es que a lo
me%or, si yo planteo requerimientos, quizs no tengo claro el problema, a lo me%or estoy
pidiendo algo que puede ser difcil, etc'. Por lo tanto me cuesta tomar decisiones# $+y
que pasa si meto las patas,, si pido esta cuestin y no sirve', entonces hay mucho
usuarios que tienen miedo a hacer requerimientos. Entonces es difcil e1traer
requerimientos.
En resumen yo dira que el tema fuerte aqu es, por el lado del ingeniero, tener claro el
problema, por el lado del usuario, tener claro tambin su negocio y tener la capacidad
de decisin. 2o saco nada con entrevistar a un bodeguero, lo importante es entrevistar
a un %efe de bodega o entrevistar a las personas claves.
. +3ree que una adecuada planificacin ayuda a la toma de requerimientos,
+Planificacin de qu,
. Para hacer las preguntas, las encuestas por parte del ingeniero.
4i, yo dira ms que una adecuada planificacin, una adecuada preparacin. 0magnate
que si me voy a una compa&a de seguros y me dicen# $oye, necesitamos hacer un
sistema para mane%o de plizas 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 cmo operan las compa&as de seguros, ver como son las plizas,
ponerme en distintos escenarios y recin en ese momento ir a hablar con el usuario.
Entonces yo dira ms que una planificacin, una preparacin. !hora, durante la
entrevista en s, estn las herramientas que se aplican, qu instrumentos aplico. 5o me
acuerdo que, cuando estudi estos temas, siempre me decan# $mire, usted tiene que
preparar una encuesta, con preguntas claras, etc.'. 6ira en la practica uno pone
grandes lineamientos, pero en la practica ocurre que durante la conversacin, van
derivando cosas, es decir, uno no puede llegar con cien preguntas, de repente una pura
pregunta puede significar dos horas de conversacin, porque la pregunta te va llevando
a otras cosas. 5o dira que es importante ah tener una visin estructurada del
problema. 4i voy a estudiar el caso de las plizas, yo no saco nada con decir# $oye,
+ustedes incorporan datos de los vehculos,' y despus# $oye, y para los vehculos
+ustedes utilizan tambin el color del vehculo como una variable importante para
asegurar el vehculo,'. 4on preguntas muy puntuales. Entonces uno va
estructuradamente, es decir, primero uno pregunta cual es tu negocio, cuales son tus
procesos principales, quien hace la generacin de plizas y ese caballero por qu act"a
de esa forma, qu tipos de plizas e1isten y por qu se hace esta cosa, pero no entrar
en cosas muy puntuales. *" te pierdes en lo bsico y te olvidas de lo medular.
7o 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. !hora, si puede ir
recogindolo en papel, mucho me%or. 7o ideal, pero es bien ideal, es, terminada una
entrevista con un usuario, uno tiene dibu%ado un caso de uso. (%o, un diagrama de caso
de uso. 5 si fuera posible, diagramado unos procesos de negocios y tambin, ms ideal
todava, tener una lista de las identidades principales. *erminar un prototipo. Para la
pr1ima reunin, llegar con cosas mucho mas finas y as entonces voy de a poco
acercndome al detalle del problema.
(tra herramienta que yo he aplicado en la prctica, es, como me he interiorizado en el
problema, uno adelanta requisitos. Por e%emplo, en el caso de la pliza uno pregunta#
$esto va a ser 8eb o no 8eb', entonces# $+sabe,, yo recomiendo que sea 8eb', $se&or
usuario, +qu le parece a usted tambin que generemos informes de plizas caducas o
de siniestros del "ltimo perodo,', entonces el usuario dice# $ah ya, bueno'. !s uno va
llegando a un nivel de detalle s"per fino. *ambin hay que tener presente para los
requerimientos, +cual es la cantidad de requisitos, 2o hay un n"mero de requisitos,
entonces yo puedo enumerar requisitos generales del sistema y despus entrar a
detallar. ! un nivel detalle alto, la cantidad de requisitos podra superar los mil, es decir,
preguntar cul es la cantidad de requisitos adecuada para un sistema, yo te podra
decir# miles. 7o 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. Definicin de actores sociales
2.1 Cules son los actores (personas/unidad) fundamentales en el
funcionamiento del proceso de captura de requerimientos
3omo deca, 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. sando la
terminologa que se usa en 4!P, 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. 5 estn los otros usuarios que hacen uso, directa o indirectamente, del
sistema. Por eso que te deca que es bueno tener un diagrama de casos de uso decir#
este es el sistema y estos son los usuarios del sistema. Entonces yo debera
entrevistarlos a todos pero el Key User es el ms importante. !hora, el tema est en
detectar quienes son realmente esos usuarios, porque a veces, pasa en la realidad, los
verdaderos usuarios estn medios ocultos o los que conocen el tema. ! veces uno va a
la estructura organizacional de la empresa y dice# $este sistema apoya a esta funcin' y
luego identifica que esta funcin est soportada por estos procesos que estn 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 informacin.
2.2 !ui"n o !ui"nes re#ulan el proceso de captura de requerimientos y su
actividad
Primero, est el ingeniero capturador. 9l se de%a llevar a veces por sus ideas, su
conocimiento, etc. y es difcil que el diga que estn bien los requerimientos. Entonces
tiene que haber un %efe de proyecto que debiera tomar la lista de requerimientos y
validarla y hacer todas las verificaciones. En la prctica yo no he visto una separacin
entre un %efe de proyectos, un tomador de requerimientos y un dise&ador. 2ormalmente
en las tomas de requerimientos est el %efe de proyectos acompa&ado de dos analistas,
entonces la toma se hace en con%unto. )e hecho, te voy a contar una e1periencia que
me pas a mi, una prctica que hice en la toma de requerimientos. na vez estudi el
problema completo, despus me %unt con los tcnicos informticos y les di%e# $este es
el problema, +que les parece,, +es as,', entonces yo les e1pliqu la metodologa. 7es
di%e que vamos a ir donde el usuario y les vamos a e1plicar esto. Entonces, como que
nos adelantamos a los requerimientos. 2osotros ya sabamos del negocio y cuales eran
los requerimientos, por lo tanto la presentacin ante el usuario no fue como $oye,
e1plcame el proceso de negocio y dime lo que quieres', no. 5o lo que hice fue preparar
un power point con el modelo de procesos de negocio e inclusive una interfaz grfica de
como sera un sistema de apoyo al usuario, y una lista de requisitos previos y casos de
uso. Entonces, cuando parti la reunin con el usuario, yo le di%e# $mire se&or usuario,
nosotros estamos viendo un sistema para usted', obviamente ya habamos hablado con
usuarios en pasillo pero no habamos entrado a estudiar requerimientos y di%e# $as
estamos viendo el tema', y le mostr el caso de uso. !h 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 gustara poder
hacer esto otro' - $o:, se anota' y en la misma reunin se va corrigiendo el caso de
uso, +te fi%as,. Entonces, terminada la reunin, ya yo tengo un caso de uso detallado y
bien afinado; y tengo un modelo de datos apro1imado. En las primeras reuniones ya
tienes bastante avanzado.
3. Rich Picture
$.1 Cree que el proceso es burocrtico o e%pedito
2o es burocrtico. <urocrtico sera un proceso donde se le diga al usuario que se van
a tomar los requerimientos y de acuerdo a la metodologa usted tiene que llenar esta
planilla y despus de llenarla hay que ir a entrevistar y despus de la entrevista vamos
a hacer tal y tal cosa y despus va a ser iterativo esto, etc. 5o creo que ah podra ser
burocrtico. Para m el proceso de toma de requisitos no es burocrtico. 5o lo miraba
burocrtico al principio, pero hoy en dia me he dado cuenta que es s"per importante no
hacer burocrtico el proceso, porque es un proceso casi de aprendiza%e.
$.2 Cmo es la relacin entre las personas con las que usted tiene
comunicacin directa en el traba&o
5o he estado con un %efe y como %efe, por lo tanto es clave la comunicacin y el
conocimiento aplicado. En otras palabras , si estoy metido en un proyecto y mi %efe no
tiene idea de como se hace el proyecto o no me est guiando respecto del proyecto,
obviamente que no va a haber espritu de cuerpo dentro del equipo y la cuestin no va
a funcionar bien.
$.' (%isten problemas que ten#an que ver con contradicciones) poca claridad en
los requerimientos o desconocimiento de los mismos
Eso es muy com"n. Por e%emplo, en un caso de un sistema de costos, el usuario dice#
$mira aqu mane%amos todos los costos de produccin y nos interesan todos los
costos.', entonces yo hago un modelo previo para discutir como se mane%an los costos
y digo yo# $a ver, las maquinas van a usar electricidad, van a usar vapor, petrleo, se va
a usar mano de obra, etc' y digo que esos sern todos los costos involucrados.
Entonces voy donde otro usuario que es gerente y me dice#'no, olvdate de la mano de
obra. Eso es gasto' y me da todas las e1plicaciones razonables y al final esta o:. =oy
donde el otro usuario y empiezan las discusiones y dificultades de que uno tiene que
ser de mediador. >ay situaciones complicadas, hay un usuario ! que es gerente y el
usuario < es el que mete las manos todos los das 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
situacin, de equilibrar distintas visiones de un mismo problema. Entonces un requisito
parti de una forma ! y termin de una forma <.
4. Sistemas sociales y polticos
'.2 !u" es lo que debe resaltarse positivamente del servicio que usted entre#a
Primero, el tener e1periencia de cmo relacionarse con los usuarios. 5o he ledo harto
respecto de eso y lo he encontrado burocrtico. 7o que he ledo lo he encontrado
burocrtico. $6ire, usted, cuando atienda a un usuario haga una lista de requisitos y
atindalos de esta manera y no mas de dos horas y las preguntas tienen que ser de
este estilo'. )isculpa lo que voy a decir, pero... las pinzas. 7a cosa en la prctica, y a mi
me resulta, es totalmente diferente. En la prctica uno tiene que entrar en un dialogo
normal con los usuarios de igual a igual. 4i tu eres el encargado de alg"n proceso, si t"
eres contador de la empresa y yo soy el analista informtico, ahora tengo que ser
contador y empiezo a hablar de igual a igual contigo, como contador y en los mismos
lengua%es tuyos. Entonces yo te digo que un factor crtico es que uno tiene que conocer
de los procesos del negocio, que es lo que te di%e al principio de la entrevista.
'.$ *e ri#e su traba&o particular por al#+n re#lamento e%terno o interno) Cul
es ese re#lamento y dnde se encuentra
2o e1isten reglamentos en informtica. 7o que si e1isten son normas o estndar de
traba%o. 5o nunca he visto en una empresa $reglamento'. >e visto la norma 04(, 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.
. !"#$%&' ("S
,.1 Cules ser-an las me&oras que reali.ar-a para me&orar el funcionamiento del
proceso y /or qu" "stas no se han reali.ado
Educar a los informticos en los procesos de negocio. Es decir., no saco nada con tener
muchas tcnicas, muchas herramientas, muchas metodologas, muchas normas
estndar, etc., si el caballero que tomar los requerimientos no tiene idea de lo que es
contabilidad, lo que es produccin, lo que es el rea comercial. Para m, los procesos
de negocio son importantes.
. ( sea que todo va por parte de los tomadores de requerimientos.
3laro, porque al usuario no lo vas a cambiar. !hora, los usuarios han ido cambiando en
el tiempo. 4e han ido acercando a la informtica, se han ido adecuando a las
metodologas, etc., pero es el informtico es el que tiene que adecuarse.
,.2 !ui"n o quienes poseen la atribucin de modificar la operatividad del
proceso de captura de requerimientos si lo desean
3uando se utiliza una metodologa, con las normas que se aplican y los documentos
que se utilizan, los instrumentos que se utilizan son siempre cuestionables. 5o no
puedo cerrar los o%os y decir# $esta es la norma de la empresa' y por lo tanto la aplico a
toda costa. 5o tengo que estar constantemente cuestionando la metodologa. 5o soy
partidario de mirar la metodologa, aplicarla y en el camino ir adaptndola, siempre,
siempre. 5o no puedo usar la misma metodologa, no puedo usar las mismas tcnicas
de entrevista o de captura de requerimientos ante situaciones distintas, escenarios
distintos. !hora, las normas de la empresa dirn# $o%o, usted tiene que terminar la
reunin, hacer una minuta y de%arla en el directorio tanto el proyecto'. <ueno, eso tengo
que cumplirlo igual, pero a lo me%or, la minuta tiene un nombre, se llama proyecto.
minuta.??@. 5o podra decir#'cambiemos la denominacin de minutas', porque en
realidad no sirve para nada esa denominacin, es mas como esto otro, o en el formato
de la minuta aparece, a veces, informacin que es irrelevante# $cambiemos ese
formato'. Entonces, es todo cambiable en el tiempo. 0nsisto, esa es la calidad. 7a
calidad se ve como si fuera continua. 7a calidad se defini y qued para siempre ah.
5o tengo que estar permanentemente analizando.