La productividad y la teoría de las ventanas rotas

La teoría de las ventanas rotas tuvo su origen en un artículo escrito por George L. Kelling y James Q. Wilson que apareció en prensa en el año 1982.

¿En qué consiste?. Lo describen de la siguiente forma:

«Consideren un edificio con una ventana rota. Si la ventana no se repara, los vándalos tenderán a romper unas cuantas ventanas más. Finalmente, quizás hasta irrumpan en el edificio, y si está abandonado, es posible que sea ocupado por ellos o que prendan fuegos adentro.

O consideren una acera. Se acumula algo de basura. Pronto, más basura se va acumulando. Eventualmente, la gente comienza a dejar bolsas de basura de restaurantes de comida rápida o a asaltar coches.»

Básicamente lo que vienen a decir es que elementos contaminantes en cualquier ámbito favorecen la aparición de nuevos elementos contaminantes.

Si nos llevamos esta teoría al funcionamiento de los equipos de trabajo en las organizaciones, estaríamos ante el caso de que personas no productivas tienden a hacer menos productivas a las personas que tienen a su alrededor y a todos aquellos que se vayan incorporando a la organización.

A los primeros porque salvo que estén muy motivados, terminarán por cansarse de ser ellos los que se implican y los que se preocupan y a los segundos porque se encuentran ya con esa situación, no tienen un buen ejemplo, es decir, si llegan a un departamento donde la mayoría pasa un 25% de su jornada laboral navegando por Internet, participando en redes sociales o escribiendo/contestando correos personales, probablemente terminen adquiriendo esos hábitos, al fin y al cabo es la situación normal en ese entorno laboral (lo anormal, es precisamente no hacer eso), otro posible ejemplo es que si en un departamento no se toman medidas contra aquellos empleados que no cumplan objetivos (por ejemplo que pese a ello se les siga promocionando), lo que vendrá a continuación es que cada vez sean más los que los incumplan porque al fin y al cabo no pasa nada.

Desde mi punto de vista, en cada organización es necesario mantener un orden y para ello es necesario que los trabajadores tengan unas condiciones laborales basadas en hechos objetivos, esto no es lo mismo que condiciones rígidas. Quien las incumpla, debe ser advertido, si las sigue incumpliendo lo mejor es que salga de la organización, tanto por el hecho de no estar respetando las condiciones que se le hayan planteado como para evitar que su conducta contamine a más personas.

Ralph Johnson. El proyecto debe funcionar según las necesidades de los usuarios, cualquier otro aspecto es menos prioritario

Ralph E. Johnson es profesor universitario y especialista en la utilización de patrones de diseño y de la programación orientada a objetos.

Precisamente por ser esa su especialidad, resulta llamativa su siguiente cita (traducción libre): «Antes de que el software sea reutilizable primero debe ser utilizable».

Y es verdad, de nada sirve un software técnicamente perfecto si después no hace lo que el usuario quiere. Si bien todo no es ni blanco ni negro, ya que no solo se debe buscar el cumplimiento de objetivos funcionales sino que también hay que pensar que el producto software va a requerir de sucesivas evoluciones y las mismas serán tan costosas como malo haya sido el diseño y la codificación (la deuda técnica).

Desarrollo de software. En seguridad parecido a desarrollo, solo que todavía peor

Hace poco asistí a un curso de SGSI. Decidí asistir al mismo ya que al estar centrado en la gestión de proyectos de desarrollo de software, existen determinados aspectos como la seguridad de la información sobre los cuales no tengo excesivos conocimientos y además necesitaba una cierta actualización de los que ya tenía.

En el curso se planteaba la problemática de que costaba implantar medidas efectivas de gestión de la seguridad de la información ya que por mucho que se trabajase y por mucho que se invirtiese, siempre se rompía la cadena por el eslabón más débil que no es otro que las personas.

El problema es la falta de conciencia de la importancia que tienen la seguridad de los activos de una entidad, la cual llega hasta los niveles más altos de la organización que no terminan de priorizar adecuadamente estas tareas integrándolas como un proceso más.

