(Artículo originalmente creado en mi cuenta de LinkedIn) Recientemente participé, como especialista de producto, en un proyecto para la empresa que trabajo. En este caso, mi participación consistió en ser el “salva vidas” del proyecto para el cual nuestro cliente estaba trabajando. Para mejorar el contexto del caso, fuimos sub contratados para solucionar problemas que nuestro cliente tenía con un tercero.
Para comenzar, quiero dejar claros los puntos que trataré en este artículo y que tomo como referencia:
- No conocer bien tu producto, a tu cliente y hacer una mala venta.
- Aumentar las expectativas de un producto.
- Gestión y administración del proyecto.
- Estimación de tiempos y esfuerzo
A continuación explicaré en detalle cada uno de los puntos.
1. No conocer bien tu producto, a tu cliente y hacer una mala venta
Cuando un comercial no conoce por completo el producto que está ofreciendo, no puede comprender cuales serán las limitaciones de la herramienta o servicio de acuerdo a las necesidades de su potencial cliente.
Conocer el producto: Me atrevo a decir que cuando un comercial tiene falta de conocimiento en su producto (y es entendible), este deba acudir a una o más personas que si lo tengan y en quienes se pueda apoyar para encontrar todas las alternativas posibles de este producto para solucionar los requerimientos del cliente, o en caso tal, a rechazar cualquier punto de un documento que no pueda ser gestionado, al menos directamente.
Conocer al cliente: Si no conoces a tu cliente y claramente el negocio específico del que tratará la negociación es muy probable que se lleguen a aceptar términos o a comprometer requerimientos que fácilmente pueden ser direccionados a una plataforma existente del lado del cliente para no aumentar la carga del producto a ofrecer. Para dar otro poco de contexto, el cliente final requiere para sus productos un proceso de Clasificación, Reconocimiento y Extracción de los datos que abarquen todo el paquete documental incluyendo ciertas (o todas) reglas de negocio aplicadas en el flujo.
Lo interesante de las reglas de negocio, es que este ya cuenta con un BPM implementado para su flujo y manejo de reglas pero por el desconocimiento en su momento al parecer de la existencia de este BPM o por el afán de vender, se ofreció todo el manejo de las reglas de negocio a nivel de nuestro producto.
Si se toma el tiempo para dibujar todo el escenario y proyectar la necesidad del cliente teniendo en cuenta la cantidad de tipos documentales versus la cantidad de reglas a implementar hubiera sido demasiado fácil comprender que la carga de reglas de negocio no debería estar soportada por el producto ofrecido sino del BPM que ya está especializado para ese tipo de cargas. Lo anterior no quiere decir que el producto ofrecido no tenga las capacidades de procesar las reglas de negocio que se necesiten. Justamente el producto que se ofreció al cliente final tiene limitaciones importantes a la hora de ejecutar estas reglas. Parte del desconocimiento del producto estriba en no comprender que existe una versión diferente que posibilita el manejo de flujos con el BPM propio sin tener en cuenta el de un tercero.
Debido a esto, se viene la pesadilla de no manejar de manera nativa las reglas del flujo aplicables a cada tipo documental o etapa del proceso sino manejarlas con lógica de programación, en este caso, escribir el código dentro de la aplicación (Visual Basic) dependiendo de la lógica de programación del ingeniero que sea encargado del proyecto. (Yo aún no había llegado en esta etapa). Es claro para un desarrollador que meter en código las reglas de negocio de más de 150 tipos documentales será toda una pesadilla a la hora de brindar mantenimiento o garantía.
2. Aumentar las expectativas del producto
Como complemento de las fallas relativas al primer punto, debe considerarse que el aumento en las expectativas de un producto ofrecido es un error grave, ya que estas no quedan en el olvido. Un cliente siempre querrá exprimir al máximo una herramienta y en el momento de presentarse las limitaciones obvias, llegan las reclamaciones, la búsqueda de excusas y diversas maneras de cubrir el “engaño” que ha sido creado para tener una venta. Dejar en claro los límites de tu producto es vital para que no se acepten requerimientos fuera de sus capacidades. Y, en caso que dichos requerimientos sean una exigencia, debe presentarse claridad en relación a cuáles serían las mejores formas de dar a solucionar problemas y evitar retrasos al cronograma.
3. Gestión y Administración del Proyecto
Llegado el momento de ejecutar, se inicia con lo que se podría decir, es una etapa ligera. Esta consiste en la firma de acuerdos, la presentación del equipo, instalación del producto en los diferentes ambientes del cliente, realización de pequeñas pruebas para certificar licenciamiento, concurrencia y otros detalles que serán vitales en el funcionamiento de la solución que se le presentará al cliente.
Como el proyecto que se desarrolla es para la gestión de los documentos, se solicitan múltiples muestras de estos para realizar los análisis correspondientes al tipo de formato, la escritura e identificación de los campos que son requeridos para las reglas de negocio y tomando en cuenta todos los aspectos requeridos para clasificar y extraer la información. Como este tipo de trabajo es casi una constante en los diferentes proyectos para cualquier cliente, es fácil entregar un estimado del tiempo que tardará ejecutar estas tareas a nivel general sin tener en cuenta las particularidades que se puedan presentar según las exigencias del cliente. El resto de actividades si requieren una estimación diferente.
4. Estimaciones de tiempo y esfuerzo
Estimar los tiempos y el esfuerzo de las actividades es crucial para cualquier proyecto, pues de esto derivan todas las tareas principales y secundarias, se definen las fechas de entrega parciales y totales. Además, con esto se indican las fechas de facturación del proyecto, ya que el ofrecimiento de un producto no es una actividad cuya función está encaminada únicamente a la satisfacción del cliente, también busca responder a los intereses de la propia empresa.
Para esta negociación en concreto, además de las fallas anteriormente identificadas, llega uno de los errores más graves: la estimación incorrecta de algunas actividades. Después de dialogar con el Gerente del Proyecto encontré dos cosas que pudieron llevar al caos: Falta de experiencia haciendo estimaciones y la presión ejercida a nivel comercial o gerencial para reducir estos tiempos
Cualquiera de las opciones anteriores es perjudicial para un proyecto. La experiencia no se deriva de un cargo o una posición en la empresa, para hacer una estimación se necesita tiempo trabajado con la herramienta, haber participado en proyectos similares o de igual complejidad. Es indispensable contar con más de un punto de vista técnico de acuerdo a cada requerimiento y tener en cuenta la fluidez del trabajo de las personas que estarán a cargo de la ejecución del proyecto.
Sobre todo, es necesario que frente a la estimación esté una persona con el suficiente poder de decisión para dejar claros estos tiempos y también aclarar que en menor tiempo, el producto no será de igual calidad o se necesitarían más recursos para poder cumplir con cada requerimiento, así el cálculo de cada actividad llevará a un tiempo total de ejecuciones que indicará una fecha de entrega prudente para el cliente. Puedo decir con certeza por que lo he vivido en otras empresas que para los proyectos tienen en mente que mientras más rápido se entregue un proyecto, será mejor para el cliente pero por más que les pasa, no tienen en cuenta que si se acelera esta entrega, no todos los requerimientos serán aceptados de inmediato cayendo en tareas de garantías y mantenimiento que igual tienen un costo de recursos importante y no todo será un soporte que puede ser facturado. Tampoco quiere decir que a mayor tiempo será mejor la calidad del producto y es por esto que se debe estimar correctamente para tener un balance (suena perfecto pero pocas veces se logra este balance).
Cuando estos tiempos son mal estimados y se solicita inclusive hacer tiempos extra para poder realizar las entregas, se comete otro error (totalmente mi opinión y nada general), este es mi pensamiento el cual puede o no, ser compartido por otras personas pero…
Yo soy una de las personas que rinde el máximo en el horario normal de trabajo pero en el tiempo “extra” me siento totalmente explotado y mi productividad baja dramáticamente.
Edwin Guzmán
Los tiempos extra de acuerdo a lo que he experimentado, no son totalmente productivos, aumentan el nivel de estrés del equipo lo que al final puede incurrir en malas ejecuciones y trasladar el problema a la siguiente jornada.
Para este proyecto, los problemas de mala estimación y errores de ejecución causaron una rotación de personal tanto de Ingenieros de Desarrollo como de Gerentes del Proyecto, a un punto tal, que decidieron subcontratar los servicios de la empresa para la que trabajo y cuya asignación de recurso para la mano de obra fui yo, de esta manera sacar a flote este barco que estaba hundido con casi un año de atraso.
Mis hallazgos
Al llegar asignado al proyecto, me di cuenta del verdadero caos.. Luego de todo lo anteriormente expuesto, tener casi un año de atraso ejerce mucha presión entre las dos partes (nuestro cliente y su cliente) y lo grave del caso es que nos solicitan dar solución a estos problemas en un tiempo record de dos meses.
Inicialmente querían que el recurso asignado (osea YO) fuera 100% administrado por ellos y la persona que administra el proyecto y el recurso por parte de mi empresa entendió que con el caos actual sería imposible delegarles la gestión total así que la petición fue rechazada.
Como debe ser, solicitamos que cualquier tarea se solicitara por escrito y con la definición clara para entregar exactamente y con evidencias lo que fue requerido, para demostrar el desorden del proyecto en curso, muchas de las tareas ejecutadas por los anteriores desarrolladores no pudieron ser certificadas puesto que todas las solicitudes del cliente lo hacían verbalmente y cuando se hicieron las pruebas, estas eran negativas indicando “esto no fue lo que pedimos”. Me gustaría compartirles la trazabilidad y el seguimiento que hice para este proyecto pero por respeto a las partes, omito esto.
Revisión del Proyecto
Siempre inicio haciendo un inventario del proyecto en curso y para este caso encontré lo que cualquier desarrollador podría definir como una pesadilla…
- 5 diferentes desarrolladores escribieron código
- De los 5 desarrolladores, solamente 2 dejaron comentarios al código
- La cuenta de las líneas de código llegó a más de 57.000
- Muchas de las 57.000 líneas pudieron ser reemplazadas por funciones y no repetir entre los diferentes tipos documentales
- Los requerimientos no estaban consolidados, existían hasta 5 versiones de matrices con todas las solicitudes
Manos a la obra
Ha llegado mi hora de ejecutar, aclaro que entre mis tareas no estaba contemplado revisar las 57.000 líneas de código sino entender cada requerimiento, ejecutar una prueba y determinar como dar solución y si en este paso debía modificar o corregir la lógica de la programación, entonces realizarlo y si yo lo consideraba, decidía comentar métodos para usar mi propia lógica.
Lo primero que hice fue sentarme con una persona del lado del cliente final para tener claridad de como se ejecutan las pruebas y la metodología para certificar los nuevos cambios que yo entregaría, me gusta estar alineado con el cliente para entregar el mejor producto posible.
Seguido a esto, me reuní con el Gerente del Proyecto y este me hace entrega de una matriz la cual debía ser validada con otro par de matrices para poder “medio” entender el desorden del levantamiento de información, al final no pude entender el desorden de documentos y solicité la información consolidada para poder trabajar.
Con cada tarea iban apareciendo retos, claramente debía hacer grandes esfuerzos para entender un fragmento de código escrito por los diferentes desarrolladores con diferente lógica a veces para las mismas tareas pero una vez acostumbrado las cosas comenzaron a fluir. En una de las tareas me surgió una duda que implicaba el entendimiento de toda una regla de negocio para poder aplicar a un documento y entre las palabras usadas para que el Gerente de Proyecto me resolviera esta duda fue “Yo asumo”, para mi esto solo se traducía en peligro.
La entidad para la que estaba desarrollando el proyecto, no podía saber que Edwin Guzmán estaba subcontratado para solucionar los problemas de su proveedor, así que toda la comunicación debía tener como puente al Gerente de Proyecto lo que hacía un poco más lenta la solución de problemas y la entrega de cada gestión para la etapa de pruebas. Muchos de los temas que yo debía aclarar correspondían a asuntos que para el cliente, ya eran tema pendiente de entrega entonces a veces, pedir información extra era complejo. Muchos de estos temas fueron fáciles de aclarar pero otros debieron quedar pendientes de aprobación.
Al tener una presión para entregar el proyecto terminado al cliente en tan solo dos meses y asumiendo varios de los trabajos, llego otro problema que en mi opinión, le suma gravedad a la calidad del producto terminado…
El Gerente de Proyecto no tenía como aclarar o pedir esta claridad al cliente por lo que me indicaron lo siguiente: “Continúe haciendo los desarrollos sin tener que hacer una validación con el cliente, si algo no queda de acuerdo a lo que se solicitó, usamos el tiempo de afinamiento en producción para corregir todos los hallazgos”.
¿Que pensar cuando te hacen esa solicitud?. Lo primero que llegó a mi mente es que el afán por entregar el proyecto está obligando al encargado del proyecto a entregar cualquier producto resultante de la presión y aprovechar los tiempos de mantenimiento y garantía para afinar todo lo que pudo salir bien desde el inicio. Con lo narrado hasta ahora es suficiente material para entender que este proyecto está lleno de problemas, muchos se sentirán identificados con gestiones realizadas o con algún proyecto en curso.
Para finalizar (y de paso poner la cereza en el postre) y aunque mi rol nunca ha sido de Gerente de Proyecto, se que las siguientes frases no deben ser dichas a ningún proveedor como en este caso era mi actividad. Se supone que antes de haber contratado nuestros servicios se debían tener claras las actividades y las gestiones a realizar pero en este caso, todo parecía sacado de una comedia, tres frases que se repitieron por varios días:
- ¿De qué otra manera podemos apoyar al cliente?
- No se que más tareas asignarle
- ¿Que más puedo ponerlo a hacer en el proyecto?
De los dos meses, solo hice efectivas 148 horas de las cuales, las últimas 23, fueron tiempos muertos esperando trabajo para realizar, a tal punto, que con 172 horas pendientes para ejecutar, no tuve más asignaciones así que debí salir temporalmente del proyecto y dedicarme a otras labores mientras llegan más tareas y mientras este tema del Covid-19 permite retornar a las labores normales.
¿Qué opinión les genera esta experiencia que me ha tocado?
Edwin Guzmán
https://edwin.tecnoficcion.com