DEUDA TÉCNICA ¿De qué trata el concepto? ¿Cuál es su origen?

Imagina que tienes una funcionalidad que necesitas agregar a uno de tus sistemas. Para ello hay inicialmente dos formas de hacerlo, una es rápida de implementar pero algo confusa (es decir, es seguro que esta opción te dará mucho trabajo mejorarlo en un futuro). La otra es hacerlo a partir de un diseño “limpio”, pero esta opción llevará más tiempo y esfuerzo de implementar.

Deuda técnica es una excelente metáfora ideada por Ward Cunningham para ayudarnos a pensar en este problema.

 “Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise.”

En esta metáfora, hacerlo de la forma rápida y confusa nos generaría una deuda técnica, con una mecánica similar a la deuda financiera. Al igual que una deuda financiera, la deuda técnica involucra el pago de intereses, que se configuran en forma de esfuerzo extra que tendríamos que realizar en un futuro a causa de haber elegido la opción de un diseño rápido y confuso. Y un principal que representa por el costo de eliminar la deuda técnica de forma definitiva.

Por lo tanto, podríamos optar por continuar pagando intereses u optar por pagar el principal a través de la aplicación de técnicas que nos lleven de un diseño rápido y confuso a uno mejor. A pesar del costo que nos trae el pago del principal, ganaremos a futuro al reducir el pago de intereses.

La idea no es eliminar toda la deuda técnica, sino concentrarse en aquellos casos donde el monto de interés que evitaríamos con la solución justifica el costo que tiene el pago del principal. De acuerdo con esto hay casos donde optar por un enfoque rápido y confuso puede ser razonable. Por ejemplo, al igual que una empresa incurre en deudas para tomar ventaja en una oportunidad de mercado los desarrolladores podrían considerar incurrir en una deuda técnica para alcanzar un hito importante para los objetivos del proyecto.

La metáfora se vuelve interesante porque generalmente las organizaciones productoras de software dejan que sus deudas técnicas se salgan de control y esto hace que pasen la mayor parte del esfuerzo futuro del desarrollo pagando intereses paralizantes. El tema es también que a diferencia de la deuda financiera, la deuda técnica no cuenta con una moneda que nos permita medirla de forma efectiva. Los pagos de interés por ejemplo deberían medirse en términos de la productividad del equipo, pero como medir la productividad es un tema complejo y pese a nuestros esfuerzos tal vez no consigamos medirla con exactitud, no podremos evaluar el efecto real de nuestra deuda técnica.

En resumen esta metáfora si bien es un concepto que no es nuevo, ejemplifica un problema que continua siendo interesante para los investigadores actuales. Distintos autores han tomado esta metáfora y la han extendido a diferentes áreas de la ingeniería de software particularmente a la vertical de calidad imagino que se debe a que es el área más difícil de evaluar cuantitativamente.

Mobile - ¿aplicaciones responsive o nativas?

¿Adaptación o Nativo? esta es una de las preguntas más repetidas de la nueva generación de aplicaciones software para dispositivos inteligentes. Cuando alguien que desarrolla software se hace esta pregunta es porque esta pensando en brindar su servicio a través de diferentes dispositivos que:

• Operan en diferentes plataformas
• Son de diferentes fabricantes
• Tienen diversas resoluciones

Lo cual seguramente tiene como objetivo llegar al público masivo, dado que las estadísticas muestran que hoy se tiene mayor interacción con dispositivos móviles que con ordenadores en el sentido tradicional. Por lo que en este contexto la pregunta inevitable es:

¿me conviene una web adaptativa (responsive) o software nativo para los dispositivos?

Hace unos años esta no era una pregunta sencilla puesto que no había ningún producto que se pueda utilizar para tener una única linea de producción que pueda compilarse en diferentes plataformas. Esto ya no es un problema puesto que existen varias plataformas que lo permiten, aunque esta claro que estas plataformas nunca serán tan efectivas y eficientes como construir directamente en el código nativo pero suelen ser una excelente opción. Mientras que la ventaja de la web era justamente una única linea de producción de software que pudiera adaptarse en el navegador a los diferentes dispositivos y ni siquiera debía ser compilada para cada plataforma. Pero claro el concepto de responsive era nuevo y se entendía como hacer que la web se viera bien en un espacio reducido lo cual no lograba el impacto visual y de usabilidad que sí podías lograr con una aplicación nativa.