A esto hay que sumarle el hecho de que exista una creencia generalizada de que la seguridad de la información se considera algo que es función del Departamento de Informática y como tal el resto de Departamentos suelen descargarse de responsabilidad.

El Departamento de Informática se encuentra con un problema ya que ahí sí que existe conciencia de la necesidad de aplicar una serie de medidas de seguridad que no es otro que tener que liderar las distintas acciones que se tomen al respecto, sin tener el apoyo del resto de departamentos y en muchos casos sin ser considerado algo prioritario desde arriba.

Al final, mucho esfuerzo que conseguirá determinados objetivos pero sin poder llegar a las personas y con la sensación de que se está luchando solo contra molinos de viento.

En los Departamentos de Desarrollo sucede algo parecido, ¿en cuántos proyectos los usuarios no han hecho adecuadamente su labor, teniendo que suplir el equipo de proyecto muchas de las funcionalidades que no han sido correctamente definidas?, ¿en cuántos proyectos los usuarios han cambiado, incluso radicalmente, los requisitos en etapas tardías de la construcción?, pero en los Departamentos de Seguridad es incluso peor, porque los sistemas y sus resultados se pueden ver, pero la seguridad no (solo se ve cuando hay un problema, que suele ser importante y del que por supuesto se hecha la culpa a Informática).

Desarrollo de software. Los proveedores existen más allá del proyecto

Lo he comentado en muchas ocasiones. En una negociación el cliente tiene todas las de ganar frente al proveedor, sobre todo si todavía no ha pagado. Por tanto y a las malas, el cliente puede forzar en una negociación y conseguir unas condiciones beneficiosas.

Los proveedores existen más allá del proyecto y las personas que trabajan en ellos mañana pueden estar en otras empresas, por ese motivo soy de la opinión de que no se debe forzar más allá de lo que se considera justo en función de cómo ha evolucionado el proyecto, cómo se ha comportado el proveedor en el mismo y cuál es presupuesto disponible.

Si abres un abismo con un proveedor o con una serie de personas después resulta muy complicado trabajar, por muy profesional que se sea, ya que la desconfianza impide que se cierren las heridas y no es cuestión de rencor. Puedes estar enfadado, muy enfadado, pero eso se supera si la confianza no se ha roto por completo (y no es nada difícil que se haga añicos).

Si el proyecto ha ido conforme a lo pactado y el proveedor ha realizado su trabajo de manera adecuada hay que ser justos en una negociación, lo cual no quiere decir que no intentemos defender la postura de nuestra organización e intentar conseguir un acuerdo favorable. Eso es lícito y entran en juego las habilidades de las personas que intervienen, pero no se debe abusar de la posición de poder (una cosa es utilizarla a tu favor y otra golpear con ella).

A veces se termina mal, muy mal, a veces será culpa del cliente, otras del proveedor y otras de las dos partes y esto sucederá porque no siempre se puede tener todo bajo control, porque existirán presiones externas que harán todo más difícil o porque no se ha querido ver que tras el proyecto vendrán otros más.

Desarrollo de software. Programación extrema (eXtreme Programming: XP) II

En el anterior artículo se describieron los principios en los que se sustenta esta metodología. Ahora toca analizar las distintas fases que conforman su ciclo de vida.

1) Exploración

Se realiza la toma de contacto con el proceso o procesos de negocio que se van a informatizar así como con la arquitectura y tecnología de desarrollo. Básicamente se realizan las siguientes tareas:

– Historias de usuario: Suponen una de las principales novedades de la metodología y no por el producto en sí, sino por cómo se elabora. Se trata de especificaciones de funcionalidades deseadas del sistema (podrían ser comparables a descripciones de casos de uso) que realizan los mismos usuarios (el mismo cliente), por lo que sus contenidos están en el mismo lenguaje que los usuarios manejan.

Se trata de especificaciones iniciales cuyo nivel de detalle dependerá de la información que precisen los programadores para realizar una estimación del tiempo que requerirá su implementación. Más adelante, cuando se vaya a abordar el proceso de construcción, los programadores recabarán todo el detalle que necesiten para el desarrollo de la funcionalidad mediante el diálogo directo con el cliente.

