Checklist de cuando los proyectos fallan

Hoy quiero compartir con uds. en mis 11 años de desarrollo de software algunas de las causas que he vivido y visto para que los proyectos de desarrollo de software fracasen con total seguridad.

• Estimación a plazo fijo y costo fijo sin un análisis previo del proyecto. Esto lo he visto un "millon" de veces. El cliente te llama, te dice que quiere esto y que le mandes la cotización por la tarde o al día siguiente a primera hora. Tal vez guíado por tu experiencia pasada en proyectos parecidos, o por la confianza en tu capacidad como desarrollador aceptas y bueno, te vendrán días tranquilos al inicio y un crunch time terrible para terminar. Si estas como dependiente, lo mas probable es que tu jefe de presione, los usuarios ya no confíen en ti, o tu mismo empieces buscando otra oferta laboral. Si eres independiente, es mas fregado, porque no te pagaran las últimas facturas si hay atrasos o el cliente concluye que lo realizado no era lo que se esperaba. Si te esta pasando esto que te cuento , di que NO, solicita revisar antes el proyecto, y establece tu los tiempos  y costos. Si aceptas de todas maneras, te pregunto ¿Tan desesperado estas? , vas a sufrir al 100% de seguridad y no necesito ser Huachano (aunque lo soy) para adivinarlo.
• Aceptar un proyecto desarrollado por otro proveedor y que te diga el cliente que lo termines o arregles, porque solo le falto algo. Si te esta pasando esto, cuidado, averigua primero porque el otro proveedor no lo pudo terminar, tal vez nunca supo que quiere el cliente, tal vez tecnicamente no es viable. Y si te dice terminalo, revisa primero, pues si tecnicamente no resuelve el problema, tal vez haya que hacerlo todo de nuevo. Nuevamente pon tus condiciones, tu eres el Doctor, no te puede dar el "paciente" su propio diagnóstico.
• Armar un equipo con "recomendados" por algún conocido, darles los mejores cargos y considerar al talento solo como "recurso" técnico. Esto es muy común, generalmente le llaman "cargos de confianza". En una industria como la de la Ing. de Software, esto puede ser que la división cierre, se tomen malas decisiones y si lo peor puede pasar (que pasará), volaran todos y el Gerente.  En una Industría como la del Software, se necesitan Ingenieros de Software. Si tienes los "Gestores" que son de tu confianza, ellos a la hora que el barco este de mal rumbo no te ayudaran. Pueden tomar decisiones que a la larga causen fracasos, recomienden productos o estimen hasta el carajo. En fin les doy este ejemplo: Por el año 2000 entre a una empresa, a un proyecto muy importante, y recomendaron el WebSphere Application Server (WAS) 2.0, se desarrollo casí un año y cuando se va a instalar la aplicación, esta cargaba el home en 2 minutos. Si 2 minutos, 2 minutos,  2 minutos, nooooooo!!!.  Bueno al final hasta se contacto al creador del WAS y este no nos pudo ayudar.  Que había pasado. Habíamos desarrollado todo en Java, pero, el WAS en esa versión solo debía trabajarse un 20% en java y el resto en otro lenguaje. Resultado final, proyecto cancelado, división cerrada.  Exodo del recurso técnico o pase a contratas, es decir, dejamos de pertenecer a la empresa para pasar a proveedores de la misma.
• Confiar en herramientas del cual no se tiene muchos casos de éxito o referencia. Esta se parece a la primera, se contrata mucha gente , se le capacita, y al final el producto terminado no cumple los requerimientos no funcionales esperados.  Hace años aparecieron muchos productos como el Genexus, estos productos vendían la idea de que el programador se puede sustituir por una herramienta generadora de código, con interfaces y todo.  Una herejía que costo caro. El producto utilizado si bien se programaba por reglas, reglas propuestas por seres humanos, finalizo en un codigo insostenible, pero que funcionaba, claro, funcionaba solo para 5 usuarios. Whatttt??? si, como se lee, solo permitía 5 usuarios concurrentes. Por mas que se trato de hacer reingeniería reversa a los jars del producto, nunca se pudo solucionar y el resultado fue, proyecto cancelado, penalizado y miembros del grupo despedidos.
• Me falta 3 semanas para terminar, contrato todos los freelances que se necesita para cumplir con el proyecto.  Esto fue lo peor en gestión que pude ver. Un conocido mío con el proyecto ya casi perdido y con 3 semanas mas de extensión no tuvo la mejor idea que contratar a cuanto programador apareciese, y que trabaje en una funcionalidad de lo que faltaba y con la espereranza de en la ultima semana integrar todo. Así que llegaba cualquier programador, hacía la funcionalidad pedida y listo, cobraba y se iba. Al final me entere que fue un desastre, era imposible integrar porque nadie entendía nada, algunos incluso programaron tan mal que su funcionalidad corría en duro jajaja Como no había revisión de código, hacían un mamarracho, cobraban y adios ( a apagar el teléfono). Resultado: Proyecto penalizado, cliente perdido, gestor despedido de la planilla de una gran empresa. Espero haya aprendido la lección porque ha seguido de gestor en otras empresas.
• Gano un proyecto y le bajo 6,000$ al contacto. Estos proyectos no terminan bien. Esa persona nunca sera tu aliada. Si las cosas van mal y el trabaja ahí, ten por lo mas seguro que te ira mal. Ademas estas robando. Di "NO" sin dudarlo. Lamentablemente algunos dirán "así es el mundo de los negocios". Pues sí, así tal vez sean, pero independientemente de tus creencias religiosas, ¿tu ética donde esta?.  Y sabes, si las cosas no van bien, el no te va apoyar, y si lo "Echas" jajaja bueno ¿como probarlo?, estas solo amigo. Así que juega limpio.
• Gano el proyecto y me contrato a programadores de 700 soles. Esto lo he visto en muchas empresas que ganan proyectos, creen que con sus dos gestores estrellas la haran. Al final esos pobres chicos traídos del interior del país, son explotados, los hacen trabajar de sol a luna, incluso los fines de semana y para variar les pagan a destiempo.  Entonces lo que supuestamente te ibas a ahorrar, se convierte en los que al final vas a pagar de penalización.  A proposito de este punto ¿ya habra acabado su proyecto mi pata que va como 6 meses de atraso?
•  Apoyar a fabricas de software en supuestas cosas pequeñas.  Ya cuantas veces he contado que muchas de las gerencias de grandes empresas contratan fabricas de software CMMI nivel 3 para arriba. Pero estas, contratan gente practicante, con poca experiencia. Si te llaman para salvarles la vida diles NO. Sino estaras como yo que cometi el error de aceptar amaneciendome para apoyarlos en un supuesto "bug" y luego ganandote el problema de otros. Lo peor es que luego en el cliente te hacen pasar verguenzas como "esto no corre en IE 7". Yo le pregunto a los chicos y ¿sabían que debería la aplicación trabajar con IE 7 ?, me responden "Si, pero corría mejor en Chrome". PLOP!. Entonces cuidado, esas posibles alianzas prometidas, que trabajaremos juntos son "problemas que se vienen venir".
• No tener al usuario disponible. Si el usuario no participa de tu proyecto como debe ser, no responde a tiempo, demora en darte facilidades, pues toma tu laptop y anda a sus oficinas y solicita un espacio. Esto me ha pasado. Hay mucho "politico" en los proyectos, un sintoma para que los descubras es que quieren quedar bien con todos: contigo y con sus usuarios. Estos son los mas peligrosos porque al final causan impedimentos y retrasos. Así que comprometelos , sino informa al sponsor, al jefe de estos "politicos" y salvaras tu proyecto.
• Equipo no comprometido. Esto si no se lo deseo a nadie. Si el miembro ya no esta comprometido con la empresa. Empezará a trabajar con desgano, incluso ya no tendrá el respeto por su equipo y trabajara "lento" o haciendo trabajos "extra" en la empresa. Es bueno mantener al equipo , pero, si se detecta esto  hay que invitarlos a salir. Se pueden dar oportunidades, un plan para alinear al compañero , conversar y ver que problemas tiene, pero, si no hay mejoras, no se puede hacer nada. O ud. deja una fruta con hongos y "telarañas" en medio de tanta fruta buena. El problema mas serio que vi en estos años es que tengan una vida desordenada. No se como sera en otros países, pero aquí he visto que su vida personal les afecta mucho. Una novia que los llama a cada rato, que los grita , incluso me han llamado a mi casa para quejarse. Que vengan arañados. Definitivamente esto no es bueno para nadie. Lastima porque talento tienen pero, puede perjudicarte tremendamente. Eso si que sea tu equipo el que tome la decisión de que lo retiren es lo mejor que te puede pasar. Es un buen sintoma tambien para ti que el equipo esta alineado.
• No pagar tributos, y tener una organización boca abajo. He visto muchas consultoras que creen que su vida es solo proyectos, expedir facturas, cobrar, pagar al team  y listo. Otra cosa que puede causarte problemas es que no pagues tus tributos, tus servicios, tu alquiler, que pagues a destiempo. Puede traerte problemas ¿porque??, porque no tendras cabeza para tus proyectos, si te embargan las cuentas, si te llegan notificaciones, si generas "distracciones", pues que cabeza tendras para el proyecto.
• Sobrecargar de proyectos a tu team. Otra de las causas que puede traerte problemas es que por manejar varios proyectos , tomes y tomes todo lo que venga y le asignes a tu team, sin preguntarles, sin validar si es posible darle esa carga. Al final se genera estres, trabajo con desgano, tiempos no cumplidos y lo que ibas a ganar puede resultar en colaboradores desmotivados, o ex colaboradores, o lo peor ex clientes.
• Preocupate que tu gente no lea, no participe en comunidades, no tenga cuenta de github?? jajaja. Si parece broma, pero, preocupa. En nuestra industria se necesita gente que este involucrada con la carrera, que le apasione, que colabore, que participe. Si solo viene y se va, y no lo ves participando en nada de la carrera, entonces, cuando investiga? cuando lee? Si todo tu equipo es ausente en los eventos de la misma empresa. Cuidado porque entonces es señal de no compromiso.
• No buscar una relación de largo plazo con tus clientes. Si solo ves a tus clientes como el proyecto o contrato que llego este mes, y no buscas algo mas con el, pues sera un cliente que no se fidelizara. Tienes que ser un consultor, ver si lo que te pide lo necesita, darle el plus de recomendarle y tenerle informado de lo que hay, que busca y que puede obtener contigo. Si tienes clientes que están contigo desde el primer dia de fundada tu empresa, es señal que las cosas van bien. 
• Aceptar proyectos con metodologías propuestas por ellos en el que el software es una añadidura. Esto lo veo mucho en el estado. Te mandan a hacer toda la documentación que exige el PMBOOK o sus combinaciones de metodologías para luego de 90 días, te den 30 para terminar todo el software solicitado. Di NO, NO, sino acuerdate de las penalizaciones por no acabar el proyecto.
• No tener un proceso de desarrollo solicitado y si lo tiene no cumplirlo. Vamos a hablar del waterfall: Análisis , Diseño , Desarrollo, Pruebas, Puesta en producción y soporte acorde a la garantía.  Olvidemosno de lo agile. Tu planteas este esquema. Pero ni lo cumples. Si bien haces el análisis, diseño, empiezas a desarrollar siguendo un gantt propuesto, pero, como ya de por si, te llegan impedimentos, las pruebas son las que sacrificaras. Te esta pasando?. Es mas tu empleador por ahorrar costos, porque seguro el cliente no lo querrá pagar, no pone un colaborador de QA (quality assurance). Entonces , ya lo habras vivido como yo, tu epoca de post producción inicia y continua con la garantía con soporte para arreglar bugs. Dale un vistazo a las metodología ágiles o marcos como scrum, kanban, XP (extreme programming). No te digo que te salvaran la vida , pero, al menos te diran si el proyecto va o no va en corto tiempo. Claro esta si tienes un contrato fijo con plazo fijo, al menos mejoraras en la gestión, tendras feedback del cliente, del team, tendras información que es lo que falta para poder saber como va todo , pues nadie que yo sepa ve el futuro.
• No incentivar buenas practicas, refactorización, delivery continuo. Si esto se lo debemos a lo agile. Pero ellos tienen razón, es bueno como Ing. de Software interesarnos por hacer mejor código, refactorizar en grupo, hacer programación en parejas, y buscar un sistema de delivery continuo. Todo esto te dará información, tendras metricas, sabras como va mejorando el equipo, y podras disfrutar de un buen trabajo, un cliente mas contento y si hay problemas, tendras mejores armas para solucionar los problemas.
• No tener controlador de versiones.  Busca un buen flujo de trabajo, revisa como gestor el codigo de tu grupo. Haz pull request, recomienda en caliente mejoras, pregunta, y enterate como va por dentro todo.
• No hacer sobredosis de tests.  Testearas todo por tener cobertura de 100%. Tiene sentido testear metodos privados? todo el javascript que tienes? todas las pruebas unitarias de la capa de dominio. Si te demoras una hora en programar y testear 5 horas, pues algo anda mal. Testea el comportamiento, busca que tus tests hablen por si solos. Si tus tests no se entienden , ese tambien es otro sintoma. Y nuevamente no digo que no hagas tests. Pero, haz lo que te de valor, lo que es el core.
• Si hay problemas te vas y les dices, pidanse pollo y soliciten factura. tienes que estar con tu equipo en las malas y en las buenas. Investiga, no solo veas office, facebook, twitter. Investiga y recomienda.  Sino estas equivocado de profesión. 

Bueno, espero seguir completando esta lista. En general recomiendo que busquen armar un buen equipo sin mucha rotación, compartan buenos momentos de esparcimiento. Vayan al cine, comprense un play, una TV (tambien para ver el task board), apoyalos y remueve todos los impedimentos que haya.

Aprendan a decir NO y justifiquenlo.

Ah y ojo que se autoorganicen. Tu no puedes hacer todo por ellos. No puedes tampoco.

Espero que les ayude en algo lo poco que me he acordado.

Jose