sábado, 14 de diciembre de 2013

La oportunidad de los becarios

La oportunidad de los becarios.

Se supone que los becarios se quedan a solas en verano: al frente del trabajo, ya que el resto de trabajadores (no becarios), han cogido todos vacaciones. Y claro, a los únicos que no les dejan coger vacaciones son a "los últimos en llegar".
Esto es un mito, y en cualquier cao no siempre es así. Los becarios exigen tiempo y esfuerzo para desarrollar sus capacidades, pero...¿realmente les estamos dando lo que necesitan para brillar?

La presión.

La presión suele ser el primer escollo. Siente que le vigilan, que le están evaluando de forma constante. El truco está en verlo como una motivación, una oportunidad.
Es una fuente de aprendizaje. La beca es así, y con ello, hemos de verlo en positivo. Salvo que estemos en una de esas empresas en las que los becarios se limitan a llevar cafés (por suerte, en mi empresa jamás he visto eso a un becario).
La presión hay que volverla en nuestro favor, que nos motive y nos dirija, no que nos bloquee y nos impida llegar a nuestros objetivos.
Otra forma de aliviar la presión es mediante  un tutor. En mi empresa existe la figura del counsellor, que viene a ser lo mismo. Y si bien es una gran idea, el problema viene dado cuando el tutor no se toma su trabajo en serio.

Cuando el tutor no dedica el necesario tiempo al becario.

El tutor no está para decir al becario lo que tiene que hacer. O al menos no de una forma paternalista. Debe guiar al becario impidiendo que cometa errores demasiado graves. Pero el aprendizaje incluye equivocarse. Cometer pequeños errores controlados. Aquí es donde el tutor entra en acción en su doble objetivo: que el becario aprenda, pero que la empresa no corra peligro.
La libertad del becario ha de ser proporcional a su responsabilidad: es decir, limitada. Pero no tan limitada que no pueda explorar su espacio y cometer esos pequeños errores controlados por su tutor.

Comportamientos a evitar

A continuación, revisamos algunos comportamientos a evitar por parte del becario:
  • Individualismo. El excesivo individualismo, y el hambre de prosperar en la empresa, son explotadas por algunas empresas. Por desgracia, a medio y largo plazo los resultados suelen ser nefastos para la empresa. A veces, incluso a corto plazo.
  • Impuntualidad. Aunque es complicado, es bueno combinar respeto y disciplina. Entrar a trabajar cinco minutos antes. Nunca después. Y nunca salir de trabajar antes de la hora, pero tampoco es necesario quedarse a trabajar  porque sí. Algún día revisaremos este punto en profundidad.
  • Pereza. La pereza es terrible. El no empezar las tareas inmediatamente, el postergar lo importante por lo urgente.
  • Problemático. Es una buena práctica el evitar problemas y confrontaciones. La energía generada en situaciones de conflicto está para ser utilizada a nuestro favor, no para embarcarse en disputas nimias que no van a resolver nada.
  • Competitivo. La competitividad es buena, pero ha de ser una cualidad secundaria. No es bueno en general presentarse cada mañana pensando en "superar a éste" o "ser más que aquél". Sí es bueno marcarse metas, pero no es bueno dichas metas pasen por ser más que otros. Porque al final, el camino fácil se presenta: si no puedo ser mejor que los demás...quizás sea hora de hacer que los demás sean peor que yo (y aquí es donde la zancadilla fácil, el extender falsas afirmaciones, etc., hacen que el competitivo haga su agosto).
  • Pelota. El pelota prefiere halagar en todo momento a sus superiores, o a cualquiera de quien pueda sacar provecho. Suele estar relacionado con un espíritu individualista y competitivo.
  • Arrogancia. La arrogancia es uno de los peores males. A pesar de parecer menos agresiva que la competitividad o el individualismo, la arrogancia es difícil de erradicar. Está basada en una creencia profunda en las propias capacidades, y por desgracia, no suele estar alineada con la realidad. Cuántos recién titulados me he encontrado que se creían los reyes del mundo, dueños de la absoluta verdad, e incapaces de dialogar y llegar al mínimo consenso. Su título universitario les convierte en Dioses, o ellos así lo creen. Y por desgracia, yo hace muchos años que aprendí que mi título no está para esgrimirlo en absurdas disputas. El título está para dar soporte a la curiosidad, al esfuerzo, y a la capacidad de ir más allá de las apariencias. Capacidad de aprender, porque más que nos pese, no llegamos el primer día de trabajo con  todo aprendido.

Comportamientos a seguir.

  • Aprender
  • Jugar en equipo.
  • Respeto.
  • Atrevimiento.
  • Planificación.
  • Organización.
  • Socialización: conseguir contactos y establecer relaciones.
  • Disfrutar.
Sí: disfrutar. Disfruta, suéltate y siéntete cómodo. Que no parezca que estés ahí cada día por un sueldo miserable. Madruga. Llega pronto. Haz las cosas con ilusión. Contagia esa ilusión. Yo personalmente prefiero a gente ilusionada, antes que a un crack, al típico fenómeno tecnológico en cualquier tema pero que lo hace con desgana. Y la desgana se contagia. Y esa desgana se ve en la documentación, en el código...

Y tú, ¿cómo prefieres llevar tu beca?

Fuente: este artículo está inspirado en un artículo que leí hace un tiempo en el periódico dominical de La Vanguardia.

viernes, 8 de noviembre de 2013

No te olvides de poner el Where...

Si alguna vez has programado, creo que tienes que ver y oír esto.

http://www.youtube.com/watch?v=i_cVJgIz_Cs

Ha pasado un mes sin publicar anda en este blog, y ya era demasiado tiempo. Y al ver esta entrada de forma fortuita en linkedin, no me he podido resistir. Merecía la pena ponerlo y guardar este momento. Que aproveche...

Gracias a Jorge Eduardo Olaya Perdomo por compartirlo y permitirme conocer la existencia de este vídeo. Y a Jorge Rubira, por publicarlo en YouTube. Saludos.


lunes, 7 de octubre de 2013

Trucos para un buen informe de seguimiento

Leía hace poco un artículo en el excelente blog de Javier Garzás, sobre lo que nunca debería faltar en un informe de seguimiento. Y me he quedado con una sensación de que me faltaba algo. En primer lugar, los informes de seguimiento no son algo estándar y cerrado válido para cualquier proyecto. Empezaremos por pensar en los objetivos del informe.

Objetivos del informe de seguimiento.

Este tipo de informes, se realizan periódicamente con el cliente en un proyecto (de software o de cualquier tipo). El informe de seguimiento software pretende:
  • Identificar brevemente el proyecto. Un par de frases, un resumen del plan o del proyecto en cuestión. Esto es útil en clientes para los que trabajan múltiples proveedores. Hay que tener en cuenta que estas reuniones las sufren constantemente, y el cliente necesita que "les hagamos una introducción". No podemos llegar y empezar a soltar nuestro rollo. Recordad: adaptar el mensaje a lo que necesita el cliente, no a lo que queremos contar nosotros.
  • Mostrar los objetivos del proyecto. ¿Qué se quería hacer? ¿Cuáles son los objetivos?
  • Mostrar de forma resumida el estado del proyecto (precisamente respecto a esos objetivos). El estado incluye cosas como revisión de posibles desviaciones en la fecha de fin, esfuerzos dedicados, o costes. Seguimiento de hitos y entregables. Cumplimiento del contrato, y los distintos acuerdos alcanzados. El estado supone comparar la situación actual respecto al global del proyecto: el coste total, el esfuerzo total en horas estimado, y la fecha final de entrega (entre otros). Presupone una planificación y un seguimiento respecto a la misma.
  • Mostrar los riesgos y su estado. Siempre hay riesgos. No gestionarlos, no dedicar tiempo de gestión, planificación y seguimiento no hace que desaparezcan.
  • Mostrar los problemas y su estado. Los problemas, se refieren aquí a problemas de gestión. No a incidentes o fallos del software. Los problemas surgen en cualquier momento (un entorno no disponible, una tecnología que no funciona, un profesional que se va de la empresa...). Los problemas han podido ser detectados previamente (como riesgos), o surgir de imprevisto.
  • Hitos clave y su estado. En todo proyecto suele haber fechas clave, que incluso pueden determinar el poder facturar o no todo o parte del proyecto.
  • Entregables clave y su estado. Los proyectos no son solo código. Suelen llevar otros entregables (documentos, hardware,...), y que estarán recogidos en el contrato u objetivos iniciales.

Otros posibles contenidos el informe de seguimiento.

Vamos a ver otras cosas que pueden incluirse en un informe de seguimiento, pero que hay que pensarse bien si encajan en el tipo de seguimiento que pretendemos presentar:
  • Avance del proyecto. No es lo mismo avance que estado. Al hablar de avance, nos referimos a lo incorporado desde la reunión de seguimiento anterior. Este tipo de reunión sería incremental, y trata de mostrar la diferencia respecto a lo anterior. De nuevo, este tipo de información suele darse en proyectos ágiles. Cuidado con esto, porque estamos mostrando la situación relativa respecto a un estado anterior, pero no respecto al proyecto total (eso sería un estado del proyecto). En proyectos ágiles, habría que dar también un estado, es decir, informar de cómo nos encontramos respecto al total del proyecto, informando de un coste estimado, fecha estimada de finalización, etc, etc.
  • Estado de la calidad. Soy defensor de la calidad, y creo que hay que planificarla, establecerla muy al principio, y utilizar para ello indicadores lo más objetivos posibles. Sin embargo, en el tipo de clientes que he visto en mis bastantes años de vida profesional, no metería gráficas ni un análisis semanal de métricas (pocos clientes los entenderían). Eso sí, esos análisis los haría "de puertas para adentro", y lo convertiría en un semáforo donde se indicara si dichos indicadores están bien, o si por el contrario alguno de ellos no se está cumpliendo. Este tipo de indicadores, por ejemplo, lo trataría en un informe de seguimiento técnico, no en un comité ejecutivo. Por desgracia, los indicadores de calidad no son entendibles, y pueden dar lugar a falsos equívocos, preocupaciones innecesarias. Lo que hay que hacer es evidenciar que se trabaja con calidad dentro de un margen, y que se trata no de dar un producto perfecto, sino un producto con un buen balance entre coste y calidad. Por supuesto, siempre es posible que un sistema automatizado, u otra empresa certificadora, sea quien presente el estado de la calidad.
  • Demo del software. Una demo del software, no siempre podrá realizarse con los clientes en todas las reuniones del seguimiento. Básicamente, porque una reunión de seguimiento ha de ser algo muy concreto, muy enfocado, y una revisión funcional del software puede llevarnos mucho tiempo. Por otro lado, una demo no se hace cada 1, 2, o 3 semanas. Tal vez sí en proyectos ágiles que lleven asociado un cliente deseoso de ver ese software avanzar. Pero no siempre. Una última cosa. Las demos son caras. Se dedica tiempo y recursos en preparar una demo. Y no sólo por el software: están las personas que asisten (cuyo tiempo es caro, y hay que respetar), están los datos, que han de estar listos para presentar el software (la gente no quiere ver el software, quiere ver las cosas que es capaz de hacer, y eso requiere de una preparación de datos previa).
