Insensatez 3 0Reflexiones acerca de las aproximaciones al desarrollo mejores prácticas y gerencia de

Insensatez 3.0desarrollo, mejores prácticas y gerencia de

proyectos de software en Latinoamérica.X Jornada de Gerencia de Proyectos ACIS

Marzo 2012Bogotá, Colombia

Jorge Aramburo SiegertCEO, PSL

jaramburo@psl.com.co

Precaución!Precaución!

Esta presentación contiene opiniones

Propósito de la presentación

La presentación tiene cuatro propósitos fundamentales:

Reflexionar acerca de las razones por las cuales en Reflexionar acerca de las razones por las cuales en Latinoamérica persiste un modelo de ingeniería tradicional, pesado e improductivo en el desarrollo de software y en general en proyectos de TIsoftware y, en general, en proyectos de TI.Analizar el impacto de este tipo de ingeniería en la competitividades de las organizaciones de negocios.Repasar ¿otra vez? el problema que las Repasar, ¿otra vez?, el problema que las aproximaciones tradicionales representan para los gerentes de proyecto, grupos de TI y clientes.No aburrirlosNo aburrirlos.

Si bien el fenómeno aún se presenta en países desarrollados aunque en mucha menor proporción y

Craso errordesarrollados, aunque en mucha menor proporción y estructuralmente decreciente, en Latinoamérica la ingeniería de software tradicional es la regla.

E t á ti t i d l Esta práctica representa un riesgo muy grande para la industria, contribuye de manera significativa a la pérdida de competitividad de las organizaciones y expone a un gran riesgo la industria de IT.p g g

La ingeniería tradicional aniquila la innovación, genera grandes atrasos, generalmente produce f d l d d l software de poco valor y no es adecuado para los

timepos modernos. Quizá no nos damos cuenta, pero las pérdidas y el atraso competitivo son

tpreocupantes

¿Por qué Insensatez?A juicio del autor, la manera como estamos enfrentando los proyectos de TI, especialmente los relacionados con software, carece de sentido.

La RAE define insensatez como:

“Necedad, falta de sentido o de razón”

Lo malo de todo este asunto es que, inclusive la mayoría de aquellos que proceden guiados por planeación tradicional, aceptan los inconvenientes de la misma y alaban las virtudes de las aproximaciones modernas Sin alaban las virtudes de las aproximaciones modernas. Sin embargo, hacen poco para cambiar.

“Estoy de acuerdo pero …..” es lo que dicen

http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=insensatez

Ingeniería tradicionalLa ingeniería tradicional secuencial en naturaleza La ingeniería tradicional, secuencial en naturaleza, encierra una serie de premisas que no se cumplen cuando se trata de proyectos de software.

S ti l l “ ” ( i i t l t )Se tiene claro el “que” (requerimientos completos)Se conoce el “como” (métodos, técnicas y herramientas)En condiciones normales, los costos y tiempos son conocidos,dentro de un rango estrecho (la buena ingeniería)dentro de un rango estrecho (la buena ingeniería)Es posible medirla de manera precisa a través de herramientas analíticas y cuantitativasEs posible llevarla a cabo a través de procesos repetitivos Es posible llevarla a cabo a través de procesos repetitivos (automáticos, manuales o mezcla de ambos).

Tuvo su origen en la construcción de elementos materiales, limitados por las leyes de la física (carros, materiales, limitados por las leyes de la física (carros, aviones, edificios, etc.)

Ingeniería tradicionalL i i í t di i l l tili La ingeniería tradicional, la que se utiliza en manufactura predecible, no está sujeta a grandes cambios.

D lí d bl l l d t l l f De una línea de ensamble sale el producto para la cual fue diseñada y no otroEl edificio, casa o apartamento que entregan es el que se ordenó construirordenó construir.

Sin embargo, los productos que salen de las líneas de ensamble fueron previamente diseñados a través de procesos que se alejan completamente de la ingeniería procesos que se alejan completamente de la ingeniería secuencial.

La creación de productos no puede ser tratada con ese tipo de ingeniería El software es siempre un nuevo tipo de ingeniería. El software es, siempre, un nuevo producto.

Ingeniería tradicionalL i i í t di i l l tili La ingeniería tradicional, la que se utiliza en manufactura predecible, no está sujeta a grandes cambios.

D lí d bl l l d t l l f De una línea de ensamble sale el producto para la cual fue diseñada y no otroEl edificio, casa o apartamento que entregan es el que se ordenó construir

Cuando se agotan las posibilidades de un producto manufacturado es necesario

Cuando se agotan las posibilidades de un producto manufacturado es necesario ordenó construir.

Sin embargo, los productos que salen de las líneas de ensamble fueron previamente diseñados a través de procesos que se alejan completamente de la ingeniería

manufacturado, es necesario comprar otro. El software, en cambio, si está bien hecho,

puede ser modificado y durar

manufacturado, es necesario comprar otro. El software, en cambio, si está bien hecho,

puede ser modificado y durar procesos que se alejan completamente de la ingeniería secuencial.

La creación de productos no puede ser tratada con ese tipo de ingeniería El software es siempre un nuevo

décadas.décadas.

tipo de ingeniería. El software es, siempre, un nuevo producto.

Pero ….… debo estar equivocado. La gran mayoría de los q g yproyectos en Colombia y Latinoamérica se contratan por adelantado, con precio, tiempo, alcance y plan de trabajo fijos.

Esa forma de contratación supone que se conoce perfectamente el “qué” (requerimientos de todo tipo), el “como” (diseño, procesos, métodos y técnicas), es posible estimar “costo y tiempo” y elaborar un “plan de posible estimar costo y tiempo y elaborar un plan de trabajo detallado” antes de comenzar. Es decir, se acepta la Ingeniería tradicional como el camino elegido para hacer software.

Si así se contrata, tiene que ser una masa crítica, y no casos aislados, de proveedores (incluyendo multinacionales), clientes, consultores, universidades y

l l d d d)

