Jummp’s Blog

De todos es sabido que cuanto antes se solucione un problema en un proyecto de desarrollo de software, menos coste tiene para el mismo y de ello salen beneficiados tanto proveedor como cliente.

Por ese motivo resulta esencial que un proyecto sea sólido desde la base, siendo la misma el análisis funcional, lo que hace que sea muy importante la figura del analista que es la persona o grupo de personas (si el proyecto es grande) que se tienen que encargar de entender, interpretar y traducir lo que el usuario demanda, sentando las bases de los posteriores procesos de diseño y construcción del sistema de información.

Hacer un buen análisis es una tarea bastante compleja, ya que resulta muy complicado obtener todos los requerimientos del usuario desde etapas muy tempranas, ya que por regla general el usuario empieza a descubrir el detalle de todo lo que quiere cuando empieza a utilizar el producto ya construido con ejemplos reales de su día a día de trabajo (también suelen comentar nuevos requisitos o enmendar requisitos previos, en otras etapas conforme se le vaya presentando la evolución del proyecto, de hecho no es malo que se corrijan, ya que cuanto más avanzado esté el proyecto, el esfuerzo de hacer los cambios es mucho mayor). De hecho es prácticamente inevitable no hacer evolutivos que solventen esos flecos que no se detectaron en análisis para dejar el producto lo más próximo posible a lo que los usuarios necesitan y demandan. Como consecuencia de lo anterior, y como es lógico, se puede considerar que un análisis funcional es más bueno conforme sea menor el número de ajustes que haya que hacer en etapas posteriores del proyecto.

Es importante matizar que un proyecto de desarrollo de software no es una barra libre y que es importante que el usuario conozca sus responsabilidades en el proceso de definición del sistema y que no se pueden estar cambiando de requisitos continuamente, como tampoco podría estar cambiando frecuentemente de opinión si le están construyendo una casa. Todo lo anterior además hay que compatibilizarlo con que todas las partes están interesadas en el que el proyecto vaya a buen término, por lo que tampoco es una buena política ser inflexibles en la modificación del catálogo de requisitos, porque si el resultado final no es el que quiere el usuario, el sistema de información tendrá muchas papeletas para no ser utilizado. Equilibrio complicado: evitar que los usuarios modifiquen continuamente requisitos y tener un poco de mano izquierda cuando se planteen esos cambios. Como ese equilibrio es complicado de mantener y es fuente frecuente de conflictos, hay que intentar que el análisis tenga la mayor calidad posible.

Hacer un análisis funcional por tanto es una tarea compleja, a lo que hay que sumar que en muchos casos hay que aprender mucho sobre el proceso de negocio que se pretende informatizar, para entender de mejor manera lo que el usuario demanda, ya que resulta todo más fácil si el lenguaje que se utiliza es el mismo. En muchas ocasiones esos procesos de negocio son tremendamente complejos y además se dispone también de poco tiempo para entenderlos, teniendo en cuenta que por regla general y como he comentado muchas veces en mi blog, los proyectos informáticos suelen estar infravalorados (por el que contrata y/o por el que es contratado (para conseguir el contrato)).

Dado que el análisis funcional consiste en abstraer un conjunto de necesidades de los usuarios es muy importante la implicación de los mismos y eso no siempre se consigue. Si los usuarios no están implicados, por muy buen analista funcional que tenga el proyecto, las probabilidades de que este salga mal crecen exponencialmente. Evidentemente un buen analista puede paliar esos huecos que deja el usuario e incluso conseguir una mayor participación de los usuarios, pero más tarde o más temprano los problemas aparecerán y al final siempre termina pagando el proyecto (en primera instancia) y el que lo desarrolla (en segunda). Por todo lo anterior, se puede pedir que un analista funcional aprenda un proceso de negocio complejo, que consiga extraer de los usuarios lo que buscan y necesitan y que además lo haga en un tiempo record, pero lo que no se le puede pedir es que haga magia y resuelva problemáticas que le trascienden, como el caso que he comentado de la inacción de los usuarios en determinados proyectos, siendo esa falta la implicación la primera causa de que un análisis no salga bien y por tanto una de las causas más importantes del fracaso de un proyecto y no se trata en este caso de tirar pelotas fuera y ponerme del lado de mis colegas de profesión, se trata de algo que he podido vivir en diferentes proyectos de manera muy directa.

