Tag Archives: Software

Comentarios

Código Muerto 💀

2 Comments

Una de las anĂ©cdotas mĂĄs comunes de un proyecto de software es que siempre hay una clase o una funciĂłn que serĂĄ recordada por el nĂșmero de lĂ­neas que esta tuvo. Estoy seguro de que al menos una vez hemos escuchado:

“No toques esa clase, tiene como 1000 lĂ­neas de cĂłdigo”

Developer anĂłnimo

Este es un dato particular de acuerdo a los proyectos en los que estuve y conversaciones entre amigos. Lo que es menos comĂșn, es saber cuĂĄntas lĂ­neas de cĂłdigo tiene el proyecto en el que estamos trabajando.

Si en este momento nos hacemos esa pregunta o se la hacemos a otro miembro del equipo, es posible de que no consigan una respuesta concreta. Si bien es cierto no considero necesario ser 100% precisos, he notado que pocas personas se preocupan de esa mĂ©trica, a menos claro, de que haya algĂșn costo asociado.

Si no les ha pasado, les comento que casos como este se dan desde hace mucho en proyectos donde se audita cĂłdigo. Sin ir muy lejos, Amazon liberĂł [CodeGuru], un servicio (aĂșn en preview) que analiza el cĂłdigo fuente. Como es de esperar, el costo estĂĄ asociado al nĂșmero de lĂ­neas y no es el Ășnico producto o servicio que hace este [tipo de trabajos]

Fuente: [Amazon CodeGuru]

¿Qué es lo que regularmente encontraremos?

He participado en proyectos donde el anĂĄlisis o auditorĂ­a de calidad de software era uno de los objetivos mĂĄs importantes. Muchas veces el costo de servicios adquiridos –u ofrecidos– estaba relacionado al nĂșmero de lĂ­neas de cĂłdigo (o LoC por [Lines of Code]).

En cada trabajo era comĂșn confirmar lo encontrado en proyectos anteriores:

  1. Pocas personas conocĂ­an el nĂșmero de LoC o la importancia de este indicador
  1. Una prĂĄctica conocida –y en algunos casos, aceptada– era “agregar cĂłdigo de ejemplo, ir cambiando y probando pero guardar la versiĂłn original por si algo se malograba”
  1. Muchas veces se mantenĂ­an las carpetas de plantillas y ejemplos de las librerĂ­as y componentes de terceros que en algunos casos ya no se utilizaban

Ya en un caso concreto, estuve en un proyecto donde el desarrollo tenĂ­a mĂĄs de un millĂłn de LoC y estaba seguro de que eso no podĂ­a ser posible pues las funcionalidades del sistema no reflejaban dicha realidad.

SabĂ­a que estaba frente a un caso de CĂłdigo Muerto, pero tenĂ­a que demostrarlo.

¿Qué es Código Muerto?

Sin entrar en detalles (pues es posible que encuentren discrepancias y hasta [una canciĂłn]), el cĂłdigo muerto o “Dead Code” es aquel que no aporta valor al negocio.

El cĂłdigo muerto se puede clasificar de la siguiente manera:

  • CĂłdigo que no se usa: Muy usual en los proyectos de software, algunas veces no se recuerda su objetivo inicial y por lo general ocurre pues las necesidades van cambiando y el cĂłdigo no se depura adecuadamente luego de cada cambio (mucho cuidado con las frases “es que no hay tiempo” o “lo vemos despuĂ©s”)
  • CĂłdigo que se ejecuta pero que no se usa: AquĂ­ entran los casos como los de variables asignadas o llamadas a funciones cuyo resultado no es utilizado. Esto es nocivo pues ademĂĄs ser cĂłdigo inĂștil, consume recursos del sistema.
Fuente: [Refactoring Guru]

ÂżCĂłmo identificar CĂłdigo Muerto?

Con el paso del tiempo preparĂ© una secuencia de anĂĄlisis que me sirviĂł para encontrar casos de cĂłdigo muerto bajo la premisa de que si algo se define en el programa, este debe ser utilizado de manera efectiva. La lista puede parecer obvia, pero ya estĂĄ demostrado que en tecnologĂ­a no debemos confiar en las obviedades 🙂

  • Variables
  • Funciones
  • Clases
  • Comentarios (sean redundantes o cĂłdigo que fue comentado para ser utilizado “mĂĄs adelante”)
  • Elementos de archivos de configuraciĂłn (por ejemplo, secciones comentads o que ya no se utilizan)
  • Archivos de configuraciĂłn
  • LibrerĂ­as (componentes de terceros)
  • Elementos idĂ©nticos (funciones, clases archivos, librerĂ­as o carpetas distribuidos en ubicaciones distintas)
  • Elementos parecidos (librerĂ­as con versiones diferentes, funciones o clases que inicialmente eran una copia de la otra)
  • Carpetas y archivos varios que poco a poco quedan relegados hasta el olvido

