La clave está en la dirección integrada de proyectos… no lo digo yo sino José Antonio Pantoja, jefe de la División de Project Management de Apia XXI, empresa dedicada a la dirección de proyectos para la administración en el artículo publicado en negocios.com . Principalmente Apia XXI se dedica al sector de la construcción (aunque en sus áreas menciona otras incluyendo las tecnologías de la información) sin embargo leyendo el artículo de un modo “diagonal” en un primer momento no detecte este hecho y me pareció que lo que indicaba coincidía con mi parecer al respecto de los sistemas informáticos en la administración.

Una vez releído y visto que se aplica en especial a la ingeniería (industrial se sobreentiende) y arquitectura aún me ha parecido más interesante. De forma habitual, por lo menos hasta hace poco tiempo, la dirección de proyectos delegada en profesionales externos a la obra parecía ser aplicable a otros campos excepto al desarrollo de sistemas informáticos. Sin embargo la especialización en técnicas de control, procedimientos de trabajo, labores de seguimiento son tanto o más importantes que para otros campos. El campo de los sistemas informáticos además de la gestión, coordinación, presupuestos, proveedores, calidad y demás facetas a realizar cuenta con un gran hándicap, la intangibilidad del producto. Esto hace que el avance de la producción, cumplimiento de objetivos, calidad de la solución, seguimiento del plan trazado se de en porcentajes ambigüos basados en la apreciación del cliente o peor del productor. Leed el artículo y ya me diréis si aplica.

Afortunadamente la ampliación de los conocimientos y profesionalidad de los responsables de la administración está haciendo más habitual la contratación de oficinas técnicas o tareas de dirección integral de proyectos de forma separada a la contratación del sistema dotando de mayor garantía de éxito en la calidad de los proyectos iniciados. Así lo reflejan los diferentes concursos para la creación de equipos de gestión especializados con equipos capacitados en PMBok y CMMI y que exigen cuadros de mando definidos.

No me atrevo a dar un porcentaje de mejor, pero sin duda el presupuesto destinado a estos sistemas es mucho más efectivo cuando la gestión de la puesta en marcha es dirigida por un equipo especializado de un modo separado del productor.

Kanban viene del japonés (como no), quiere decir ‘etiqueta de instrucción’ , está relacionado con los términos ya conocidos por los lares del desarrollo de software como Lean o just-in-time y como viene siendo habitual se trata de una metodología creada en Japón tras la segunda guerra mundial. Concretamente en TOYOTA se creó como una manera de manejo del flujo de materiales en una línea de ensamble para producir eficientemente sin causar trastornos ni retrasos en la entrega de un producto.

Con el espíritu de aprender del mercado norteamericano, ingenieros japoneses viajaron a estados unidos donde observaron el modo de actuar de los comercios y supermercados. Obtuvieron dos conclusiones, importantes:

- El almacenamiento de la mercancía hasta su venta se limitaba

- Cuando de un producto quedaba un número fijado de unidades se reponía para que siempre hubiera servicio al cliente.

Con estas premisas y ampliando esta filosofía a toda la cadena de servicio se desarrollo Kanban en el que se enuncia que es la orden de que el pedido es el que debe poner en marcha la producción y no a la inversa como hasta el momento. Esto se tradujo en una orden de pedido que da nombre a la metodología.

Las reglas concretas de Kanban son las siguientes:

1. No se debe mandar material defectuoso a los procesos subsiguientes
2. Los procesos subsiguientes requerirán sólo lo que es necesario
3. Procesar solamente la cantidad exacta requerida por el proceso subsiguiente
4. Balancear la producción
5. Tener en cuenta que KANBAN es un medio para evitar especulaciones, realizar tan solo lo que indica el pedido.
6. Estabilizar y racionalizar el proceso

Parece todo muy lógico y evidente. Una explicación más detallada la podréis encontrar en monografías de donde he tomado alguna de las notas que os dejo.

Sin embargo para su aplicación al desarrollo de software es necesario “adaptar” algo estas normas. Para explicarlo de un modo sencillo he localizado una presentación y un documento que basándose en SCRUM y marcando las diferencias con está nos cuenta el funcionamiento.

Tras la lectura de estos documentos, que os recomiendo, me he acordado del post de Ddaz acerca de SI es una moda esto de SCRUM y la Agilidad.

