El perfil de analista

En un equipo de trabajo dedicado a la ingeniería del software, la existencia de perfiles asociados a recursos concretos denota un alto nivel de especialización. Es normal encontrarse equipos de trabajo donde los recursos que los forman hacen de todo o casi de todo. Donde trabajo, eso no sucede. Desde hace algún tiempo, como parte de un cambio en la cultura de empresa, se comenzó a forjar un alto grado de especialización. Entre los distintos perfiles que se definieron, está el analista.

No quiero añadirle el completo “funcional”, prefiero referirme a él, como analista. Según la RAE, un analista es el que hace análisis, y un análisis es:

  1. Distinción y separación de las partes de un todo hasta llegar a conocer sus principios o elementos.
  2. Examen que se hace de una obra, de un escrito o de cualquier realidad susceptible de estudio intelectual.
  3. Estudio, mediante técnicas informáticas, de los límites, características y posibles soluciones de un problema al que se aplica un tratamiento por ordenador.

He tomado de la RAE las acepciones más cercanas al tema que nos atañe. Pues bien, comenzaré con que no estoy de acuerdo con la parte de la tercera acepción en la que dice “...y posibles soluciones de un problema al que se le aplica un tratamiento por ordenador“. Dar soluciones a un problema considero que forma parte del diseño, y para eso ya tenemos a otros perfiles. Cuando nos encontramos ante un problema, lo primero que hacemos es obtener toda la información (datos, relaciones, semejanzas, contradicciones, etc) que es objetiva del problema. En este punto, dejamos a un lado cosas como “habrá querido decir…”, “supondrá esto que…”, es decir, las cuestiones subjetivas a un lado. Una vez que tenemos bien estructurada la información, entonces es cuando comenzamos a usar nuestro conocimiento en la materia del problema y podemos hacer uso incluso de suposiciones para encontrar una solución. Mi profesor de matemáticas nos decía que los problemas es fácil que se puedan resolver de múltiples formas, especialmente en las matemáticas. ¿Y no es cierto que un mismo proyecto software puede ser diseñado de múltiples formas? Sin embargo, los datos objetivos del problema son únicos, es decir, una persona puede ver un problema y obtener cierta información objetiva y, sin embargo, otra persona, puede ver esa misma información objetiva o incluso otra que la contenga.

A continuación expongo las principales funciones que deben recaer sobre el perfil de analista:

  • Localización de las fuentes de información: Una vez que el analista toma contacto con el reto (sustituye al problema antes mencionado) debe detectar sus fuentes de información. En una gran parte de las ocasiones su fuente de información vendrá de usuarios expertos que le proporcionarán la información. En otros casos, tendrá que recurrir a biografía, internet, etc.
  • Formalizar el reto: Evidentemente no puede retener toda esa información, necesitará organizarla, estructurarla, revisarla, etc. Por lo tanto, necesita seguir ciertas convenciones o prácticas para que él mismo pueda gestionar esa información.
  • Interlocutor entre quien plantea el reto y quienes darán solución al reto: Según esto el punto anterior toda aun más fuerza porque el resultado de formalizar el reto no sólo le servirá a él, sino a otras personas (recursos).
  • Velar porque la información objetiva que refleja el formalizar el reto siga íntegra: Tiene que ser capaz de analizar no sólo el reto sino también la solución, pero en este caso con el objetivo de asegurarse de que la información considerada en la solución es correcta.
  • Proteger la solución: Siempre pueden aparecer datos que inicialmente estaban ocultos y, evidentemente, no podemos obviarlos, pero tampoco podemos permitir que el desarrollo de la solución deje de ser válido.

Evidentemente, no es fácil. De hecho considero que es un trabajo complicado y que requiere de ciertas habilidades/capacidades como por ejemplo:

  • Capacidad de síntesis
  • Capacidad comunicativa
  • Buena oratoria
  • Disciplina
  • Orden
  • Ser muy meticuloso con todo, incluso con los pequeños detalles.
  • Capacidad de abstracción
  • Capacidad de conceptualizar

Es probable que me haya dejado atrás tanto funcionalidades como habilidades/capacidades, supongo que cada uno tiene sus propias listas, pero creo estas resumen lo que busco en un buen analista. Personalmente creo que se comete un error cuando se dice que:

  • Un analista primero tiene que haber sido desarrollador.
  • Cuando se piensa que la evolución de un desarrollador es ser analista.
  • Cuando se cree que para analizar hay que conocer las herramientas de usan los diseñadores