Un hecho comĂșn en todos los casos, es que el cĂłdigo muerto existe debido al temor a perder cĂłdigo o a malograr el sistema construido. Esto tiene relaciĂłn directa con el desconocimiento de que los gestores de versiones permiten volver al pasado si es que se necesita ver algo que ha sido borrado.

Otra consecuencia es que a mĂĄs cĂłdigo muerto, mĂĄs complejo serĂĄ el entendimiento de nuestro sistema, la mantenibilidad serĂĄ afectada y a su vez generarĂĄ dependencias con un programador en particular (a veces pueden ser mĂĄs personas). Recuerden, el cĂłdigo es de todos los miembros del equipo y mientras menos dependencias, mejor.

¿Qué herramientas debemos usar?

Puede que parezca una broma, pero un elemento muy importante es la inspecciĂłn visual. A pesar de ello, esta debe pasar a segundo plano pues debemos evitar confiar totalmente de los presentimientos o “literalmente” de puntos de vista.

De acuerdo a esta premisa, lo primero que debemos hacer es trabajar con [herramientas de anĂĄlisis estĂĄtico] que nos brinden un enfoque acertado de lo que estĂĄ ocurriendo.

A pesar de ello, hasta el momento no he encontrado una herramienta que brinde un indicador de cĂłdigo muerto bajo un enfoque holĂ­stico. Es asĂ­ que utilizo principalmente [SonarQube] como base del trabajo a realizar.

Regresando al caso del millón de LoC, encontré pistas que me ayudaron a confirmar la existencia del temible código muerto.

Si queremos empezar con estas prĂĄcticas, algo que nos podrĂ­a ayudar estĂĄ incluido en las herramientas del navegador web. Una de las que ha llamado mi atenciĂłn es la utilizada para analizar la cobertura de los archivos JavaScript y CSS. Esta viene en [Chrome] y no es complicado de usar/entender.

¿Qué conseguí luego de presentar lo encontrado?

El objetivo de mi trabajo en dicho proyecto, fue preparar un informe sobre lo que se estaba construyendo y sobre eso un plan de trabajo para implementar una nueva arquitectura. No me parecĂ­a adecuado llegar con una presentaciĂłn llena de indicadores ni menos señalar responsables (aunque en algunos casos ese ha sido mi trabajo), asĂ­ que gracias al apoyo y explicaciones que el equipo dio cuando estaba analizando el cĂłdigo, tenĂ­a el conocimiento necesario para “limpiarlo”, al menos en casos que parecĂ­an obvios o donde veĂ­a que complejidad baja o media.

Como este tipo de trabajos me gustan, no parĂ© hasta eliminar 95% del cĂłdigo del sistema. No esperaba llegar a ese nĂșmero pero mĂĄs de un millĂłn lĂ­neas era cĂłdigo muerto que se podĂ­a limpiar fĂĄcilmente.

Nada mejor que llegar con un informe que tenga un entregable como ese 🙂

La buena noticias es que el equipo quedó sorprendido. Cuåndo me preguntaron cómo lo hice, les comenté que empecé por las obviedades (y ya saben lo que pienso de ellas :)) creo que eso los animó a seguir limpiando (luego de una segunda limpieza el código no superaba las 30 mil LoC)