Aunque no coincido plenamente con Ddaz si defiendo que no existe un traje (metodología) que nos ajuste a la medida. Utilizar una metodología sin adaptarla a nuestra forma de trabajo no resulta más que generar problemas nuevos. Pero, aunque como se menciona en la opinión de Ddaz que casi todo lo enunciado resulta obvio no por ello es más sencillo de realizar.

En definitiva el nombre SCRUM , LEAN, KANBAN, TDD no es importante pero ayuda a tener un lenguaje común. Y a pesar de ser perogrulladas las enseñanzas que contienen no impide que requieran de mucho esfuerzo para implementarlas…aunque merece la pena.

Que sea el pedido el que ponga en marcha la producción, y no la producción la que se ponga a buscar un comprador

Sirva la frase de uno de nuestros más importante, controvertido y extravagante personaje nacionale para presentar a otro personaje mucho más tranquilo Ralph Kimball.

Kimball es uno de los padres del BI moderno, nosotros seguimos a diario sus guías para nuestros proyectos. Por eso cuando a través de Todo BI me he releeído las 10 errores (delitos!) que publicó hace algún tiempo me ha parecido muy interesante hacer una referencia, de vez en cuando debemos volver al origen. Os transcribo con un resumen para las meditéis.

Mistake 12: Place text attributes in a fact table if you mean to use them as the basis of constraining and grouping.
Mistake 11: Limit the use of verbose descriptive attributes in dimensions to save space.
Mistake 10: Split hierarchies and hierarchy levels into multiple dimensions.
Mistake 9: Delay dealing with a slowly changing dimension (SCD).
Mistake 8: Use smart keys to join a dimension table to a fact table.
Mistake 7: Add dimensions to a fact table before declaring its grain.
Mistake 6: Declare that a dimensional model is “based on a specific report.”
Mistake 5: Mix facts of differing grain in the same fact table.
Mistake 4: Leave lowest-level atomic data in E/R format.
Mistake 3: Eschew aggregate fact tables and shrunken dimension tables when faced with query performance concerns; solve performance problems by adding more parallel processing hardware.
Mistake 2: Fail to conform facts across separate fact tables.
AND THE BIGGEST MISTAKE …
Mistake 1: Fail to conform dimensions across separate fact tables.

Unos comentarios propios:

Error 11: Sobre todo ahora que el HD es tan económico (incluso con el impuesto SGAE)

Error 10: La sencillez siempre es un valor a mantener

Error 6: Uno de los errores más difíciles de evitar.

Aquellos que han compartido conmigo alguna de las múltiples discusiones y divagaciones (es un tema que me apasiona) acerca de porque España a pesar de tener un enorme potencial de creatividad y saber hacer no destaca como país inventor habrán oído mi  teoría de los garajes.

Norteamérica con su forma de pensar y ser ideó su modo de vivir con casas de menor calidad que las europeas, menos eficientes energéticamente pero con un gran espacio. Como parte de ese espacio la casa típica norteamericana posee un garaje que además de servir como sitio para guardar el coche (o coches) sirve como almacén de trastos y para desarrollar el hobby de algún miembro de la familia.

Como resultado de ello muchos de los inventos (Apple, Microsoft, HP,…) han salido de estos lugares. ¿Por qué?…eso da para empezar una de esas largas divagaciones que no es el objeto del post pero apunto unas cuantas razones:

• Se trata de un espacio propio
• No hay que respetar reglas, no existen salvo las que tú quieras
• Estas allí porque quieres, porque deseas conseguir el objetivo que te has planteado
• No hay presiones, es mi casa, realizo el trabajo cuando, como y cuanto quiero.
• Tengo a mi disposición lo que necesito y puedo permitirme
• ….(seguro que podéis añadir muchos)

Estoy tan convencido de las ventajas de los garajes que con la esencia de esas ideas aplicables a la empresa comenzamos nuestra andadura en keen.

La publicidad ha explotado ya esta idea, Audi la utilizó en uno de sus mejores anuncios. Hoy a través de desdesarrollo de software he visto como HP ha utilizado sus inicios en el garaje como motivador para su gente.

Es publicidad pero me ha encantado ver tan bien expuestos nuestros principios que de hecho estoy pensando en imprimir una gran copia para empapelar una pared de nuestro “garaje” , ¿qué os parece?.

