Proyectos IT fallidos

No hay nada como participar de un proyecto IT que falla para aprender qué es lo que se hace mal en IT, a veces sin querer inclusive y con todo el training y la buena predisposición personal+laboral. Plus, se aprende que en IT, a veces el camino más corto de A a B no es una línea recta, y que ni un presupuesto gigante garantiza el éxito.

Lo que garantiza el éxito o fracaso de un proyecto IT, son las personas.


Algunas perlas de mi expertise-box personal de proyectos (es un pastiche, muy focalizado desde la visión de proyecto relacionados con Operations, y algo de sysadmin también):

- Software opensource y propietario, ambos deben ser evaluados para soluciones, si todavía no lo sabés, en algun momento te vas a dar cuenta (viendo de cerca los deadlines y la cuenta de presupuesto vaciandose).

- No importa qué tan caro sea un software, puede fallar, tener bugs, ser inusable (sí,esto quiere decir que habiendolo pagado, no se lo va a implementar finalmente), etc.

- Si el software es propietario, lo anterior sigue valiendo, más allá de lo que digan los sales engineer.

- No importa qué tan caro y propietario sea un software, qué tantos kg. de documentación incluya, y qué tantas horas de training se pueda hacer/obtener, puede ser increíblemente malo en el diseño/arquitectura, e imposiblemente difícil de deployar (implica un TCO - oculto - mucho más alto de lo esperado teniendo soporte (tel./mail)+documentación+cursos/training).

- Cuando la documentación de un software es inmensa, y todo el tiempo escuchan que el software es "fácil de instalar y administrar", sepanlo, no es fácil para nada, y al contrario, puede ser mucho más difícil de lo usual para otras opciones del mercado.

- Lo que vale de verdad respecto del soporte no es la palabra-promesa de los sales engineer en las reuniones de ventas, sino lo que dice el support agreement (leanlo con atención).

- No importa qué tan grande, fastuosa, vieja (X años/décadas de experiencia y demás sanata), popular ("tenemos de clientes a fulano"),  sea la empresa vendedora del software, todo lo anterior sigue siendo válido.

- Nada de lo que no esté supported por el vendor va a ser soportado de forma "extra", "favor de amigos", etc. por el reseller local. Hay honrosas, escasísimas excepciones y siempre son por tiempo limitado, y sin hacerse responsables - desde lo legal - de lo que pueda o no arreglarse (o romperse), en ese support no oficial.

- Si no tenés un especialista en un campo, no esperes que tu "recurso" (el tipo que va a hacer el trabajo), se convierta en un experto en 1 mes, no va a pasar, y si lo pedís de jefe a empleado, te van a decir que sí, pero después tampoco va a pasar :-) true story. Lo real es planificar una curva de aprendizaje realista, que involucre no solo lectura de documentación, sino implementaciones en escenarios de testing (claro, hace falta agregar más tiempo al proyecto para hacer esto).

- (casi redundando) Los trainings no crean expertos, sino la práctica+experiencia, si tenés gente entrenada, no son expertos, sino personal capacitado. La diferencia es el tiempo: cuanto tiempo va a tardar en hacer X trabajo una persona capacitada, vs. lo que tardaría un experto.

- (redundando) Si los "recursos" ya tienen práctica, igualmente no son expertos, les falta la experiencia. Siguen sin llegar al skillset level de los expertos, hay que tenerlo en cuenta.

- (más redundante todavía) No le pidas peras al olmo: Un jr. de lo que sea, no es un experto, la inteligencia puede adelantar camino rápido (a tenerlo en cuenta si ves un jr. con muchas luces), pero no puede ganar experiencia sin haberla vivido (más o menos en realidad). Conclusión: ambigüa, hay Jr. increíbles, que se convierten en Sr. de una semana para la otra, pero hay que tener precauciones extras al basar cualquier proyecto esa presunción. Los Jr. son Jr. en gral.