A nivel documental, una historia de usuario será como una ficha, a la que se le asigna una numeración (sería como el ID de la ficha), un nombre, un autor, un número de versión (una historia de usuario puede retocarse todas las veces que sean necesarias), una prioridad, un nivel de riesgo, una estimación de tiempo de desarrollo, el número de iteración que se le asigna, una descripción y unas observaciones.

Como es puede apreciar, existen diversos aspectos que cumplimentan los técnicos del proyecto (o el mismo usuario si el técnico le facilita la información), pero la mayor parte de la ficha es responsabilidad del cliente.

– Definición de la arquitectura del sistema.

– Posibilidad de realizar algún prototipo, si fuera necesario, para determinar la viabilidad de determinadas soluciones técnicas o tecnológicas.

2) Planificación:

Los programadores realizan la estimación del tiempo necesario para implementar cada historia de usuario. En algunos casos será necesario complementarlas con spikes, que pueden ser desde simples bosquejos a mano alzada, prototipos estáticos, prototipos dinámicos, etc…, estos, en función de su complejidad, podrán ser elaborados por usuarios, técnicos o de forma colaborativa. El objetivo es intentar disminuir en lo posible el margen de error en la estimación.

Las historias de usuario pueden contener especificaciones de funcionalidades simples o complejas (composición de funcionalidades). Dado que se considera que cada historia de usuario debe ser programada entre una y tres semanas, es necesario realizar ajustes en las mismas para que entren en ese período de tiempo, de manera que si se estima que se desarrollan en menos de una semana es necesario agrupar historias de usuario y si tardan más de tres semanas, dividirlas en partes.

Una vez que las tareas de estimación han terminado, el siguiente producto a obtener es el plan o cronograma de entregas (Release Plan), en el que participan todos los actores del proyecto. En él se definen las historias de usuario que se implementan en cada iteración.

Como estamos ante un proceso de desarrollo iterativo e incremental, resulta conveniente la revisión de este Release Plan cada cierto número de iteraciones, con el objeto de ajustarlo en cada momento a la realidad del proyecto (en el desarrollo de las iteraciones pueden aparecer nuevas historias de usuario o modificaciones de las ya existentes) y de corregir aspectos de la planificación que no se hayan estimado convenientemente, como por ejemplo la velocidad del proyecto (número de historias de usuario que se pueden implementar por iteración), ya que lo mismo se ha sido demasiado optimista o pesimista.

Se considera que cada iteración debe llevar a lo sumo dos o tres semanas (hay autores que sitúan el margen entre una y cuatro semanas) y que una entrega completa (el resultado de varias iteraciones disponible para su paso a producción) no debería tardar más de tres meses.

3) Iteraciones

Se desarrolla en cada iteración el conjunto de historias de usuario que se han seleccionado para la misma. Cada una de ellas se clasifica en tareas de ingeniería que vendrían a considerarse como las entradas de trabajo para cada equipo de programadores.

A nivel documental, como sucede con las historias de usuario, las tareas de ingeniería vendrían a ser como una ficha que contendría el número identificador de la tarea, el identificador de la historia de usuario con la que está relacionada, el nombre de la tarea, el tipo (nuevo desarrollo, corrección, mejora, etc…), la fecha de inicio, su fecha de fin, el equipo responsable y la descripción.

Como se comentó anteriormente los detalles que necesite el equipo de trabajo para realizar la tarea de ingeniería los tratará directamente con el usuario.

Cuando se construye se tienen en cuenta todas las prácticas especificadas en el primer artículo: construcción de pruebas unitarias, refactorización, pruebas unitarias, pruebas de integración, etc…

Para cada historia de usuario se definen pruebas de aceptación que deben ser realizadas (como mínimo) al final de cada iteración, donde también se realizan pruebas de regresión (comprobando que se verifican adecuadamente las pruebas de aceptación de iteraciones anteriores).

4) Producción:

Se realizan pruebas adicionales y de rendimiento antes de la puesta en producción efectiva de la versión de la aplicación con la que se ha estado trabajando.

