Analizando el Análisis

Hace poco sostuve una reunión con unos amigos quienes me mencionaban la relevancia de que una empresa tuviese definidas sus lineas de carrera. Concretamente ellos al igual que yo en su momento hemos realizado análisis en un proyecto, sin embargo hasta el día de hoy seguimos en la duda si fuimos Analistas de Sistemas, Analistas Funcionales, Analistas Programadores o Analistas de Procesos. Ciertamente, son pocas empresas las que aclaran esto, porque sinceramente creo que ni ellas entienden la diferencia de funciones. Es que al final haces de todo, por eso que identificarte con un rol específico es muy dificil.

hasta el día de hoy seguimos en la duda si fuimos Analistas de Sistemas, Analistas Funcionales, Analistas Programadores o Analistas de Procesos. Ciertamente, son pocas empresas las que aclaran esto, porque sinceramente creo que ni ellas entienden la diferencia de funciones.”

Pero bueno, al margen de esto, el día de hoy he decidido definir cada rol y además sugerir algunos conceptos y herramientas que deberían servirnos para realizar nuestras funciones:

Analista de Sistemas: dícese del analista que posee la capacidad de traducir requerimientos de negocio en un modelo de sistema. Generalmente, se encuentra involucrado en un proyecto durante la fase de análisis. Sin embargo, es común que sus funciones trasciendan dicha fase y más bien persista a través del diseño, desarrollo y estabilización.

Analista Funcional: dícese del encargado de elaborar modelos de negocio. Su intervención debería permitir optimizar los procesos de negocio. Generalmente, un Analista Funcional se encuentra del lado de la empresa que solicita un sistema, y son encargados de proporcionar el know how de un proceso de negocio.

Analista de Procesos: dícese del encargado de elaborar los flujos o workflows de procesos de una empresa. Si bien es cierto muchos creen que este rol lo desempeña un Ing. Industrial, no es del todo cierto, también puede ser realizado por un Ing. de Sistemas o afines. La diferencia con un analista funcional, es que su ámbito no necesariamente está enfocado sólo en el negocio, sino que más bien debería tener como objetivo construir una metodología propia de la empresa (o área almenos).

Analista Programador: dícese del Analista de Sistemas que además de modelar los requerimientos del negocio los programa. Este suele ser el más técnico de todos los analistas y es que debería conocer bien la tecnología sobre la cual se desarrollará el software requerido.

Tipicamente, y al margen de que tipo de analista uno sea, es necesario contar con las siguientes características o competencias:

• Alta capacidad analítica
• Buen trato interpersonal
• Alta capacidad de gestión (para gestionar los requerimientos)

Pero si uno es analista de Sistemas o Analista Programador, es necesario además de lo anterior tener una amplia habilidad técnica. Esta última depende ciertamente de la tecnología en la que el sistema será desarrollado, pero lo más importante es que el analista pueda modelar un requerimiento dentro del marco tecnológico deseado.

Entre los conceptos y herramientas a manejar principalmente habría que resaltar:

Para el modelamiento de procesos: Six Sigma (SIPOC o COPIS). Entre las herramientas que me permiten modelar esto están: ARIS Six Sigma, Microsoft Visio (este uso yo), IBM Business Modeler, Oracle Crystal Ball, etc. Mientras que para la lluvia de ideas que dan origen al SIPOC o COPIS se tienen Xmind (este uso yo), Mind Manager, Free Mind, Mind Mapper y hasta el mismo Microsoft Visio entre otros.

Para el modelamiento de procesos, funcional y de sistemas: conocer BPM y UML es básico, aunque también ayuda el básico diagrama de flujos. Entre las herramientas están: IBM Rational Rose, BizAgi (este uso yo) y otra vez Microsoft Visio entre otros. También es importante señalar que Visual Studio 2010 ya incluirá algo de UML por lo que podría considerarse como una herramienta también.

Bueno espero este tema haya sido de su interés y que haya aclarado las dudas que a veces se tiene…

Fábricas de Software – El Diagnóstico

En mi post anterior sobre fábricas de software escribí un poco de lo que  estas son a nivel general. Como comenté, la primera etapa para la implementación de estas es conocida como Diagnóstico. Pero concretamente, ¿qué aspectos son los que debo diagnosticar? bueno, son estos aspectos los que empezaré a comentar:

La Metodología: este aspecto suele ser el más básico. Pero muchos piensan que hablar de metodología es hablar de algo complejo o pesado, de documentación en abundancia y artefactos por doquier. Realmente no es así, metodología es hacer que los métodos comúnmente aplicados por miembros de mi equipo se formalicen e implanten no a nivel individual, sino de equipo. Es por ello que cada método o procedimiento debe ser analizado por todos los miembros, se deben comparar y así determinar el más adecuado (basándonos en criterios como eficiencia, calidad, esfuerzo requerido, etc.), posteriormente esto se puede documentar aunque sea en un formato checklist (ojo también pueden ser plantillas más elaboradas) y aplicar el versionamiento respectivo.

El Equipo: es fundamental conocer al equipo que se posee, conocer sus competencias técnicas y de aptitud. Es necesario tener claro el perfil de cada miembro del equipo, así como los temas de su preferencia o dominio (línea de negocio que más le guste o aplique). El conocer el equipo me permitirá identificar a su vez aspectos claves como: roles con los que cuenta el equipo (a veces todos son programadores, y resulta que también necesito Analistas Funcionales, Testers, etc.), si conocen la tecnología que requiere el cliente, si se encuentran actualizados, si encajan con lo que ofrece mi servicio. En base a esto debería apuntar por lo menos a cubrir los siguientes roles: Jefe de Servicio, Jefe de Proyecto, Arquitecto de Software o al menos Líder Técnico, Analista Funcional, Analista Desarrollador o al menos Desarrollador, Analista de Control de Calidad o al menos Tester, y Help Desk. Si no tengo cubiertos todos estos roles, dificilmente pueda cumplir con el servicio que debería ofrecer una fábrica de software.

Las Herramientas: hay herramientas principales que debería identificar como: software de gestión de proyectos (por lo menos algo como MS Project), control de código fuente, portal de colaboración (administrador de contenido del proyecto), software de modelado BPM/UML/Diagramas de Flujo que me permita modelar el negocio y sistema, software de modelado de ER/base de datos, entorno de desarrollo integrado (popularmente conocido como IDE) de la tecnología a utilizar, software de pruebas unitarias (generalmente incluido en el IDE), software de documentación de observaciones (al menos algo como MS Excel) y software de incidencias (que me permita generar tickets de atención a usuarios del sistema). Todas las herramientas identificadas deben documentarse brevemente; además, debe tenerse información de soporte como How To’s, ayudas, videos, manuales, etc.

La metodología, el equipo, las herramientas y el workflow de servicio son los aspectos claves que debo diagnosticar. La calidad de estos determinará, en mayor o menor medida, el cumplimiento adecuado del servicio de mi fábrica de software“

El Workflow de Servicio: este aspecto es clave, practicamente es el que determina si ciertamente cumpliré con lo mínimo requerido por mi cliente. Un flujo de servicio determina, o debería determinar, el flujo de atención de mi fábrica. Hay que desarrollar aspectos claves como: tipos de proyectos que se atienden, duraciones, documentación a generar para cada tipo, roles que intervienen (sobre todo para las aprobaciones), entregables e indicadores de medición de mi servicio.

Como consecuencia del diagnóstico debería obtenerse conclusiones que me permitan tomar medidas preventivas, de seguimiento y control, y correctivas del servicio brindado por mi fábrica de software.