¿Qué es lo que aprendí?

  • Es posible que este tipo de trabajos sea incomprendido al principio, pero se consigue mucho enseñando con el ejemplo. En dicho proyecto tenĂ­a que preparar una arquitectura que aproveche lo que ya estaba construido, pero ante las sospechas de cĂłdigo muerto, decidĂ­ detenerme un momento y evaluar cĂłmo eliminarlo, primero por mi cuenta y luego con el equipo.
  • Lo que he encontrado en muchos casos, es que hay pocas intenciones de refactorizaciĂłn que a veces no se dan por el uso desmedido de frameworks y herramientas. Lo que creo que se debe hacer es sentar una base medible de lo que estĂĄ sucediendo sin olvidar que lo mĂĄs se hace en un proyecto de software es la construcciĂłn del mismo. Si es asĂ­ Âżpor quĂ© no saber cĂłmo va creciendo nuestro cĂłdigo?
  • La automatizaciĂłn de pruebas es muy importante pero esta se debe postergar si hay casos obvios de cĂłdigo muerto, he comprobado que a veces resulta mĂĄs rĂĄpido borrar (sin miedo) que ponermos a programar un caso de prueba.
  • Siempre debemos utilizar un gestor de versiones (personalmente prefiero Git sobre GitHub) y tenerlo enlazado a un motor de automatizaciĂłn (como [Jenkins] o [Azure DevOps], ambos me parecen buenos y Azure DevOps es mĂĄs sencillo de configurar) que ayude a tener visibilidad de la integraciĂłn continua.
  • El equipo de desarrollo pasa a otro nivel de conocimiento, pues ademĂĄs de entender la importancia de prĂĄcticas de limpieza de cĂłdigo muerto se abre una nueva puerta hacia la calidad del producto.
  • Si la confianza y comunicaciĂłn son las adecuadas, este tipo de situaciones se convierten en anĂ©cdotas del equipo.

ÂżCuĂĄl fue mi reflexiĂłn final?

Antes de refactorizar o hacer lo que sea en el sistema, eliminen el CĂłdigo Muerto, no teman.

Un abrazo,

Fuente imagen cabecera: [Finding Dead Code]

Comentarios

¿Qué tanto le debes a tu sistema?

2 Comments

En términos simples, la deuda técnica tiene que ver con el tiempo que tendrías que invertir para solucionar problemas que estås dejando de lado a nombre de generar un resultado en el menor tiempo posible.

SĂ­, con esto me refiero a las consecuencias del “dĂ©jalo ahĂ­, luego lo arreglamos”

Lo que me he encontrado es que esa es una frase que es aceptada hasta que los problemas se empiezan a poner serios. Por otro lado, hay que considerar que si queremos mejorar “algo”, pues tenemos que saber cĂłmo medir ese “algo” antes y despuĂ©s de los cambios realizados.

ÂżCĂłmo mido un sistema?

Estoy seguro de que hay muchas formas para eso, pero aquĂ­ los pasos que sigo regularmente:

  1. Perspectiva del usuario final
  2. Comportamiento en tiempo real (anĂĄlisis dinĂĄmico de cĂłdigo)
  3. Perspectiva del desarrollador (anĂĄlisis estĂĄtico de cĂłdigo)

1. Perspectiva del usuario final

Asumiendo de que el usuario estĂĄ contento con las funcionalidades existentes y de que no hay errores en producciĂłn (SĂ­, es un gran supuesto), lo que normalmente sugiero es tomar nota del comportamiento de la aplicaciĂłn.

¿Qué se hace ahí? Pues se mide lo que llega al usuario ¿Cómo medimos la aplicación? Para nuestra suerte, si estamos trabajando con una aplicación web, existen herramientas gratuitas que nos permiten tener reportes como el que nos genera [GTmetrix]

Fuente: [AnĂĄlisis del blog personal]

Parece obvio, pero les cuento que he estado en proyectos en los que no se habĂ­a considerado una revisiĂłn bajo esa perspectiva y ya se tenĂ­an quejas de que “el sistema estaba lento”

Lo bueno de herramientas como GTmetrix, es que brindan una mirada objetiva de lo que le entregas al consumidor final. Aquí es donde encontrarås aspectos como el tiempo de carga de la pågina (Fully Loaded Time) o incluso el tamaño de lo que se descarga al navegador (Total Page Size)

Por otro lado, GTmetrix incluye una serie de anĂĄlisis usando herramientas como [PageSpeed] o [YSlow]. Para ambos casos se genera un score que puede mejorarse si sigues las recomendaciones que, para tener una idea, se crearon bajo estĂĄndares de Google (para el caso de PageSpeed) o Yahoo! (para el caso de YSlow)

Otra opciĂłn interesante viene con Google Chrome y se puede usar desde la opciĂłn Developer Tools/Audits, lo cual, en resumen, hace uso de [Lighthouse], que tambiĂ©n es usado por Google PageSpeed 🙂

Fuente: Archivo personal

Los que me conocen saben del cariño que le tengo a YSlow y que me apena que ya no haya una extensiĂłn de navegador para hacer un anĂĄlisis a ese nivel de detalle. Tiempos aquellos 🙂

Update: Si pueden denle una oportunidad a https://yellowlab.tools/ Se ve muy interesante!