Hoy el concepto de adaptación responsive, se entiende de otra forma y a través de herramientas como CSS 3 y HTML 5 puedes lograr que tu web se adapte a las diferentes resoluciones pero mutando en el proceso de forma tal que puedas aprovechar mejor la experiencia logrando no solo aplicaciones de alto impacto visual sino también de usabilidad. Con esto se disminuye tanto la brecha entre aplicaciones nativas y web que la pregunta inicial se reduce al siguiente análisis:

¿Quiero aprovechar la información del usuario en dispositivo? ¿quiero usar los dispositivos periféricos tale como: GPS, cámara, efectos especiales, alarmas, notificaciones, billetera electrónica, market place, etc.? si tu respuesta es SI entonces debes ir por las aplicaciones nativas, en cualquier otro caso la mejor alternativa puede ser la aplicación web responsiva dado que el hecho de no aprovechar las ventajas propias del dispositivo en tu aplicación no justificar la inversión y el impacto que consigas puede ser equivalente. La cuestión de la inversión no es menor porque si buscas que tu aplicación nativa sea óptima deberás contar con una linea de producción independiente para cada dispositivo, porque la opción de una herramienta (como Titanium) que compile una única linea de producción en cada plataforma será útil pero nunca igual de efectiva que una aplicación nativa.

En definitiva como todo en el software no hay una opción idónea para todos los casos sino que siempre dependerá de tus objetivos y del contexto en el que te encuentres.

Valor Ganado - método

La propuesta es brindarte una idea para la automatización del calculo de la métrica de valor ganado, que como ya vimos es de mucha utilidad para el control del proyecto desde el punto de vista financiero y del uso de los plazos.

Para esta receta necesitamos:

• 1) Registrar las horas de aquellos que trabajan en el proyecto, con rigurosidad.
• 2) Conocer el costo de cada recurso del proyecto.
• 3) Combinar 1) y 2) con los conceptos de valor ganado para realizar el cálculo.

Ahora veamos como automatizar con una arquitectura software cada uno de los pasos anteriores:

• Para el punto 1) vas a encontrar muchas herramientas que te permiten colectar las horas; yo recomiendo altamente JIRA. Es una herramienta que aunque tiene costo, te brinda una gran flexibilidad de diseño de tus proyectos y provee un API web con la cual interactuar para la automatización del proceso de descarga de horas.
• Para el punto 2) te propongo el diseño de una base de conocimiento donde almacenar el costo individual de cada uno de tus proyectos; que al combinar con el punto 1) te permita conocer el costo actual de las actividades que se están desarrollando.
• El punto 3) voy a dividirlo en dos: para automatizar el cálculo de la métrica yo te propongo utilizar Project de Microsoft porque tiene un API nativo para Windows con el cual se pueden automatizar las tareas de sincronización con las herramientas mencionadas anteriormente.
• En cuanto a la sincronización entre herramientas podrás encontrar varios plug-in para Project que puedes utilizar, nosotros podemos brindarte una solución que integra tanto Jira como la base de costos al mismo tiempo que actualiza las perspectivas de Project facilitando la automatización del cálculo de la métrica de valor ganado y los respectivos índices de performance.

Esta arquitectura ya la hemos implementado antes y hemos conseguido grandes resultados, al facilitar a los proyectos el modelado de las tareas y su posterior seguimiento. Si te interesa puedes contactarnos y te informaremos más detalladamente sobre la solución completa.

Aunque hay un trabajo tan importante como la automatización que es más bien cultural, al respecto de la carga de horas de forma rigurosa y sistemática. Para que esta arquitectura funcione el valor de la información es vital por lo que hay que lograr que tus colaboradores sean metódicos en su parte del proceso y por lo general esto cuesta trabajo sobre todo al principio. Sin embargo, conocerte de forma empírica te ayudará a tomar mejores decisiones por lo que creo que es una inversión que te traerá grandes beneficios.

El síndrome de la cafetera

Si has tenido la posibilidad del andar lo suficiente, habrás notado al igual que yo un síndrome que se repite sistemáticamente en las organizaciones cuando estas atraviesan una situación económica delicada; me refiero al hecho de que siempre habrá alguien que al analizar la situación dirá:

" ... y si apagamos la máquina de café, así nos quitamos ese costo" 

