archivo

Archivo de la etiqueta: creatividad

No se puede entender el desarrollo de software sin cooperación y sin el elemento imprescindible para que sea efectiva: la comunicación.

Cuantos más distancia (no me estoy refiriendo a distancia física) haya entre las personas y los equipos y más muros (o fosos) se pongan en medio más complicado será que el proyecto vaya a algún sitio.

La creatividad también es importante si no se pierde el control sobre la misma ya que no poseemos un recetario que ofrezca soluciones a todos los problemas.

Comenta Alistair Cockburn que: “El desarrollo de software es un juego cooperativo de invención y comunicación” y estoy totalmente de acuerdo con esa apreciación: si no sabes o no quieres jugar el trabajo se resiente.

Reducir distancias, eliminar fronteras y agilizar las relaciones requiere de mucho esfuerzo y habilidad pero sobre todo depende de que creamos que realmente es así como hay que trabajar. No basta con que lo leamos o que nos lo digan, hay que creer en ello porque mantener el equilibrio no es nada sencillo debido a que las propias contingencias de un proyecto desestabilizan y porque detrás de todo estamos las personas y no hay nada menos estable que nuestro comportamiento.

¿En qué circunstancias sueles entrar con más frecuencia en lo que los estudiosos de la productividad llaman “la zona”?, ¿suele coincidir con la resolución de problemas en los que te han dado un cierto grado de autonomía y que suponen un reto personal superarlos?, ¿suele coincidir con aquellos momentos en los que aplicas tu creatividad para dar solución a un problema o a una tarea?.

Cuando en el artículo anterior hablaba de entornos que te llenasen profesionalmente estaba refiriéndome precisamente a aquellos en los que se fomente la autonomía y la creatividad (dentro de los límites del trabajo que estás desarrollando, ya que como en otros muchos campos el exceso, en este caso, de creatividad puede dar lugar a muchos problemas).

Esa mayor autonomía hay que ganársela (y mantenerla) y eso se consigue a base de conseguir resultados dentro de los márgenes de responsabilidad que te vayan asignando.

Te pedirán unos resultados, existirán unas ciertas reglas del juego (procesos, condiciones contractuales con el cliente, etc…) y unos ciertos puntos de control (que serán más frecuentes y con más detalle en función de la naturaleza de los trabajos y del grado de autonomía que te hayas ganado).

¿No prefieres trabajar en un entorno así?, ¿no te importa eso y sí el sueldo que recibes? Cada cual tiene en la vida unas prioridades y las respeto, este artículo y el anterior los publico con el objetivo de que reflexionemos sobre esto.

Nuestro primer instinto puede ser intentar conseguir el mayor sueldo posible pero pasado un tiempo se empiezan a valorar más otras cosas si estás en un trabajo en el que no progresas (y no me refiero necesariamente a conseguir ascensos), en el que todos los días hay una crisis o en el que estás encorsetado y no tienes prácticamente margen de maniobra no es precisamente el sueldo lo que tiene más importancia. Es posible que el salario que cobres, la situación del mercado laboral o tu situación personal te tengan atado a tu organización pero probablemente si tuvieras la oportunidad aceptarías irte a otro entorno laboral que te llenase más profesionalmente incluso cobrando menos (siempre y cuando se supere el umbral de lo que consideras necesario para vivir).

El desarrollador de software, por regla general, es creativo. Esa creatividad lleva en muchas ocasiones a incrementar la complejidad del producto bien sea añadiendo funcionalidades innecesarias o por querer hacer filigranas sobre funcionalidades que son importantes o sobre aspectos más internos del desarrollo como la arquitectura o la programación.

La complejidad adicional puede ser bienvenida si realmente aporta un valor proporcional al esfuerzo necesario para llevarla a cabo. El problema realmente se produce porque la complejidad añadida no suele tener aparejado ese beneficio y se convierte al final en un lastre con el que tenemos que cargar y que no siempre resulta sencillo quitárnoslo de encima.

Sobre aspectos técnicos (salvo en proyectos con usuarios con el perfil adecuado) el usuario no va a entrar a valorar tus decisiones por lo que en estos casos se requiere una cierta disciplina personal para ser práctico, diseñando un software de calidad pero sin entrar en excesos que pueden poner precisamente en peligro ese nivel de calidad o incluso la posibilidad de alcanzar las expectativas por incurrir en un coste excesivo en este tipo de tareas.