2. Comportamiento en tiempo real (anĂĄlisis dinĂĄmico)

Una vĂ­a rĂĄpida para reaccionar a lo que le ocurre al sistema, es saber lo que le pasa a este mientras va funcionando. No soy partidario de esta forma de trabajo, pero en sistemas que ya se estĂĄn ejecutando en producciĂłn es importante contar con al menos una herramienta que permita tener una vista de ese tipo.

AquĂ­ es donde hablamos del anĂĄlisis dinĂĄmico del cĂłdigo con herramientas del tipo APM (Application Performance Monitor). Una que hace muy bien ese trabajo es [New Relic]

Fuente: [New Relic]

La importancia de este tipo de herramientas radica que no son invasivas. Es decir, no tienes que tocar tu código y la performance de la aplicación no se ve afectada. Antes de New Relic probé otros analizadores que degradaban la aplicación al punto que decidíamos desactivar el analizador.

3. Perspectiva del desarrollador (anĂĄlisis estĂĄtico)

Tal como mencioné en la sección anterior, no soy partidario de ir reaccionando acorde a lo que le ocurra al sistema pues creo firmemente que la mejor forma de solucionar un problema es evitåndolo.

Bajo esa premisa estamos en la obligaciĂłn de encontrar mecanismos que permitan controlar lo que se estĂĄ construyendo o modificando. AquĂ­ es donde entran herramientas como [SonarQube]

Fuente: Archivo personal

Lo bueno de esta herramienta (entre muchas cosas) es que te ayuda a clasificar los posibles problemas de programación y te da una estimación base de lo que necesitarías para cubrir esa deuda técnica.

¿Qué ocurre normalmente?

Lo que he encontrado en algunos proyectos es:

  1. No se mide lo que se estĂĄ construyendo
  2. Se mide lo que se construye pero en términos de deuda técnica convencional (anålisis eståtico con SonarQube)

No pondré en duda si se toma acción sobre la deuda técnica pero lo que regularmete encuentro es que se pierde la perspectiva de lo que ocurre en producción o se hace a consecuencia de un problema.

¿Qué estamos perdiendo?

No soy un experto en el tema pero les puedo asegurar que poco a poco iremos perdiendo el control de nuestra aplicaciĂłn analizada. No he encontrado un estudio detallado del impacto financiero al respecto, pero valgan verdades hay situaciones en las que el equipo de desarrollo sugerirĂĄ rehacer un componente/servicio/mĂłdulo/aplicaciĂłn a consecuencia de que lo encontrado es inmantenible.

¿Se imaginan eso en términos financieros? Pues ahí un primer vistazo al dinero perdido a consecuencia de una deuda técnica mal gestionada.

¿Qué tenemos que hacer?

La primera respuesta es obvia, “tenemos que medir nuestra aplicaciĂłn” pero en realidad, ademĂĄs de invertir para lograrlo, hay mucho por hacer al respecto pues lamentablemente no he encontrado una herramienta que nos muestre lo que es realmente la deuda tĂ©cnica. Si bien es cierto SonarQube nos da una idea al respecto, pero no podemos confiar en ese Ășnico indicador (Resumen, SonarQube te ayuda pero no es la soluciĂłn definitiva â˜č)

La segunda respuesta tiene que ver con lo que algunos llamamos el diseño y ejecución de nuestro plan de pagos. Es decir ¿cómo vamos a ir pagando nuestra deuda técnica?

Es aquĂ­ donde tenermos una [gran responsabilidad], pues ademĂĄs de englobar esta serie de issues/riesgos/problemas/bugs tenemos que darle forma al indicador y a su impacto tĂ©cnico/financiero. Por otro lado, debemos aceptar que siempre estarĂĄ ahĂ­ pues estoy seguro de que no hay proyecto que elimine la deuda por completo. Es decir, siempre habrĂĄn issues con los que tendremos que convivir, pero si es asĂ­, tiene que ser una convivencia sana 🙂

Un abrazo,

Architecture, arquitectura, Comentarios

¿Qué tan importante es la arquitectura de un sistema?

2 Comments

ÂżQuĂ© ocurre “normalmente”?

Me gustarĂ­a empezar aclarando lo que posiblemente muchos hemos vivido en nuestros proyectos. Un sistema se construye con o sin una arquitectura definida. La realidad indica que quieras o no, el sistema se construirĂĄ pues asĂ­ lo determina el negocio. En resumen, tenemos que responder a una necesidad.