Al final, no existe un informe perfecto. El informe debe servir al cliente y a los propósitos del proyecto. Todo lo aquí comentado suele incluir se en informes, pero hemos de recordar que no todas las reuniones de seguimiento son iguales.

Antes de presentarnos a una reunión, deberemos: establecer qué necesita el cliente, cuál es el ámbito del proyecto... De todas formas, yo recomendaría siempre al principio del proyecto establecer claramente:
  • Modelo de relación: tipos de reunión, quiénes asistirán, decisiones a revisar, periodicidad...
  • En cada tipo reunión, definir qué informe se revisará, contenido, roles (quién lo presenta, quién lo aprueba, etc).

jueves, 26 de septiembre de 2013

El necesario estrés

Hablando el otro día con un compañero de trabajo, me contaba una interesante metáfora.

Había un pescador que pescaba atunes, pero los tiburones diezmaron la pesca. Y para evitar arruinarse, tuvo una gran idea. Decidió crear una piscifactoría, criar los atunes en cautividad, y venderlos para así obtener grandes beneficios. Pronto se dio cuenta de que los atunes no se vendían tanto como él pensaba. El motivo era que tenían demasiada grasa. En cautividad, los atunes se criaban gordos, y no tenían un incentivo que les hiciese hacer ejercicio.

Recordando cómo era la pesca en el mar, pensó que los atunes libres se crian con un sabor perfecto, y hacen mucho ejercicio porque deben sobrevivir. Así que decidió traer un tiburón y soltarlo en la piscifactoría. Pronto, los atunes ganaron en calidad, mejoraron su sabor, y se criaron más sanos y produciendo unas mejores ventas. Incluso considerando las pérdidas producidas por el ataque del tiburón, merecía la pena.

Al final, el motivo era la introducción de un nivel de estrés pequeño, pero suficiente para que los atunes se vieran en la necesidad de sobrevivir, criarse ágiles y sanos.

Al final, la moraleja que comentaba con este compañero es clara: un poco de estrés es bueno. Sin un incentivo, sin la adecuada presión...la gente se relaja. Y demasiada relajación, no nos lleva a los éxitos, ni provoca que la gente se estimule en mejorar su código, su planificación, sus pruebas...

Al final, PON UN POCO DE ESTRES EN TU VIDA. ¿Pero sin pasarse, eh?

Programación eXtrema (XP)

EXtreme Programming (en adelante, XP), al igual que en otras metodologías ágiles, es una metodología adaptativa y centrada en las personas. XP agrega buenas prácticas que abarcan más allá de la gestión de proyectos definiendo aspectos más técnicos y cercanos al desarrollo software.

Las buenas prácticas de XP

XP establece unas serie de buenas prácticas entre las que encontraremos:

  • Planning Game: Este método de estimación de la siguiente iteración.
  • Entregas pequeñas: pequeñas e iterativas, las entregas en XP permiten la construcción y despliegue de forma rápida.
  • Metáfora: produce una descripción simple y entendida por todos de lo que hay que construir. De esta forma, se guía a los desarrolladores sin entrar en complejos documentos funcionales. La metáfora es fácil de comprender por el cliente y el equipo, y proporciona suficiente información para guiar la arquitectura del proyecto.
  • Programación estándar: Los programadores escribirán el código fuente de acuerdo con estándares de programación y buenas prácticas que favorezcan la comunicación. En este sentido, la buena práctica no tiene que malinterpretarse y generar una gran cantidad de documentación sobre cómo escribir código fuente.

La metáfora: ventajas

  • La metáfora ayuda a entender los elementos básicos y sus relaciones
  • Mediante ejemplos, es posible completar la definición funcional sin entrar en compleja documentación.
  • Proporciona una visión de la arquitectura, sin entrar en el detalle.
  • Establece un mecanismo sencillo de elaborar el producto y comunicar los objetivos.

La metáfora: inconvenientes

  • Por desgracia, una metáfora no da detalles y profundidad a la explicación de lo que hay que construir.
  • Los ejemplos asociados a la metáfora, pueden ser confusos, y no deben ser tomados de forma literal.
  • La metáfora, no es realmente una arquitectura.
  • La metáfora, no es sólo para los programadores, clientes o jefes de proyecto.

martes, 10 de septiembre de 2013

La nueva ISO 27001:2013 se publicará en Octubre

Más control y seguridad, es lo que promete la siguiente versión de la ISO 27001:2013, que se publicará de forma oficial el próximo mes de Octubre de 2013.

Actualización a los nuevos riesgos.

Los principales cambios incluyen las experiencias de los usuarios de la anterior ISO 27001:2005, así como una importante actualización a los nuevos tiempos y los riesgos que suponen los dispositivos móviles y la evolución de internet.

 

Mejor integración con el resto de normas.

Otra mejora incluye una mayor coherencia y compatibilidad con la estructura de las normas ISO existentes, de forma que ahora una organización tendrá más fácil integrar (y mantener) los distintos sistemas de gestión:
  • ISO 27001 Gestión de la seguridad de la información.
  • ISO / IEC 22301 Gestión de continuidad del negocio
  • ISO / IEC 20000-1 Gestión de Servicios TI
  • ISO 9001 Gestión de la calidad (ISO 9001)

Impacto en las empresas ya certificadas.

Todas aquellas empresas que ya estuvieran certificadas en la ISO 27001:2005, no deberían de tener más impacto que el que supondrá actualizarse a la nueva versión en el período de transición que se determine. Por otro lado, se pueden incluir dentro de las actividades de mejora continua, las acciones que permitan cubrir las diferencias entre la anterior versión y la nueva.

Fuentes (y más información en):

martes, 13 de agosto de 2013

SEPG North America 2013

Hoy he recibido un correo de notificación del CMMI Institute, recordando la celebración de un interesante evento que tendrá lugar en Pittsburg el próximo 1 y 2 de Octubre de 2013. Nada menos que el SEPG North America 2013, un evento anual (bueno, vale, hay otros similares en Europa y Asia, también anuales), donde se tratarán temas candentes y de actualidad como por ejemplo:
- Kanban y CMMi
- Flexibilidad Agile: cómo CMMi hará que Agile sobreviva y se fortalezca.
- Implementación ágil de CMMi
- Métricas.
- Desarrollo de Software seguro con Secure by Design for CMMI-DEV
- Microsoft IT Data Management Maturity
...y más.

Me parece muy interesante el esfuerzo por simplificar y acercar CMMI al movimiento ágil, y en general, al resto de iniciativas y tendencias actuales en el desarrollo de software. Espero que sean muy interesantes, y aunque no creo que esté presente, espero poder acceder al material de los eventos y poder estudiarlos. Algunas de las conferencias prometen bastante.

Aunque ya os he puesto más arriba el enlace principal al evento, os adjunto otro par de enlaces directos a:
- Agenda: Conferencias y ponentes.
- Acerca de: ¿Qué son las conferencias SEPG?

lunes, 12 de agosto de 2013

Feliz verano 2013

Parece mentira, pero ya ha pasado un mes desde mi última entrada en este blog. Y no ha sido precisamente de descanso. Salvo los últimos días en que por fin, sí, efectivamente estoy de vacaciones, han sido intensos. Muy intensos. Dejémoslo ahí.

Este año que entra, promete ser también...intenso. Mucho trabajo por delante, grandes retos, y las consecuentes responsabilidades asociadas. Nada que no afrontemos con una sonrisa y las ganas de repetir, como todos los años, el placer y la satisfacción de esos pequeños éxitos.

Estaba leyendo un artículo de Javier Garzás en el que presenta la calidad como la principal tendencia en el desarrollo de software para los próximos años. El artículo se basa en el estudio de la prestigiosa consultora Gartner, y presenta algunas tendencias más en el desarrollo para los próximos años. En ello estábamos...y en ello seguiremos. Según Gartner: "Para 2016, más del 50% de los contratos de outsourcing de desarrollo de aplicaciones exigirán el uso de una herramienta específica de gestión de calidad software". Interesante.

Recarga las pilas, feliz verano, y si estás de vacaciones, disfrútalas. Si no lo estás, espero que las disfrutes pronto. Nos veremos por aquí.

jueves, 18 de julio de 2013

PMO IV - Inconvenientes de una PMO

Este es el cuarto de una serie de artículos sobre PMO:

PMO I - Introducción
PMO II - Descripción
PMO III - Ventajas de una PMO
PMO IV - Inconvenientes de una PMO

Hoy repasaremos brevemente los principales inconvenientes que ofrece una PMO. Veremos que más que inconvenientes, se trata de riesgos que podemos controlar mediante las adecuadas técnicas de mitigación y contingencia.