profesionales la que soporta y defiende este tipo de ingeniería.

¿En serio?¿En serio defendemos la ingeniería tradicional?

En la mayoría de los casos, “lastimosamente” no. Así d l l procedemos, pero en general no creemos en lo que

hacemos.

Y digo “lastimosamente”, pues aunque no creo en la í d l h fingeniería tradicional para hacer software (con

excepciones), tratar con alguien que defiende de manera razonada una posición, aún así sea contraria a la propia, es muy fácil. propia, es muy fácil.

Con muy pocas excepciones, los resultados de la ingeniería de software tradicional son muy pobres, y de esto si pueden dar fe la generalidad de los interesados.esto si pueden dar fe la generalidad de los interesados.

¿Entonces?¿Si son tan malos los resultados por qué continuamos ¿Si son tan malos los resultados por qué continuamos utilizando la ingeniería y planeación tradicionales?

El Anexo a esta presentación esboza las principales razones por las cuales el autor cree que se sigue razones por las cuales el autor cree que se sigue utilizando. Pueden agruparse en:

C i ió Los siguientes slides Convicción

Conveniencia

Desconocimiento

Los siguientes slides tratan de demostrar porque la tradicional no es una buena forma de hacer Desconocimiento

Obligación

Incapacidad

forma de hacer ingeniería. Están dirigidos a quienes están convencidosque si lo es.

Algunas

¿Es útil?veces, 16%

A menudo, 13%

Nunca, 45%

La versión 3 del Chaos Report (Standish Group), el cual analiza miles de proyectos alrededor del mundo, muestra que un 45% de los

Siempre, 7%

Raras veces, 19%

muestra que un 45% de los requerimientos desarrollados por anticipado (tradicional), no son utilizados por los usuarios

Se pierde gran parte del software desarrollado.Se incrementa el tiempo y costo de desarrollo Se entrega el software contratado pero no el que se necesitaSe generan relaciones conflictivas

Pero lo más importante, impide que las compañías se muevan a la velocidad que requiere el mundo, restándoles

competitividad y sacrificando muchas oportunidades de negocio!

¿Es útil?

“We fundamentally know that fixed-price IT projects are a very poor way of working. Luckily, so do our customers. Whenever a customer insists on a fixed-

priced IT project, even within the scope of an RFP that's been put out to bid, ethically we must attempt to dissuade them from this perilous path. Unless we

start providing a consistent front against fixed-price projects, we will never get off this treadmill that we find ourselves on. We must actively choose to reduce

the inherent risks in our industry, and the desire by customers for fixed-price IT projects is likely the greatest one that we face”.

Is Fixed-Priced Software Development Unethical?Scott W. Ambler

“El estándar DOD STD 2167, necesita una revisión radical para reflejar las más modernas mejores prácticas. El desarrollo evolutivo es mejor

técnicamente, ahorra tiempo y dinero”., p y

¿Es útil?Inclusive los creadores de métodos tradicionales y formales tales como Ivar Jacobson (uno de los padres de RUP), Tom DeMarco, Meyer, DoD, IBM y muchos otros, han adoptado paradigmas no

“Todavía creo que hace sentido hacer ingeniería de software. Pero eso no es exactamente lo que ingeniería de software ha llegado a significar. El término

b j ífi d di i li i l d d fi id

tradicionales, mucho más ágiles.

abarca un conjunto específico de disciplinas incluyendo procesos definidos, inspecciones y walkthroughs, ingeniería de requerimientos, matrices de trazabilidad, métricas, control de calidad preciso, planeación y control

rigurosos y codificación y documentación estándar.

… El desarrollo de software es y siempre será de alguna manera experimental. La construcción en si del software no, pero su concepción si. Y aquí es donde

nuestro foco debe estar”.

Tom DeMarcoIEEE, Agosto 2009

¿Es útil?No conozco un solo producto de valor que, habiéndose No conozco un solo producto de valor que, habiéndose desarrollado con ingeniería tradicional, haya costado lo que se estimó y tomado el tiempo planeado. En cambio, solo para citar algunos ….

Han revolucionado el mundo en el mundo en poco tiempo, a una fracción del costo

Qué esta malEl problema de la ingeniería tradicional comienza al creer que es una buena idea y además posible desarrollar por escrito los requerimientos de un sistema por adelantado, y que estos:

Reflejarán fielmente las necesidades de clientes y usuariosPermitirán realizar un diseño definitivo de bajo nivelPermitirán realizar un diseño definitivo de bajo nivelServirán para llevar a cabo estimaciones y compromisos de costo y tiempo fijosPermitirán desarrollar un plan de trabajo detalladoSerán una buena base para comprometerse contractualmente y desarrollar una relación fluida con el clienteLos usuarios obtendrán lo que necesitan y se optimizarán los costos de desarrollo pues se tiene claro el “qué”costos de desarrollo pues se tiene claro el “qué”Permitirán controlar el proyecto “profesionalmente”