En esta fase, donde el cliente realiza la aceptación del producto que se pasa a producción pueden ser detectadas determinadas correcciones o mejoras a incorporar al sistema previo a su puesta en funcionamiento real. Sobre las mismas se puede tomar la decisión de incluirlas en esta versión o en otra sucesiva, si se decide incorporarlas, se realizarán iteraciones más cortas para llevarlas a cabo.

5) Mantenimiento:

En esta fase el equipo de proyecto debe realizar, si fuera necesario, un mantenimiento correctivo del proyecto mientras puede llevar a cabo nuevas iteraciones.

6) Muerte del proyecto:

No existen más historias de usuario que incluir en el sistema, el cual además es estable en aspectos no funcionales.

El software no se desgasta pero sí se deteriora

Además de la separación entre el mundo físico y el lógico, el hecho de que el software no se desgaste es a mi juicio una de las dos principales diferencias que tiene con el hardware, sobre todo teniendo en cuenta las tendencias actuales en el mundo del desarrollo orientadas a su industrialización, la reutilización de componentes, la delegación de funcionalidades en otros sistemas, etc… Si bien es cierto que el software tiene un componente de desarrollo a medida que es inherente a él mismo, ocurriendo esto incluso en la orientación al producto, donde en muchos casos hay que hacer adaptaciones para clientes concretos.

La otra diferencia es el propio proceso de obtención de un nuevo componente físico donde no es posible conseguir nada si no se disponen de los materiales necesarios, si se dispone de la materia prima la cadena de montaje empieza a funcionar hasta que se obtiene el producto. Es decir, la obtención de un nuevo producto idéntico a otro tiene un coste. Con el software no pasa eso, una vez construido obtener una copia es algo inmediato y sin coste. Lo mismo pasa con otros productos lógicos digitales como la música o el vídeo.

El software una vez desarrollado no se desgasta, no se estropea. Puedes dejar un programa diez mil años en un dispositivo y sobrevivirá tanto tiempo como el dispositivo que lo contiene y si antes lo has copiado garantizará su continuidad en otro (otra cosa distinta es que se pueda ejecutar o interpretar, este tema lo trato en el artículo: «La oscura era digital»).

Pero el software sí se deteriora, sufre mucho con los mantenimientos, ya sean correctivos, evolutivos, adaptativos o perfectivos (depende de lo que se quiera perfeccionar). El deterioro no tiene por qué ser idéntico en todos los sistemas. Dependerá de muchos factores: la calidad del producto final (a nivel de arquitectura y codificación), su tamaño, de si el equipo de mantenimiento es distinto del de desarrollo y ha existido un período de transición suficiente para poder hacerse cargo de la herramienta, de la urgencia con que sea necesario realizar los mantenimientos y de la cantidad de los mismos (si todo es prioritario y para ya, hay un problema) y de la metodología utilizada (si la misma hace hincapié en la refactorización del código con el objeto de controlar su nivel de calidad y simplicidad el deterioro será sensiblemente menor).

De manera objetiva pudimos comprobar esto en mi organización tras los primeros meses de implantación de Sonar.

Tu propósito, el background que te permite alcanzar los objetivos

Detrás de todas las metas y objetivos que nos marcamos y luchamos se encuentra el propósito que sirve de motor a las mismas.

Al cumplimiento de un objetivo, aparecerán nuevos retos a los cuales seguirán otros. El propósito permanecerá, podrá tener algunos cambios, pero es como nuestra sombra ya que nos acompaña a todos lados.

El propósito no algo a corto, medio o largo plazo, sino que es aquello a lo que se pretende llegar, pero es atemporal, ya que se encuentra dentro de nosotros mismos, como un molde esperando a ser rellenado. El cumplimiento de nuestras metas reúne los ingredientes, los mezcla de la forma adecuada y los vierte en el recipiente.

¿Cuál es nuestro propósito?, ¿qué nos mueve?, identificarlo resulta fundamental porque de lo contrario es como tener delante nuestra un mapa, un vehículo pero no saber a dónde ir. Conocer el destino no lo es todo, hay que llegar allí y ahí es donde entramos nosotros para poner los medios adecuados para llegar a él.

Edward V. Berard y la complejidad de desarrollar sobre requisitos cambiantes