Burocracia adicional.

Una PMO introduce procesos, metodología, y un nivel de control y supervisión de los proyectos que puede aportar mucho a la dirección. Sin embargo, desde muchos estamentos, puede considerarse que la PMO añade burocracia. El añadir flujos de trabajo, la necesidad de aprobar las cosas antes de hacerlas...hace pensar a muchos que las cosas son más lentas, que requieren de más burocracia.

Territorialismo

La PMO se ve como un órgano impuesto, y la reacción es defender el departamento/territorio del nuevo intruso.
Esta reacción lleva a muchos a comportarse a la defensiva, o incluso de forma agresiva frente a las peticiones de una PMO, rente a sus flujos  y metodologías de trabajo.
Cuanto menor control y supervisión tienen los equipos de trabajo, más fácil es que la reacción sea la que aquí comentamos.
Después de todo, muchos se sienten "reyes del mambo", auténticos caciques que hacen y deshacen a su antojo...hasta que llega la PMO.

Lastre

La PMO puede ser considerada como un servicio no productivo, un lastre innecesario o de beneficios discutibles.
El aumento de costes derivado de los sistemas soporte, formación, y otros servicios adicionales, puede verse como crítico frente a los beneficios potenciales, que por supuesto, siempre encuentra gente dispuesta a minimizarlos frente a los costes mencionados.

Obstáculo profesional

Riesgo de considerar a la PMO como un obstáculo en la carrera profesional de los equipos de desarrollo.
Normal, en muchas empresas, determinadas personas se ven con carrera por el hecho de disponer de oportunidad, de estar estratégicamente posicionados, tener cierto poder o control...Y entonces llega la PMO, y establece un flujo y metodología estándar, que coarta la libertad de los que hasta ahora se veían con un futuro prometedor.

Torre de Marfil

Riesgo de que la PMO se considere una torre de marfil, no alineada con las necesidades organizativas.
Puede ser por la actitud de los integrantes de la PMO, por envidias, o por una falta de efectividad en el funcionamiento de la PMO, por lo que este departamento se considere una "torre de marfil", inalcanzable, con demasiado poder, sin escuchar ni atender las demandas de los proyectos o la organización.

Falta de soporte

Riesgo de falta de soporte de la alta dirección, principalmente.
Sin el adecuado soporte de la dirección, la PMO no tiene poder efectivo, y puede considerarse "un bonito florero", sin utilidad ni capacidad real de llevar a cabo su función.

¿Y vosotros? ¿Os habéis encontrado con estos problemas u otros similares? Saludos
 

martes, 9 de julio de 2013

PMO III - Ventajas de una PMO

Este es el tercero de una serie de artículos sobre PMO:

PMO I - Introducción
PMO II - Descripción
PMO III - Ventajas de una PMO
PMO IV - Inconvenientes de una PMO

El de hoy va a ser un artículo que espero sea interesante y a la vez breve. Repasaremos brevemente las principales ventajas que ofrece una PMO, y también veremos en un próximo artículo, sus posibles inconvenientes. Vamos allá.

Definición y estandarización de procesos.

  • Una PMO ayuda a definir los procesos de la organización. Básicamente no es inventar nada nuevo. Basta con dejar por escrito todo lo que ya se hace, obtenido de quienes saben hacerlo.
  • La ventaja, es que esto ayuda a que no se pierda el conocimiento, se estandaricen las formas de trabajar, se aproveche la ventaja de la experiencia adquirida.

Aumento de la eficiencia.

  • De una correcta definición de procesos, del aprovechamiento del conocimiento y la experiencia, se obtiene como resultado natural un aumento de la eficiencia.

Reducción del trabajo duplicado.

  • Como resultado de la experiencia y eficiencia, se facilita el reducir el trabajo duplicado.
  • Si se han detectado duplicidades en ocasiones anteriores, ese conocimiento se aprovecha.

Menores costes de desarrollo.

  • Como resultado de los anteriores, los costes disminuyen.
  • Esta disminución no tiene porqué ser radical. Todo depende de lo optimizados que estuvieran los procesos y la organización antes de implantarse la PMO.

Mejora de las comunicaciones internas y externas.

  • Una PMO ejerce principalmente como órgano gestor de las comunicaciones.
  • Se estandarizan no sólo los canales, sino los formatos y los contenidos. Se identifican responsables de realizar la comunicación, el escalado, los distintos interlocutores, etc.

Alineamiento organizativo orientado a unos objetivos comunes.

  • El principal objetivo de la PMO es asegurar que los procesos, las tareas que se realicen, estén alineadas con los objetivos de la empresa.
  • Estos objetivos comunes, bien establecidos por la PMO, permiten que todo el mundo trabaje para un fin común. Se aprovechan sinergias.

Mejora en la planificación estratégica.

  • Ya no sólo hablamos de planificar proyectos, y hacer el seguimiento. Estamos hablando de una planificación a nivel estratégico, totalmente alineada con los objetivos organizativos.

Mejora en la madurez y profesionalización de la gestión a nivel organizativo.

  • La gestión se profesionaliza. Aumenta la madurez, apoyada por el conocimiento y unos procesos bien definidos, y una experiencia aprovechada.

Mejor formación a nivel organizativo.

  • La formación se alimenta de la experiencia de los proyectos, de las necesidades organizativas, y de las lecciones aprendidas.
  • Como resultado, la formación mejora a su vez el rendimiento en los proyectos, satisface las necesidades de la organización, y permite mejorar las lecciones aprendidas. El ciclo se cierra.

Mejora continua: el uso de lecciones aprendidas evita volver a caer en errores anteriores.

  • Los errores cometidos, permiten mejorar los procesos.
  • La gestión de riesgos mejora, permitiendo sucesivamente el prevenir errores y problemas anteriores.
  • La experiencia permite solventar problemas y prevenirlos de forma cada vez más eficiente.
Hasta aquí todo parece de color de rosa. Pero una PMO no es tan sencillo, y puede tropezar con un alto número de obstáculos, que terminen como inconvenientes para la organización que trató de mejorar su gestión. Esto lo veremos en el próximo artículo de esta serie.

jueves, 4 de julio de 2013

Ebooks gratis para este verano

Hoy os traigo una amplia colección de ebooks gratuitos, en diversos formatos (epub, pdf, mobi, doc) para que no os aburráis este verano, y para que mantengáis vuestras inquietas mentes alimentadas.

Todo viene de la mano de Eric Ligman, Program Manager de Microsoft, que nos trae un gran número de ebooks gratuitos en su blog.

Podéis bajarlos desde este enlace.

Que disfrutéis. Feliz verano.

jueves, 27 de junio de 2013

Ser ágil no es ser rápido

Hoy vamos a hablar de la diferencia entre agilidad y rapidez. Y porqué las metodologías ágiles, no tienen que ver con hacer un proyecto más rápidamente, y por tanto, con acabar antes. Cuánta confusión veo constantemente, generada precisamente por los desconocedores y los interesados en las metodologías ágiles. Los primeros, porque asocian automaticamente ágil=rápido, ya que la semántica nos induce a ello. Y los segundos, porque siembran la red de confusión en este sentido ya que tienen intereses profesionales y económicos al respecto. No hay mejor argumento de venta que el decir: ágil=rápido=barato.

Sinceramente, creo que hemos llegado a un nivel de información en la red en el que tenemos que empezar a dudar en la credibilidad de todo lo que vemos escrito, y darle un poco de trabajo a nuestro sentido común (que en ocasiones parece el menos común de los sentidos), y a nuestro sentido crítico.

Este artículo, viene inspirado en diversas entradas que estoy leyendo en las redes y que insisten consistentemente en sembrar la confusión entre estos conceptos. Y señores, no son iguales.

Podemos encontrar multitud de artículos en la web en que incluso defensores del agilismo, admiten la confusión entre estos dos términos. Pero vamos a tratar aquí de usar un poco de sentido común para entender un poco más el problema.

El concepto de rapidez en los proyectos ágiles.

En los proyectos ágiles, la medida del avance es la rapidez. Otra contradicción, por otro lado necesaria, ya que la única forma de saber cómo vamos y cuándo vamos a acabar, es utilizar esta métrica.

Al contrario que los proyectos que no usan metodologías ágiles, el estar abiertos al cambio hace que los requisitos estén permanentemente sujetos al cambio. La única forma de anticipar cuándo acabaremos, no está por tanto en medir el avance por requisitos, sino basarnos en la velocidad. La velocidad o rapidez, es por tanto, lo único cierto y medible. El resto: dependerá de cuántos cambios asumamos. Puede que ahora tengamos 20 historias de usuario. Pero pueden cambiar, y ser mañana 30, o 15...

Notemos aquí lo curioso del tema. Al hacer proyectos con metodologías ágiles, también necesitamos predecir y controlar cuándo va a finalizar el proyecto. La diferencia es la que estamos comentando, que no se basa en el cuánto (nº de requisitos), sino en el cómo (rapidez). Es por eso que los diagramas burndown chart son los principales referentes a la hora de conocer el avance y tratar de predecir cuándo tendremos el producto.

La rapidez en estos proyectos con metodologías ágiles será el número de puntos de historia de usuario (u otra métrica relativa) que realizamos por unidad de tiempo. De esta forma, si hemos estimado bien, podremos predecir el futuro.

El concepto de agilidad en los proyectos ágiles.


En las metodologías ágiles, el término agilidad o ágil está relacionado con la capacidad de adaptación al cambio. Pero no tiene nada que ver, e insisto en el NADA, con la velocidad del proyecto.

Agilidad, es la capacidad para adaptar el curso del desarrollo a la evolución de los requisitos y a las circunstancias del entorno (fuente: Navegapolis.Net, "Gestión de proyectos ágil: conceptos básicos").