Qué esta malEl problema de la ingeniería tradicional comienza al creer que es una buena idea y además posible desarrollar por escrito los requerimientos de un p qsistema por adelantado, y que estos:

Reflejarán fielmente las necesidades de clientes y usuariosPermitirán realizar un diseño definitivo de bajo nivelPermitirán realizar un diseño definitivo de bajo nivelServirán para llevar a cabo estimaciones y compromisos de costo y tiempo fijosPermitirán desarrollar un plan de trabajo detalladop jSerán una buena base para comprometerse contractualmente y desarrollar una relación fluida con el clienteLos usuarios obtendrán lo que necesitan y se optimizarán los

t d d ll ti l l “ é”costos de desarrollo pues se tiene claro el “qué”Permitirán controlar el proyecto “profesionalmente”

No es … b id d ll i i i … una buena idea desarrollar requerimientos escritos

detallados por adelantado, y mucho menos para comprometerse contractualmente

El lenguaje escrito es muy impreciso y no puede describir adecuadamente un intangible complejo (las palabras escritas parecen más precisas de lo que realmente son)parecen más precisas de lo que realmente son)No, pues son impersonales, de una sola vía y no transmiten significadoNo, pues de todas formas quedarán incompletos, p q pNo, pues generalmente no reflejan la necesidad (el cliente obtiene lo que escribe y contrata, no lo que necesita)No, pues necesariamente van a cambiarNo, pues toman mucho tiempo (mejor utilizarlo haciendo software) y cuestan mucho dinero

No es … b id d ll i i i … una buena idea desarrollar requerimientos escritos

detallados por adelantado, y mucho menos para comprometerse contractualmente

El lenguaje escrito es muy impreciso y no puede describir adecuadamente un intangible complejo (las palabras escritas parecen más precisas de lo que realmente son)

Ya muchos compradores ni siquiera se toman la molestia de hacer

Ya muchos compradores ni siquiera se toman la molestia de hacer parecen más precisas de lo que realmente son)

No, pues son impersonales, de una sola vía y no transmiten significadoNo, pues de todas formas quedarán incompletos

toman la molestia de hacer requerimientos, pues concluyeron

que es una labor ardua, imprecisa y costosa. Solución: Eso es problema

! C b d i ió

toman la molestia de hacer requerimientos, pues concluyeron

que es una labor ardua, imprecisa y costosa. Solución: Eso es problema

! C b d i ió , p q pNo, pues generalmente no reflejan la necesidad (el cliente obtiene lo que escribe y contrata, no lo que necesita)No, pues necesariamente van a cambiar

suyo! Con una breve descripción genérica buscan contratar a precio y plazo fijos. El resultado es conocido.

suyo! Con una breve descripción genérica buscan contratar a precio y plazo fijos. El resultado es conocido.

No, pues toman mucho tiempo (mejor utilizarlo haciendo software) y cuestan mucho dinero

¿Eso significa …… que toda la documentación se suprime? De ninguna manera. Se conserva solo la documentación útil. Los detalles de los requerimientos y los diseños de bajo q y jnivel se aplazan hasta el último momento responsable (LRM).

El diseño también evoluciona Se parte de un El diseño también evoluciona. Se parte de un arquitectura guía y esta se va detallando en la medida que avanza el proyecto. Una arquitectura emergente

ig ifi it t lt d l P no significa una arquitectura que resulta del azar. Por el contrario, en las aproximaciones modernas la arquitectura es intencional.

Arquitectura intencional

Alto ValorAlto RiesgoAlto Valor

Alto RiesgoBajo ValorAlto RiesgoBajo ValorAlto Riesgo

Las aproximaciones modernas eliminan el riesgo de

Hacer de primeroEvitar! gg

Alto ValorAlto Valor

gg

Bajo ValorBajo ValorRi

esgo

el riesgo de arquitectura al tiempo que construyen

p e o

Hacer deHacer de Alto ValorBajo RiesgoAlto Valor

Bajo RiesgoBajo Valor

Bajo RiesgoBajo Valor

Bajo Riesgoconstruyen primero lo que más valor le agrega al producto / negocio

Hacer desegundo

Hacer de tercero

Valorproducto / negocio

Muchas veces me he preguntado por qué la mayoría de grupos de ingeniería comienzan un proyecto desarrollando tablas de referencia ingeniería comienzan un proyecto desarrollando tablas de referencia (no agregan ningún valor y no tienen riesgo). Es una pérdida de tiempo y dinero!

Arquitectura intencional•Visión•Backlog de producto•User Experience•Arquitectura inicial•GUI

Sprint 0 (-1)

Sprint 1•Diseño del GUI•Especificación de requerimientos•Diseño

Sprint 2

Diseño

•Diseño del GUI•Especificación de Sprint 2

Actividades de Actividades de Actividades para Actividades para

requerimientos•Diseño

preparación para una preparación para una posterior iteraciónposterior iteración

ppcompletar la completar la

iteracióniteración

Eso no se puede!Algunos a pesar de reconocer las desventajas de la Algunos, a pesar de reconocer las desventajas de la ingeniería y planeación tradicionales, arguyen que las formas de negociación no les permiten cambiar hacia

á ti d á f ti D d prácticas modernas y más efectivas. De acuerdo con nuestra experiencia:

