Maik es un usuario duro. Evita cualquier saludo, gesto, información o explicación que te pueda ayudar en tu trabajo. No es su problema. A él la vida no se lo ha puesto fácil, ha tenido que trabajar muy duro para llegar a ser jefe de línea. Él tampoco te lo pondrá fácil a ti, consultora cuqui con zapatos cuquis y portátil cuqui.
Maik no es Mike ni Mick ni Michael. Realmente en su DNI pone Miguel Ortuño Perales, pero el último consultor que – inocente él – le llamó Sr. Ortuño, todavía está buscando los retrovisores de su coche. Maik y punto.
Maik se sienta en frente de Marisa, en la reunión de análisis de requisitos del área de Producción. El objetivo es recoger, aflorar, capturar los requisitos del área, en boca del responsable de la línea principal. A Marisa le viene a la mente la especificación cuqui ISO/IEC/IEEE 29148:2018, relativa a Ingeniería de software e Ingeniería de Requisitos.
En esa especificación se establece que un requisito pata negra debe ser:
- Necesario
- Apropiado
- Inequívoco
- Completo
- Singular
- Factible
- Verificable
- Correcto
- Conforme
- Consistente
- Comprensible
- Capaz de ser validado
Esa definición ya ha empleado más palabras de las que Maik usará en la reunión, así que Marisa está really f*ck3d.
Se impone una estrategia de captura de requisitos diferente a la habitual. Optará por centrar la conversación en las quejas y urgencias que el usuario transmite, en lugar de perderse en definir abstracciones o datos maestros base. Es decir, un proceso de afloración TOP-DOWN, donde el usuario sólo le contará algo del TOP, y Marisa tendrá que ir deduciendo el DOWN necesario para soportarlo.
Se ganará su confianza, y con el tiempo Maik se irá relajando al ver que el ERP cubre sus necesidades. En poco tiempo se mostrará mucho más participativo.
[Continuará en el próximo capítulo]
Spanish
English
French
German
Italian
Portuguese
Comentarios recientes