Es decir, que la palabra "ágiles" en metodologías ágiles, no tiene nada que ver con rapidez del proyecto, sino con la adaptabilidad al cambio: la disponibilidad y facilidad para asumir cambios en el alcance (nuevos requisitos, o requisitos existentes).

¿Confusión interesada?

Llegados a este punto, empiezo a preguntarme si la confusión de términos no es interesada. A ver, no tengo nada en contra de los defensores del agilismo. Yo también defiendo el agilismo. Pero si lees este blog, sabrás que la cuestión no es defenderlo, sino defenderlo si aplica. No defenderlo porque sí. Todo dependerá del proyecto, equipo de trabajo, cliente, y metodologías actualmente en uso.

domingo, 23 de junio de 2013

¿Porqué a los usuarios no les gusta el desarrollo ágil?

Parece que los de ITWorld se han dado cuenta de algo que hace tiempo que vengo diciendo y que por otro lado, no es más que lo que muchos venimos observando: que las metodologías ágiles están en un punto muerto, están en crisis. Y no porque estén mal, sino porque el excesivo bombo y platillo que se ha hecho en los últimos tiempos, han hecho que se usen para todo. Sólo falta que sirvan para lavar la ropa.

Hace poco, leía un artículo de ITWorld con un título similar a este que amigo lector, estás leyendo. Y es que el problema es que por un lado, hay que entender que las metodologías ágiles han subido como la espuma sobre todo por un motivo fundamental: gustan a los programadores. Pero al final, quienes han de pagar las facturas son los usuarios y los usuarios no ven con buenos ojos unas metodologías que presentan para ellos varios problemas:

 

Los usuarios no entienden las metodologías ágiles

Se usan metáforas complejas, conceptos muy novedosos y alejados del mundo de los clientes. El tener que participar para la revisión del producto final en cada iteración, puede ser demasiado para un cliente ocupado que por otro lado, ya ha gastado demasiado en un producto que nunca termina de estar.
El término ágil en en sí mismo contradictorio, ya que no siempre implica rapidez. En muchos proyectos, se prefiere abandonar términos y palabras de moda como "ágil" o "scrum", para centrarse en conceptos más simples y cercanos al cliente.

Los usuarios quieren saber cuánto les va a costar el software.

Claro, desde el punto de vista de los programadores, es distinto. Los programadores quieren hacer un software perfecto, que requiera el mínimo mantenimiento, y que acierte al 100% con la funcionalidad deseada. Y si esto es a costa de entregar las cosas más tarde (obviamente, el tiempo se invierte en realizar iteraciones que nos permitan hacer software cada vez más cercano a lo que querían los usuarios), no pasa nada. Pero el tiempo es dinero. Y el precio final, hay que conocerlo. Los clientes suelen funcionar con presupuestos. No tienen el dinero en un cajón y tampoco lo tienen detenido. Cuesta mucho esfuerzo para un cliente presupuestar el dinero requerido para ciertos proyectos, por lo que ahora no sirve volver al consejo de dirección y decirles: "oye, necesitamos más dinero pero no os preocupéis, porque quedan pocas iteraciones y creemos que terminaremos pronto".

Los usuarios gustan de lo predecible.

A los usuarios les gusta saber no sólo lo que les va a costar el software. Además quieren saber cuándo va a estar disponible, y mucha más información del producto y proyecto final. Que sea difícil de predecir, no deja de ser algo que es problema de los informáticos, no de los usuarios.

Al hablar de iteraciones, los usuarios ven desorganización

En ocasiones, la sensación del usuario es que los informáticos se han rendido a los caprichos de los clientes. "Nos adaptamos a los cambios", decimos. Pero los clientes ven desorganización y falta de control. Y ojo, no nos obsesionemos con que esto no es así. Yo no digo que sea así. Lo importante es que el cliente sí que lo ve así. Y con esto tenemos un problema (unos cuantos ya en este artículo).

Los usuarios quieren ver el final

La sensación que percibe el cliente es que las metodologías ágiles llevan a proyectos sin final. Al no existir una fecha cerrada de entrega, sólo tienen claro que se les va a entregar un producto que sigue los requisitos (al menos, eso les hemos vendido durante muchas iteraciones). Pero no saben cuándo. Y necesitan ver el final. Porque muchas veces, cuando tenemos una fecha planificada y nos retrasamos, el cliente se puede poner nervioso. Pero si estamos iterando, aunque nosotros como informáticos entendemos que nos estamos "acercando progresivamente" al producto final...resulta que el cliente no lo ve así. Es posible, muy posible que lo que el cliente vea es un "retraso iterativo", es decir, se están haciendo cambios, y más cambios, pero la fecha se sigue escapando de las manos.
"¿No eran esto metodologías ágiles? ¿No se supone que tendría que haber terminado esto ya?"

Los usuarios quieren control

Las metodologías ágiles son buenas en entregar cosas, pero el usuario quiere el control, no dejárselo a los programadores. La percepción del cliente es que por mucho que se le involucre en la revisión de historias de usuario que entran en cada iteración, y en la revisión del producto final de dicha iteración...su control es escaso. Y lo que es peor, hay una falsa sensación de control que se confunde con exceso de poder. El usuario tiene el poder de moldear el producto final...aunque esto le lleve a dar bandazos funcionales que en el fondo, no son el control. Porque el cliente no entiende como control añadir y quitar funciones.

¿Estamos ante el fin de las metodologías ágiles? Pues no lo creo. Yo llevo usando y conviviendo con ellas desde 1999. El problema es que han pasado de grandes promesas a grandes decepciones. Se puso demasiado énfasis y demasiadas esperanzas en las que prometían ser las grandes balas de plata del siglo 21. Y no han resuelto nada de lo que prometieron. Por supuesto, en los proyectos y clientes que encajan, las metodologías ágiles suponen una ventaja.

¿Qué podemos hacer con los usuarios? Pues como hemos visto en este artículo, los usuarios, el cliente, pueden no entender o incluso ser poco receptivos a las metodologías ágiles. Y es nuestra obligación RESPETARLOS. Sí, no podemos pedir respeto para nuestra profesión, y luego tratar de imponer cosas al cliente, faltándole al respeto. Tenemos que solventar estos problemas con el usuario a base de:
  • Disciplina
  • Uso consistente y coherente de buenas prácticas
  • Educación
  • No agobiar al cliente con conceptos ágiles. Usar terminología adaptada al cliente. Somos nosotros los que debemos esforzarnos en hablar su lenguaje, NO AL REVES.
  • Formación
  • Introducción progresiva de las técnicas ágiles, aun cuando los proyectos no usen metodologías 100% ágiles.
  • Flexibilidad. Si el cliente no encaja técnicas ágiles, buscar sustitutos adecuados (sin obsesionarnos con si son ágiles o no, solamente en que sean adecuados al proyecto/cliente).
Sólo así lograremos credibilidad con nuestros clientes y éxito en nuestros proyectos.

sábado, 8 de junio de 2013

El escalado y la falta de criterio

Hoy, vamos a ver el concepto del escalado. Y aunque os puede sonar un poco teórico, no sólo no es así, sino que por desgracia, se produce habitualmente en cualquier empresa.

En ITIL, se conoce al escalado (entre otros ámbitos) dentro del proceso de Gestión de Incidentes, al caso que se produce cuando algo no se puede resolver de forma inmediata, y es necesario recurrir a un especialista (léase experto, tanto a nivel de conocimientos, como a nivel de decisión o poder), para tomar decisiones que escapan a su responsabilidad.

Es decir, se han de dar una o varias de las siguientes condiciones:
  • Ha de haberse producido un problema o incidente real
  • Ha de producirse una situación que realmente no podemos resolver
  • ...o bien ha de producirse algo que escape a nuestra responsabilidad.
¿Hasta aquí todos me habéis seguido? ¿Alguien se ha perdido? Espero que no.

Hasta ahora hemos hablado del escalado: qué es lo que debe cumplirse para que pueda producirse un escalado, y qué violaciones o negligencias se pueden realizar. Pero aún falta hablar de la otra mitad del post...la falta de criterio.

¿Cuál es el problema? Pues el problema viene cuando alteramos o manipulamos el escalado de una de las siguientes formas:
  • No se ha producido el problema o incidente que mencionamos. También puede ser que lo estemos exagerando, o que ocultemos parte de la verdad en nuestro beneficio (o en perjuicio de terceros).
  • No hemos intentado resolver la situación. La escalamos sin actuar, esperando que otro se ocupe de ello. También se conoce como "pasar el marrón" o "que le explote a otro".
  • No actuamos a pesar de ser nuestra responsabilidad. Claro, si es nuestra responsabilidad, si o si, tendremos que actuar ANTES de escalar. El problema es cuando no queremos responsabilizarnos del problema, y por eso lo escalamos (aunque tal y como hemos visto, técnicamente no sería un escalado, ya que deberíamos habernos responsabilizado primero de ello).
¿Y tú? ¿Escalas?

sábado, 1 de junio de 2013

¿Todavía quieres ser programador?

Hace cosa de un mes, estaba leyendo uno de mis blogs favoritos. Jeff Atwood es todo un elemento, una figura reconocida en la red. Y sin embargo, consiguió sorprenderme (otra vez). Y no es porque no sea un tema conocido y de candente actualidad. Me gustó su enfoque. Y es que como tantas otras ocasiones, Jeff daba en el clavo.

Yo, personalmente, me ocupo de recibir y guiar en su inicio a las nuevas incorporaciones que suelen llegar a mi oficina. Es algo esporádico, y que no suele gustar a mis compañeros. Bueno, en nuestro entorno, es difícil encontrar a gente que en general les guste hablar en público. Pero sigamos. A esas nuevas incorporaciones, les trato de contar brevemente lo que pueden necesitar, sobre la empresa y nuestro sector. Pero también me encuentro muchas veces (y no sólo en mi empresa actual, sino más bien en todas), programadores que no tienen claro cuál es su futuro.