Si el sistema ya estĂĄ en producciĂłn y no estĂĄ claro si hubo un trabajo de arquitectura, mĂĄs que tomar una posiciĂłn al respecto, lo que debemos hacer es evaluar y fundamentar con evidencias, el comportamiento del software desde su primera liberaciĂłn al usuario.

Fuente: [Clean Code]

Si el sistema no ha presentado problemas a consecuencia de cambios constantes en el negocio, podremos concluir de que la decisiĂłn tomada fue la mejor para esa realidad. Claro estĂĄ, que eso no implica que dicha formula funcione para otras realidades.

Ahora, si es que está en nuestras manos incluir este tipo de trabajos (es decir, los de arquitectura), pues tenemos que hacerlo sin dudar siquiera un segundo 🙂

ÂżCuĂĄl es el impacto “mĂ­nimo” de una arquitectura?

En este tipo de situaciones considero poco profesional que nos basemos en supuestos, puntos de vista, corazonadas o peor aĂșn en feelings, pues lamentĂĄblemente estos no nos servirĂĄn en momentos que llegan gracias a los clĂĄsicos y no tan queridos “cambios de Ășltima hora”. Es por ello que en vez de feelings, lo mejor es que tengamos a la mano hechos concretos:

  1. Impacto en el proyecto: Un caso –muy grĂĄfico– se remonta a un hecho ocurrido en USA en 1940. Si no conocĂ­an [la caĂ­da del puente Tacoma Narrows], les comento que hay [estudios al respecto] y que todo indica que el diseño inicial omitiĂł consideraciones como por ejemplo, el efecto que tendrĂ­a el viento sobre la estructura del puente ÂżServirĂĄ de algo compartir este tipo de experiencias? Esto lo dejo a su elecciĂłn, pero vale la pena mencionar que para esa Ă©poca, USD 6MM fue la cantidad de dinero que literalmente “se fue al agua”
  1. Rapidez de implementaciĂłn: PodrĂ­a sonar lĂłgico escuchar que una buena prĂĄctica incrementa la rapidez del desarrollo, pero es mejor mostrar un caso en el que, por ejemplo, TDD genera una mejora de al menos 30% del tiempo esperado bajo “condiciones normales”
Fuente: [Clean Architecture]
  1. Costos de mantenimiento: Si bien es cierto este estudio se hizo hace mĂĄs de veinte años, estoy seguro de que se han encontrado con problemas que son complicados de resolver, pues la soluciĂłn implicaba “cambiar muchas cosas”. AquĂ­ un grĂĄfico que refleja lo encontrado luego de analizar proyectos en empresas como HP o IBM, el cual en resumen indica que si hemos avanzado mucho en el trabajo y nos encontramos con un error, corregirlo serĂĄ muy costoso.
Fuente: [Code Complete]

¿Qué consideraciones debe incluir nuestra arquitectura?

La “respuesta corta” es, tenemos que implementar nuestro sistema considerando una arquitectura que soportarĂĄ las necesidades del negocio.

La “respuesta larga” incluye estas consideraciones:

  1. Estamos en la Ă©poca en la que gracias a la agilidad, podemos confirmar en plazos cortos si nuestro producto (o parte de este) es Ăștil. De aquĂ­ es donde se desprende el concepto de valor.
  1. El valor se asocia a la utilidad desde el punto de vista el usuario, y eso es bueno, pero lo que no debemos olvidar es que el usuario final no es ni serĂĄ el Ășnico usuario del sistema. Pues de alguna u otra manera, los desarrolladores y resto del equipo tĂ©cnico son usuarios. Por consiguiente, el valor tambiĂ©n se debe visualizar desde una perspectiva tĂ©cnica.
  1. Este “valor tĂ©cnico” muchas veces es confundido con una necesidad que podrĂ­a estar en una prioridad distinta a la requerida por el usuario final. Y es lo que comĂșnmente ocurre, pues “eso es transparente para el usuario”
  1. Esta nueva restricciĂłn podrĂ­a basarse en la experiencia del equipo, pero lo recomendable es incluir criterios de calidad probados por el mercado. Para esto hay muchos modelos, pero creo que una base muy entendible es [la propuesta de Jim McCall]:
  1. Cubrir los criterios de cada perspectiva, requerirå contar con una arquitectura que las soporte y un conjunto de pråcticas que no necesariamente se verån reflejadas en el diseño, pero sí en la implementación del mismo. Es aquí donde entran a tallar el uso de eståndares de programación o de pråcticas como la de TDD o incluso pråcticas de DevOps (y la lista podría ser muy larga)

