archivo

Archivos diarios: abril 5, 2011

Si no se tiene un perfil técnico se está estigmatizado, como si se tuviera menos confianza en la capacidad de esa persona en un proyecto de desarrollo de software o en una empresa del sector.

Viste mucho o tiene más glamour ser arquitecto, analista orgánico o realizar tareas de programación. Son funciones importantes, eso es innegable, pero también lo son las tareas funcionales (sobre todo teniendo en cuenta que son los primeros que toman contacto con el proyecto y que su trabajo, bueno o malo, condiciona el resto del desarrollo).

Programadores los hay excelentes y muy malos, los analistas funcionales no son una excepción.

Un buen analista funcional no tiene precio. Si es capaz de realizar una definición adecuada del proyecto crecen las posibilidades de que salga bien, un mal análisis es difícil de remontarse por muy buenos técnicos que participen en el proyecto.

Es necesario respetar todos los perfiles que participan en un proyecto, tras los perfiles hay personas y lo podrán hacer bien o mal. Es decir, se puede hacer una selección no adecuada de perfiles en un proyecto o acertar y quienes desempeñen un determinado rol no funcionar, pero en ningún caso es culpa del perfil en sí.

Por tanto, si un perfil de analista funcional no encaja en un proyecto será porque el proyecto requiere otro tipo de perfiles o requiere que quien desempeñe el papel de analista funcional, sea polivalente y pueda ser también analista orgánico o realizar tareas de construcción, pero como en el fútbol, es muy complicado ser a la vez buen delantero, buen centrocampista y buen defensa.

Tener buenas referencias es importante, tanto por lo que puedas presentarles a potenciales clientes como por la posibilidad de esos buenos clientes actúen, sin quererlo, como tus mejores comerciales.

Puedes tener un comercial excepcional, pero si una organización pide consulta a otra y da malas referencias, lo tienes complicado.

Las buenas referencias vienen a través de un trabajo o un producto de calidad en el que el cliente se encuentre satisfecho y vea que la inversión realizada ha merecido la pena, algo que en los momentos actuales es mucho más complicado que hace años, ya que las disponibilidades presupuestarias no son las mismas, lo que tiene como consecuencia un aumento de la exigencia.

¿Cómo se sabe que un cliente es bueno? Eso tienen que evaluarlos las personas con poder de decisión en la organización, que tendrán que analizar el posicionamiento y grado de influencia de la empresa a la que se le presta el servicio o se le vende el producto y su relación con otras.

Una vez que se llega a la conclusión de que el cliente puede merecer un trato especial, el siguiente paso será analizar hasta dónde llega la inversión, es decir, si el servicio requiere un nivel de calidad superior al contratado o tiene un alcance mayor (o se le quiere ofrecer), ¿hasta cuándo se puede llegar?. Es muy importante plantearse los límites porque de no hacerlo al final lo mismo no merece la pena.

Con productos es más sencillo, al fin y al cabo ya lo tienes hecho y lo que le estás ofreciendo es un acuerdo de licencias, aquí si puede haber más manga ancha y lo mismo hasta te interesa dejar la licencia a un precio simbólico (lo de darla gratis tiene como inconveniente que lo mismo desde el cliente no se termina de valorar como se merece lo que ha recibido).

Quiero matizar lo del gratis, ya que doy por hecho que el producto no es software libre (aunque el software libre no tenga por qué ser gratis) o tiene una versión comercial.

La experiencia es muy importante ya que las circunstancias vividas sirven de complemento a tus conocimientos y tu análisis de la situación permitiendo que cuando tengas que tomar decisiones dispongas de más cartas a tu favor para poder acertar.

La experiencia viene de la mano del tiempo trabajado, ya que cuanto mayor sea tu trayectoria profesional con más circunstancias y problemas te habrás encontrado y de esta forma se habrá adquirido un conocimiento y un bagaje importante.

Ahora bien, ese tiempo es relativo, no es lineal, de manera que la experiencia de una persona que haya trabajado X años no tiene por qué ser superior a la de alguien que haya trabajado Y, siendo X>Y. Al final dependerá de la naturaleza del trabajo realizado, de la responsabilidad adquirida, de tu grado de implicación y de haber aprendido de los aciertos y sobre todo de los errores.

Durante mucho tiempo he recibido análisis de requisitos donde se describían las funcionalidades a demasiado alto nivel. Esto tiene un gran problema y es que al final casi todo es interpretable y en muchos casos ambiguo. Este problema se trasladaba después a los casos de uso.

Al final tenemos un análisis que no cumple sus objetivos, ya que los analistas programadores y programadores no disponen de la información necesaria para hacer su trabajo, por lo que necesitarán la continua asistencia del analista, el cual además, al no ser un experto funcional en la mayoría de los casos, sino alguien que ha aprendido el negocio en el proyecto, tendrá lagunas que, si no quiere arriesgar demasiado, tendrá que consultar con el grupo de usuarios expertos.

El problema no es que se tenga que preguntar en medio del diseño o de la construcción (que lo es), sino el coste que eso conlleva, ya que requiere una mayor atención al proyecto por parte del analista, cuando la mayor parte de su trabajo debería haber sido llevado a cabo antes de manera adecuada.

Pero el problema principal es que al final la interpretación de los requisitos y de cómo interactúa el usuario con la aplicación deja vendido a las dos partes, cliente y proveedor y empiezan las luchas de poder, en las que generalmente el proveedor tiene las de perder. El hecho de que el cliente tenga ventaja en las disputas no quiere decir que este tipo de situaciones sean convenientes, ya que al final, en las negociaciones siempre se perderán funcionalidades interesantes o estas se conseguirán después de mucho desgaste entre las partes.

Por estos motivos, me he planteado como objetivo ser mucho más riguroso en estas etapas iniciales del proyecto, estoy seguro que al final merecerá la pena.