Normalmente, todos tienen claro que quieren más en su futuro laboral: más dinero, más categoría profesional...Pero no tienen claro cómo es el negocio del desarrollo de software y la programación, y por tanto, tienen dudas. El mundo del cine, prensa y televisión nos vende como un negocio lleno de oportunidades, con gran cantidad de puestos de trabajo, y porqué no...¡guay!

Pero los jóvenes que llegan a trabajar recién licenciados, empiezan una carrera como informática, o incluso otras diferentes como matemáticas o físicas. Y me da la sensación de que no tienen claro en qué se han metido. Y no me refiero a que sea malo. Simplemente, que al ser una profesión nueva y en constante evolución, creo que no hay información realista disponible sobre el sector, enfocada a los pre-universitarios. O incluso a los universitarios.

Normalmente, en este sector, los recién titulados empiezan programando. Simplemente porque hay mucha más oferta en programación en por ejemplo ... administración de sistemas o diseño de circuitos.

El problema, es que la programación no tiene porqué gustar a dichos recién titulados. Y se nota en las preguntas que hago del tipo:
  • ¿Sabes qué es un ciclo de vida?
  • ¿Has oido hablar de la ingeniería del software?
  • ¿Cuántos tipos de pruebas conoces?
  • ¿Has automatizado pruebas funcionales?
  • ¿Has programado en algún lenguaje?

Y por desgracia, las respuestas son decepcionantes. Y seguid sentados los que defendéis que tan sólo deben programar informáticos, y que el intrusismo por aquí, y que el resto no saben programar, y bla bla bla. Digo seguid sentados, porque las respuestas son igualmente decepcionantes para los que vienen de carreras como informática (técnica o superior). No digo que la universidad no sirva para nada. Digo simplemente, que hay una brecha significativa entre lo que prepara la universidad, y la realidad de las empresas y el mercado.

Y aquí es donde viene la pregunta. ¿De verdad te gusta programar? ¿Quieres ser programador? Porque te tiene que gustar. Porque lo tienes que disfrutar. Y porque de esa manera es como puedes mantenerte actualizado, y sobrevivir a proyecto tras proyecto (y empresa tras empresa).

Jeff Atwood va un poco más allá en su blog, y plantea una pregunta con trampa: "¿Todavía quieres ser programador?". Y es que Jeff plantea que por desgracia, hay que tener en cuenta que esta profesión, no todo el mundo es capaz de aguantarla toda su vida. ¿Quieres seguir siendo programador a los 30...40...50...60? Alguno comentará que no hay problema, que a los 2 o 3 años te hacen analista, y en otros tantos, jefe de proyecto. Sí...claro. Y yo soy Mickey Mouse.

En esta profesión, como en muchas otras, no todo el mundo puede ascender para siempre de forma continuada. La carrera profesional está ahí, pero cada 100 nuevos recién titulados no pueden ser mañana 100 jefes de proyecto. No es posible. Así que hay que prepararse en nuestro sector para una pregunta clave, que Jeff sabe plantear en su blog con acierto: "¿Todavía quieres ser programador?". Porque a cierta edad (no hablo de 40 o 50 años, sino mucho antes), la ganancia en productividad de la experiencia, se ve contrarrestada por otros factores. Y no nos engañemos, hay gente que simplemente, no tiene esa pasión y esas ganas de investigar y estar al día: volver de trabajar tras una jornada agotadora y ponerse a leer lo último (lenguaje, herramienta, metodología, etc.), probarlo, etc, etc.

Hay muchas posibilidades en nuestro sector, pero hay que saber moverse. Hay muchas posibilidades en las que aplicar nuestro conocimiento adquirido tras años y años programando, y disfrutando (o sufriendo) en múltiples proyectos y en múltiples empresas y clientes. Tanto si en el fondo no te gusta tanto programar como pensabas (o como decías), tanto como si llevas tanto programando que empiezas a estar ya saturado, existen opciones como:
  • Gestión.
  • Testing.
  • Calidad.
  • Analista
  • Analista funcional
  • Escritor técnico/documentación
  • Implantador de software.
  • Ventas
En muchos de estos roles, encontrar gente realmente conocedora de los entresijos de hacer software, es muy difícil. Así que ¿porqué no aprovechar tu experiencia y conocimientos adquiridos en algo más? ¿No es eso mejor que quedarse estancado en tu carrera, siguiendo con una programación que realmente nunca te gustó, o dejó de hacerlo hace mucho?

Y tú...¿todavía quieres ser programador?

domingo, 26 de mayo de 2013

Deloitte University

Pues ya hemos vuelto de Texas, y en realidad a pesar de mi entrada anterior, la Deloitte University estaba más propiamente en WestLake, no en Dallas. De hecho, estábamos tan al norte, que el famoso desastre de los tornados en Oklahoma nos afectó y bastante. Pero bueno, eso ya es otra anécdota.

Sobre el evento, he de comentar varias cosas:
  • Formación. El enorme esfuerzo que se hace en las compañías americanas en formación. En este lugar privilegiado no sólo había directores, gerentes y responsables en general (por algo le llaman el Leadership Learning Center), sino que cantidades ingentes de nuevos y jóvenes empleados (auténticos yogurines de apenas 20 o 23 años), llegaban a cientos a este centro formativo.
  • Lujo, belleza y tecnología. Los mejores materiales, un cuidado diseño que hace pensar que estamos en un hotel de cinco estrellas en lugar de un centro formativo, eso sin olvidar que hay un cyber-center donde cualquier cosa que necesitemos, está a nuestra disposición para comprar: iPhones, iPads, portátiles, otros móviles, adaptadores, cables, etc, etc. Wi-fi gratis en todo el complejo, incluyendo la conexión inmediata de los empleados al usar sus portátiles o móviles de empresa.
  • Gourmet ¿Alguien tiene hambre? Es difícil salir de este centro formativo sin unos kilos de más. Salas repletas de comida de todo tipo se reparte por las 5 plantas del complejo de habitaciones. Pensado para los que no tienen tiempo para bajar, o simplemente quieren picar algo sin alejarse de la habitación. Después, los restaurantes con buffet o los múltiples espacios para picar habilitados junto a las salas de formación, hacen que el día se pase sin sentir (salvo en el estómago!).
  • En forma. Para compensar lo anterior, existe un gimnasio gigantesco: DTFit. En este lugar podemos encontrar desde decenas y decenas de máquinas de todo tipo, gran cantidad de actividades diarias programadas para que nadie tenga que aburrirse por su cuenta, hasta un exterior de varias hectáreas de terreno verde con árboles y muy cuidado para facilitar el running. Doy fe: no es extraño ver a la gente corriendo por las distintas pistas, especialmente a primera hora de la mañana o por la tarde.
  • Relax. Un exterior cuidado, con árboles, pistas verdes, zonas ajardinadas con iluminación nocturna, un lago con aves, tortugas, peces...
  • Sostenido. Un equipo de alrededor de 200 personas cuidan y mantienen el complejo: seguridad, camareros, cocineros, jardineros, mantenimiento, dependientes, limpieza, etc.
Así que tras este ajetreo, me pongo a pensar en lo importante que es la formación, y lo importante que es cuidar a los empleados. La mentalidad de que para rendir como los mejores, hay que invertir en nuestros empleados dándoles lo mejor, puede ser chocante. Pero no debería ser así, ¿verdad?

viernes, 17 de mayo de 2013

Nos vemos en Dallas

Bueno, aprovecho un breve hueco para comentar que estaré en Dallas (Texas, USA) la semana del 20 de Mayo, más concreto en la Deloitte University, recibiendo formación.

Y bueno, a ver si da algo de tiempo para ver alguna cosa, aunque viendo la programación del curso, me temo que veré muy pero que muy poco de Dallas.

Me parece una oportunidad increíble para aprovecharla en muchos sentidos:
  • Un viaje al extranjero. Oportunidad de practicar (aún más) el idioma cara a cara.
  • Un curso de formación. Aclarar dudas es fundamental para hacer las cosas bien.
  • Una formación a la americana. La forma de llevar los cursos en otros países es mucho más participativa, y a pesar de que inicialmente puedas pensar que distraen, la realidad es que es al revés: te involucras mucho más y se asientan los conocimientos mucho mejor.
  • Participar activamente en las políticas de calidad de una empresa, ser partícipe de muchas cosas que nos involucran después en el día a día, como son las metodologías de trabajo, plantillas. entregables...
Nos vemos en Dallas.
Un cordial saludo

sábado, 11 de mayo de 2013

El tamaño importa

He leído recientemente en algún blog, sobre la forma adecuada de medir el tamaño del software, y que ésta, debe ser contraria a la que se usa en construcción de casas.

Vaya con la maldita manía de que como se supone que el software y las casas son distintos (según algunos, radicalmente opuestos), pues las formas de trabajar, medir, etc, deben serlo también. Esto ya es incluso un caldo de cultivo para los defensores del "agilismo porque sí", ya que como una casa se hace por fases, y esto se asimila a un método de desarrollo en cascada, está claro que eso es algo obsoleto y por tanto, la forma de trabajar en el software ha de ser distinta. Interesante, pero absurda conclusión.

Para medir el tamaño del software, podremos usar Puntos Función (PF), o cualquier otra medida. En la construcción de casas, esa medida no es válida, claro está.

Tambien se suele afirmar que en la construcción de software, la unidad de medida habitual sigue siendo en esfuerzo: se paga por la cantidad de esfuerzo empleado en lugar de por lo efectivamente producido (valor). Aquí sí que tienen ventaja las metodologías ágiles, ya que se centran en el valor incorporado en cada iteración.