Nadie es infalible y un analista funcional tampoco lo es. Habrá errores (independientemente de que la causa de los mismos sea provocada por circunstancias adversas en el proyecto o no), puede que en este proyecto sean muy pocos y que en otros sean mayores, por eso es importante que el analista lo tenga asumido desde un principio, como también lo es que de esos errores se debe aprender y que resultarán fundamentales en la formación del mismo. Al final esos errores terminan curtiendo y permiten que cada vez los análisis que se realicen sean mejores. Por tanto, la experiencia resulta importante. En cualquier caso, suponer un análisis perfecto es suponer que en un proyecto se dan circunstancias ideales y que todas las variables que pueden influir en que las cosas vayan mejor o peor, están todas a favor.

De todo lo comentado en los párrafos anteriores se extrae que es importante que un analista funcional sea un buen comunicador, primero con el usuario ya que resulta fundamental que el usuario conozca todo lo que hemos entendido y cómo se pretende llevar a cabo (no conseguir eso es ir a ciegas) y segundo con el equipo de proyecto ya que tiene que trasladar a documentación y hacerles entender la interpretación de lo que el usuario quiere y cómo lo quiere.

Un buen análisis funcional no asegura el éxito del proyecto, ya que la ejecución técnica del mismo también tiene un peso importante, pero lo que sí es seguro es que si el análisis funcional no es bueno, la ejecución técnica difícilmente puede salvar las deficiencias del mismo y tocará corregir el producto una vez construido y además, por regla general, en diferentes evoluciones, lo cual es muy costoso y tampoco asegura que ese árbol que empezó torcido, termine por enderezarse.

Hay muchos jefes de proyecto o gerentes que ni lo dudan, en el momento en que un proyecto se detecta que se puede ir en lo económico (o directamente ya se ha ido) se ponen en contacto con el cliente para intentar buscar una solución. La solución suele pasar siempre en primer lugar por pedir más dinero y si no es posible por intentar reducir el alcance.

Mi opinión al respecto es que buscar una renegociación de los acuerdos de un proyecto cuando existen desviaciones debería ser algo obligatorio para cualquier responsable de proyectos de una empresa de desarrollo de software, eso sí, no vale en todas las circunstancias, aplicado el intento de renegociación sin unas razonas objetivas puede provocar que, en ocasiones, sea peor el remedio que la enfermedad.

En el proceso de renegociación hay que tener en cuenta que, siempre, siempre, tiene la sartén por el mango el que paga y que por muy hábil que sea la persona que negocia o muchas razones que tenga, la sartén siempre la tiene quién paga, lo cual lo pone en unas condiciones muy ventajosas en el proceso de negociación (y casi todos los clientes saben que tiene ventaja y no todos los proveedores que buscan una renegociación son conscientes de esta circunstancia).

¿Es malo que el cliente tenga la sartén por el mango? Evidentemente nunca es bueno negociar en desventaja, pero por lo menos si se es consciente de quién tiene todas las de ganar, se sabe de qué va el juego y eso es un tanto a favor, ya que por lo menos se es consciente de cómo se debe enfocar la renegociación (al menos, en términos generales).

Como ya dije en el post, Lenguajes distintos, personas distintas, no se puede abordar un proceso de renegociación igual con todo el mundo, ya que cada persona es distinta, por lo que una estrategia que puede ser apropiada para un individuo, para otro puede producir el efecto contrario. Por eso es importante conocer lo mejor posible al interlocutor o posibles interlocutores.

Por regla general, la gente tiende a ser sensata (aunque el grado de sensatez puede verse afectado en función de lo que la renegociación afecte a la cartera) si se exponen argumentos sensatos, es decir, si se demuestra que se ha trabajado bien, que se ha ido haciendo todo lo que se ha pedido, que se ha ido informando convenientemente del avance del proyecto (por eso insisto tanto en la importancia de la comunicación con los clientes) y que el proyecto efectivamente tiene un alcance que supera lo previsto inicialmente (o que se han producido una serie de circunstancias ajenas al equipo de desarrollo, perfectamente demostrables, que han provocado una desviación de los costes del proyecto). Otro aspecto importante es que si se van a producir desviaciones el cliente las conozca cuanto antes, de la misma manera que conozca lo bien que se está trabajando, de esta manera se evita la situación de “sorpresa” que puede tener la solicitud de una renegociación si no hay indicios previos de que pueda ser necesaria.

Si se disponen de esos argumentos, la renegociación tiene más posibilidades de llevarse a cabo con éxito (no hay una fórmula que asegure que la negociación salga en los términos deseados) y digo, más posibilidades, ya que dependerá de muchas circunstancias llegar a un acuerdo que sea plénamente satisfactorio. En cualquier caso, siempre hay que intentar salir mejor que como se llegó (y en el peor de los casos igual), si se intenta renegociar con las manos vacías (desviaciones provocadas por una actitud negligente del equipo de proyecto, por una oferta que no se ajustaba a la realidad, etc…) lo mismo se salé mucho peor.