Sobre aspectos funcionales sí que debe ser el usuario el que tenga la última palabra (no entro a valorar las situaciones en las que hay que discutir aspectos presupuestarios que condicionarán hasta dónde se puede llegar con el presupuesto existente en base al esfuerzo invertido en las tareas realizadas hasta ahora).

Claro que podemos expresar nuestra opinión y debatir con el usuario (toda propuesta es mejorable), incluso mostrarnos con una cierta vehemencia en lo que creemos que es lo más correcto, pero al final la decisión debe ser siempre del usuario (aunque se equivoque y le hayas advertido) porque de lo contrario te estás echando a la espalda una responsabilidad que no te corresponde y que después te saldrá cara y por otro lado porque si desarrollas funcionalidades que no ha pedido el usuario pocas veces te lo agradecerán, lo más probable es que tengan menos utilidad de lo que crees y seguirás teniendo que hacer los desarrollos que estaban pactados.

La siguiente reflexión de Dave Thomas resume toda esta situación (traducción libre): “Si trabajas con el usuario con una mayor proximidad. Si trabajas interactivamente con el usuario ya sea diaria o semanalmente, el usuario tendrá la capacidad de indicarte cuando es tiempo de parar. No le permitas a los programadores añadir funcionalidades solo porque piensen que podrían ser una buena idea. Añadir funcionalidades debería ser una decisión del usuario y no una decisión del programador”.

La cultura del miedo es una mala estrategia, por un lado afecta a la iniciativa de los empleados que buscarán siempre que sea posible la aprobación de un superior antes de realizar una acción o de entregar un trabajo (incluso por encima de los que marquen los procesos establecidos en la organización, si es que existen).

También afectará a su productividad porque saltarán siempre más dudas de las necesarias antes de ejecutar cualquier acción.

La creatividad también se verá afectada ya que existirá temor por salirse de la línea establecida.

Y yo destacaría, sobre todo, que va a afectar a la propia comunicación dentro de la organización y la credibilidad de los datos que se manejan. En un cultura del miedo, donde por cada acción que se entienda incorrecta puede dar lugar a consecuencias severas, quien quiera conservar su posición o su puesto de trabajo, tenderá a maquillar resultados y a ocultar información, haciendo todavía más daño tanto a él como a su propia organización (ver, por ejemplo, el antipatrón “migración de coste“).

Es lógico que si alguien comete errores y los mismos tienen impacto, que estos tengan consecuencias, pero tras un análisis objetivo de qué es lo que ha pasado, conociéndose previamente qué tipo de actuaciones pueden dar lugar a acciones por parte de la organización (que no necesariamente pasan por el despido o por tocarte el variable).

Por tanto, el personal de la organización debe saber que si actúa de manera positiva tendrá recompensas y si actúa de manera negativa (sobre todo negligente), todo lo contrario y también ser consciente de que no se está trabajando en un entorno donde cualquier error, sea del tipo que sea, provocará una reacción en su contra que además será desproporcionada en la mayoría de los casos.

Tan negativo como la cultura del miedo es la cultura de la tranquilidad o la cultura del nunca pasa nada, es decir, pase lo que pase o haga lo que se haga prácticamente nunca tendrá consecuencias ya sea al conjunto de empleados de la organización o a un grupo de empleados concretos de la misma (ver, por ejemplo, el antipatrón “el niñito de oro“).

La creatividad de los desarrolladores de software es una de sus grandes virtudes (tal vez la que más) y mal empleada, uno de los mayores defectos.

Hay veces donde hay que crear, otras donde el trabajo a realizar está restringido al ámbito de un proyecto y donde resultas más conveniente ser práctico que complicar un desarrollo por intentar saltarse sus propios límites o el propio contexto en el que se encuentra el proyecto.

Teniendo en cuenta que la creatividad produce resultados y puede marcar diferencias si se aplica en aquellos proyectos y ámbitos donde es necesaria, resulta de interés crear el contexto adecuado o caldo de cultivo donde la misma pueda ser expresada, sin olvidar de lo necesario que resulta educar a los desarrolladores sobre los momentos en que resulta más adecuado ceñirse al guión establecido.

Me gusta esta reflexión de Frederick Brooks porque ofrece una visión romántica de lo que es un programador (traducción libre): “El programador, como el poeta, solo funciona si se encuentra un poco retirado de lo estrictamente racional. Construye sus castillos en el aire, desde el aire, creando a través del esfuerzo de la imaginación. Pocos medios de creación, son tan flexibles, tan sencillos de pulir y reconstruir y tan fácilmente capaces de concebir grandes estructuras conceptuales”.