Esto es lo que yo llamo el "Síndrome de la cafetera". Desde mi punto de vista este comportamiento es un patrón que se repite sistemáticamente en las organizaciones, cuando deben tratar a fondo el tema de optimizar sus costos.

El problema esta en que en lugar de analizar sus procesos y resultados buscando una causa raíz sobre la cual trabajar, la desesperación los lleva a concentrarse en los gastos operativos que podemos catalogar como superfluos. Los cuales son un alivio momentáneo que justifican el proyecto de optimización, pero que probablemente al considerarlos en su conjunto noten que no alcanzan el 5% del pasivo que buscan recuperar.

Para recuperar el pasivo de operaciones, hay que analizar varias cuestiones: el nivel de staff, nuestros procesos, nuestra forma de producir, nuestro proceso de ventas. Porque el problema económico general puede deberse a diferentes situaciones, y cito algunos ejemplos relacionado con lo que acabo de mencionar como cuestiones de análisis:

• Procesos eficaces que no son eficientes
• Procesos eficaces y eficientes pero no hay un volumen de ventas sólido.
• Demasiado staff para el volumen de trabajo y la proporción de facturable/no facturable que habíamos previsto para costear el staff excedente no se esta alcanzando.

Pueden existir un sin fin de oportunidades de mejora; lo que intento decir es que la masa critica de la optimización de costos no va a estar en los gastos superfluos como: café, premios, insumos generales sino que estará en nuestras operaciones.

Cuando estemos en esta situación, debemos hacer un profundo análisis causal y tomar acciones correctivas, implementarlas y hacerles seguimiento para poder mejorar. Un socio brasilero me decía:

" ... los costos en algún punto son como las uñas, hay que recortarlos todos los días"

Trabaja tus costos, controla tu ahorro (nivel de inversión contra lo facturado) y acompáñalo con una gestión profesional de tus operaciones y notarás como las cosas comienzan a mejorar.

Reflexiones sobre el Staff ....

Cuando tenemos como objetivo mejorar para optimizar nuestra performance o disminuir nuestros costos, no podemos evitar analizar el staff con el que contamos como parte de nuestra planificación estratégica. 

Habitualmente ocurre que no se proyecta adecuadamente o no se regula de acuerdo con las circunstancias, puesto que se trata de personas y por lo tanto puede ser un tema sensible. 

Según como yo lo veo, hay por lo menos tres formas de manejar el nivel de staff para soportar nuestras operaciones:

• Normal: Digamos que esta es la situación ideal donde  nuestro equipo dispone de la cantidad máxima de recursos necesarios para realizar el trabajo previsto y el futuro sin comprometer los objetivos y los costos asociados. Todos los recursos están ocupados de forma constante al 100% de su capacidad. Pueden haber tiempos muertos.
• Menos del necesario: Con esta alternativa lo que buscamos es optimizar costos sobre-asignando los recursos que tenemos en nuestro equipo. Digamos que lo que buscamos es eliminar los tiempos muertos en los proyectos previendo una constante doble asignación que permita que nuestra gente este constantemente produciendo a pesar de los contratiempos de los proyectos.
• Mas del necesario: Esta opción es viable cuando queremos soportar un esquema de inversión o tener mayor capacidad de trabajo para afrontar de pronto compromisos futuros no confirmados. Si esta fuera la estrategia tenemos que considerar que una fracción de nuestro equipo no estará produciendo por lo que su costo debe estar cargado al costo del resto del equipo que si produce. La ventaja es que siempre tendrás fuerza de trabajo para afrontar compromisos no previstos o apoyar otros proyectos, esto no puedes hacerlo tan fácilmente con las alternativas anteriores.

Realmente no hay una opción óptima por sobre las demás, depende mucho del tipo de organización. Sin embargo en cualquiera de los casos el trabajo de planificación de recursos, en términos de previsión de flujo de trabajo y nivel de asignación se vuelve indispensable. 

Si logramos realizar la planificación de forma sistemática y constante, vamos a contar con un mapa de recursos completo. Esto nos va a facilitar el tomar decisiones más acertadas en cuanto a la estrategia de staff para la situación de la organización. 

Si tienes este problema o te interesa mejorar tu planificación de recursos, nosotros contamos con una aplicación diseñada específicamente para ello. Deja un comentario con tu dirección de contacto y podemos programar una demo.