Otra de las cosas que he aprendido en estos años, todavía escasos, de experiencia profesional, es que la Ley de Murphy castiga sin piedad a los proyectos de desarrollo de software en cualquiera de sus ámbitos (desarrollo, gestión, etc…) y quien piense lo contrario que recuerde todas aquellas demos donde todo parecía controlado y algo fallaba (no necesariamente el sistema de información que se iba a enseñar).

Por ese motivo, intento que en la medida de lo posible queden en los proyectos los menores cabos sueltos posibles, ya que una cadena es tan fuerte como su eslabón más débil. El hecho de intentar no dejar cabos sueltos, no quiere decir que no se sea consciente de que siempre se quedarán algunos sin atar, algunos de forma inconsciente y otros por no haber sabido detectarlos o haber tomados decisiones equivocadas. Lo importante de todo esto es que si se está en la mano resolver un problema en un proyecto, la decisión más adecuada desde mi punto de vista no es huir hacia adelante sino resolver el problema (independiente de que sea costoso o complejo) porque tarde o temprano pasará factura.

En cualquier caso, tampoco es conveniente tomar eso como una regla general sin pensar en las características del proyecto que se está desarrollando (técnicas, económicas, temporales, etc…), porque en un mundo tan complejo como el desarrollo de software, siempre habrá excepciones y circunstancias donde la solución más lógica no es la más adecuada o donde la solución que funciona en muchos casos no funciona en un proyecto concreto. Por tanto es importante siempre minimizar el número de cabos sueltos, resolverlos lo antes posible cuando son detectados y aplicar siempre el sentido común a la hora de priorizar la resolución de problemas y la propia evolución del desarrollo.

Tener en la plantilla de tu organización, personal con un alto nivel técnico es muy positivo, de hecho es una condición importante para alcanzar el éxito en la misma. No obstante, a esos galácticos, cuya función principal debe ser pensar en innovación y desarrollo por un lado y por el otro dedicarse a resolver las tareas más complejas de los proyectos, por otro, se les suele dar otras responsabilidades como la gestión de proyectos, gestión económica, gestión de recursos humanos, etc… No digo que este perfil de personas no sea capaz de hacerlo, es más, mucho de ellos lo harán extraordinariamente bien, lo que pasa es que la cabra tira al monte y las personas con alto nivel técnico siempre tiran a la técnica y pueden olvidar otras tareas que son absolutamente necesarias en el puesto que le han asignado, es decir, si ya eres jefe de proyecto, no te puedes centrar exclusivamente en la solución técnica del proyecto o incluso programar, sino en cuidar otros aspectos como la gestión de recursos del proyecto, costes, relación con clientes y/o usuarios, comunicación, gestión comercial, etc…

A los galácticos hay que acompañarlos por personas que teniendo el conocimiento necesario del negocio, tengan otras habilidades y que sean el complemento que requieren ellos y la organización para que la maquinaria funcione.

La falta de comunicación es una fuente de problemas ya que como nadie tiene una máquina para leer el pensamiento, al final, cada cual interpreta una determinada situación a su manera y generalmente, si existe un conflicto, la interpretación además, en la mayoría de los casos tenderá a ser negativa, lo cual tenderá a agravar las circunstancias.

Cuando el problema se presenta, la falta de comunicación no lo va a solucionar, por lo menos, a corto plazo, después el tiempo puede borrar cosas y poner las cosas en su sitio, pero todo ese tiempo que ha pasado, es tiempo perdido.

La comunicación no garantiza resolver un problema, pero el hecho de que no sea infalible no quiere decir que no sea un buen recurso para eliminar un problema o un malentendido o ayudar al menos a relativizarlo o contextualizarlo y además ayudará a que la bola de nieve no siga creciendo, ya que el silencio es un acelerante.

¿Puede la comunicación empeorar un problema? Depende del uso que se le quiera dar a esa bandera blanca, es decir, si se quiere utilizar para arreglar una situación o si se quiere utilizar para atizar a la otra persona.

La comunicación es un instrumento que puede ser empleado o no, que en el caso de ser empleado, puede ser utilizada correctamente o provocar efectos negativos, con sus pros y sus contras, entiendo que los beneficios que puede aportar superan a los riesgos y que permite evitar problemas y malos entendidos y que en el caso de que se produzcan ayudan a eliminarlos.

Por todo lo anterior considero que la comunicación es esencial en un proyecto de desarrollo de software, siempre será mejor un exceso de comunicación que su ausencia y siempre será mejor andar con certezas que con suposiciones.