Creo que tenemos un problema. Somos nosotros, los desarrolladores, los que pretendemos que nos paguen por esfuerzo. No es que sea la medida habitual: es lo que habitualmente pretendemos. Los clientes no quieren saber si nos costó 1000 ó 1050 horas hacer su programa de facturación, o su sistema de control de fábrica. El cliente quiere saber lo que realmente necesita para su negocio que es:
  • Fecha: ¿Cuándo estará el software disponible? ¿Cuándo podrá integrarlo con otros productos? ¿Cuándo tendrá que tener lista la formación para su personal? ¿Cuándo tienen que estar disponibles los responsables de sistemas para su puesta en marcha? ¿Llegará el producto a tiempo para hacer lo que tiene comprometido por contrato en una fecha concreta?
  • Coste: ¿Cuánto dinero va a costar? ¿Se puede pagar a plazos? Los clientes no tienen un baúl como en los dibujos animados lleno de dinero. El dinero en las empresas, no suele estar disponible en todo momento. Depende de la facturación, de si toca o no pagar impuestos, etc. Muchas empresas necesitan pedir un préstamo para acometer pagos, incluso los previstos.
  • Calidad: ¿se cumplirán las necesidades y requisitos establecidos? ¿estarán todas las normas obligatorias recogidas? ¿Hay criterios de calidad adicionales que aporten valor (usabilidad, etc)?
Si os fijáis, estos factores son significativos. El negocio del cliente es directamente dependiente de estos factores. Un pequeño cambio en cualquiera de los tres, y podemos hacer que la empresa del cliente se arruine, y sus trabajadores acaben en la calle. Y esto sirve para todo, no solo para el software.

El coste, por otro lado, estará marcado por el mercado. Habrá productos, que si no sabemos desarrollarlos por un coste inferior al precio de mercado, tendremos un problema. Aquí está la clave: ser competitivos.

¿Entonces porqué esa manía de medir el software en esfuerzo? Pues porque es lo único que nos importa, en un entorno todavía inmaduro que parece no querer ver más allá y no involucrarse en satisfacer al cliente.

Se está huyendo de dos premisas, muy integradas culturalmente en otros sectores, pero que parece que en el software nos negamos a asimilar:
  • Compromiso. Los acuerdos se hacen mediante contratos. Y los contratos están para cumplirlos.
  • Disciplina/Ingeniería: debemos tener las herramientas y procesos adecuados para estimar y reestimar progresivamente si vamos a terminar en fecha y con el coste pactado. Y por supuesto, con la calidad pactada como mínimo.
Se oye hablar de que las casas se venden por metro cuadrado, y que esto no es válido para el software, ya que las casas siguen un método industrial (supuestamente radicalmente diferente del desarrollo software). De nuevo, otra falacia interesada.

Las casas, si se fabrican iguales, costarán un precio similar. El problema no es el método, sino que los materiales, mano de obra, etc., están muy estandarizados en la construcción de casas. Pero siempre existirán casas hechas a medida, con piezas no estándar, y que costarán un ojo de la cara (es decir, su precio por metro cuadrado, se dispara). De todas formas, si nos fijamos en las casas estándar normales...¿habéis comprado alguna casa? ¿Os habéis fijado que en mismo edificio de casas, donde dos de ellas supuestamente deberían ser iguales...no han salido igual? ¿Verdad que todas las casas no salen con los mismos fallos? ¿Verdad que si medís los metros cuadrados de todas las viviendas...ninguna cumple exactamente con lo que dicen los planos?

Por tanto, llegamos a la conclusión de que las casas no son iguales, no se construyen iguales (sencillamente porque es imposible), y se requiere una ingeniería detrás para poder conocer cuándo podrán estar terminadas, y cuánto dinero van a costar. Eso se hace con planificación y gestión. ¿Por qué no hacemos lo mismo con el software? ¿Porqué seguimos renegando de los métodos de ingeniería, pero no estamos dispuestos a que dejen de llamarnos ingenieros?

lunes, 29 de abril de 2013

El vendedor de motos

El vendemotos, es otro de los integrantes de la fauna que podemos encontrar en cualquier empresa de software. El vendemotos no tiene porqué ser siempre el comercial de turno. Hay también vendemotos en otras categorías laborales, aunque suelen estar relacionados íntimamente con otro miembro de la fauna laboral: "el trepa". De éste hablaremos otro día.

El vendemotos te venderá (si es comercial) o tratará de que se use (si es técnico) la última moda tecnológica, supuestamente consiguiendo con ello la mejor eficiencia, mayor productividad, accesible desde el móvil, con soporte para la nube, etc, etc.

El comercial vende-motos

Si es un comercial, se lo ofrecerá al cliente, para mayor horror y desengaño del vilipendiado equipo de desarrollo, que se verá obligado a tratar de implantar tecnológicas poco probadas, de escaso impacto en valor real para el cliente, pero por supuesto, con un coste y un sobre-esfuerzo que pondrá al límite tanto al equipo de desarrollo como a la economía de la empresa. Claro, esto al cliente le dará igual, porque el precio cerrado conseguirá que esto no se le transmita al cliente, que sólo verá con horror como se producen retrasos en unas funcionalidades que para él eran triviales.

El técnico vende-motos.

Si el vendemotos es un técnico, se tratará de un miembro del equipo que tratará de influir en el resto, bien por categoría (analista, jefe de equipo o de proyecto), o bien por insistencia (el auténtico pesado que te está dando la paliza para que uses el nuevo hibernate-struts-mvc-loquesea). Claro, este técnico de pacotilla, auténtica piltrafa tecnócrata, trata de colocar estas novedades...¿pero por qué? Analicemos este punto:
  • Habrá leído unos días antes de las bondades de la nueva tecnología
  • Querrá impresionar a sus responsables o subalternos con estas novedades, atrayendo hacia sí una falsa sensación de profesionalidad.
  • Quizá se aburría, y busca una forma de desarrollarse a sí mismo y a su currículum a costa de sus compañeros y empresa actuales.
  • Quizá lo usó en otro proyecto, que no se parecía a este en nada, y lo que allí le salió bien (o vio a otro que le salió bien), cree que ahora puede encajar. Me encanta cómo se desprecia el valor de la experiencia y de un buen análisis que compruebe realmente lo adecuado de las cosas en relación a los objetivos buscados.  
Después de todo, para cuando se implante la tecnología, o bien le habrá dado tiempo a aprenderlo...o bien ni siquiera la termine implantando él (ya pringará otro), o bien ni siquiera estará ya él en la empresa/proyecto. Cuántos habré visto abandonar los proyectos que ellos mismos han empezado torpedeando con arquitecturas demasiado novedosas.

El mantenimiento, también se verá gravemente afectado. Las nuevas tecnologías, en cuanto maduran, empiezan a ser realmente mantenibles y productivas, pero pobres de los proyectos que las hayan implantado cuanto aún eran novedades tecnológicas: esos proyectos serán difícilmente mantenibles, porque las arquitecturas creadas alrededor de esas novedades para poderlas "sostener", serán reduntantes. Cuántas veces hemos visto implementar en los frameworks (struts, mvc, EF,...) funcionalidades que en sus primeras versiones se han tenido que implementar "a pelo" (es decir, con sufrimiento y dolor).

¿Quién pierde?

  • Pierde el cliente, que ve tirado a la basura su tiempo y dinero, y que con suerte ve una solución cara e inadecuada que podría haberle salido mucho más barata (a corto plazo por el precio, y a largo plazo por el mantenimiento que va a tener).
  • Pierde el equipo de desarrollo, que ve cómo sus horas se disparan al tratar de hacer funcionar cosas imposibles, complejas, bizarras. Sí, habrán aprendido mucho. Me encanta ver cómo los defensores de las novedades se escudan en el aprendizaje. Para aprender, vete a la autoescuela. Cuando sepas correr, coges el Ferrari. Los peatones te lo agradecerán.
  • Pierde la empresa, que ve cómo los costes se disparan al inicio del proyecto, y se tiene que comer con patatas el precio vendido. Al final, o pone a los recursos más baratos para no arruinarse, o todo el mundo a hacer horas extras.

¿Quién gana?

  • El dueño de la tecnología, que ve cómo se usa algo inmaduro y fuera de contexto, proporcionándole un beneficio a través de los vendemotos que han caído en la trampa.
  • El vendemotos, suele ganar, ya que su enorme habilidad de escaquearse, hace que no le afecten los negativos resultados de sus gestiones o falta de habilidad.

¿Y tú? ¿Has visto recientemente a algún vende-motos?

sábado, 27 de abril de 2013

Formación 2.0 en la red.

Por una vez y sin que sirva de precedente, aquí va una entrada breve y espero que fructífera: os paso un enlace de una web con abundante meterial educativo online, y en español:

http://wwwhatsnew.com/2013/03/10/buenos-lugares-para-encontrar-recursos-educativos-en-espanol/

Hala, ahora a estudiar! Saludos

lunes, 15 de abril de 2013

Influencia de la carga de trabajo en el ángulo del monitor

Hoy os voy a relatar hechos verídicos y contrastados. Se trata de una nueva teoría científica que creo que va a revolucionar el mundo de la tecnología. Seguramente pueda vender esta teoría y jubilarme. A ver qué opináis.

Vengo observando una correlación bastante acusada entre el ángulo de los monitores de los programadores, y su carga de trabajo, que voy a ir desarrollando a continuación:

Caso 1: alta carga de trabajo.

La experiencia muestra que cuando el empleado tiene una fuerte carga de trabajo, el monitor se encuentra situado justo enfrente del mismo, de forma que éste forma una línea paralela con el eje de los hombros, y habitualmente, también con la mesa, como muestra la figura siguiente.

Además, resulta interesante destacar que esta posición es independiente de la posición en la que se encuentre sentado el responsable/supervisor del empleado.

Caso 2: baja carga de trabajo durante un corto lapso de tiempo.

La gran mayoría de casos observados permiten notar un aumento en el ángulo del monitor, que ya no se encuentra paralelo al eje de los hombros, como se muestra en la figura. Lo que resulta ya sorprendente, es que el ángulo del monitor puede ser a un lado u otro, y esta vez, sí que hay una dependencia a la posición del jefe, de forma que el jefe parece tener la manía de situarse justo donde su posición impide ver correctamente la pantalla del empleado.