Procuraré escribir sobre la relación entre el perfil de analista y el resto de perfiles. Como curiosidad os recomiendo que busquéis en los portales de trabajo ofertas relacionadas con los analistas (informáticos). Al hilo de esta entrada os recomiendo leer “El arquitecto de software en versión española”.

17 thoughts on “El perfil de analista

  1. Tus reflexiones me han parecido interesantes, pero me gustaría hacer un par de puntualizaciones. Podría hacer muchas más, pero en lugar de un comentario esto parecería un post ;)
    1. Cuando hablas de las competencias del analista, y comentas que “el estudio de posibles soluciones a un problema al que se le aplica un tratamiento por ordenador” no debe formar parte de las mismas, y por otra parte hablas de la función de “Interlocutor entre quien plantea el reto y quienes darán solución al reto”, creo que existe cierto grado de incongruencia. Me explico: no hay que perder de vista que los Análisis toman como punto de partida un Catálogo de Requisitos (a veces incluso sólo eso), que a su vez ha de ser verificado y validado por el cliente. Esto implica que ese Catálogo de Requisitos ha de estar descrito en términos del negocio, lo cual a su vez puede llegar a generar cierta confusión entre “quienes darán la solución al reto”. Creo que es fundamental que ese proceso de estudio sea un trabajo en que intervengan ambos perfiles, tanto el Analista como el Desarrollador.
    2. Cuando hablas de “Localización de las fuentes de información” es obvio que la búsqueda de documentación (bibliografía, internet, etc.) es una tarea que recae entre las funciones del Analista, pero, ¿realmente consideras que en la detección de fuentes de información también se determinan los usuarios expertos? Hasta el momento y por mi experencia, los usuarios expertos siempre han sido seleccionados “a dedo” por un ente superior, sobre el que no he tenido ninguna capacidad de influencia en este sentido. Hay ocasiones que los usuarios expertos son seleccionados de forma arbitraria, corriendo el riesgo en dicha aleatoriedad de que el grupo de toma de requisitos esté formado por gente desmotivada, totalmente indiferente ante el éxito o el fracaso del proyecto.
    3. Por el punto anterior, creo que se podría añadir una nueva cualidad en el Analista, la de motivar e involucrar a los usuarios expertos, haciendo un especial esfuerzo sobre aquellos individuos que describía en el punto anterior. En definitiva, se trata de hacer sentir a los usuarios expertos como miembros del equipo de análisis. Para esto hay muchas técnicas, que juegan más con la psicología y las capacidades sociales que con la propia ingeniería del software.
    Se me quedan algunas cosas en el tintero (o en el teclado en este caso). Creo que tras este comentario me he convencido a mi mismo de la necesidad de crearme un blog. ;P
    Un saludo.

  2. Hola José María:

    Algunos comentarios a los puntos que has planteado:

    1.- ¿incongruencia? Creo que no. Ser el interlocutor no significa que tenga que participar en el diseño de la solución. Es interlocutor porque está en medio entre quien plantea el reto y quienes tiene dan una solución. Simplemente eso. No creo que el analista parta de un catálogo de requisitos, él genera ese catálogo de requisitos. Evidentemente, él parte de una simple presentación o de las notas que él mismo toma en una primera toma de contacto. Ojo, yo no he hablado de desarrolladores ni tampoco de las relaciones entre el analista y el resto de perfiles. En analista claro que trabaja con los que diseñan la solución pero su participación debe consistir en lo que he expuesto en el punto 4 (“Velar por…”). Quizás el catálogo de requisitos no se el “artefacto documental” correcto para trabajar con el cliente. No lo sé, ahí tengo mis dudas.

    2.- Ahí precisamente es donde entran en juego las habilidades del analista.

    3.- Lógicamente, esa destreza es clave porque el final, todo pasa por cuestiones personales.

    PD: Pues ánimo con el blog, hoy en día quien no tiene un blog es porque no quiere.

    Un saludo

  3. Hola Manu,

    no puedo dejar de escribir para escribirte mi opinión con respecto al comentario donde expresas que dar soluciones al problema forma parte del diseño.

    No estoy de acuerdo en este sentido, entiendo que la solución será única (aquella que cumpla con el catálogo de requisitos definidos). Durante el diseño definiremos el camino que nos va a llevar hasta la solución, pero el diseño debe conocer el objetivo final, la solución. Y creo que es labor del analista dar con ella.

    Saludos!

  4. Hola Darío:

    Me alegro que participes. ¿Desde cuánto un reto/problema tiene una única solución?, y menos en el terreno en el que nos movemos. Soluciones que satisfagan un análisis puede haber muchas. ¿Y dónde dejas al diseñador de interacción, arquitecto software, diseñador gráfico, etc..? Son ellos los que dan la solución y por eso interviene en la fase de diseño.

    Evidentemente, hay muchas formas de ver las cosas. La mía es una más, sólo eso.

    Un saludo

  5. En mi opinión, hay muchas decisiones de diseño que tomar en un proyecto, que afectan a múltiples disciplinas del software.

    Tal vez en el diseño de la arquitectura (física o lógica) no deba intervenir el Analista, ni en el diseño tecnológico que sustente a la solución, y mucho menos en el diseño gráfico, naturalmente. Tal vez en el diseño de interacción sí (junto con el perfil correspondiente) a través de Storyboards donde a nivel de Análisis se definan los escenarios que modelarán los casos de uso (o las historias de usuario, o los requisitos funcionales, etc). Tal vez también en el diseño de las clases de análisis (junto con el perfil correspondiente), donde se vuelquen en asociaciones, herencias, patrones de diseño, etc. todas aquellas relaciones y dependencias surgidas en el Catálogo de Requisitos.

    Creo que la intervención del Analista en las tareas que comentaba son fundamentales, y más aún cuando un Análisis se limitan a un mero Catálogo de Requisitos.

    En este sentido coincido con Darío, aunque como bien dices, hay muchas formas de ver las cosas; ésta era la mía.

  6. Que puedo decir, que el último comentario de José María es el que más se acerca a mi opinión (mia, personal e intransferible). Tanto tal vez en la asignación de tareas y funciones del rol me parece que demuestra que se comente un error al intentar tener una separación tan clara de roles de arquitectura-diseño-análisis-programador-blah-blah-blah. No porque eso sea considerar la informática una cadena de montaje, que en un mundo ideal lleno deflores y de buen tiempo podría ser, pero es darle la espalda a la realidad: a la falta de tiempo, a la falta de comunicación, renunciar a la creatividad, renunciar a motivar y a formar y aún más cosas.

    La respuesta habitual en contra de esto suele ser que en organizaciones grandes no todos pueden hacer de todo, lo cual es siempre cierto, no sólo en organizaciones grandes. Pero cualquier que haya trabajado en una empresa grande sabe que precisamente por esa especialización (el resto lo hace la naturaleza humana) suelen funcionar tan mal como funcionan, de modo que ese argumento se rebate así mismo (por qué copiar algo que funciona mal?). Las únicas empresas grandes que yo he visto que funcionaban (que las hay) no se debía a su grado de especialización, sino a su grado de autonomía.

    Hace poco hemos escrito nuestra visión sobre eso de forma reducida: http://weblog.linkingpaths.com/2008/08/12/la-especializacion-es-para-los-insectos/

  7. Hola José María:

    ¿Analista en el “diseño de clases”? Pero si hasta las palabras chocan, y más, en estos tiempos en los que los diseños suelen estar condicionados por herramientas de tipo ORM, etc. Pero prefiero no entrar en temas tan concretos. El objetivo de mi post era centrarme en lo que espero de un analista e insisto en que aun no he hablado de sus relaciones con el resto del equipo. Lo que sí tengo claro es qué cosas es pero de ese perfil.

    Hola Alberto:

    Nada más comenzar a leer tu comentario sabía por donde ibas. Como nos conocemos ya ;)
    No puedo hablar desde la experiencia porque no he trabajado en empresas grandes, pero sí podría hablar de una situación que me pilla muy cerca donde los resultados son realmente positivos. Sólo eso.
    De todas formas, después de leer vuestros comentarios, entiendo que José María habla de las competencias (área de actuación) del analista y tú hablas de la especialización.
    Por otro lado tú hablas de no “copiar” lo que funciona mal (creo que has generalizado muchísimo) y yo iría en la línea de mejorar ciertas cosas de las que tú mismo has comentado: falta de tiempo, falta de comunicación, etc.
    Muchas veces falta tiempo porque hacemos las mismas cosas una y otra vez, cuando no profundizamos y nos conformamos con “esto parece que funciona”, “yo creía que”, etc. ¿Falta de comunicación? Lógico, hay “equipos” que no saben trabajar en equipo, y como todo, es un proceso de aprendizaje.

    Un saludo a ambos.

  8. Coincido con lo que comentas en tu post, y realmente es lo que más se acerca aquí a lo que he visto en Irlanda (y por lo que me han comentado, también en Europa) donde la mayor parte de Business Analysts, y nótese la diferencia ya de por sí con nuestro tan querido término de Analista/Programador, ya sea en empresas pequeñas, medianas o grandes, no tienen realmente un background de programadores, ya que los programadores prefieren otros caminos que te lleven a puestos más senior, líderes de equipo o managers.

    Yo tampoco creo que un analista requiera tener un background en programación, y probablemente ni siquiera en informática (dependiendo del software que se está realizando), y mucho menos que deba influir en absolutamente nada de la parte técnica de la aplicación, desde arquitectura hasta la menor de las líneas de código. Se me antoja el límite razonable como la definición de los casos de uso y siempre utilizando conceptos de alto nivel acordados previamente con la parte técnica de la compañía.

    Me parece muy interesante el quinto punto, y quizás separaría entre la protección en sí de la aplicación del exterior y un punto de compromiso con la solución, en forma de asumir las responsabilidades que conllevan los cambios en los requisitos, especialmente cuando el desarrollo está avanzado, y reconocer las consecuencias en cuanto a costes de dichos cambios.

    El de analista es un rol importante dentro de una compañía, y en cuanto lo mezclamos con otros roles y responsabilidades su valor se diluye. Analista, al igual que arquitecto (como comentaba en el post), es uno de los roles más prostituidos del sector, aunque comentaba por ahí un amigo que hoy por hoy casi todo el sector está prostituido, lo que probablemente también sea cierto.

    Saludos.

  9. Manuel, con sólo ver el título de tu post yo sabía también tu opinión y que no me iba a gustar XD.

    Te pondré otro ejemplo. Una empresa que vende por todo el mundo, tiene servicio de atención al cliente en cinco idiomas. Para dar mejor servicio, deciden tener un experto en cada lengua. De esta forma, los clientes de cada país estarían de lo más contentos de como les atienden. Sin embargo, como a esas personas sólo les pagan por atender en su idioma, se esfuerzan por mejorar en ese idioma, olvidándose de la lengua común, ya que no tienen ningún aliciente para practicarla. Sólo el jefe intenta hacerles llegar a todos la misma información, pero claro, eso hace que tenga que repetir las cosas (por señas, claro, perdiendo mucha información) cinco veces. Además, si uno deja de estar al día de lo que se mueve en la calle respecto a su idioma, nadie tiene capacidad para saber si es así. Cuando decide dejar la empresa, nadie sabe como se dicen la mitad de las palabras relacionadas del producto en ese idioma, porque a fin de cuentas, como nadie lo entendendía, para que lo iba a escribir.

    Eso es la especialización, ¿relato exagerado?. No lo sé, no me cuesta transferirlo a analistas (o jefes de proyecto, o arquitectos, o cualquier otro puesto) que se guardan información, que miran por encima del hombro, que se refugian en “su tarea” cuando algo no va bien, porque es la naturaleza humana. ¿Generalizo?, es posible, pero no hablo de las personas, hablo de las organizaciones y lo que este tipo de organización fomenta, obviamente siempre hay buenas personas (que normalmente acaban quemadas, pero es otro cantar).

    La solución no pasa obviamente por tener a cinco personas que hablen los cinco idiomas, ni siquiera hay una solución mágica.

    Sobre trabajar en equipo… depende de la definición del trabajo en equipo. Para mi tu especialización no es trabajo en equipo, es una cadena de montaje.

    Sobre la falta de tiempo, etc. simplemente eso es una realidad independientemente de que las cosas se hagan bien o mal. Decir que no hay tiempo porque las cosas se hacen mal y porque te conformas con poco es reducirlo demasiado. A mi ese me parece tu caso concreto, no mi experiencia XD. Tres de las últimas cuatro empresas en las que he trabajado funcionaban bien pero nos faltaba tiempo para hacer todo lo que queríamos hacer (sobre todo fruto de nuestra propia no-especialización), no por repetir cosas o hacerlas mal.

    En todo caso, por supuesto que me alegra que os vaya bien, y espero que os siga yendo bien por muchos muchos muchos años.

    Lo dejo, creo que no nos vamos a convencer, y no quiero repetirme ni aburrir a nadie que lea esto (si alguno ha llegado hasta aquí, mi más sentida enhorabuena por su tesón).

  10. Se me había olvidado… el día que la empresa de los cinco idiomas hace un lanzamiento en uno de los países, se le triplican durante una semana las llamadas. ¿Clientes contentos esperando tanto tiempo porque sólo una persona habla bien ese idioma?.

  11. Hola Alberto:

    ¿Estamos hablando de lo mismo? Creo que hubo un momento en el que me perdí completamente. Sigues intentando llevar la “conversación” por el tema de la especialización y no es ahí donde mi post pretendía (quizás equivocadamente) llegar.

    Dejando a un lado el nivel de especialización, lo que necesito ahora es que quien/quienes analicen cubran esas funciones y desarrollasen esas habilidades. Sólo eso. Que eso lo haga un perfil concreto, no es lo que más me preocupa, lo que deseo es que se haga de esa forman.

    Hablas de la naturaleza humana, sin embargo, instantes después dices que no hablas de las personas, sino de las organizaciones. Pensaba que las organizaciones las dirigían personas.

    En cuanto mirar por encima del hombro, refugiarse en “su tarea” y otras cosas que has comentado, poco puedo decirte. Tengo la gran suerte pertenecer a un grupo de trabajo donde hay muy buen ambiente y donde estamos fomentando día a día el trabajo en equipo. Es absurdo no reconocer que tenemos problemas y cuestiones que mejorar, pero en ello estamos.

    Os agradezco a todos (José María, Alberto, Darío y Martín) vuestros comentarios y opiniones. Se aprende mucho.

    Un saludo

  12. Manuel, no he hablado de la ‘naturaleza humana’. Supongo que me ha faltado poner “concretas”, no hablo de las personas concretas, sino de lo que las organizaciones (vale, diriigidas por personas) fomentan. Supongo que es fallo mio.

    Sobre si me salgo del tema, tu primera frase es:

    “En un equipo de trabajo dedicado a la ingeniería del software, la existencia de perfiles asociados a recursos concretos denota un alto nivel de especialización”

    De hecho en ese primer párrafo aparece dos veces la palabra especialización y sólo una vez vez la de analista. Tu respuesta de cortar las discusiones que para mi afectan al tema principal me denota una intención de especialización de post que sigue (en mi opinión) sin encajar con la naturaleza humana XD. No tengo interés en llevar el tema a un sitio en concreto, pero en todo caso no he hablado de fútbol ni de toros.

    Sobre

    “lo que necesito ahora es que quien/quienes analicen cubran esas funciones y desarrollasen esas habilidades. Sólo eso. Que eso lo haga un perfil concreto, no es lo que más me preocupa, lo que deseo es que se haga de esa forman.”

    Entonces hablas de roles (bueno de tu post, las funciones van al rol, las habilidades al perfíl de la persona, pero el trabajo lo definen siempre las funciones, todo el mundo debería tener capacidad de síntesis, trabajar un equipo y ser buen orador), y te has equivocado con el título del post XD. Pero esa es una cuestión lingüistica banal.

    Y ahora sí que lo dejo, porque llevar la conversación a un “tu dijiste, yo dije” de una conversación parcheada a lo largo de varios días es algo de lo que si quiero prescindir.

    Martín, si no recuerdo mal… aquí al Business Analyst le llamaban “analista orgánico”, aunque en alguas empresas ha ido dejando paso a “consultor de negocio”, otro termino prostituido, mal entendido y mal copiado de otro tipo de consultoras escasas en España.

  13. Pingback: Mi espacio » El diseño de interacción en Drupal 7

  14. Hola Manuel,

    Tengo una pregunta que probablemente me puedas ayudar a responder. Veo que las entradas anteriores son algo viejas, así que espero todavía le dediques un poco de tiempo a tu sitio y te llegue la pregunta. La pregunta es: ¿Cómo seleccionarías a los elementos de un equipo de analistas de información? estoy interesado en saber que puestos formarías y qué perfil tendrías en cuenta para cada puesto.

    Gracias.

  15. ok, trataré de simplificarla. ¿Qué puestos forman el equipo de analistas de información y cuales son sus funciones? Gracias.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>