Disclaimer
No deja de extrañarme la cantidad de veces que recibo solicitudes para tiempos y procedimientos exactos en los proyectos de desarrollo e implementación de Software. A decir verdad, es nuestra responsabilidad como desarrolladores o consultores o como les quieras llamar, intentar dar un estimado de tiempos tan apegado a la realidad como sea posible. Pero la exactitud de dicho estimado suele estar relacionada con factores que no necesariamente se relacionan con la habilidad, conocimientos o actitud del personal que te prestará el servicio.
Por lo anterior, te presento estos puntos que tal vez sea interesante que consideres en dichas situaciones. Si eres un proveedor, son razones por las cuales aunque quieras, es difícil encontrar el balance entre que el cliente sienta que le estás encajando el diente (mucho tiempo) o que tus empleados o compañeros se sientan explotados (poco tiempo). Si eres un cliente, ojalá te ayude a entender que no es ningún fetiche por "cobrar con taxímetro", simplemente es o sería lo más justo para todos.
Aunque las métricas y procedimientos mejoran con los años, el desarrollo de software como tal está, en mi opinión, aún muy lejos de ser una ciencia exacta. Si bien estos años han hecho que ya no sea más una especie de "trabajo artesanal". Yo diría que al día de hoy puede entrar más en la clasificación de disciplina: existen ciertos conocimientos que debes tener, no te cae nada mal un poco de intuición o talento, pero en realidad nunca puedes ser exacto. La duración de los ciclos de pruebas y mantenimiento (versus el tiempo total del proyecto), en comparación con otras actividades, es una clara muestra de lo anterior.
Así mismo, y relacionado con lo anterior, por factores muy diversos (que espero abordar en otro post) la rotación de personal en las fábricas o consultoras es constante. Además, en virtud de la ramificación de las sub-disciplinas dentro del software, el ritmo de trabajo varía entre los diversos equipos o personajes multidisciplinarios que son requeridos para un desarrollo "de acuerdo a los cánones".
Esta relativa especialización (que todos piden, pero pocos dan oportunidad de obtener) en los desarrolladores da como resultado que el nivel de conocimientos no pueda, de ninguna manera, ser el mismo entre el proveedor y el personal de mantenimiento del cliente (en el mejor de los casos, suponiendo que exista un área o personal de mantenimiento de software). Es esto lo que imposibilita la redacción de manuales "paso a paso" que puedan ser útiles bajo cualquier situación. Sencillamente porque, si cada probable escenario de falla estuviera previsto y pudiera ponerse en un manual, entonces sería mucho más sencillo crear un software adicional que se encargue de resolver los problemas, y la razón de que tu área de soporte exista quedaría reducida a nula. No hay que subestimar de esa manera el trabajo del proveedor de servicios.
A lo anterior, súmale que tu personal también es propenso a rotar. Así como hoy puedes tener un elemento que sepa manejar perfectamente el sistema operativo que le pongas en frente, con unas horas de Googleo, puede que en unos meses el encargado del sistema se moleste porque no le estás explicando paso a pasito cómo usar vi (me ha pasado). La documentación debe estar centrada en las particularidades del sistema, del desarrollo per se. Pero esto no implica que se creará un troubleshooting para cada incidente que se te pueda presentar (y si no me crees, checa que después del troubleshooting, el instructivo de tu electrodoméstico suele traer los datos de soporte ;-) ).
Te preguntarás entonces, ¿qué es lo que se debe hacer para que todos ganemos? En lo que respecta a los procedimientos, una idea que me agradó mucho en
Javanes fue la relacionada con contratos de soporte. En estos, se provee un "seguro" de X horas al mes (donde X es derivado de un análisis tanto del sistema como de la pericia del cliente), mismas que pueden o no ser consumidas. Cada que se termina un servicio, se entrega una memoria de las actividades realizadas. Esto lo puedes agregar como apéndice a tu documentación, y poco a poco te irás haciendo de procedimientos para incidentes específicos, que incluso pueden incrementar la base de conocimientos de tu equipo.
Por otro lado, en lo que respecta a los tiempos, como cliente lo que puedes hacer es tener comprensión hacia el proveedor, que al final siempre intentará encontrar el balance entre tu beneficio y el de sus empleados. Al final, encontrar ese balance es su trabajo :-) .
¿Cuáles son tus opiniones respecto a este tema?
Saludos,