Caso 3: nula carga de trabajo durante largo tiempo

De nuevo, los datos empíricos muestran que en la mayoría de casos, el monitor del empleado que lleva mucho tiempo sin recibir trabajo, acaba como muestra la figura siguiente: prácticamente perpendicular al eje de sus hombros. Para evitar el bizqueo o el colapso del empleado, éste tiende a colocarse "ladeado", corrigiendo de esta forma la postura del monitor.

Otro punto a considerar es que como ocurría con el caso 2, el jefe del proyecto tiende a situarse en el lado del empleado desde el que no se puede ver su pantalla, hecho que hemos atribuido a la mera casualidad.

Influencia de la hora.

Otro hecho sorprendente, es que especialmente en los casos 2 y 3, al principio de la jornada, y cuanto más nos acercamos a la hora de salida, el ángulo del monitor se hace todavía mayor si cabe. Sin embargo, en las horas centrales del día el monitor tiende a volver a su posición normal. De nuevo, hemos de suponer que esto es mera casualidad.

Influencia del número de monitores.

Si en lugar de un monitor, analizamos las situaciones anteriores con empleados que tengan dos monitores, ocurre algo muy curioso. El primer monitor, al que llamaremos "1", permanece siempre frente al empleado (esto es, paralelo a lo que hemos llamado su "eje de hombros"). Sin embargo, el segundo monitor, sí parece verse afectado por los casos anteriores, de forma que sufre ángulos escandalosamente extraños en función de la carga de trabajo.
De nuevo, el número de monitores y la hora del día parecen tener una correlación, de forma que el monitor "1" parece usarse en las franjas centrales del día, y es el segundo monitor (el que hemos llamado "2"), el que recibe mayor carga de trabajo en las horas tempranas, y en las horas cercanas al final de la jornada.

 

Influencia de la distancia al jefe.

Otro punto interesante digno de estudio, es que el ángulo aumenta cuanto menor sea la distancia con el jefe. Es decir, el jefe muy alejado, hace que el ángulo del monitor sea pequeño. Pero si el jefe se acerca, el ángulo se hace mayor.

¿Y tú? ¿Has observado también en tu trabajo este extraño fenómeno?

viernes, 12 de abril de 2013

Plantillas...¿para qué sirven?

Escribo esta entrada tras observar una interesante actitud en nuestra profesión, aunque por otro lado no es nueva, sino que es tan antigua como dicha profesión. La verdad es que la tenía medio escrita hace ya días, y como llevo un buen lapso sin tener un minuto libre, creo que ya es el momento de sacar esta entrada a la luz.

Por un lado, desde el área de calidad yo preparo con cariño la metodología para cada proyecto:
- Adapto los procesos y herramientas.
- Adapto las plantillas al entorno, cliente, tecnología...
- Adapto el número de plantillas y procesos a cubrir al tamaño del proyecto y sus requerimientos de rigor, etc.
- Finalmente, intento detectar gaps que me indiquen que se trabaja más de la cuenta, y no se aporta valor al proyecto o a la empresa. El objetivo es hacer lo mínimo indispensable, y buscando siempre que nada se haga dos veces en dos sitios distintos.
- Luego con el día a día, compruebo si los proyectos necesitan algo (de más, o de menos).

Dicho esto, puedo encontrarme con la siguiente situación: para comunicar algo, alguien del proyecto manda un correo al cliente usando como adjunto un word en blanco (y unas frases escritas en él, sin ningún formato, logo ni orden prefijado).

Cuando lo reviso, realmente me pregunto porqué no se usó la plantilla que yo con tanto esfuerzo había preparado. Y no es porque me haya costado tiempo. En esta profesión, desde que se es programador, hay que aprender a que el trabajo (código o lo que sea) no es nuestro. No hay que tener el apego que se tiene a una obra de arte o a un hijo nuestro. Si hay que rehacerlo, o si hay que aplicar un cambio, se acepta. Eso no significa que lo hagamos con desgana ni sin cariño. Significa que hay que aceptar esos cambios igual que se acepta que un hijo tomará su propio rumbo lejos de nosotros algún día.

Volviendo al tema, a que si recibiéramos un documento de una empresa o del gobierno, nos gustaría que dicho documento no estuviera en blanco...sino que tuviera un formato...un logo identificando al organismo o empresa que nos lo envía...Sin embargo, cuando se trata de mandar al cliente un documento...¿porqué no usar una plantilla si ésta se encuentra ya disponible? ¿No da su uso una imagen de profesionalidad, coherencia y buen hacer?

¿No tiene el código su estilo, tabulaciones, estructura y formato? ¿Porqué no hacer lo mismo en lo único que va a ver el cliente (los documentos)? ¿No es cada día más común el usar patrones y estructuras de código estándares y que de esta forma nos aceleren el desarrollo?

Yo creo que el problema está en nuestra percepción de la diferencia entre el código y los documentos. El código lo vemos como algo que es para nosotros, y por eso le dedicamos más tiempo y atención. Sin embargo, la documentación nos es ajena: es algo para el jefe, o para el cliente.

Y aquí, en mi opinión, es cuando pecamos de no aplicarnos lo que exigimos a los demás. El código que nos pasan los compañeros nos gusta que esté estructurado y cumpla un estándar, si es posible, coherente y común en todo el proyecto. Pero no sentimos la misma obligación de seguir un estándar a la hora de por ejemplo usar un documento de cara al cliente.

Hay otro problema añadido con los documentos, y es que tienen la habilidad pasmosa de salirse de contexto. Un word adjunto a un correo, tiene sentido. Pero cuando alguien lo copia y pega en otro correo...o lo guarda en una carpeta de red...ya hemos perdido el contexto. Perdemos el autor, la fecha, la empresa...(oh, claro, tenemos las propiedades del documento, que ni son obvias ni fáciles de ver, aparte de que no demuestran un autor, sino la máquina desde la que se creó).

¿Y tú? ¿Eres de los que prefieres usar un documento en blanco aún cuando existan plantillas para algo? ¿O prefieres inventar la rueda una y otra vez excusándote en la creatividad?

sábado, 23 de marzo de 2013

El síndrome de Estocolmo

Podemos encontrar en Wikipedia la definición de este tipo de desorden:

Wikipedia: El síndrome de Estocolmo es una reacción psicológica en la cual la víctima de un secuestro, o una persona retenida contra su voluntad, desarrolla una relación de complicidad, y de un fuerte vínculo afectivo, con quien la ha secuestrado. Se debe, principalmente, a que malinterpretan la ausencia de violencia contra su persona como un acto de humanidad por parte del secuestrador.

Esta definición, que nos parece tan fuera de nuestro ámbito de empresas de desarrollo de software, ocurren en nuestra industria mucho más de lo que creemos.

 

El equipo de desarrollo con el Jefe de Proyecto.

Cuántas veces hemos oído a los programadores o analistas excusar al jefe de proyecto que gestionó algún conocido desarrollo o implantación.

Por desgracia, cuanto mayor es el sobre-esfuerzo, cuanto mayores y más largas son las semanas o meses de brutal agotamiento, mayor es el síndrome de Estocolmo. Se llega a oír cómo las más peregrinas excusas surgen de los labios de quienes han sufrido de primera mano las malas decisiones, la pésima gestión (o la total carencia de la misma) de ese jefe de proyecto.

Es normal que aceptemos las imperfecciones de la gente, es correcto. Pero ya no es normal olvidarnos de las responsabilidades y trasladarlas a otros, como si un jefe de proyecto fuera una imagen de un mártir, un inocente de las circunstancias.

El programador con el Analista/Arquitecto.

Tampoco es extraño oír cómo el equipo defiende a su analista responsable, al arquitecto que definió la estructura, a quien pensó (con tan mala fortuna) las pantallas...

Pues sí, el síndrome de Estocolmo también aplica a los perfiles técnicos altos, pues tantas horas con ellos, tantas excusas ofrecidas, acaban por minar la resistencia moral. Después de todo, están con nosotros en las largas semanas (días y noches incluidos) que necesitamos para hacer funcionar sus incompetentes diseños y sus incongruentemente desorganizadas y sobrecargadas arquitecturas.

El programador con el cliente.

No nos engañemos. También podemos sufrir este síndrome con un programador. Si se trabaja mucho tiempo en las oficinas del cliente, llega a establecerse un vínculo entre el equipo de desarrollo y el cliente. Sin embargo, al pasar el tiempo y si el equipo de desarrollo sigue trabajando en las oficinas del cliente, este equipo pierde su vínculo con su propia empresa.

En este tipo de situaciones, nos encontramos con casos en que los desarrolladores obedecen al cliente, aún en situaciones en que saben que están desobedeciendo o contradiciendo las órdenes recibidas de su jefe de proyecto.

Ocurre en desarrollos, pero también en mantenimientos. En un mantenimiento, es típico ver cómo un programador sale corriendo a resolver una incidencia sin esperar a que sea notificado su registro, sin esperar a que sea revisada, escalada, etc. En estos casos, el equipo de desarrollo se preocupa solamente de contentar al cliente, y acaba trabajando como si formara parte del equipo del propio cliente.

En estos casos, llega a perderse el control de lo que se trabaja. El equipo de mantenimiento está muy ocupado, pero sus responsables no son conscientes de ello. Se registran menos incidencias de las que realmente se resuelven...incluso de llevan a cabo evolutivos a escondidas que con suerte se quedan como simples correctivos.

¿Y tú? ¿Has observado también en algún proyecto el Síndrome de Estocolomo?

viernes, 15 de marzo de 2013

De novato a experto en 10 minutos. Manual de gurupollas.

