Varias encuestas sostienen que sólo en el orden del 20% de los proyectos finalizan obteniendo el objetivo planteado, en el tiempo y con los recursos estimados. Esta problemática se da en todo tipo de proyectos, y está particularmente acentuada en proyectos tecnológicos.
Desde ya que el 80 % de proyectos que no tuvieron la misma suerte – por diferentes motivos – genera un aumento de costos directos (en los casos que los proyectos finalicen con mayor recursos que los previstos) e indirectos por la NO disponibilidad de los beneficios previstos que brindaría dicho proyecto si hubiera finalizado en tiempo y forma. Dichos beneficios seguramente han sido destacados en el momento de desmenuzar el plan estratégico de la organización, el cual dio origen y justificación al nacimiento de dicho proyecto.
Del último análisis surge entonces que además de los costos directos que son fácilmente contabilizables, existen los costos indirectos que seguramente son mucho más importantes que lo pueda suponerse – de no ser así entonces la falla estuvo en promover un proyecto que no aportaba demasiado valor a la organización. Esto fundamentalmente impacta en una baja de productividad de algún área de la organización y en un COSTO de OPORTUNIDAD al no disponer de un resultado que seguramente será un eslabón importante para la cadena de factores críticos de éxito previstos en la estrategia global.
Esto nos lleva a darle una importancia superior a los motivos que generan estos fracasos y desarrollar lineamientos para corregirlos. En la Argentina particularmente, y dada la situación de los últimos años, muchos proyectos de TI han seguido la misma suerte que la estadística general.
La permanente búsqueda en reducción de costos de RRHH han llevado a las empresas a generar proyectos de alta criticidad y exigencia con el fin de que los mismos aporten algún beneficio tangible a la organización que necesita aumentar ingresos y bajar costos. Pero al introducir esa baja de costos, casualmente en las área que deben ejecutar dichos proyectos, se generan dos malos escenarios: se tiene gente preparada para liderar dichos proyectos, pero sobrecargada de trabajo, lo cual implica no poder ejecutarlos como se debe y por lo tanto se ingresa en el 80%; o se recambia personal con menor costo y menor experiencia para la función, lo cual produce el mismo resultado.
En un aspecto más conceptual, la dirección o liderazgo de proyectos no ha tenido la categorización de una especialidad en sí misma, lo cual implica que se improvisa muchísimo. Este escenario, nos lleva a replantarnos la forma de cómo se ejecutan los proyectos. Se necesitan más líderes, para conseguir concretar los proyectos de cambio en las organizaciones de manera tal de aumentar la productividad de las mismas.
Hacia fines del 2005 he realizado un estudio con unos 50 responsables de proyectos, para analizar las causas que alimentan los fracasos según los parámetros definidos. Este estudio que se nutrió de experiencias personales -más allá de los números-, me permitió detectar diversos factores que entorpecen el camino de un proyecto y que se analizan en el libro recientemente editado “Liderando Proyectos”, a continuación los analizaremos.
Motivos que originan fracasos en el cumplimiento de los proyectos:
- 21 % Cambios en los objetivos definidos a nivel estratégico
- 31 % No utilización, o mala utilización de metodologías de trabajo
- 48 % Problemas humanos, de conducción, comunicación y conflictos entre la gente
Con relación al ítem de cambios en los objetivos, el mismo es responsabilidad de las máximas autoridades de la organización. El análisis lo he centrado en los otros dos factores que son responsabilidad de quien dirige un proyecto.
Con respecto a la profesionalidad para diseñar y ejecutar un proyecto, el factor crítico es la utilización de metodologías. En muchas organizaciones pequeñas y medianas el factor brilla por su ausencia, y en muchas organizaciones grandes el mismo existe y en general se trabaja bien, pero no son pocos los casos en los cuales -en general por falta de tiempo- la metodología termina siendo utilizada como una máscara formal para el cumplimiento de normas y etapas y no como lo que verdaderamente es, el eje del proyecto tomando el contenido de la metodología y no solo la forma.
En el siguiente artículo escribiré sobre los problemas de recursos humanos, coordinación y conflictos entre la gente.
Por: Por Daniel Aisemberg
División Consultoría de Evaluando Software
www.evaluandocrm.com
Lo difícil, como se estudia en “Análisis de Sistemas” es integrar a la gerencia, o quien toma las decisiones, al proyecto. Estas personas suelen tener peso en la empresa pero no saben de Sistemas, lo que les da miedo que la automatización de un proceso les quite poder .. y tienen razón, desde que ese poder radica en que los demás no sepan qué es lo que él hace con el conocimiento, que no suele ser tanto como aparentan, y se devaluarían. Así nacen proyectos castrados y guay de los que encentren un atajo, porque ya están fuera de la empresa.
Lo difícil, como se estudia en “Análisis de Sistemas” es integrar a la gerencia, o quien toma las decisiones, al proyecto. Estas personas suelen tener peso en la empresa pero no saben de Sistemas, lo que les da miedo que la automatización de un proceso les quite poder .. y tienen razón, desde que ese poder radica en que los demás no sepan qué es lo que él hace con el conocimiento, que no suele ser tanto como aparentan, y se devaluarían. Así nacen proyectos castrados y guay de los que encentren un atajo, porque ya están fuera de la empresa.
Lo difícil, como se estudia en “Análisis de Sistemas” es integrar a la gerencia, o quien toma las decisiones, al proyecto. Estas personas suelen tener peso en la empresa pero no saben de Sistemas, lo que les da miedo que la automatización de un proceso les quite poder .. y tienen razón, desde que ese poder radica en que los demás no sepan qué es lo que él hace con el conocimiento, que no suele ser tanto como aparentan, y se devaluarían. Así nacen proyectos castrados y guay de los que encentren un atajo, porque ya están fuera de la empresa.
Solo aclararte que no me quejo de lo que comentaste antes… solo quería matizar.
Por todo lo demás, totalmente de acuerdo contigo.
Matías, gracias, creo que es buena tu respuesta y aunque te quejas por mis apreciaciones, las cuales obviamente no son la verdad absoluta ni mucho menos, no dejas de darme la razón ya que en uno de mis párrafos hago mención a las “fallas de quienes deben controlarlos” a los desarrolladores, y realmente creo que ahí está la base de gran parte del problema o de los fracasos en el desarrollo de software.
Cobrar software caro porque tiene muchas líneas de código, es un engaño a quien encargó el desarrollo y lamentablemente, un día, más tarde o más temprano, se da cuenta que le vendieron software por kg. Bienvenidos los desarrolladores que utilizan parte de su valioso tiempo para crear esa única línea de código que hace falta para resolver con belleza y elegancia un problema y saquen a los gerentes que creen que cantidad de código es sinónimo de trabajo esforzado. Todas las metodologías creadas para lograr desarrollos eficientes se han creado justamente porque se quieren evitar muchas de las malas costumbres que describí antes. La belleza, elegancia y eficiencia que son parte inseparable de un código bien escrito, causan placer a quien lo escribió, a quien supervisa ese desarrollo y al cliente que lo recibe.
No se si mi pequeño aporte en esta discusión causará algún impacto positivo en alguna gente, pero más que criticar, trato de señalar algunos errores básicos, que son simples de corregir cuando quienes supervisan tienen los objetivos claros y saben que el software no se vende por kg. Medir el rendimiento de un desarrollador basado en la cantidad de líneas de código que escribió no parece buen método, medir la capacidad de un gerente por la cantidad de nombres raros que puede mencionar sobre los muchos métodos existentes para desarrollar mejor código, tampoco me parece un buen método.
Todas las metodologías que existen para lograr mejor código, son válidas, pero lo único que la final del camino interesa, es que el código escrito haga su trabajo, no falle y sea fácil de mantener. Si a esto le podemos agregar la elegancia de lo sencillo, todos quienes intervinieron en el proceso se sentirán satisfechos y tendrán jefes y/o clientes satisfechos. Para quienes están en esto, escribir y lograr buen código es un placer mayúsculo, así que disfrútenlo.
RDV, no creo estar de acuerdo en algunos de los puntos que planteas. Por un lado, tu enumeración de máximas solo es aplicable en algunos casos y no para todos.
Cuando hablas de que los desarrolladores no tienen reloj muchas veces se confunde, desde la otra mirada como: Ya me comprometí con mi cliente a entregarlo para X fecha y estos desarrolladores no se apuran. Cuando en ningún momento se toma en cuenta si esa fecha era factible. Por más que no se trabaje con elementos físicos, que ocupen espacio, no quiere decir que se pueda construír algo de forma automáticamente más rápido porque así lo quiero. Todo tiene un tiempo y normalmente existe una desconexión entre el directivo y el ejecutor, donde el primero prometió y luego no escucha razones.
Otra de tus máximas hace referencia a que el desarrollador hace una y otra vez el código y pareciera que nunca termina, eso es sano en un punto y totalmente destructivo, como dices, en otro. Pero el hecho de que haya desarrolladores que no sepan cuando detenerse no propaga a todos. Pocos conocen acrónimos como KISS, YAGNI, o GOLD PLATING, y por desconocimiento general nunca se sientan las bases para esto.
Por otro lado tienes las líneas de código numerosas. Lamentáblemente hacer pocas líneas de código requieren de mucho más tiempo que hacer muchas líneas de código, el error común que cometen muchas empresas es el de medir o equiparar productividad a cantidad de líneas de código escritas, ya que en la mayoría de las oportunidades las empresas cobran por TAMAÑO de software, y por supuesto, las líneas de código son la medida ideal para esto.
Ahora, yo te pregunto, si eres gerente, y pasas delante del desarrollador y este está sin tocar el teclado, con cara de desconexión cerebral y mirando una única línea de código. Al rato vuelves a pasar y está en el mismo estado. Este gerente automáticamente piensa: Este tipo no está haciendo nada. Cuando en realidad es probable que esté tratando de crear esa única línea de código para no tener que escribir 2000. Tendras miles de líneas cuando la presión por terminar algo desde la gerencia sea tal hacia los desarrolladores que no los dejen pensar, por lo que tendrás patrones de código como los orientados a banderas, super clases, métodos con miles de líneas en su interior y un largo etc.
No digo que el desarrollador sea un santo, pero extrañamente, cuando sabes aplicar metodologías como Scrum y el grupo toma conciencia del trabajo a realizar, todos estos vicios no suceden. Como todo, es necesario una educación hacia esos que no saben escribir código, y al mismo tiempo, como decía originalmente, hacia esos gerentes que han sido educados bajo el modelo clásico de gestión y siguen pensando que el empleado es malo.
Que bueno este tema. Veo que se analiza el porqué del fracaso pero no el porqué del éxito, lo cual sería mucho más ilustrativo, pero por lo que se comenta a raíz de este artículo, parece ser que no se sabe bien la razón del éxito, lo cual me lleva a sospechar, dado el bajísimo porcentaje de éxitos, que estos son más bien producto de la suerte o la constancia inclaudicable, que de la aplicación de métodos que funcionen.
Cualquiera que haya trabajado con desarrolladores está en conocimiento de ciertas características inherentes a estos y que también son parte del problema.
* A los desarrolladores les gusta más escribir código que buscar la solución más fácil y con menos complejidad para resolver un determinado problema.
* A los desarrolladores les encantan las soluciones complejas y más difíciles de entender por quienes deben controlarlos, con infinitas cantidades de líneas de código que pudieron haberse resuelto con unas pocas funciones específicas.
* A los desarrolladores les encanta irse por las ramas y de una posible solución saltar a otra que parece más prometedora y así hasta el infinito, hasta que el resultado es que se pierden y pierden el objetivo a donde debían llegar.
* Ningún desarrollador se siente conforme con la primer solución encontrada y buscará nuevas formas de manera ininterrumpida.
* La mente de un desarrollador es de por si compleja y en esa complejidad se siente realizado. Si debe partir de A para llegar a C, no solo pasará por B, sino por todo o casi todo el abecedario. Este es su karma.
* Puedo seguir con muchas más características pero estoy seguro que Uds. las conocen, pero solo agrego una más: los desarrolladores no usan reloj y para ellos el tiempo no existe.
Las fallas de quienes deben controlarlos y guiarlos a tierra firme es que es posible que también sean así y todos terminan perdidos en una maraña de código poco eficiente, complejo de entender y mantener, dando más importancia a algunas de las infinitas metodologías de desarrollo que al problema que debían solucionar. He visto software casi imposible de ser utlizado por humano alguno, con necesidades impresionantes de horas de capacitación para quienes deben utilizarlos, con presentaciones muy lindas o muy feas pero en general muy poco intuitivas, plagados de funcionalidades que nadie pero nadie va a usar, que admiten acciones del operador, no controladas por código, que causan caidas del sistema o de la aplicación, pero que se venden al público como los más sofisticados sistemas de gestión, contabilidad, sueldos o lo que sea.
Para colmo en Argentina (Quizás en muchos otros países también, pero lo ignoro) aún se utilizan lenguajes y métodos de desarrollo ya obsoletos y se siguen manteniendo en venta sistemas obsoletos, por la imposibilidad de transcribir aquellos códigos tan complejos y rebuscados a lenguajes y APIs de desarrollo más eficientes.
Desarrollar software es lo mismo que desarrollar proyectos de ingeniería de cualquier clase, con la gran diferencia que en las ciencias duras es imposible económicamente plantear tantas alternativas diferentes para resolver un problema y se llega a una solución de compromiso con un nivel de satisfacción bastante alto, de manera mucho más natural. A ningún ingeniero civil por poner un ejemplo, le permiten construir 10 puentes para ver cual es más lindo o mejor o más resistente; a un desarrollador de software si y ahí es donde radica el problema.
Buena nota, muy profesional.
Depende en que ciudad estés. Pero con los números que te dieron tus compañeros podes ver que esta pagando el mercado.
Yo creo que tenes que tomar como indicativo el que trabaja de desarrollador y pedir entre $3.000 y $3.500, el testing paga por lo general menos que el desarrollo … por lo que lo tendrías que dejar fuera de la referencia.
Pero como recomendación, si sos joven y estas por ingresar al mercado laboral, estos primeros años tendrías que dedicarte a buscar trabajos donde principalmente aprendas y pruebes varias empresas. Eso te abre mucho la cabeza y además es el momento indicado, luego con el paso de los años vienen obligaciones financieras (mantener una casa, un auto, una familia, etc) y perdes mucha de la libertad de tomar grandes riesgos como ahora.
POR FIN !!! una nota interesante.
Coincido con ese 48%.No hay conciencia de metodologias de proyectos, por lo general se va haciendo todo sobre la marcha.
Me gustan estos temas. Porque es de lo que menos se habla en la facultad.
Tambien estaria bueno algun informe sobre promedios de sueldos en Argentina segun la experiencia y titulo universitario o terciario.
Porque tengo 2 compañeros en la facultad que trabajan y me dicen:
– uno trabaja 8 horas de lunes a viernes y cobra $2500. Esta en el puesto de tester, es su primer trabajo y esta en 4to año de Ingenieria en Informatica. Tiene 2 semanas de vaciones al año.
– el otro trabaja 4 horas diarias de luens a viernes y cobra $3500. Esta en el puesto de desarrollador, es su primero trabajo y esta en 3er año de Ingenieria en Informatica. Igual me comento que tenia parientes en la empresa que le consiguieron el laburo. Tiene 1 mes de vaciones al año.
Yo ando buscando un trabajo part-time de 4 horas como desarrollador, pero tengo la duda con el sueldo que deberia pedir. Estoy en 4to año de Ingenieria en Informatica, tengo el certificado PET de ingles, antes de la facultad tenia el titulo de programador en Delphi y Mantenimiento y reparacion de PCs, pero todo eso practicamente lo di en la facultad tambien.
¿Cuanto de sueldo deberia pedir en mi primer trabajo de 4 horas como desarrollador?
Disculpen pero a las empresas le importa un carajo el sector IT! Tratan de pagar los sueldos mas bajos y exprimirte el cerebro lo que mas puedan como no entienden lo que hace un IT y para colmo para llegar hacer IT tenes que estudiar y no solo eso sino tener mucha experiencia para resolver los quilombo que se producen. Únicamente le servimos para apagar incendio! Y hechar culpas por la por la falta de especialización que tiene los usuarios!
Franlu,
No soy de recursos humanos, pero si me voy a atrever a decir que ellos no son tan culpados como parece. El tema viene de fondo, de la empresa en general, de la dirección. Se venden proyectos, la forma de venderlos en general es 2000 horas por ejemplo de desarrollo. La empresa de ahí saca una estructura donde dice, ahhhh excelente eso hay que dividirlo en 1 Proyect Lider, 1 Senior, 2 semi senior, 6 junior y en X meses esta resuelto. A recursos humanos te juro que le llegan requisitos o para contratar un perfil de esta manera, o hacen que la empresa se tenga que mantener en una estructura piramidal con cierto porcentaje para cada puesto.
El problema nuevamente es, se intentan usar números mágicos o recetas mágicas para suplir la falta de idea de las empresas de entender como el desarrollo de sistemas funciona.
Matias, concuerdo con tu respuesta. También me gustaría adicionar el problema de paradigma que hay relacionado al desarrollo de software. Tengo visto millones de proyectos especificados en papel y estimados usando millones de métodos y planillas para luego querer ejecutarlos como si fuera el plano de un edificio.
Simplemente ese enfoque es errado, es producto de una concepción antigua de sistemas, se debe pensar en sistemas como un área mas ligada al diseño y menos a un ingeniería dura como la arquitectura.
Creo que el 80% de los proyecto que falla es porque en el 50% de los casos comienza mal conceptuado y en la marcha nadie consigue hacerlo pivot a donde se desea. El otro 50% es culpa de gerencia y recursos humanos porque como bien hacés notar se piensa en las personas que participan del proceso como objetos con un check list necesario para hacer una tarea. La verdad es que sistemas requiere de personas con capacidad y entrenamiento a adaptarse al cambio y no con un checklist como la industria ingenuamente contrata (JSP, Struts, Hibernate, JPA, etc etc etc).
Una empresa de sistemas es tan capaz de entregar proyectos como lo son sus integrantes de resolverlos. Si bien las metodologías ayudan y dan un formato de trabajo que colabora con esto, nada pero nada va a cambiar que todo sigue dependiendo de las personas.
Se necesita entender que a diferencia de una fabrica de autos, no se depende de cuantos autos el robot suelda por minuto, o si hay que realizar un upgrade al sistema de pintura, etc. Aquí la unica forma de ser una empresa mejor es haciendo que las personas mejoren.
Por favor, no es tan difícil de entender que el activo mas importante son las personas, contraten a personas capaces para liderar empresas y dejen de criticar a la inflación, rotación o generación Y, X , Z o como les guste llamar a los que están cansado, desmotivados o mal pagos y terminan rotando con el sueño de poder encontrar un lugar donde sean reconocidos, valorados o pagos con un salario acorde, porque si alguien se los paga y la empresa que lo conoce no lo hace, quiere decir que la persona no sirve y mejor que se vaya, o que la empresa tendría que pro-activamente haber salido a incrementar el valor del sueldo.
Concuerdo mucho con lo que decis Matias, en especial con el último
párrafo, donde los gerentes piensan que pagar poco y por eso se les va
la gente, pero nunca evalúan qué hacen ellos por sus recursos.
Estoy
en ese dilema justo acá, donde trabajo ahora. Me quiero ir porque en
otros lugares me ofrecen hasta U$D 450 más por mi posición. Ya me pasó
de hacer un cambio así, y caer en un lugar que se laburaba tan mal o
peor que en el otro.
También influye mucho el poco cuidado que
tienen las empresas no relacionadas a las tecnología de manera directa
para con sus recursos. No ajustan sueldos a la realidad y tampoco se
preocupan por la alta rotación. Se piensan que enseguida van a conseguir
un JR al que sí le va a servir el sueldo que le ofrecían al anterior,
sin medir los gastos que a la empresa le genera tener que capacitar una
nueva persona desde cero para que entienda la metodología de trabajo y
lo peor, cómo pilotearla con sus clientes (ya sean externos o usuarios
de sectores).
Muy buen tema Daniel A. Espero ansioso la contraparte de los gerentes de RRHH.
Un saludo
Desde la experiencia propia puedo decir que la mayoría de
las empresas con proyectos que fracasan tienen síntomas similares. Sean
pequeñas, medianas o grandes.
En general se olvidan de las siguientes cosas:
– El triángulo de hierro
– No leyeron The Mythical Man-Month
– No leyeron PeopleWare
– Por moda, intentan aplicar a todo lo que se mueve una gestión ágil. Optan por
Scrum porque es el que está más a la mano, pero no tienen ni idea ni de gestión
ágil, ni de Scrum.
– RRHH no está conectado intelectualmente con las áreas de desarrollo.
– Cuando algo no anda del todo bien por errores en la aplicación de políticas
se recurre rápidamente a las teorías clásicas de la administración, se suplanta
la visión del empleado Z por el X y se aplican más reglas absurdas.
(Probablemente nunca hayan escuchado de Chris Argyris)
– No se educa al cliente.
– Las capas más altas poco y nada saben del proceso de desarrollo (Cuando
hablamos de desarrollo de software)
Si bien hay muchos otros elementos que no están presentes en las mentes de
aquellos que gestionan los proyectos, las fallas que he visto una y otra vez en
empresas minúsculas hasta inmensas se reducen a estos puntos. Mala gestión
hacia lo humano. La gestión no es solo medir ingenierilmente las líneas de
código y si estafeo 2 personas más entonces voy a llegar al deadline. La
gestión pasar por lo humano y por potenciarlo, más cuando estamos hablando de
un rubro donde la cabeza de la gente es la que crea el producto.
Aún recuerdo escuchar a gerentes decir que el alto grado de rotación de
personal se debe a que la empresa del frente pagaba 500 pesos más de sueldo,
cuando no podían ver el estado anímico de los empleados.
Desde la experiencia propia puedo decir que la mayoría de
las empresas con proyectos que fracasan tienen síntomas similares. Sean
pequeñas, medianas o grandes.
En general se olvidan de las siguientes cosas:
– El triángulo de hierro
– No leyeron The Mythical Man-Month
– No leyeron PeopleWare
– Por moda, intentan aplicar a todo lo que se mueve una gestión ágil. Optan por
Scrum porque es el que está más a la mano, pero no tienen ni idea ni de gestión
ágil, ni de Scrum.
– RRHH no está conectado intelectualmente con las áreas de desarrollo.
– Cuando algo no anda del todo bien por errores en la aplicación de políticas
se recurre rápidamente a las teorías clásicas de la administración, se suplanta
la visión del empleado Z por el X y se aplican más reglas absurdas.
(Probablemente nunca hayan escuchado de Chris Argyris)
– No se educa al cliente.
– Las capas más altas poco y nada saben del proceso de desarrollo (Cuando
hablamos de desarrollo de software)
Si bien hay muchos otros elementos que no están presentes en las mentes de
aquellos que gestionan los proyectos, las fallas que he visto una y otra vez en
empresas minúsculas hasta inmensas se reducen a estos puntos. Mala gestión
hacia lo humano. La gestión no es solo medir ingenierilmente las líneas de
código y si estafeo 2 personas más entonces voy a llegar al deadline. La
gestión pasar por lo humano y por potenciarlo, más cuando estamos hablando de
un rubro donde la cabeza de la gente es la que crea el producto.
Aún recuerdo escuchar a gerentes decir que el alto grado de rotación de
personal se debe a que la empresa del frente pagaba 500 pesos más de sueldo,
cuando no podían ver el estado anímico de los empleados.