Si es posible - con argumentos, experiencia y conocimiento Si es posible con argumentos, experiencia y conocimiento suficientes-, convencer a muchos clientes que existen mucho mejores aproximaciones (posiblemente no a las entidades públicas, y por esta razón son tan atrasadas en p , y pcuanto a TI y soluciones innovadoras). ¿Cuál es la alternativa? ¿El fracaso, la insatisfacción permanente? ¿Las pérdidas económicas? ¿La creación de productos inferiores? ¿El abandono de la profesión?

Podemos estar atrapados en la primera ley de la mala

Estamos atrapadosPodemos estar atrapados en la primera ley de la mala gerencia (*)

“Esto que estoy tratando de hacer debería funcionar; el hecho té f i d b bl t i l que no esté funcionando probablemente sugiere que no lo

estoy haciendo bien”.

Con este razonamiento los clientes hacen más de lo que están qhaciendo, intentándolo hacer mejor, lo que agrava el problema.

“El último proveedor no era el adecuado. Necesito uno mejor”.“Las multas deben ser más estrictas”Las multas deben ser más estrictas .“El contrato debe ser más detallado”.“Solo pagamos a la finalización del contrato”“La responsabilidad del proveedor debe ser ilimitada”p p…. Y otras insensateces.

(*) La primera ley de la mala gerencia fue observada por Jerry Weinberg en 1990.

Podemos estar atrapados en la primera ley de la mala

Estamos atrapadosPodemos estar atrapados en la primera ley de la mala gerencia (*)

“Esto que estoy tratando de hacer debería funcionar; el hecho té f i d b bl t i l que no esté funcionando probablemente sugiere que no lo

estoy haciendo bien”.

Con este razonamiento los clientes hacen más de lo que están Este tipo de posturas conducen a

procesos completamente formales Este tipo de posturas conducen a

procesos completamente formales qhaciendo, intentándolo hacer mejor, lo que agrava el problema.

“El último proveedor no era el adecuado. Necesito uno mejor”.“Las multas deben ser más estrictas”

procesos completamente formales, escritos, lentos, burocráticos, pues

obligan a las partes a defenderse para evitar las consecuencias. Un proceso

b d l d fi á

procesos completamente formales, escritos, lentos, burocráticos, pues

obligan a las partes a defenderse para evitar las consecuencias. Un proceso

b d l d fi á Las multas deben ser más estrictas .“El contrato debe ser más detallado”.“Solo pagamos a la finalización del contrato”“La responsabilidad del proveedor debe ser ilimitada”

basado en la desconfianza está destinado al fracaso.

basado en la desconfianza está destinado al fracaso.

p p…. Y otras insensateces.

(*) La primera ley de la mala gerencia fue observada por Jerry Weinberg en 1990.

Proveedores

Estamos atrapadosProveedores

“Debemos seleccionar mejor los clientes”“Esos %&$### no sabían estimar. Tuve que despedir varios”.q p“Falló la gerencia de proyectos. Necesitamos ser mas estrictos”“El grupo era muy malo”

Este es un asunto que debe escalarse a la alta gerencia de Este es un asunto que debe escalarse a la alta gerencia de las compañías, tanto compradoras como proveedoras. Infortunadamente muchas compañías en Latinoamérica están diseñadas o le apuntan a la eficiencia olvidando la diseñadas o le apuntan a la eficiencia, olvidando la efectividad, lo cual les impide cambiar.

Un buen estratega debe cuestionar las gpremisas fundamentales del proceso!

Proveedores

Estamos atrapadosProveedores

“Debemos seleccionar mejor los clientes”“Esos %&$### no sabían estimar. Tuve que despedir varios”.q p“Falló la gerencia de proyectos. Necesitamos ser mas estrictos”“El grupo era muy malo”

Este es un asunto que debe escalarse a la alta gerencia de

Jamás convencerá a alguien si usted primero no está convencido, tiene

Jamás convencerá a alguien si usted primero no está convencido, tiene

Este es un asunto que debe escalarse a la alta gerencia de las compañías, tanto compradoras como proveedoras. Infortunadamente muchas compañías en Latinoamérica están diseñadas o le apuntan a la eficiencia olvidando la

argumentos, experiencias y conocimiento para demostrar que lo

que propone es mucho mejor. El cliente accederá si usted le muestra

argumentos, experiencias y conocimiento para demostrar que lo

que propone es mucho mejor. El cliente accederá si usted le muestra diseñadas o le apuntan a la eficiencia, olvidando la

efectividad, lo cual les impide cambiar.

Un buen estratega debe cuestionar las

cliente accederá si usted le muestra mejores alternativas. De otra forma

no lo hará.

cliente accederá si usted le muestra mejores alternativas. De otra forma

no lo hará.

gpremisas fundamentales del proceso!

Usted está equivocado!A pesar de la evidencia en contrario, muchos piensan que es posible utilizar la forma tradicional de hacer software.Atribuyen los fracasos a un mal desempeño del grupo de ingeniería (proveedor) o a una mala gestión de parte del cliente.

Un mal desempeño y gestión arrojará siempre pobres Un mal desempeño y gestión arrojará siempre pobres resultados, bajo cualquier aproximación. La cuestión es que bajo la ingeniería y planeación tradicional, un buen desempeño puede conducir al fracaso. En este último desempeño puede conducir al fracaso. En este último caso, el problema no es de la gente, es del método seleccionado.

Il t é d l ti ió l Ilustraré dos casos muy comunes; la estimación y el control tradicional de cambios.