El planteamiento de un marco común de trabajo, se articule de la manera que se quiera (framework único, libros blancos de desarrollo, metodologías de calidad, guías de buenas prácticas, consensos entre los miembros de un departamento, etc…), desde mi punto de vista resulta de mucho interés para conseguir productos finales que a la larga sean más fácilmente mantenibles.

Todo lo anterior además debe ser compatible con el objetivo final de cualquier proceso de desarrollo de software que es la entrega de un producto que sirva al usuario y funcione, sin esta premisa, como ya he comentado en otros artículos, de nada valen que se cumplan todas o la mayoría de las iniciativas de calidad del software que acompañen al proceso de desarrollo, ya que el primer mandamiento que debe cumplir toda aplicación informática es la verificación de los requisitos del usuario (además de otros importantes como la usabilidad, seguridad, etc…) y por tanto que satisfagan sus necesidades.

No deben ser aspectos contrapuestos o incompatibles conseguir productos software que sirvan y funcionen y que sean acordes con un marco común de desarrollo, es más, resulta más que razonable que si tiene que haber excepciones sobre ese marco, las haya, siempre y cuando estén justificadas por el propio proyecto en sí. No aplicar esa flexibilidad, sería ir en contra de lo que es el propio proceso de desarrollo de software en sí, donde no todo es previsible o planificable y donde una solución concreta puede requerir una estrategia, una técnica o unos recursos no contemplados dentro de una metodología de calidad o de desarrollo y que no por ello se deberían impedir su utilización si permiten resolver el problema de manera eficiente.

Comenta el blog Genbeta, el “mal rato” que pasó Steve Ballmer en la reunión anual de accionistas de Microsoft, por las preguntas que le hicieron determinados accionistas.

Estas preguntas estaban centradas en la necesidad de mejorar en marketing para intentar relanzar la imagen de la compañía.

Creo que para todos es evidente que Microsoft tiene un grave problema de imagen, ya que se le ha asociado la imagen de enemigo del software libre, de elaborar productos más orientados a los resultados de la compañía que a los usuarios, de haber perdido capacidad innovadora (los dos factores anteriores, da un imagen como una empresa que desarrolla productos de una generación anterior), de ser un látigo para la competencia, etc…

A todo lo anterior hay que sumarle otros aspectos como el mal sabor de boca que han dejado algunos productos suyos como es el caso de Windows Vista o Zune.

En lo que respecta al problema de imagen Microsoft no ha sido víctima de nada, sino que esta misma empresa no ha enfocado nada bien sus campañas de marketing, ya que se han olvidado de que tienen competencia (este es el problema de quien está dominando de manera clara un determinado sector, como el de los sistemas operativos, desde hace muchos años). De esto, como he comentado en diferentes artículos se han aprovechado todos sus competidores. Un ejemplo de todo esto lo tenemos con la imagen de enemigo del software libre de Microsoft, tras la cual se han parapetado todas las actuaciones que han realizado gigantes como Apple, Google, Oracle, etc…, que aunque participen o subvencionen algunos proyectos de software libre, sus productos estrella y la línea principal de sus negocios se basan en software propietario puro y duro, que además lo seguirán siendo, salvo sorpresa, por muchos años.

El marketing es fundamental siempre y más en un entorno tan competitivo como en el que se mueve Microsoft. Apple ha sabido manejar muy bien los tiempos del marketing (de hecho tener algo que sea de Apple, se ha asociado a tener algo guay) y lo ha acompañado con productos sensacionales e innovadores, lo cual ha tenido un impacto muy importante en el mercado y, en consecuencia, en el balance de la compañía.

Microsoft debe reaccionar y no sólo en marketing, el entorno ha cambiado y ahora tiene competencia real y fuerte en todos los sectores, hasta incluso en el de los sistemas operativos, con productos de gran calidad y tremendamente innovadores. Si Microsoft no reacciona lo puede pasar muy mal, ya que lo más lógico es que dada la competencia que tiene, por ejemplo, en los sistemas operativos (Mac OS, Linux, próximamente Chrome OS), lo normal es que pierdan cuota de mercado, ya que hay más donde elegir y esa pérdida de cuota de mercado tendrá resultados directos sobre los balances de la compañía.

Yo espero que Microsoft reaccione, ya que necesitamos a esa empresa, necesitamos que exista una competencia viva en el sector, que proporcione innovación y cada vez mejores productos.

Una de las claves del compromiso es la motivación. No somos robots y por más que nuestro carácter y personalidad sea tendente al compromiso y el entorno laboral y el trato de la empresa también lo favorezca, es importante el ingrediente de la motivación, que permite mantener sano el compromiso y si cabe darle un plus.