ÂżDĂłnde estĂĄ el cĂłdigo?

Si bien es cierto soy partidario de hablar con cĂłdigo en mano, este es un caso en que necesitamos aceptar que el cĂłdigo llegarĂĄ luego de entender con claridad los criterios mencionados por el Modelo de McCall. La mala noticia es que no hay magia en este trabajo, si queremos empezar y no sabemos por dĂłnde, pues podrĂ­amos tener en cuenta lo siguiente:

  1. Hace poco escribí sobre [10 aspectos a considerar si les interesa la arquitectura]. Si es que ya se sienten listos para empezar con la parte técnica, pues les sugiero revisar los puntos 3 y 7 (Conceptualizar y Estudiar y poner en pråctica).
  1. Si bien es cierto [mi post] lo menciona, es posible que no estĂ© claro cĂłmo empezar con lo que denomino “conceptualizaciĂłn” ÂżCĂłmo podrĂ­an empezar con esto? Pues este grĂĄfico de niveles de diseño, les darĂĄ una idea de lo que a algunos les podrĂ­a parecer obvio, pero que a pesar de ello he notado que muchas veces no se hace bien, debido a la necesidad de escribir cĂłdigo lo mĂĄs pronto posible.
Fuente: [Code Complete]
  1. Este tipo de razonamiento se debe complementar con conceptos de diseño como [acoplamiento / cohesiĂłn] y claro, de [SOLID]. De este Ășltimo he encontrado un [video que lo explica muy bien] y que ademĂĄs muestra ejemplos de cĂłdigo.

Conclusiones

Creo que sobran argumentos sobre la importancia de la arquitectura de un sistema, pero esto no sirve de mucho si no aceptamos que la arquitectura es solo una parte del trabajo que debemos realizar.

Líneas arriba mencioné la relación que existe entre la arquitectura y las pråcticas como TDD, DevOps y aquí podría agregar los estilos de arquitectura, el uso de patrones de diseño, automatización de pruebas y herramientas que nos permitan acelerar de manera eficiente el trabajo del equipo de desarrollo. Sin olvidar claro, el concepto de valor.

Por otra parte, lo que no debemos hacer es separar el concepto de valor en mĂĄs de una vertiente. Mi explicaciĂłn del “valor tĂ©cnico” fue hecha por la necesidad de demostrar de que el “valor” incluye otros factores, y que en primera instancia estos son transparentes para el usuario, pero con una correcta asesoria este comprenderĂĄ la necesidad de incluir estos alcances a lo largo del proyecto.

Me gustarĂ­a agregar que la entrega de valor debe estar equibilibrada bajo la premisa de que no hay un solo tipo de usuario. Esta es muchas veces una lĂ­nea delgada con alto riesgo de ser confundida u omitida.

Un abrazo,

Architecture, arquitectura, Comentarios

Our Jenga Architecture

Leave a comment

I’m sure you know how to play Jenga. Otherwise, let me tell you how easy the game is. First you have to pull one block from the Jenga tower, then you have to put the selected block at the top of it taking care about a possible destruction. Each player has to repeat these steps until the tower has fallen.

Source [kisspng]

In life (like this kind of games), sometimes the easy things come with interesting problems. Sometimes you can be that Jenga tower destructor even on your first game play.

Continue reading Our Jenga Architecture →
Comentarios

Éxito y Calidad de Software (Borrador)

Leave a comment

Estaba pensando en una investigación que hace mucho dejé de lado, pero que he decidido retomar. El triångulo de hierro estå involucrado y también una presentación que hice hace 9 años (!@#!@#! estamos envejeciendo)

Tenemos que aceptarlo, hace mucho que la calidad ha pasado a un segundo o tercer plano debido a la posiblle confusiĂłn generada por la agilidad y la necesidad del negocio porque es “transparente”, “ya deberĂ­a venir”, “no habĂ­amos pensado en eso” o bueno, “es una caja negra”, cuando en realidad es un factor crucial para el Ă©xito en un proyecto.

Pero bueno, voy a darle una mirada a esa presentaciĂłn que hice en Microsoft PerĂș por esa Ă©poca, estoy seguro que muy pocos la recuerdan. TambiĂ©n estoy seguro que mis chistes fueron malos, Pero diablos, tanto tiempo y esa ppt tiene cosas que siguen caladas en mi ser!

exito-suma-esfuerzos
Fuente: AMANCAY

Abrazo de gol peruano.

JD