El ingeniero de software Edward V. Berard, autor de diversos libros sobre la materia, realizó la siguiente cita: «Caminar sobre el agua y construir software desde una especificación son sencillos si ambos están congelados».

Desde luego que sucede así, sobre todo si se aplican enfoques metodológicos tradicionales a proyectos de gran tamaño y en otros donde sea complejo capturar requisitos (proceso de negocio complejo, usuarios no implicados en el proyecto, etc…) y donde resulta más apropiado la aplicación de un metodo iterativo incremental (una metodología ágil) en el que el sistema de información vaya creciendo y adaptándose según las necesidades de los usuarios.

Definir requisitos y casos de uso, por muy buenas prácticas que se empleen y por mucha experiencia que tenga el analista requieren su revisión en diversos momentos del proyecto, aunque se haya elegido una ciclo de vida en cascada. Ahora bien, si no se ha previsto esto entre todas las partes implicadas se pueden producir numerosos problemas entre las mismas, ya que se quiere introducir una variable de adaptación a una metodología de desarrollo eminentemente predictiva y el proveedor, con razón, no querrá desandar camino ya andado, mientras que el cliente sí querrá que se incluyan esos cambios que considera importantes respecto a las especificaciones iniciales pero que hasta fases posteriores no han sido detectados.

Desarrollo de software. Cuando un equipo de proyecto no se comporta como tal

No importa la metodología que se utilice, si el equipo de proyecto no es un equipo, sino simplemente es un conjunto de personas que realizan una serie de tareas pero sin ningún tipo de vinculación más, tendrá consecuencias sobre el resultado final que se obtenga.

Un equipo funciona cuando la suma de su conjunto es mayor que la suma de las individualidades. Un equipo que no funciona no solo es que no consiga eso, sino que se suele producir el efecto contrario y es que la suma del conjunto es bastante peor que la suma de lo que puede aportar cada individuo.

¿Por qué un equipo de proyecto llega a no comportarse como tal? Los factores pueden ser muchos, enumero a continuación unos cuantos:

– El jefe de proyectos o responsable de equipo no ha conseguido que se entienda que para llevar a cabo el proyecto con éxito, es necesario que todos tengan en mente ese objetivo y que no se consigue si no existe compromiso entre todas las partes.

Esto puede ser debido a un problema de comunicación, falta de credibilidad del gestor, falta de motivación por parte del equipo de proyecto (alguno se podrá preguntar, ¿qué beneficios tendré yo si el proyecto tiene éxito? y es razonable pensar en ello, por este motivo es importante que si un proyecto tiene éxito el trabajador también sea partícipe, dependiendo claro está de los beneficios reales tangibles e intangibles que obtiene la empresa con el proyecto, esos beneficios pueden ir desde premios, hasta promociones en la carrera profesional), mala elección de las personas que lo conforman (hay personas que pueden ser excelentes trabajadores, que pueden trabajar bien en equipo, pero que no pueden tener química entre sí), la suma de algunas o todas de esas variables y otras muchas más.

– El jefe de proyectos no trata de manera objetiva a todo el equipo. En el momento en que la subjetividad entra en liza, se empezarán a dar circunstancias en las que miembros del equipo estén disgustados, ¿por qué se valora el trabajo realizado cuando es como mucho igual que el que realizo yo?, ¿por qué tengo que echar más horas, mientras otras personas dedican incluso menos tiempo que la jornada laboral?, ¿por qué me caen a mi todos los problemas y a otros, que incluso tienen más sueldo que yo, les asignan tareas más fáciles?. Si detrás de estas decisiones hay criterios objetivos, las molestias serán menos y se tendrá argumentos para discutirlas si es necesario.

– El equipo de proyecto no se conoce y están acostumbrados a trabajar de distinta manera. Esta circunstancia es muy común este problema en las uniones temporales de empresa, donde además los trabajadores pueden trabajar en sedes distintas. Antes de intentar que el equipo de proyecto se alinee, lo primero que tienen que dejar de lado las empresas son sus intereses individuales, es decir, no puedes pedir a personas que sean una piña si a nivel de empresas no se intenta o consigue. Las uniones temporales de empresas no tienen por qué ser malas, pero es necesario que rompan la barrera de lo individual centrándose en la fuerza del colectivo.