Suponga que …... su cliente potencial (interno o externo), a raíz del último fracaso decidió contratar y controlar “mejor” el proyecto por lo cual le solicita por adelantado un p y p pcronograma detallado del mismo (No, no es un chiste. Es la norma!). El cliente desea controlar el proyecto por el método del valor ganado, y ha establecido una p g , yserie de multas para los incumplimientos.

Suponga además que posee los requerimientos d t ll d d l i t ( i id l bt !)detallados del sistema (ni idea como los obtuvo!),realiza una estimación por puntos de función y se gana el proyecto.

Suponga que …... su cliente potencial (interno o externo), a raíz del último fracaso decidió contratar y controlar “mejor” el proyecto por lo cual le solicita un cronograma detallado del mismo (No, no es un chiste. Es la norma!). El cliente desea controlar el proyecto por el método del valor ganado, y ha establecido una serie de multas para los

“Este cronograma debe contener la totalidad de las actividades, duraciones, dependencias, recursos, costos asignados y las fechas de inicio y fin calculados con base a los anteriores Es indispensable que el cronograma tenga

incumplimientos.

Suponga además que posee los requerimientos detallados del sistema (ni idea como los obtuvo!)

los anteriores. Es indispensable que el cronograma tenga incluido costos en todas las actividades de último nivel, para poder realizar seguimiento con el método de valor ganado. Cuando el trabajo puede asociarse con entregables a costo

detallados del sistema (ni idea como los obtuvo!),realiza una estimación por puntos de función y se gana el proyecto.

fijo, el cronograma respectivo debe contemplar las tareas correspondientes a la elaboración de éstos, a un nivel adecuado para que el director del proyecto pueda monitorear el avance del trabajo”.el avance del trabajo .

No puede ser!... pero es!

El plan… contiene una de las mentiras más repetidas en … contiene una de las mentiras más repetidas en

proyectos de software...

… y necesariamente le traerá muchos problemas.

¿Mentira?Si usted es consciente que la realidad será muy diferente a lo que planeó, es una mentira. De otra forma, es una ingenuidad

Estimar y comprometerse son dos cosas diferentes. Las estimaciones, cuando se tiene información para hacerlas, arrojan una rango en el cual se puede mover un proyecto.j g p p yLas estimaciones son siempre una distribución de probabilidad. ¿Posee baselines para conocer la distribución de probabilidad del grupo?Sino incluye análisis de riesgos en su proyecto, reflejan un mundo ideal.Son imprecisas por naturaleza (especialmente en el d ll d ft )desarrollo de software).

Ya está en problemas

En planeación y administración administración tradicional los atrasos suman pero los pero los adelantos no restan.

Si aceptó las multas, necesariamente lo multarán. Algunos puntos caerán por encima y otros por debajo de la media estadística, lo que es normal.

¿Y el control de cambios?Con contadas excepciones, el control de cambios es una fuente de problemas, atrasos, conflictos, y la mejor manera de no cambiar el software