Esto es una guía de cómo actuar como un auténtico gurupollas, y está inspirada, antes de continuar, en el enlace: "De profesión experto. Manual exprés." A los que lean el artículo original, les aviso de que como siempre, aquí hay buena parte de mi cosecha. Vamos allá.

1. Escoja un tema difícil de verificar.

Si no lo puede crear, únase al último de moda. Asegúrese de que sea algo novedoso y poco conocido, de forma que nadie pueda rebatir sus escasos o inexistentes conocimientos. Cuanta más prisa se de en aparecer como referente en ese tema, más fácil será que sus círculos acaben asumiendo que usted efectivamente forma parte de esa nueva corriente de pensamiento.


2. Invente un concepto y nómbrelo en no más de tres palabras.

Una de ellas debe ser un sustantivo sonoro y contundente de no más de cuatro sílabas. Algo así como burbuja o mariposa. No trate nunca de explicarlo. Ya tratarán los demás de darle sentido. Piense en títulos de libros o películas para inspirarse.


3. Abra un blog y escriba a diario contenidos inspirados, agudos e ingeniosos sobre la materia.

Abuse de términos como sinergias, implementar y proactivo. Trate de incluir espasmódica y sistemáticamente referencias a algún libro famoso del término nuevo. O mejor: diga que participó como co-autor de dicho libro y que está en disputas legales con el autor reclamando sus derechos.


4. Tuittee intensivamente y solicite sin pudor que le retuitteen.

Cree hashtags como si no hubiera un mañana (pero nunca diga "como si no hubiera un mañana"). Retuitee cualquier twit en el que se hable del tema en que quiere venderse como experto. Se trata de que por cansancio, le acaben relacionando con ese tema.

5. Haga circular información sobre su omnipresencia digital.

Cuente a todo Dios las veces que ha sido retuitteado.  Exagere detalles y circunstancias del hecho. Siempre alguien se lo creerá. Hable de los muchos blog que escribe, libros, participación en revistas, foros, etc. Tiene que parecer que de cada 10 palabras que se escriben en internet, usted ha escrito al menos 3... y al menos otras 6 están inspiradas en las suyas.

6. Escriba un libro.

En breve será considerado  "la biblia de …" y usted "el gurú de …". Esto enlaza con una de mis últimas entradas sobre los gurupollas. Siempre puede pagar a otro para que escriba el libro...o tomar uno existente y afirmar directamente que ¡usted lo pensó primero! Deje caer en los medios sociales que va a tomar medidas legales y represalias contra el autor del libro por robar su idea. Por supuesto, no haga nada de esto en realidad.

7. Hágase con un buen enemigo. Alguien famoso e intelectualmente disfuncional que ponga en duda su teoría.

No le tema, él lo necesita más a usted. Difunda las opiniones contrarias. No hay corriente sin contracorriente. Es la llamada "dicotomía gurupóllica" (ok, me lo acabo de inventar): es cuando dos gurupollas, cada uno se inventa un término opuesto y lo defiende. En lugar de contradecirse, acaban apoyándose y logrando crear dos escuelas de pensamiento opuestas.

8. Adquiera la última versión del Ipad o IPhoney póngalo en cualquier superficie visible durante sus charlas.

Representa solvencia técnica, intelectual y económica. Vincule toda opinión humana o divina al espíritu de Silicon Valley. Si puede, lleve además otros dos o tres móviles de alta gama para apoyar que usted está metido en tantos proyectos que es capaz de necesitarlos.

9. Contrate por un módico precio a un experto anglosajón que le cite con frecuencia … en Inglés.

Mejor aún: pague a alguien en Linkedin para que haga comentarios positivos y exagerados sobre sus cualidades y participación en los proyectos. Asegúrese mencionar que en sus proyectos ha tenido alrededor de 4 o 5 veces más gente a su cargo que en la realidad. Si ha estado en algún proyecto de pasada, diga que usted fue el arquitecto y principal responsable, con todo el resto de gente a su cargo. Difícilmente nadie se lo va a contradecir, y sin embargo impresionará a mucha más gente. Además tiene que parecer que usted escribe inglés con naturalidad. De hecho, debe quedar patente que los principales diccionarios en inglés le piden a usted que los revise y los valide. Usted no es responsable de anglicismos en el castellano, sino de castellanizar la lengua de Shakespeare.

Si te ha gustado, puedes seguir con el artículo original, algo distinto, pero con muchos más pasos para convertirte de novato a experto. Enhorabuena a su autor.

Conforme lo escribía, me asustaba porque me encontraba a mí mismo tentado de usar varios de ellos en  alguna que otra ocasión. En fin. Ya se sabe que el lado oscuro poderoso es.

domingo, 10 de marzo de 2013

La gestión por falsa presión

Hola, tras el éxito del último post sobre los gurupollas, vamos a retomar la temática del desarrollo de software y la calidad.

Hoy el tema versa sobre la metodología de gestión basada en crear una falsa presión en el equipo. Hay varias formas de hacerlo. Repasaremos algunas, y creo que así me entenderéis mejor:

1. Falsa fecha de finalización.

Esta técnica, consiste en trasladar al equipo de desarrollo una falsa fecha de fin de proyecto. Es decir, si por ejemplo sabemos que el proyecto ha de estar entregado el 15 de Junio, podríamos decir al equipo que debemos entregar el 15 de Mayo. Con esto, conseguiremos trasladar una falsa presión, pedir más compromiso, bla bla bla.

¿Y qué ocurre si se llega con éxito a la falsa fecha? Pues tendríamos casi un mes para añadir funcionalidad o corregir errores y preparar documentación.

¿Y si no llegamos a la fecha de fin? Pues no hay problema, porque contaríamos con un mes de margen. Y siempre les podemos decir al equipo que somos nosotros, gracias a nuestra maravillosa gestión, quienes hemos conseguido un mes más de plazo.

Así matamos dos pájaros de un tiro: conseguimos que el equipo se esfuerce desde el minuto cero como si fuésemos retrasados antes de empezar. Y además, podremos defender que gracias a nuestra maravillosa gestión (¿qué gestión?), hemos conseguido un mes más de tiempo para que se pueda terminar con éxito.

En resumen: (a) esfuerzo desde el principio, y gratis. (b) Logramos quedar como los salvadores del proyecto gracias a nuestra gestión. (c) El cliente, consigue tener algo funcional y operativo mucho antes, y hay tiempo asegurado para cambios de última hora, documentación, etc. Eso sí, luego hablaremos del coste humano que tiene.

2. Falsa fecha de entrega parcial.

Este caso es una variante del anterior. Basta que le digamos al equipo que el cliente quiere tener una entrega funcional parcial de la solución final.

Si alguno de nuestros programadores conoce la fecha de fin de proyecto, será el truco que tendremos que usar, ya que no podremos mentirles con una "falsa fecha de finalización".

Los resultados son los mismos, pero por desgracia, los costes (más adelante hablaremos de ellos), también.

3. Funcionalidades falsas por exceso.

Hay ocasiones en que hay funcionalidades extras, que o bien interesan al jefe de proyecto, o bien estaban en el contrato como "extras" o "valor añadido".

También es posible que sean funcionalidades que detectemos que pueden venir bien de cara a la imagen del producto final, aunque realmente no estuvieran identificadas como requisitos.

Si en lugar de tratarlas como requisitos, nos limitamos a decir que son "obligatorias" y estaban "pactadas" desde el principio, tendremos una variante de los casos 1) y 2): logramos trasladar presión al equipo para empezar a esforzarnos al límite desde el principio pero no por una fecha falsa, sino por unas funcionalidades falsas.

4. Funcionalidades falsas por defecto.

Esta es una variante de la anterior (nº3), en la que el jefe de proyecto decide trasladar a su equipo sólo un subconjunto de los requisitos, pero normalmente se combina con las técnicas 1) y 2) para de nuevo, lograr una falsa presión en el desarrollo, y de esa forma, lograr con sobreesfuerzo y sacrificios lo que no somos capaces de hacer mediante nuestra capacidad de gestión.

¿Beneficios?

A continuación, veamos qué hemos logrado con todo esto:
  • Esfuerzo del 120% del equipo, desde el minuto 0
  • Trasladar un sentido de culpa al equipo de desarrollo, trasladándoles la culpa y la presión. Después de todo, el jefe de proyecto no es que no gestione porque no sepa, sino porque la falsa presión creada hay que justificarla también con una locura organizativa, falta de planes, calendarios y objetivos. Se trata de correr a toda costa para lograr los falsos objetivos parciales.
  • El jefe de proyecto consigue reconocimiento, pues es más fácil lograr el éxito, a costa del equipo y su salud.
  • El jefe de proyecto consigue quedar bien, pues aparenta que las nuevas fechas y funcionalidades son gracias a su gestión con el cliente y sus enérgicas habilidades negociadoras, y no por haber ocultado y tergiversado los objetivos en fechas y funcionalidades.
  • El cliente observa avance, esfuerzo y tiene una falsa percepción de compromiso.

Costes de esta mala praxis

¿Y esto sale gratis? ¿Tiene alguna consecuencia?
Pues claro. Veamos algunos de los costes derivados:
  • El equipo se quema muy pronto. Es fácil perder empleados que se van a otras empresas, bajas por depresión o enfermedad, etc.
  • El producto conseguido necesita corregirse, bien en el tiempo "extra" conseguido, o bien en una fase de mantenimiento. El producto suele funcionar más o menos, pero suele ser insostenible, del tipo "mírame pero no me toques". La calidad se ve penalizada, y creedme que lo lamentará el pobre mortal que se atreva a mantener este inmundo código.
  • El esfuerzo necesario para hacer la aplicación es mucho mayor, ya que la falta de documentación y la tensión necesaria lograr los falsos objetivos hacen que luego haya que retocar todo para que realmente funcione.
¿Te ha pasado alguna vez algo parecido? ¿Has observado en tus proyectos o en proyectos de conocidos alguna de éstas técnicas y/o sus consecuencias?