– El jefe de proyecto no es una coraza para los integrantes del equipo de proyecto tanto para el cliente como para la empresa. Al equipo hay que protegerlo, no se puede dejar vendido a nadie. Si eso sucede la desconfianza entra a formar parte del día a día y la persona que debe ejercer de líder pierde su credibilidad. Esto no quiere decir que todo el equipo sea inmune, es decir, si hay personal que no hace su trabajo bien o que crea mal ambiente, puede ser relevado, pero siempre siguiendo criterios objetivos.

Desarrollo de software. Los usuarios son determinantes en el éxito del proyecto

La metodología de desarrollo, la arquitectura del software, la selección de un buen equipo de trabajo, la existencia de unos plazos y presupuestos razonables, todo eso influye en gran medida en que un proyecto de desarrollo de software salga de la mejor manera posible (nunca conseguirá la perfección y es un error buscarla).

Sin embargo el factor que desequilibra la balanza son los usuarios encargados de realizar la definición del sistema. Si sus responsables no les permiten dedicar tiempo suficiente o no les hacen ver la importancia que tiene su participación en el proyecto (si es que no se dan cuenta por ellos mismos) nos encontraremos con el caso de que muchas funcionalidades no estarán definidas de manera adecuada y tampoco la forma en que el usuario interactúa con ellas.

A lo anterior hay que sumarle un factor que se produce en muchas ocasiones cuando el usuario está obligado a participar pero no entiende su rol en el proyecto (como muchos de ellos piensan: «esto es cosa de los informáticos») y es que tampoco se sienten implicados con las decisiones que toman, lo que hará que errores propios lo trasladen al equipo de desarrollo y que no defiendan ante sus compañeros y organización determinadas decisiones adoptadas.

Otro aspecto de interés es la selección de los usuarios por parte del cliente. Supongamos que se seleccionan usuarios que están comprometidos en el proyecto y se les permite dedicar el tiempo necesario. Si todo ha ido bien en el proceso de desarrollo, tendremos un producto de calidad razonable en producción, pero, ¿estaban todos los que tienen que estar?

Me explico: Muchas organizaciones tienen sedes que en diversas zonas geográficas, incluso algunas de ellas fuera del país donde está la sede central.

Cuando se desarrolla un producto horizontal para la misma, el resultado del producto final puede afectar prácticamente a todas las sedes. Si antes del nuevo sistema, cada una de ellas utilizaba soluciones particulares para cubrir informáticamente el área o áreas de negocio que ahora contempla el nuevo sistema es posible que exista un rechazo por el nuevo producto, si este no ha tenido en cuenta necesidades que el anterior sí tenía implementadas.

Si se produce esta situación, el rechazo puede poner en peligro la viabilidad del sistema (que no se use o se utilice en paralelo con la solución antigua o basadas en productos ofimáticos), puede tener impacto en la productividad de los departamentos que utilicen la herramienta y también se verá afectada la calidad del dato, al querer en muchos casos suplir carencias de la aplicación con la grabación de datos en secciones donde no deben ir o simplemente dejando de grabar otros que resultan de interés.

La sede central de la organización debe imponer el uso de la nueva solución si no quiere que quede en desuso y establecer unos estándares de calidad respecto a los datos y documentos que se incluyen en la misma. Esto permitirá que con el tiempo y si se establece un control de la utilización que se hace de la herramienta la situación se normalice (lo hará antes si se tienen en cuenta las demandas de los usuarios de los otros centros que estén orientadas a la mejora del sistema).

Todo este problema se hubiera reducido de manera considerable si de entrada se hubiera contado con la participación de usuarios de otros centros (no será posible, salvo que sean muy pocas sedes que todas estén representadas) ya sea para el día a día de la definición del proyecto o para recibir su opinión de las decisiones que se han ido adoptando.

Un desarrollo iterativo incremental no asegura que si en un proyecto de desarrollo de software se produce alguno de los problemas descritos el sistema no vaya a ser impactado. Lo será, pero el efecto será menor que con metodologías donde el producto se entregue prácticamente completo y mucho después de haberse definido las funcionalidades.