Quien lo contrató cree en o solo conoce la ingeniería tradicional. Ya se comprometió en la compañía con un presupuesto y un plan estableció multas y logró que presupuesto y un plan, estableció multas y logró que usted aceptara un absurdo.Aunque le haya prometido lo contrario, los requerimientos si van a cambiar (cuando existen por requerimientos si van a cambiar (cuando existen, por supuesto). En este contexto se impone el control de cambios. El cliente defenderá su presupuesto y el modelo de cliente defenderá su presupuesto y el modelo de contratación. Usted intentará perder lo menos posible.

¿Y el control de cambios?Con contadas excepciones, el control de cambios es una fuente de problemas, atrasos, conflictos, y la mejor manera de no cambiar el software

Negar que los requerimientos van a cambiar es negar la

Negar que los requerimientos van a cambiar es negar la

Quien lo contrató cree en o solo conoce la ingeniería tradicional. Ya se comprometió en la compañía con un presupuesto y un plan estableció multas y logró que

van a cambiar es negar la realidad. Usted puede intentar hacer un pacto con San Pedro para que no llueva, o sacar un

E j

van a cambiar es negar la realidad. Usted puede intentar hacer un pacto con San Pedro para que no llueva, o sacar un

E j presupuesto y un plan, estableció multas y logró que usted aceptara un absurdo.Aunque le haya prometido lo contrario, los requerimientos si van a cambiar (cuando existen por

paraguas. Escoja. paraguas. Escoja.

requerimientos si van a cambiar (cuando existen, por supuesto). En este contexto se impone el control de cambios. El cliente defenderá su presupuesto y el modelo de cliente defenderá su presupuesto y el modelo de contratación. Usted intentará perder lo menos posible.

¿Y el control de cambios?El b á i l !El proceso es supremamente burocrático, lento y costoso!

El cliente solicita un cambio y le pide que lo estime.Se escribe el requerimiento. Usted debe hacerlo porque el cliente

i ino tiene tiempo.Se lleva a cabo el proceso de estimación y propuesta (entendimiento del cambio, análisis de impacto, estimación de tiempo y costo, oferta al cliente). Todo por escrito “porque somos tiempo y costo, oferta al cliente). Todo por escrito porque somos muy ordenados”. La propuesta es discutida con el contacto primario del cliente. Generalmente no estará de acuerdo, le pedirá rebaja o la d h ádesechará.Si supera el contacto primario, la propuesta es sometida a un comité, al cual por supuesto debe asistir. Se dan negociaciones adicionales.Si es aprobado, usted reorganiza el plan, las personas, recursos, etc. … hasta dentro de unos pocos días.

En todo este proceso…No le pagan por el tiempo invertido en los análisis de cambios No le pagan por el tiempo invertido en los análisis de cambios (o no se lo tienen en cuenta si usted trabaja para el cliente). En este proceso interviene mucha gente! “Yo no pago por cotizar”.Los tiempos invertidos en estas tareas, aún así los cambios no se lleven a cabo, son muy elevados. Muchos proyectos con pocos cambios, pero muchas solicitudes rechazadas,

lti li d t l ti ti d Al i t multiplicaron por dos o tres el tiempo estimado. Al mismo costo por supuesto!Este proceso genera relaciones muy conflictivas. El cliente defenderá el presupuesto y el plan Usted defenderá su defenderá el presupuesto y el plan. Usted defenderá su posición. El cliente intentará que sin costo haga cambios o “no le recibo el software y le declaro la caducidad. Usted verá”.Es un proceso burocrático, supremamente lento. En muchas ocasiones paraliza al grupo de trabajo mientras se toman decisiones (¿Y mientras tanto?).

En todo este proceso…No le pagan por el tiempo invertido en los análisis de cambios

El cliente defenderá el plan y el t

El cliente defenderá el plan y el t No le pagan por el tiempo invertido en los análisis de cambios

(o no se lo tienen en cuenta si usted trabaja para el cliente). En este proceso interviene mucha gente! “Yo no pago por cotizar”.

presupuesto pues ya se comprometió con la organización que lo emplea. Siempre buscará

el culpable en el proveedor

presupuesto pues ya se comprometió con la organización que lo emplea. Siempre buscará

el culpable en el proveedor Los tiempos invertidos en estas tareas, aún así los cambios no se lleven a cabo, son muy elevados. Muchos proyectos con pocos cambios, pero muchas solicitudes rechazadas,

lti li d t l ti ti d Al i t

p p(interno o externo). El problema comienza desde la negociación!

p p(interno o externo). El problema comienza desde la negociación!

multiplicaron por dos o tres el tiempo estimado. Al mismo costo por supuesto!Este proceso genera relaciones muy conflictivas. El cliente defenderá el presupuesto y el plan Usted defenderá su defenderá el presupuesto y el plan. Usted defenderá su posición. El cliente intentará que sin costo haga cambios o “no le recibo el software y le declaro la caducidad. Usted verá”.Es un proceso burocrático, supremamente lento. En muchas ocasiones paraliza al grupo de trabajo mientras se toman decisiones (¿Y mientras tanto?).

Son un desperdicio!Los procesos formales de control de cambios tradicionales son una absoluta pérdida de tiempo, dinero, confianza y calidad de vida.

“Rápidamente calculamos que solo el proceso de estimación estaba consumiendo cerca del 33% de la capacidad, y en un mal mes podría

llegar hasta el 40%. Esta capacidad se podría utilizar en codificación y b L ti ió t bié d b t b l l ”pruebas. La estimación también desbarataba los planes”.

David J. AndersonKANBAN

S f l l ti h f t h l b iSuccesful evolutionary change for your technology businessAmazon Kindle Edition, 2010

Por supuesto que los controles de cambio son útiles Por supuesto que los controles de cambio son útiles, pero para otro tipo de asuntos.

La ingeniería tradicional… no es adec ada para los tiempos modernos Al final de la … no es adecuada para los tiempos modernos. Al final de la

década, casi todo el software se desplegará como servicio (SaaS). En este tipo de software:

El cambio es permanente (no puedo imaginar la evolución del El cambio es permanente (no puedo imaginar la evolución del software con los tipos de contrato e ingeniería que se hacen en Colombia). El TDD es mandatorio para este tipo de ambientes (incluso el p p (test continuo), lo mismo la integración continua, propiedad colectiva del código y refactoring. Una sola copia del software atiende múltiples clientes /

i i l i l l f l l usuarios, a quienes les importa poco la plataforma en la cual corre (¿Por casualidad, sabe cual es la marca de la planta telefónica de ETB, EPM, COMCEL, TIGO, etc.?).Los grupos que lo desarrollan deben ser grupos de alto Los grupos que lo desarrollan deben ser grupos de alto rendimiento, por lo cual el lado humano de la ecuación debe ser diferente.

El desarrollo de… ft d l i ét d … software moderno no solo exige procesos, métodos y

técnicas nuevas. Implica un sistema de principios y valores muy diferente, así como concepciones sobre la administración de compañías y dirección de proyectos completamente

t l t di i lopuestos a los tradicionales.

PropósitosValores (entre ellos el compromiso con la verdad)H ild dHumildadDeterminación para emprender el proceso de mejoramiento (el cual requiere por supuesto la adquisición de nuevo conocimiento y competencias).p )Plena exposiciónDisposición para abandonar algunas “oportunidades”. Una verdadera estrategia organizacional implica “que” y “que no” hacerhacer.Persistencia

Una última reflexiónLos proyectos de TI modernos, requieren otro tipo de grupos de trabajo.

Cultura colectiva con participación permanente del p p pcliente.Personas dispuestas a compartir conocimiento y abiertas a la crítica de sus pares.Con sentido de propósito.Auto organización y auto dirección, dentro de los límites y restricciones establecidos (El grupo, no el gerente, y ( g p gpuede decidir que no desean trabajar con algún miembro del equipo, incluido el gerente). Todos ganan o todos pierden. Propiedad colectiva.Si tiene métricas (ojalá las tenga), debe también medir y premiar el desempeño colectivo.

Una última reflexiónComprometidos con la verdad y completamente abiertos al examen del cliente.Responden inmediatamente a los comportamientos y p p ydesempeños equivocados

Oportunidad de mejoramiento Oportunidad de mejoramientop jNo trabaje más con la persona. Recuerde que la retroalimentación negativa se convierte siempre en agresión

Juzgan el desempeño profesional no por los conocimientos y experiencia sino por la capacidad de hacer la cosas (resultados).

No se…… cual es la visión y propósitos de su compañía de su … cual es la visión y propósitos de su compañía, de su grupo de ingeniería, los suyos. Sin embargo…

¿No le importa saber que los grandes productos, aquellos que están transformando el mundo no están aquellos que están transformando el mundo, no están siendo desarrollados con ingeniería y planeación tradicionales?

¿No le preocupa que estemos aniquilando la ¿No le preocupa que estemos aniquilando la imaginación, la creatividad, la innovación?

¿No se ha puesto a pensar que la ingeniería tradicional ifi l titi id d d l i i d l sacrifica la competitividad de las organizaciones y de la

sociedad como un todo?

¿Ha ensayado otras formas de hacer las cosas? Muchas ¿ yorganizaciones colombianas y latinoamericanas podrían haber avanzado mucho mas.

“…creando un mundo hiperconectado. Se trata de un mundo en el cual la educación, la innovación y el talento

se recompensarán más que nunca antes Se trata de un se recompensarán más que nunca antes. Se trata de un mundo en el que ya no habrá países “desarrollados” y “en

desarrollo”, sino sólo países PMI (que permiten mucha innovación) y PPI (los que sólo permiten poca)” innovación) y PPI (los que sólo permiten poca)

Thomas L. Friedman

Muchas graciasuc as g ac as

Anexo Algunas razones por las cuales continuamos

utilizando técnicas de la denominada Ingeniería tradicional para desarrollar proyectos de softwaretradicional para desarrollar proyectos de software

¿Por qué persistimos en el error?Las aproximaciones tradicionales, ceremoniosas, pesadas e improductivas, han encontrado apoyo, por acción o por omisión, en varios actores de la industria:

Quienes tienen capacidad de influenciar el rumbo de la industria (SEI, ISO, PMI, autores, grandes fabricantes, grandes compañías de países , g p pdesarrollados)

Los compradores de soluciones de software

Los proveedores de soluciones (internos o externos)

Consultores y universidades.

¿Por qué persistimos en el error?Influenciadores

La aplicación de técnicas de manufactura tradicional a la producción de software a fines de los años 70 impulsada por producción de software a fines de los años 70 impulsada por Bemer en GE, Mcilroy en AT&T, Hitachi y otras.

La definición de Ingeniería de Software acogida en la conferencia de la OTAN en 1969 y el modelo en cascada conferencia de la OTAN en 1969, y el modelo en cascada (incorrecta interpretación del documento de Royce en 1970), de amplia utilización.

ISO 9001 l SEI (S ft E i i I tit t ) l d l ISO 9001, el SEI (Software Engineering Institute), el modelo CMM, CMMI y muchos Lead Assessor posicionaron aún más la ingeniería tradicional.

La aplicación del cuerpo de conocimientos del PMI ha contribuido a que se trate el desarrollo de software como un proyecto predecible.

¿Por qué persistimos en el error?Compradores

Los políticas de compra han acentuado la ingeniería tradicional. Con pocas excepciones, el comprador Latinoamericano acude al

RFP’s con requerimientos de alto nivel. En ocasiones son un poco más elaborados, pero nunca completos, y no contienen

p p , pmercado, más o menos bajo las siguientes condiciones:

realmente lo que el cliente necesita.

En estas condiciones, exigen precio, y costo fijo por adelantado. Llegan al punto de solicitar discriminaciones g pdetalladas de proyecto a nivel de Fase / Etapa / Persona, horas, valor …. Y lo peor es que casi siempre obtienen respuesta!!!!

Por supuesto, casi todo RFP “serio” a precio fijo viene Por supuesto, casi todo RFP serio a precio fijo viene acompañado de una serie de absurdos y multas.

C d

¿Por qué persistimos en el error?Compradores

P dé d l i i í d f di i l jó

Las razones para comprar de esta forma son varias:

Por décadas, la ingeniería de software tradicional aconsejó desarrollar requerimientos y diseños por adelantado, lo mismo que planes formales predictivos con compromisos de costo y tiempo (lo que ha demostrado ser un desastre). costo y tiempo (lo que ha demostrado ser un desastre).

Para tener la sensación de un presupuesto controlado (ocurre todo lo contrario).

Para seleccionar entre varios proveedores se requiere comparar el precio (pocas veces se elige el mejor y, cuando se elige el más económico, pocas veces resulta siéndolo).

Porque el “proveedor debe asumir el riesgo”.

¿Por qué persistimos en el error?Compradores

á í

Las razones para comprar de esta forma son varias:

Porque ese es el “RFP estándar de la compañía”.

Porque “esta es una compañía pública”.

Porque así me “lo recomienda el asesor”, muchas veces extranjero, y que quizá nunca haya hecho software (y si lo hizo, se le olvidó).

Por desconfianza del proveedor (en este caso, deberían tratar de encontrar compañías en las cuales confiar, no insistir en lo mismo).

“Porque es muy difícil cambiar esta compañía, aunque usted tiene razón”.

¿Por qué persistimos en el error?Compradores

Las razones para comprar de esta forma son varias:

El poco conocimiento que tienen los compradores sobre lo que están sacrificando sus compañías al contratar, “aparentemente”, de la mejor manera. Porque por falta de conocimiento le compran a quien les Porque, por falta de conocimiento, le compran a quien les responda lo que quieren oír (en muchas ocasiones el desconocimiento no es de los profesionales de TI. Sin embargo, no logran convencer a sus compañías acerca de la necesidad del cambio) cambio). El desconocimiento del hecho que la ingeniería de software tiene un aspecto humano y cultural determinante. Los grupos que desarrollan software son sistemas complejos. Los q p jcompradores pocas veces analizan este aspecto, y mucho menos en procesos con RFP’s impersonales.

P d

¿Por qué persistimos en el error?Proveedores

A pesar que los procesos de compra son, en la mayoría de casos, disfuncionales, tanto compañías multinacionales como locales i di d t ti d li it d L ti é i siguen respondiendo a este tipo de solicitudes en Latinoamérica.

Igualmente, los grupos internos de TI siguen comprometiéndose, e incumpliendo, bajo premisas incorrectas.

¿Por qué se sigue contratando bajo condiciones como las expuestas? ¿Estamos locos compradores y

vendedores?vendedores?

Amén de destruir valor, los procesos de contratación están determinando los enfoques metodológicos, cimentando la ingeniería tradicional, generando caos y alimentando la mala fama de los grupos de TI

¿Por qué persistimos en el error?Proveedores

Las razones para ofertar y aceptar contratos bajo las condiciones expuestas son varias: expuestas son varias:

Inexperiencia e ingenuidad (“Yo soy capaz!”)Desconocimiento de la ingeniería (ser bueno en Ingeniería de Software no es tarea fácil)Software no es tarea fácil)Presión de los gerentes (“¿Cómo que no somos capaces?”)Dinero (comisiones a vendedores)Supervivencia (“Solo me compran de esa forma”)Supervivencia ( Solo me compran de esa forma )Procrastinación (“Ya veremos como salgo luego del lío”)Deshonestidad (“Luego, cuando esté atrapado el comprador, pido adiciones”)pido adiciones )La esperanza que el monto y el tiempo serán suficientes y no se perderá dinero