- No le pidas peras al olmo 2: un experto no siempre es un experto, a veces solamente es alguien que tiene "trayectoria". La trayectoria, hace cuantos años se recibió, cuantas empresas fundó (teniendo éxito o no), hace cuantos años trabaja en IT, etc. No (NO), es una garantía ni reaseguro del skillset. Es una señal positiva únicamente ("podría ser que tuviera tanto skillset como dice tener"). Los RR.HH. lo saben, ahora vos lo sabés. En la pista se ven los pingos (más o menos tambien / en Argentina "pingo" es un apodo para un caballo).

- Me acordé, "en la pista se ven los pingos" es la muletilla nacional de RR.HH. para cotizar - a la baja - sueldos ("retribución" en jerga), de expertos IT. En lo personal la escuché en 5 provincias diferentes (so far). No (NO), es la "posta", escatimar sueldos para pagar expertos cuando se los necesita. No, la sumatoria de X cant. de Jr. (baratos y jr.-jr, no pibes excepcionales), no constituye el skillset de un experto. Este tip es universal, si no lo seguís, el proyecto "te lo hace saber" debidamente, sin importar en qué parte del mundo estés o qué idioma estés hablando (no es una amenaza, es una promesa).

- Debido a todo lo anterior, una buena estimación rápida de la relación bueno/fácil-de-implementar del software suele ser pedirle al sales engineer que explique la arquitectura de la solución, "cortito, en 10 minutos". Es una (mala)señal si te replica pidiendo una meeting de 2 horas (o peor), que invites a TODOS tus ingenieros (así entre todos logran "entender cómo funciona"), cañon, notebook para pasar slides de powerpoint, pizarrón, marcadores, etc.

- Si de todos modos tenés que usar ese soft (el de las 2 a 4 horas de explicaciones "básicas"), hay que hacer importantes previsiones respecto de la necesidad de expertos, training para Jr., etc.

- Un PM (project manager) de un proyecto IT debería tener un excelente background técnico respecto del campo puntual del proyecto (Networking, Adm., Desarrollo, DBs, etc.).
- Los PM sin background IT tienen el potencial de crear situaciones y circunstancias inverosímiles durante un proyecto IT ("no puede ser que en 2 años, con un proyecto tan chico y habiendo gastando X millones no se haya terminado", de hecho sí se puede).

- FTE. Este concepto parece extraterreste en muchos lugares (sería una mala señal darse cuenta de eso en un proyecto a realizar ahí). Me refiero a la idea (la sigla puede ser otra, según la especialidad, carrera, universidad, país donde se esté). FTE es la cantidad de laburo que puede hacer una persona por año. La ausencia de la consideración de FTEs suele ser una señal de que el tipo "a cargo" (gerente o lo que sea), no tiene mucho background de administración de organizaciones (ni se preocupó en adquirirlo tal vez, luego de cambiarse al campo gerencial).

http://en.wikipedia.org/wiki/Full-time_equivalent

Etc.

Y por supuesto, (casi) todo es relativo, el contexto exacto, el escenario puntual siempre tiene mucho que ver, o todo.

Van a leer mucho (un montón), de material sobre cómo se "hace bien" un proyecto IT, y hay muchísimo material bibliográfico. Lo que se "hace mal" no suele estar muy presente en las conversaciones, hay buenos libros, pero muy pocos sobre malas prácticas en proyectos IT.


Hay muchos más tips de los anteriores en mi box, pero les dejo estos otros (ajenos), para hacer el contraste:

http://spectrum.ieee.org/riskfactor/computing/it/queensland-health-payroll-system-one-of-the-worst-it-projects-ever
http://spectrum.ieee.org/riskfactor/computing/it/conclusion-of-uk-firecontrol-final-post-mortem-extraordinary-failure-of-leadership
http://spectrum.ieee.org/telecom/security/napolitano-cancels-the-us-1-billion-sbinet-virtual-fence-project
http://spectrum.ieee.org/riskfactor/computing/it/saic-agrees-to-forfeit-500-million-for-citytime-project-debacle
http://spectrum.ieee.org/riskfactor/computing/it/queensland-health-payroll-problems-just-go-on-and-on

Sldos.

yaco