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.
Los problemas básicos que tenemos nosotros son la comunicación. La comunicación de nosotros con el usuario. El hecho que nosotros tenemos, tal vez, un lenguaje mucho más técnico que el usuario, eso provoca que a veces el usuario no nos entienda y al revés, como usan un lenguaje demasiado “light”, nosotros también entendemos muy “light” el requerimiento.
Por otra parte, el tema de la documentación, cuando se hace la documentación y se le entrega al usuario, la verdad es que para ellos debe ser una lata revisar el documento completo y no lo hacen a conciencia. En general, el país tiene una mala comprensión lectora entonces eso perjudica también que el tema sea bien llevado.
1.2 ¿De qué forma afectan a usted y al proceso de captura de requerimientos dichos problemas?
Esto es como una bola de nieve. Tenemos un requerimiento que si quedo mal definido desde un inicio, va ir agrandándose, agrandándose, hasta llegar a la etapa de diseño que no queda bien definida tampoco y después al requerimiento que al final el usuario te va a decir: “esto no fue lo que te pedí”. Entonces es un efecto que si no queda bien definido en la primera etapa en detalle, entonces las consecuencias pueden ser bastante graves.
- ¿Usted participa en el proceso en que interactúan con el usuario o solamente en la primera etapa?
- ¿Durante el proceso de...?
- Durante el proceso de construcción
Hace poco se implementó una metodología. Lo que pasa es que en informática no hay muchas metodologías al respecto, son más bien artesanos al principio. Entonces en esta compañía hace menos de un año se comenzó a trabajar en serio. Antes se hacían cosas a pedido por correo. Tan informal como eso. Ahora ya existe una metodología para enfrentar el tema y se hace participar al usuario de todas las etapas del proyecto.
- ¿Existen, a veces, cambios en los requerimientos por parte del usuario durante el proceso de desarrollo?
Siempre, hasta en la etapa de prueba. ¿Y por qué sucede esto? Bueno, el usuario no tiene muy claro lo que quiere pedir. Segunda cosa, nosotros le entendemos una cosa y el a lo mejor quería decir otra y lo cambia. Después se da cuenta que... “ah no, no era eso. Mira mejor así”. O si no simplemente él ve el producto ya terminado y ya de ahí le empieza a picar el bichito de la ambición, entonces dice: “mm si, pero podríamos hacer esto además, agreguémosle esto otro...”, y así es un cuento de nunca acabar.
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?
Nosotros tenemos el área de tecnología, que esta dividida como desarrollo de software e infraestructura. Hay un área paralela a nosotros, que no pertenece al área de tecnología y que es de calidad. Entonces son esas tres unidades enfocadas a dar apoyo al desarrollo de software.
2.2 ¿Quién o Quiénes regulan el proceso de captura de requerimientos y su actividad?
El proceso, como te decía, esta normado por una metodología que se implementó hace menos de un año y que ahora esta en evolución. Entonces, hay un comité de arquitectura o de normativa. Ellos van evolucionando el versionamiento de la metodología. Pero, quien controla el cumplimiento de los plazos, tenemos algo que se puede llamar PMO. No sé si has escuchado ese concepto.
- No.
La PMO es Proyect Management Office. La PMO... son varios niveles de PMO, así como los de CMM. El objetivo de esto es controlar el avance de los proyectos y no sólo controlar, además se coordina y apoya e incentiva el desarrollo de nuevos proyectos. Nosotros estamos en el nivel más básico de la PMO que es sólo controlar plazos. Ellos nos controlan que cumplamos la carta Gantt, mandan un informe y esto es permanente, son todos los días. Una vez a la semana se lleva un informe en que dice en que estado está el proyecto, si se cumplió o no el plazo y si los documentos asociados están o no.
2.3 ¿Quién o Quienes son sus clientes?
Mi cliente es el área de marketing y el área de operaciones de la compañía. Lo que pasa es que en este minuto estamos desarrollando una Intranet. Un sitio colaborativo. Entonces, en este momento tengo a la gerencia de administración y finanzas; y marketing por el tema de la página Web.
3. Rich Picture
3.1 ¿Cree que el proceso es burocrático o expedito?
Yo creo que es burocrático para el cliente. Él tiene la sensación de que es burocrático. Hay pasos que nosotros, por ejemplo exigimos una solicitud de proyecto. Cuando él dice: “ah, pero yo puedo mandar un mail y decir quiero que en la página Web halla un botón tal”. Nosotros le exigimos una solicitud de proyecto. Lo obligamos a escribir eso. ¿Por qué?, porque en las organizaciones se tiende a tirar mail y mandar ideas y todos corren para ese objetivo y después ni siquiera se preguntan que beneficios le trae hacer ese desarrollo. Muchos desarrollos quedan a la mitad o se terminan y después no se usan.
- ¿Una especie de contrato con lo que fijan ustedes y el cliente?
Si, para decir “eso es lo que yo quiero”, y en ese contrato entre comillas, también tiene que decir: “mira, esto aportará tales beneficios a la compañía”. Porque si los beneficios no están claros ¿Tiene sentido hacer el proyecto?
- En caso de que esos beneficios no estén de acuerdo al proyecto que está pidiendo, ¿ustedes evalúan y dicen que no va a dar tales frutos?
Si. Se le cuestiona el tema a nivel de gerencia. Pero, si el tipo insiste en que si va a ganar 15 millones de pesos, entonces se le dice: ya ok, pero es su responsabilidad. Tú dijiste que al tanto tiempo iba a haber 15 millones de pesos. Nosotros vamos a hacerlo, pero ahí ves tú.
3.2 ¿Cómo es la relación entre las personas con las que usted tiene comunicación directa en el trabajo?
Es buena, pero hay varias patas, porque ahí uno tiene que tener varias habilidades interpersonales, de las que nosotros como informáticos, no estamos muy dados. Cuando uno sale de la universidad, uno tiene que aprender a adquirir el tema de la comunicación y ponerse en el lugar del otro, eso también nos cuesta mucho. Hay que hacerlo para entenderlo porque el otro no entiende nada de nuestro mundo, entonces hay que tratar de explicarle y tratar de entregarle la información lo más clara posible.
- Usted como jefe de proyecto, ¿cree que es una buena líder?
Hay distintos tipos de liderazgo. Hay distintos tipos, sobre todo acá en la compañía. Hay liderazgos que son así como duros, o sea, como patrón de fundo y hay un liderazgo con el que yo me inclino que es más consensuado. En realidad a mi me gusta que la gente trabaje conmigo mas por compromiso, por compartir objetivos, que por susto. Entonces, yo creo que si. A mi me gusta que trabajen de esa manera así.
3.3 ¿Realiza labores no asociadas con el trabajo propio del proceso de captura de requerimientos?
Algunas veces entregan tareas de investigación. Por ejemplo, el año pasado, a mi me tocó hacer una sobre PMO. Que sería como una labor extra. A otro este año le tocó ver el tema de arquitectura con el Proyect Server. Entonces, de repente te dan tareas anexas. Ahora, si complica la labor, cuando estas haciendo gestión, te complica por salirte de la asunto, porque pierdes el hilo muy fácilmente y no puedes coordinar a las demás personas.
3.4 ¿Existen problemas que tengan que ver con contradicciones, poca claridad en los requerimientos o desconocimiento de los mismos?
Siempre y sobretodo lo último. Poca claridad de lo que quiere el usuario y por otro lado también hay un factor súper importante que es cuando el proyecto abarca múltiples áreas, abarca múltiples usuarios. Ahí se designa un usuario líder, pero ese usuario líder tal vez no tiene el expertise, más que en su propia área, entonces ahí también hay un tema. Una cosa es el usuario líder, que coordina, pero no necesariamente es el experto del tema. Hay que indagar y asegurarse que el usuario líder se esta asesorando por los usuarios expertos para sacar los requerimientos.
- En caso que cambien los requerimientos durante el proceso de desarrollo, ¿como resuelven esos problemas?
Hay unos documentos que se llaman control de cambios. El usuario entrega el documento y se le tiene que decir que significa para el proyecto: el atraso por construcción, pruebas, etc. y eso aumenta las lucas.
- En caso que hay cambio en el diseño, han tenido que reinventar de nuevo el proceso o generan prototipos genéricos y luego los van adaptando. ¿Cual es la estrategia en ese caso?
Cuando tenemos un cambio de diseño, tratamos de chutearlo y decir versión 2.
4. Sistemas sociales y políticos
4.2 ¿Qué es lo que debe resaltarse positivamente del servicio que usted entrega?
Nosotros estamos orientándonos más al cliente, a conocer el proceso de negocio, porque eso es importante. Conocer el proceso de negocio, para nosotros no es sólo ser capturadores de requerimientos, además poder sugerir mejoras a los procesos que ellos están tratando solucionar. Porque algunas veces la problemática no va por lo que ellos están visualizando si no que con una solución mucho mas fácil y que nosotros técnicamente la podemos proveer de manera mucho mas rápida. Entonces, mas allá de listar las cosas, tenemos que empaparnos de la problemática del cliente para poder entregar una mejor solución.
4.3 ¿Se rige su trabajo particular por algún reglamento externo o interno?, ¿Cuál es ese reglamento y dónde se encuentra?
El reglamento que nosotros tenemos es una metodología. Esta metodología se basa en el desarrollo estándar de software, el de cascada, y una combinación de la PMO enlazado con una metodología de desarrollo de proyectos que se llama, que esta enlazada por el Proyect management institute, que es un ente que entrega una metodología para el desarrollo de proyectos, pero es muy genérica, que nosotros la hemos ido adaptando a nuestra realidad.
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?
¿Por que no se han realizado? Bueno, nosotros, en nuestro equipo de trabajo, se ha renovado últimamente y llevamos muy poco siendo más rigurosos dentro de la organización. Entonces nosotros en este minuto estamos creciendo en cuanto a metodologías, estándares desde el punto de vista de desarrollo de software, arquitectura de hardware, etc. Entonces, ¿cuales mejoras tenemos?, infinitas. Tenemos para crecer mucho. Imagínate que hoy establecimos un estándar para todos los proyectos que tiene tales etapas. Ahora estamos en una mejora de la metodología, donde se van a exigir otro tipo de documentos. Después de exigir los entregables, hay que meterse en el detalle de los documentos. ¿De verdad me sirve tener (te voy a inventar) separados los requerimientos en 1,2, 3 y una lista? A lo mejor hacer necesito hacer casos de uso, que no los tenemos. Y empezar a mejorar, digamos, la documentación y la forma de entrega al cliente.
-O sea que antes de toda esta etapa no se realizaba...
No, aunque te parezca increíble.
5.2 ¿Quién o quienes poseen la atribución de modificar la operatividad del proceso de captura de requerimientos si lo desean?
La compañía en general. Se esta tendiendo a que los jefes escuchen a sus subalternos. Entonces aquí lo que esta pasando es que tu detectas algún problema, lo llevas a tu jefe y de eso se presenta como una mejora. Acá son súper abiertos a las sugerencias. En tanto eso puede ir modificándose en el tiempo tantas veces como uno proponga una mejora. Pero esto, tú la propones y eso va a una mesa de arquitectura donde está el gerente... Lo analizan y ven si se hará o no y cuando.
- ¿Y usted puede modificar el proceso en caso de?
No. Yo soy parte del área de tecnología que tiene varios grupos, digamos de trabajo, y esos grupos son los que usan la metodología. Entonces no puedo yo llegar y tomarme esa atribución. La que tiene la atribución, digamos mas cercana a mi, seria el subgerente de tecnología. A todos los equipos de trabajo, tendría que entregarles esa modificación.
- Dentro del área que usted trabaja hay varios equipos de trabajo.
Claro. Esta el subgerente y después están las áreas de trabajo que atienden a las distintas subgerencias de la compañía. Yo veo lo que es Web e Intranet. Hay otra persona que ve todo lo que es créditos hipotecarios y de consumo. Hay otra persona que tiene que ver con todo lo que es seguros, y cosas así. Estamos divididos por líneas de negocios.
- ¿UD cree que esta segmentación de personal, en tantos grupos, tiene algún problema en el sentido de comunicación?
Claro que tiene, porque resulta que hay gente que, o sea, la gente que ve seguros, que es el problema que yo tengo. Yo soy Web y por tanto, ahora todo quieren entregárselo al cliente a través de la página. No se, ponte tu, hacen un desarrollo en crédito hipotecario. Ahora estamos entregando la cartola en las aplicaciones de crédito hipotecario para las ejecutivas. Entonces llega el usuario y dice entreguémoslo también en la Web. Entonces sacan desarrollos, desarrollos, desarrollos, y yo estoy mirando a la Internet pero no me entero de todos los desarrollos que ellos hacen, hasta que el cliente dice “ya, pero llevémoslo a la Web”. Y ahí hay que correr, porque tiene que estar acá con la ejecutiva y a la vez tiene que estar en la Web.
No hay comentarios:
Publicar un comentario