¿Por qué persistimos en el error?Proveedores

Las razones para ofertar y aceptar contratos bajo las condiciones expuestas son varias: expuestas son varias:

La creencia que es posible desarrollar todos los requerimientos de un sistema por adelantado, lo mismo que el diseño técnico del mismoel d se o téc co del s oLa aplicación de técnicas tradicionales de gerencia de proyectos a la creación de productos nuevos (el software es siempre un nuevo producto). Las técnicas tradicionales se

li d i di iaplican a proyectos de tipo predictivo.El desconocimiento de las técnicas de estimación, su alcance, exactitud, cuando es posible aplicarlas, etc.D i i t d l i i í d ft l Desconocimiento de la ingeniería de software y las aproximaciones modernas para el desarrollo de software.

¿Por qué persistimos en el error?Proveedores

Las razones para ofertar y aceptar contratos bajo las condiciones expuestas son varias: expuestas son varias:

La falta de liderazgo y carácter para cambiar procesos a todas luces disfuncionales.La utilización de CMM/CMMi ISO PMI ITIL etc como La utilización de CMM/CMMi, ISO, PMI, ITIL, etc., como estrategia de mercadeo, no como un vehículo de mejoramiento Falta de reflexión y estudio. Las personas / organizaciones f y p g“compran” lo que mejor se mercadeaObsesión por los procesos.Ingenuidad con buenas intenciones, sobre todo de organizaciones gremiales.