Desde Dirección de Proyectos nos introduce otro cálculo matemático para la gestión de proyectos. Se trata de un indicador para cuantificar la muy frecuente cuestión del grado de cumplimiento de proyecto. Me refiero a grado en que se ajusta la realidad al plan trazado no al progreso del proyecto.

A través de 2 entradas se explica el modo de calcular un % que indica la adherencia del proyecto a la planificación, os dejo los dos enlaces aquí y aquí.

Gracias a GEDPRO he vuelto a ver el video de una de estas competiciones norteamericanas que solo se les ocurre a ellos. Al estilo de cazadores de mitos o grandes construcciones la competición consiste en construir una casa en menos de 4 horas. Cualquiera que escuche este reto dirá que es imposible, y así es.

La casa que construyen es, evidentemente, de estilo norteamericano con una estructura y paredes en madera con un material aislante estilo sándwich. Pero no es allí donde está el “truco” del mínimo tiempo, lo está en la planificación, es allí donde radica el éxito o fracaso de la empresa….pero esto no cuenta en el tiempo de las 4 horas .

A través del video podréis ver sus efectos las personas tienen un trabajo definido y claro, con objetivos concretos y tiempos de inicio y fin. Hay tremendas diferencias entre construir una casa y realizar un proyecto informático sin embargo hay técnicas de “perogrullo” cuando las vemos aplicadas y sin embargo no en todos (ni siquiera la mayoría) de los proyectos se aplican:

• Existe un documento completo con todo el plan, tiempos, equipos y tareas. Pero no se trata de un documento han leído todos, que deben actualizar con los cambios durante la ejecución y demás burocracia. Se trata de un guión que ha permitido al jefe de obra:

• Verificar que todo se ha tenido en cuenta en la planificación
• Repartir el trabajo entre los equipos
• Adquirir los materiales necesarios
• Programar el fin del proyecto

• Durante el “desarrollo” no hay reuniones de horas acerca de que vamos a hacer, planificación y demás, las ha habido antes para ver el trabajo de cada uno.
• Hay conversaciones mínimas “on the fly” durante el desarrollo para la coordinación y ajuste.
• Todos los miembros del equipo tienen su tarea pero conocen y asumen como propio el objetivo general común y principal, construir una casa en 4 horas.
• Los miembros del equipo opinan que es dificil, un reto, pero están convencidos de que lo van a conseguir y que será divertido hacerlo.
• Hay personas dedicadas únicamente a  inspeccionar el trabajo (los de la camisa a rayas) que de modo inmediato, incluso durante el trabajo, indican los errores que existen e instan para su corrección.
• Cada técnico es un especialista, sabe cómo hacer el trabajo. Personal con experiencia y los conocimientos necesarios evita errores debidos a la falta de experiencia y realiza trabajos de calidad incluso con el tiempo justo (fijaros en los montadores de la cocina que incluso se dedican a limpiar las puertas tras el montaje) .
• Se realiza un ensayo completo anterior, un pilotaje para probar si funcionará, si el plan es correcto, si hay que ajustar algo. La experiencia solo se adquiere con trabajo no se puede suplir solo con conocimientos.
• El material y equipos necesarios está preparado y listo.
• El personal es el necesario y suficiente para la empresa a acometer.
• Por último la planificación tiene un tiempo lo suficiente amplio para asumir imprevistos. De esta forma aun en el peor supuesto se llega a plazo y en el mejor…ved el video, sobretodo el minuto final, es como ver a las hormigas.

En el video se ve como el éxito del proyecto es del equipo y no de algunos miembros más que de otros. Al igual que en los proyectos la planificación no ocupa un papel protagonista (no hay una sola mención de la dedicación del tiempo que ocupa su planificación) sin embargo es necesaria y clave para el éxito del proyecto.

¿Qué prefieres en el desarrollo de software iteraciones de calidad o un mayor número de iteraciones?

Ante esta cuestión y sin más información apuesto que de forma mayoritaria todo el mundo se decantará por las iteraciones de calidad. Sin embargo esto se trata de un prejuicio que vale la pena plantearse en cada situación o proyecto. A través del ejemplo en La masa, el ladrillo, la bota, el bocadillo… se demuestra que no es una elección a realizar sin valorar la disyuntiva. Ninguna duda que si es posible ambas cosas mejor que mejor pero el ser humano aprende con el error y mejora cuantas más veces puede comprobar si acierta o yerra. Por tanto la velocidad + calidad llega aplicando la velocidad, al revés no.

