Jummp’s Blog

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.

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.

¿Es malo tener una referencia en el ámbito laboral?, ¿es bueno?, ¿depende de quién sea la referencia?, ¿es mejor crecer sin fijarte en nadie?, ¿qué se gana y que se pierde teniendo a alguna persona como referencia?, ¿supone la referencia un límite al que llegar o simplemente marca un camino que puede trascenderle?.

Muchas preguntas, difícil acertar en una respuesta, porque creo que depende mucho de cada uno (más que de las referencias).

Sobre este asunto y centrándome en la profesión que desempeño, mi visión sobre este asunto es la siguiente:

- En el mundo de las TICs nunca se termina de aprender, es más, como he dicho en muchas ocasiones, cada día se desaprende más, ya que todo el conocimiento que se genera es siempre muy superior a la capacidad que tenemos de asimilarlo. Las referencias son eso, referencias, sirven como baliza, como guía, para no perdernos. Si a alguien le ha ido bien y las formas y métodos que ha utilizado para que le vaya bien nos parecen correctos, ¿por qué no utilizar su comportamiento, su estilo, sus métodos para progresar en nuestro trabajo?.

- Evidentemente no tiene porque existir una sola referencia, puede haber varias y quedarnos con lo que nos parezca mejor de cada una.

- Escoger una referencia, varias o ninguna no garantiza nada, ni para bien, ni para mal, ya que todo depende del uso personal que hagamos de esas referencias.

- Cada persona tiene diferentes visiones sobre la vida y por supuesto diferentes visiones sobre lo que debe ser su trayectoria profesional y de lo que es su entorno laboral, por lo que todo el mundo no tiene por qué compartir las mismas referencias o lo que es lo mismo una referencia que para una persona puede ser válida para otro puede resultar todo lo contrario.

- Si las referencias marcan un camino, evidentemente si nos equivocamos en la mayoría de ellas nos perderemos en el camino. No obstante siempre se está a tiempo de volver a desandar lo caminado (como es lógico cuanto menos se falle, más rápido podremos progresar).

- Si en el ámbito laboral no hay referencias, tampoco podemos inventárnoslas. Mejor que existan referencias que el caso contrario, pero también mejor que no haya referencias a escoger una incorrecta.

- Una referencia no tiene por qué marcar un límite, simplemente marca un camino, los límites no lo ponen las guías que utilicemos, sino nosotros mismos.

- Nuestro estilo es nuestro estilo independientemente de que las referencias marquen un camino, nuestro sello son las trayectorias que cojamos dentro de ese camino, así como las salidas de pista que decidamos elegir.

Como ya he dicho en un artículo de este blog, yo he tenido dos influencias principales en mi trayectoria profesional aunque no han sido las únicas y seguro que en el presente y en el futuro existen o se incorporarán nuevas referencias de las cuáles seguir aprendiendo.

En una entrevista que escuché hace mucho tiempo el vocalista de un importante grupo musical español comentó que en la gira de conciertos había veces que actuaba en recintos que estaban abarrotados y otras en recintos donde había cien o doscientas personas, pero que en un caso o en otro, se decía él a si mismo y su grupo que esto es Rock and Roll y que había que dejar toda la carne en el asador.

No siempre un proyecto de desarrollo de software sale bien, no siempre el proceso de desarrollo va como la seda, no siempre se trabaja con el mejor estado de ánimo, no siempre los proyectos que se tienen asignados gustan, no siempre piensas que te escuchan, no siempre el esfuerzo lleva bajo el brazo una recompensa, etc… Y esto nos pasa a todos, nos dediquemos a la informática, al desarrollo de software o a cualquier profesión.

Desde que escuché aquellas palabras en aquella entrevista, muchas veces, cuando llueve demasiado y no tiene pinta de escampar pronto, me digo: “Esto es Rock and Roll”.

Una solución ideal puede chocar con la realidad de un entorno. Esta circunstancia provoca en muchas ocasiones el fracaso de un proyecto de desarrollo de software o una consultoría. Es importante que el resultado final se adapte a las circunstancias de la organización y de los usuarios, esperar lo contrario no es una visión real del problema. Con esto no quiero decir que no se pueda intentar mejorar el funcionamiento de un determinado proceso de negocio, pero una cosa es intentar optimizar y otra es que esa mejora tenga que ser consecuencia de un proceso previo de cambio brusco para la adaptación al resultado del proyecto.

Si hay que cambiar y este cambio debe hacerse en profundidad, lo mejor es intentar hacerlo poco a poco, con una visión a largo plazo, pero estableciendo metas a corto. Intentar ir más rápido puede provocar un rechazo del proyecto que lo avoque al fracaso o bien que provoque circunstancias que den lugar a una pérdida de la eficiencia y de la productividad, por la necesidad del período de adaptación, pérdidas esta que si se sostienen en el tiempo, también provocarán el fracaso del proyecto, ya que por encima de cualquier este se encuentra que la organización o el departamento puedan realizar su trabajo con normalidad.

Marcar soluciones realistas no es pecar de falta de ambición, ya que al fin y al cabo la ambición persigue el éxito, tal vez éste tarde tiempo en salir a la luz, pero más vale tarde que nunca.

Hace unas semanas tuve una reunión con un proveedor de software en la cual, entre otros temas, hablamos de una serie de evolutivos que había que hacer sobre un producto software que se había puesto en producción dos meses atrás. El proveedor me comentaba que si dedicabamos presupuesto a realizar esos evolutivos, podríamos quedarnos sin presupuesto para el desarrollo de algunos de los sistemas de información que estaban programados y que formaban parte de ese contrato (la famosa teoría de la manta: que si te cubres los pies te dejas la cabeza al aire y si te tapas la cabeza lo que dejas al aire son los pies).

Mi respuesta fue que dada la buena acogida que había tenido la aplicación entre los usuarios, que lo que habían solicitado no era algo desproporcionado en esfuerzo y además iba a permitirles mejorar la eficiencia y experiencia en el uso de la aplicación, se desarrollasen los evolutivos.

El motivo es que la aplicación es una realidad, ha pasado el durísimo proceso de desarrollarse e implantarse y además los usuarios se están adaptando a la misma, las otras aplicaciones son importantes también que se hagan, pero hasta el momento son proyectos, llegado el momento, si hiciera falta, se reduciría el alcance de alguna de ellas para que entrase en presupuesto, pero que lo importante es dejar la aplicación que se ha puesto en producción perfectamente rematada.