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.

Fábricas de Software - Introducción

Hoy en día el término Fábrica de Software, o bien conocido en inglés como Software Factory, viene asomándose con fuerza en la mayoría de empresas que tienen un área de sistemas o consultoras que brindan servicios en tecnologías de información. Sin embargo, como parte de mi experiencia en este rubro he podido corroborar que a veces esto sólo queda en un término debido a que en la práctica, por ejemplo, no se aplican criterios de control de calidad del software que se produce, o aún peor, los miembros del equipo no saben que deben hacerlo.

En efecto, todo esto me ha llevado a sentir en muchas oportunidades que el término "Fábrica de Software" lo utilizan más para efectos de marketing o ventas y no para lograr producir software de calidad bajo un esquema de eficiencia en el servicio.

Con este post busco iniciar lo que será el tema de Fábrica de Software debido a que existen muchos aspectos por abordar y temas por tocar. Seré bastante conciso en los puntos principales, sin embargo, advierto que en la realidad para que una empresa se vuelva Fábrica de Software pueden pasar años y no sólo es necesario incluir al equipo que desarrolla el software sino a toda la organización.

En mención a todo lo anterior, es necesario situar un punto de partida para una fábrica de software, en la práctica ese punto de partida resulta ser la estrategia de la organización. Por ejemplo, si una empresa como estrategia para el cumplimiento de su misión y visión decide apuntar a una certificación internacional como CMMI entonces será necesario alinear todos los procesos y personas a las metas de cumplimiento de CMMI (en el nivel requerido); asimismo, será necesario contar con la tecnología necesaria para poder cumplir con dichas metas de manera eficiente.

Pero no sólo es necesario conformar el triángulo Procesos-Personas-Tecnología que le permita ejecutar la estrategia de una organización sino que también todo esto debe estar inmerso en un marco de trabajo medible y certificable. Medible porque para tomar decisiones de mejora deben existir indicadores claros para las respectivas gerencias. Por otro lado, debe ser certificable porque obtener un certificado internacional como CMMI, ISO u otros brinda un valor sustancial a la organización de cara a sus competidores en el mercado.

Entonces, luego de analizar todos estos puntos podemos concluir que una fábrica de software resulta ser un tema mucho más complejo de manejar que el sólo hecho de producir software. Más de una vez he podido apreciar como una organización ofrece sus servicios como fábrica de software y sin embargo el grado de satisfacción del cliente es muy bajo, y es que el mejor indicador de que tan bien nos va resultan ser los mismos clientes.

Como recomendación final quisiera decir que lo más sensato antes de iniciar este díficil proceso que es convertirse en fábrica de software se debe hacer un diagnóstico detallado de la situación de la organización, de los equipos de desarrollo, de nuestros servicios y de nuestros clientes pues sólo de esta forma sabremos de manera más certera que es lo que necesitamos para cumplir con los objetivos estratégicos.

El Capital Humano

Desde hace unos días estuve pensando la mejor forma de empezar este nuevo blog; finalmente, me decidí por comenzar por lo que para Alphab-IT constituye uno de los puntos claves en una empresa: El Capital Humano. Mi nombre es Roberto Camacho y lo que busco a través de este post (y todos los siguientes) es reflejar de manera práctica lo que significa vivir el día a día en este gigantezco y apasionante negocio que son las tecnologías de información.

Resulta que cuando egresé de mi carrera técnica de Computación e Informática me puse a pensar cual iba a ser el factor clave por el cual me iba a "hacer querer en una empresa" al punto que esta buscara retenerme o, mejor dicho, me diera estabilidad, proyección laboral e invirtiera en mí. Bueno, luego de unos cuantos tropezones y malas experiencias laborales lo entendí: no era más que mi compromiso de mejora individual al punto de dominar los productos por los cuales se regía el mercado en ese momento. En principio, quisiera que no se pensara que ser un buen profesional y persona como tal no es importante, en realidad lo es, pero en un inicio cuando tu buscas ganarte un lugar en una empresa pues debes conocer y hasta dominar lo que necesita el mercado a la que esta apunta.

Hoy por hoy, luego de innumerables estudios científicos se refleja que una de las claves del éxito de una empresa es el Capital Humano. Entonces, si nos referimos un poco al término "Capital Humano" concluiremos que mientras más valor tengas en conocimientos tus posibilidades de conseguir un lugar serán mayores.

Quisiera precisar un poco más en este tema; quisiera enfocarme en lo que resulta ser el Capital Humano en una empresa que se dedica a las Tecnologías de Información. En ese sentido, está claro que cada empresa tendrá diferentes tipos de trabajadores los cuales yo considero que se clasifican en dos grandes grupos: los conocedores que van a la vanguardia y los demás que aplican lo que dictan los primeros. Siendo así, los conocedores que van a la vanguardia deberán estar capacitándose siempre antes que los demás con el objetivo que sean ellos los que impongan la nueva dirección de la empresa (y si digo dirección me refiero a que nueva tecnología debe apuntar mi negocio). Por otro lado, los demás que siguen dichas tendencias dictadas pues deberán nivelarse en conocimientos sobre estas tecnologías de forma que sean útiles en el cumplimiento de objetivos de la empresa.

Nosotros, como especialistas en entrenamiento en tecnologías de información, somos concientes que debemos tener planes de capacitación para ambos grupos. Es por eso, que también creemos que cada persona antes de capacitarse debe establecer en que grupo desea estar, y según eso, armar un plan de capacitación a su medida que puede ir desde como optimizar sus labores cotidianas hasta que nuevas tecnologías son las que más convendrán a su negocio.

Espero que este primer post despierte el interés en dos cosas importantes: ¿Qué perfil tenemos: somos de los que determinan que nueva tecnología implantar o de los que siguen a los primeros? y la segunda y más importante ¿Estamos capacitándonos de manera efectiva de forma que día a día nos hacemos más eficientes?