Echadle un vistazo al artículo y pensad en las ocasiones en las que habéis desarrollado un proyecto con un resultado “mejorable”, ¿hubiera salido mejor de haber realizado más releases parciales y comprobando sus errores?

Imagen: Kriss Szkurlatowski

Brevemente os dejo el enlace a PMP_free_mock un website que proporciona información para obtener el archiconocido PMP.

La historia que a lo largo de 17 entregas a contado Andrés Panitsch en su blog desdesarrollo de software llamada “Frankenstein, el líder de proyecto” ha terminado en su última entrega.

Ya dije en mi anterior entrada sobre el cuento que el descubrimiento de Frankie es que en los proyectos el principal problema son las personas. Pero, como se saca de conclusión tras la lectura, la solución no es ajustar a las personas a un mismo patrón sino que el proyecto sea quien salga con una guía exacta y el modo de hacerse sea más adaptable a la persona (be Agile!)

Os recomiendo la lectura completa de la história seguro, que os sonará mucho a experiencias personales.

I, II, III, IV, V, VI, VII, VIII, IX, X, XI, XII, XIII, XIV, XV, XVI y XVII

Open source y todas las licencias asociadas desde luego han supuesto y suponen un gran impulso al avance del software. Sin embargo a la hora de su uso y comercialización resultan algo complejas. Para documentarlo os cuento mi última experiencia sobre este asunto.

Hace un par de semanas comentaba con un colega los resultados de una consultoría que estamos haciendo a un cliente respecto al software a utilizar para el desarrollo de una aplicación de escritorio. Para la selección de la base de datos a utilizar hemos valorado MySQL y su coste comercial ya que el uso que va a hacerse es en un software propietario. Mi colega de profesión aseguraba que no era necesario adquirir una licencia comercial, MySQL es Open Source con licencia GNU GPL lo que permitía su uso sin pagar licencia alguna.

Me hizo dudar, así que me puse en contacto con otro colega, un especialista del MySQL, sin embargo la cuestión tampoco la tenía muy clara. Apostaba por que el uso sería libre siempre y cuando se indicará el propietario de la base de datos y su tipo de licencia.

Aunque tenía total confianza en mi segundo confesor no me di por satisfecho y recurrí a la fuente directamente. Me puse en contacto con SUN para explicar el problema. Según el comercial estaba claro, el uso con cualquier otro software exigía el mismo tipo de licencia GNU GPL. Es más, me explico la técnica que de forma habitual se utilizaba por algunas aplicaciones para en teoría “burlar” esta norma. En su distribución no incluían MySQL pero si indicaban su necesidad y redirigían al usuario durante su instalación a la descarga directamente de la web de SUN (yo he utilizado alguno de estos software). Según el comercial en cuestión, este hecho no exculpa de delito ya que MySQL es una parte necesaria del software y por tanto requiere de una licencia comercial.

Todo claro, hay que pagar licencia, de acuerdo, ¿cuanto es?.

- SUN: Bueno depende, no hay un precio por licencia fijado, ¿cuanto cobra usted por el software?

- KEEN: Nada, es gratuito, es un software propietario que se obsequia a los clientes.

- SUN: ya, ¿y cuántas copias reparte?

- KEEN: aproximadamente X

- SUN: ¿y qué beneficio causa a la empresa el obsequio del software a los clientes, se puede cuantificar?

- KEEN: Es difícil

- SUN: ¿Qué uso tiene?

Total, la licencia tiene un coste asociado al beneficio que de ello puedas obtener con su uso según el criterio del comercial. Como ejemplo me contó el comercial de un cliente que había indicado que la aplicación que iba a hacer uso de MySQL era gratuita con uso universitario. Se fijo una licencia simbólica y lanzó el software. Cuando SUN averiguo que se estaba utilizando para una aplicación que investiga fármacos para la cura de una enfermedad muy contagiosa que los laboratorios regalaban con la compra de un aparato de medida extremadamente caro se sintieron engañados. El precio de licencia se fijo a la relación que tenía con la máquina en cuestión.

Como decía, Open sí, Easy no. Por eso me parecido interesante y útil el par de diagramas explicativos que la Oficina de Software Libre de la Universidad de Santiago de Compostela ha confeccionado sobre las licencias que he conocido a través de Software Libre y Cooperación

Podéis consultar todas las licencias o las más utilizadas a través del web del movimiento Open Source.