¿A quién no le pasó que le cayó de paracaidista un proyecto que ya ha iniciado "otro equipo", o un proyecto de un cliente que dice que terceriza algunas partes del mismo? ¿Y a quién no le sonó que algo andaba mal con ese proyecto de entrada?
Aunque no entendamos exactamente por qué tenemos esa extraña sensación negativa, lo cierto es que nuestro cerebro es más inteligente de lo que pensamos. Sabe que hay algo mal, que hay un peligro cercano.
Podríamos ver las consecuencias de tomar un proyecto hecho/iniciado por otros, pero con ello no llegaríamos a la raíz del por qué. De todas formas, vamos a enumerar un par de problemas que se nos presentan para ponernos en contexto:
* Hay que atender a estándares que no son performantes, no son a lo que estamos acostumbrados o son incompatibles con nuestra forma de trabajar.
* Se suman miembros al equipo que no son adecuados, que no trabajan o que aportan negativamente. Esto es típico. Los clientes suelen designar un arquitecto propio y esperar que el mismo controle a los desarrolladores tercerizados. Lo mismo puede pasar con analistas técnicos o líderes de proyecto. Si bien es "común" que los recursos tercerizados sean los ineficientes, muchas veces es al contrario, y de repente nos encontramos haciendo equipo con miembros ineficientes o que ponen trabas constantemente.
* Se tienen que estimar fechas sin siquiera conocer el sistema, ya que la fecha es un motivo de aceptar o no la licitación, por lo que no tendremos nada de código fuente hasta que no esté la estimación de fecha y de dinero.
* Los miembros de equipo del cliente no integran a los tercerizados, los rechazan o los usan para echarles la culpa de todo.
* El código fuente, una vez develado, es un desastre. Un maremagnum de anti-patrones que lleva a plantearse, ya desde el inicio de un proyecto, si el mismo va a dar pérdidas. El problema es que generalmente en este punto uno ya se comprometió, y quizás no para un requerimiento sino para varios. Y ni hablemos si firmó una multa en caso de no cumplir o terminar repentinamente el contrato.
* Escaso o nulo soporte. Falta de recursos y materiales. Lo que nos dicen que instalar tomaría 5 minutos en realidad nos llega a tomar una semana hacerlo andar.
* Trabajando concurrentemente podemos encontrarnos con breaking changes constantes no informados, lo que lleva a grandes dolores de cabeza y extensos insultos al aire.
Y así podríamos seguir toda la tarde. Lo cierto es que todos estos problemas son la consecuencia de algo más profundo. Analicemos un momento "por qué" alguien tercerizaría un proyecto ya iniciado:
* Falta de personal.
* El proveedor original no dió a basto con los requerimientos o las fechas.
* El proveedor original terminó el contrato repentinamente.
* Falta de expertise para llevar a cabo el proyecto
* Si es un proyecto que se terceriza a varias consultoras, entonces se puede tratar del descontento con los proveedores actuales.
Pero siempre hay una que suele sobresalir entre todas las demás: "No se dió a basto". ¿Y cuándo nos pasa eso? Sinceramente, yo soy del fuerte pensamiento de que un proyecto sólo puede fracasar (desde lo técnico) cuando el mismo no está bien elaborado. Es decir, cuando un producto de software posee una calidad baja.
Además, podríamos usar el siguiente pensamiento para darnos cuenta de por qué fallan estos proyectos:
"¿Cuáles son las probabilidades de que un proyecto desarrollado por terceros, que debe continuarlo otra empresa, esté desarrollado bajo un concepto de buenas prácticas, con las pruebas realizadas correctamente, y con una calidad en general elevada?" Me atrevería a decir que un 0%. Antes decía 0.01% pero si me abstengo a las estadísticas personales de mi experiencia en IT tengo que decir 0%.
Resulta tan shockeantemente obvio que nos preguntamos cómo no nos dimos cuenta antes. Lo cierto es que siempre que un proyecto esté desarrollado por otros "Y" necesite de nuevos proveedores, SIEMPRE va a tener un sinfín de problemas. Es un proyecto enfermo. Algo le ocurre, es evidente.
Todo este post viene a raíz de un proyecto en el cual tuve que participar como líder durante 3 meses. Ha sido la peor experiencia de mi vida en lo concerniente a software. Nunca ví tantos anti patrones y tantos problemas juntos. Encima en un ambiente donde absolutamente nadie se cuestionaba si se estaban haciendo las cosas mal. Ya desde el vamos, el proyecto estaba destinado a dar pérdida. Enumero a continuación algunos de los tantos problemas que tuve:
* Instalar un ambiente local para desarrollo debía tardar 5 minutos. Lo cierto es que terminaron siendo 22 días hábiles (un mes entero). Algo tan increíblemente ridículo que todavía me pregunto cómo puede ser que haya ocurrido.
* El analista funcional designado era una persona incapaz que no se acordaba siquiera lo que vió en reuniones con los funcionales del cliente. Finalmente, debido a ello y otras cosas, tuve que hacerlo remover del proyecto. Este fué un error de la empresa proveedor (de la cual soy parte), al integrar a alguien no compotente y desinteresado.
* La complejidad del proyecto era elevada, debido a la cantidad de anti patrones y a la inflexibilidad del sistema.
* Me asignaron sólo un recurso para ayudarme en el desarrollo, y no tres como se había establecido que hacían falta para cumplir las fechas.
* Dicho recurso era Junior y no Senior o Semi Senior como necesitaba un proyecto de complejidad ALTA.
* La creatividad permitida en el proyecto era BAJA, casi NULA diría. Para poder cumplir con las fechas (que establecí yo, y no que estableció la empresa, que habían caducado antes de hacer andar el ambiente de desarrollo) tuve que desligarme de la pésima forma de trabajar que tenía el cliente.
Como anécdota, les me tocó estar un par de días en las oficinas del cliente para darles soporte con la implementación. Lo cierto es que tenían un modelo de source control totalmente ligado a la problemática del merge que permiten algunas aplicaciones de source control actuales. De vez en cuando puede venir bien trabajar por merge, pero no el 100% del tiempo. Era increíble ver en todas las pc de los desarrolladores las MISMAS pantallas. Todos codeando sobre lo mismo.
Y lo que es peor, eran las mismas pantallas que nos tocaron retocar a nosotros, y como si eso fuera poco, también a otros dos proveedores. Caótico. Al final estuve 2 días sin hacer nada porque pretendían hacer el merge entre los proveedores y lo que ellos estaban haciendo, encontrando breaking changes por todos lados.
Entonces esto nos dá para pensar en la siguiente idea. Consideremos los siguientes parámetros:
* Complejidad del proyecto: No sólamente la complejidad de lo que hay que hacer, sino tambien el CÓMO está hecho. Recordemos que estamos teorizando sobre proyectos pre-existentes.
* Creatividad permitida del proyecto: Si los estándares son duros e inflexibles, programadores experimentados podrían sentirse muy incómodos al tener que adaptarse a un estándar, especialmente si el mismo no vá acorde con las buenas prácticas y sus ideas particulares.
* Nivel requerido en el programador: Esto vá de la mano con la complejidad del proyecto. Si el proyecto es muy complejo, vamos a encontrarnos que quizás sí o sí necesitemos programadores muy experimentados (y por ende, caros).
* Cantidad de recursos requeridos: Otro valor que multiplica sobre el nivel requerido en los programadores. Cuanto más recursos necesitemos (para hacer varias tareas a la vez y demás cosas), mayor será el costo del proyecto.
Bajo el ejemplo que cité, y asignando valores en el rango de NULO-BAJO-MEDIO-ALTO podemos ver que en el proyecto en el que estuve se encuentran los siguientes valores de parámetros:
* Complejidad del proyecto: ALTA. El código es un desastre.
* Creatividad permitida: BAJA. No pongo nula porque al final terminé haciendo mis shenanigans.
* Nivel requerido: ALTO. Es tan malo el código que para poder trabajar de una forma medianamente eficiente y rápida se necesitan recursos de un mínimo nivel Senior.
* Cantidad de Recursos: 3. Aquí el número no fué dado al azar sino pensado tras haber realizado estimaciones y paralelización de tareas. Ví que por etapas podíamos tener 7 programadores contínuos, pero que generalmente todo redondeaba a 3. Viendo que era imposible pedir 7, pedí 4, esperando que me dieran 2 aunque sea. De pedo metieron uno.
Entonces aquí podríamos tener un objeto de estudio: La viabilidad motivacional.
Si tu proyecto es de una alta complejidad pero de una creatividad baja o nula, entonces requerís programadores muy experimentados que no tengan problema con ser "code monkeys". O sea, gente muy profesional que esté dispuesta a renunciar a la creatividad. Es algo bastante complicado de conseguir. Te diría que cualquiera que sepa en lo que se está metiendo va a tratar de aumentar su costo en un 40%. Yo ni llegando a las 5 cifras me metería en ese proyecto de nuevo.
Es un estudio de viabilidad que tiro como idea. Jamás lo ví en ningún lado, por lo que puede resultar interesante cuestionarse "¿cuál será el nivel de motivación de los recursos ante este proyecto?".
En resumen, los proyectos que vengan hechos de afuera SIEMPRE serán un dolor de cabeza. Queda en ustedes evaluar si la ganancia económica hace valer la pena el estrés que adquirirán inevitablemente.
No comments:
Post a Comment