¿Por qué persistimos en el error?Universidades

Con excepciones, las universidades en Latinoamérica están muy alejadas de la realidad de la industria de software. alejadas de la realidad de la industria de software.

En general, los profesores no son practicantes expertos.Poco enseñan Ingeniería de Software . Algunas se centran solo en aspectos técnicos (“Computer Science”) otras en solo en aspectos técnicos ( Computer Science ), otras en administración de IT o una mezcla entre ambas.Las pocas especializaciones que abordan aproximaciones metodológicas, gerencia de proyectos de software, buenas g g p yprácticas, etc., tienen programas en general anticuados y puramente académicos.No se aborda el componente humano de la ingeniería.La industria se ve obligada a proveer “educación paliativa”.

Consultores

¿Por qué persistimos en el error?Consultores

Extrañamente, tanto consultores locales como internacionales, incluyendo los más grandes y famosos en el mundo, generalmente apelan a las aproximaciones tradicionales cuando son contratados para guiar grandes proyectos de desarrollo de software.

De 14 grandes proyectos investigados por el autor en los últimos g p y g ptres meses, en varios países (México, Costa Rica, Panamá, Colombia y Perú), la totalidad se centraba alrededor de RFP tradicionales (es decir, de hace décadas), “Precio fijo”, “Costo Fijo” “Multas” etcFijo , Multas , etc.En ninguno de ellos había suficiente información para hacer estimados, ni siquiera aproximados.Cuando logramos abordar directamente algunos clientes, g g ,reconocieron que no era una forma apropiada de contratación, pero que esa era la forma recomendada ‘por los consultores.