Por este motivo, entiendo que no se deben tratar a los recursos humanos de una organización como robots y que hay que tratar cada caso de manera individual de manera que cada persona se encuentre realizando en cada momento el trabajo o tarea en la que se encuentre más motivada. Evidentemente, esto tiene sus matices:

1) No siempre es posible realizar la asignación de personas a tareas que le resulten motivantes, ya sea porque está cubierto el cupo de personas asignadas a las tareas que a un recurso le resultan motivantes, porque no existen esas tareas motivantes (imaginemos que una empresa de desarrollo de software tiene una línea de desarrollo en un determinado lenguaje de programación y ahora no hay trabajo para esa línea) o cualquier otro motivo que impida que una persona sea asignada a una tarea que le proporcione esa motivación.

2) Una persona puede estar asignada a una tarea que en su momento pudo ser motivante o no y la desvinculación a la mismo no puede resultar inmediata o bien no ser posible hasta la finalización a la misma.

3) No es nada sencillo tener siempre a todo el mundo contento y motivado, ya que requiere de un conocimiento profundo de cada empleado, además escuchar cuáles son sus impresiones con relativa frecuencia y que se den las circunstancias que permitan los cambios de tareas. Esto en empresas muy grandes resulta complicado.

4) La motivación no tiene que estar asociada forzosamente a una tarea en concreto, lo mismo un tipo de tarea resulta interesante, pero no las circunstancias en que se desarrolla la misma. Por ejemplo, a un programador le puede resultar muy motivante trabajar en un proyecto I+D de minería de datos, pero lo mismo no le parece más interesante si ese trabajo es a mil kilómetros de distancia y se tiene que separar de su familia.

Aún siendo consciente de que el problema no es de fácil solución, sí que resulta lógico pensar que una tarea o un proyecto de desarrollo de software (si lo orientamos más hacia mi profesión) funcionará mejor si el equipo está motivado. Evidentemente no asegura el éxito, ya que el éxito requiere de otras muchas variables, pero si se tiene a favor el ingrediente de la motivación ya es un paso que se tiene ganado.

Para responder a esta pregunta me voy a basar en que por regla general existen dos niveles de calidad, uno el que marca el proveedor del servicio y otro el que marca el cliente.

En el caso de que alguno de los dos o los dos (cliente y proveedor) tengan un nivel de calidad, el nivel de calidad que debe tener el proyecto es aquel que tenga un umbral más alto. Una empresa de desarrollo de software podría aprovechar que el cliente tenga un listón por debajo del suyo para entregar un producto con menos calidad que la media que pretende alcanzar, pero esto aunque permite ganar algunos euros más, al final resulta contraproducente, ya que la calidad es un factor diferencial en el proceso de desarrollo de software (empresas de desarrollo hay muchas, pero que normalmente desarrollen productos con calidad, no tantas) y si se quiere tener la calidad como llave para mantener o incrementar el nivel de negocio, es necesario por un lado que la calidad sea siempre mayor o igual que la que espera el cliente y mayor o igual que el nivel de calidad establecido en la empresa y por otro crear un hábito en los procesos de desarrollo, ya que el establecimiento, seguimiento y exigencia de una calidad determinada en los mismos, hace más sencillo el cumplimiento de la misma en la mayoría de los proyectos. Sin la existencia de ese hábito, el esfuerzo por alcanzar el objetivo en cuanto a calidad se incrementa de manera considerable.

Hace unas semanas asistí a un curso que me ha resultado bastante improductivo. El mismo trataba sobre un determinado producto y sus posibilidades de integración con terceras herramientas.

¿Cuáles fueron las causas?

1) Curso inflado de horas. Es decir el curso estaba programado para X horas, cuando en realidad se podía haber impartido en X/2 horas.

2) Del curso sólo me interesaba una parte, la otra parte llegaba a un nivel de detalle que no me resultaba útil y me tentaba a desconectar.

3) El curso ha resultado muy monótono, muy plano, lo que ha hecho que no terminara de despegar y despertar interés.

4) La constante sensación de que estaba perdiendo mi tiempo, unido a que era consciente de las muchas tareas que estaba dejando sin atender (las cuales no paraban de crecer), no ayudaba precisamente a centrar mi atención

Por tanto, gran parte del problema fue por mi culpa: no elegir el curso apropiado, no conseguir alcanzar el nivel de concentración adecuado, sobre todo en aquellas secciones del curso que no me resultaban útiles y no conseguir la desconexión total con el trabajo. No obstante, no hay que restar responsabilidad al mal diseño y dimensionamiento del mismo y al no haber aplicado la metodología más idónea para fomentar el interés en el curso.