Este es un proyecto cancelado que no recibe actualizaciones. No obstante, puedes acceder a su archivo como referencia.

Versión Cero

Conversación con el Capitán del Proyecto

Hoy estuve en el chat con un amigo a quien llamaré el Capitán del Proyecto para preservar su anonimato. El Capitán me contaba lo que estaba pasando en su proyecto, que no es nada nuevo, ni nada sorprendente. Pero no por ello menos impactante.

por Sergio Montoro Ten, 22 noviembre 08

C: Oye, quiero usar algo tuyo
S: ¿Y qué puedo hacer por ti?
C: Dejarme usar parte de tu texto de Mejoras envenenadas
S: Si, se puede reproducir, copiar y modificar
C: Me ayudará a desenmarronarme
S: ¿Y a qué se debe tanto veneno organizativo?
C: En el proyecto que gestiono, desean unas modificaciones que no tienen ni pies ni cabeza, ni técnicamente, ni organizacionalmente
S: Diles de mi parte, que la Regla Nº1 de la Informática es: “Si funciona ¡no lo toques!”. Nunca hay que intentar arreglar nada que no está realmente estropeado. Entonces es cuando se jode de verdad
C: Pero ellos no saben que realmente no está estropeado. Lo que sucede es que son un grupo de gestores administrativos jugando a ser técnicos de finanzas. Pero si no saben la diferencia entre firmar un contrato y contratar, poco puede hacer la aplicación (y yo) por ellos
S: Las personas deben enteder que la tecnología no es la solución a los problemas, sólo es una herramienta para solucinarlos, pero no la solución en si misma
C: Quizás ni para solucionarlos, quizás para mantener la solución una vez que se ha encontrado. Una profilaxis de introducción de datos no va a hacer que tus datos mierderos sean maravillosos; primero limpia, y luego aplica el proceso
S: Entonces ¿Cual es exactamente el problema?
C: Efecto Pygmalion, lo llamo yo
S: ¿Qué es lo que quieren hacer?
C: Tienen bugs que se solucionan con service packs y, al mismo tiempo, muchos desarrollos. Desarrollos llevados a cabo por alquien que no conocía el producto. Pues bien, quieren no aplicar los service packs, desarrollar ellos mismos los fix contenidos en los service packs, y, una vez estabilizada la aplicación, aplicar los service packs estándar y hacer upgrade. FLIPA. Luego, obviamente, eso desgranado en centenares de mejoras que son incoherentes con su proceso de negocio Y, en algunos casos, podemos decir que hay bugs serios, pero en la mayoría es, además, porque en vez de a la derecha, X aparezca a la izquierda
S: ¿Y el problema es que los nuevos service packs que arreglan los bugs se dan de ostias con sus propios desarrollos?
C: No, se desarrolló sobre aplicación sin service pack con lo cual, si aplicas un service pack CABE LA POSIBILIDAD de que los desarrollos se vayan al carajo. Esa es una. Pero además, ¿para qué vas a desarrollar si luego, encima, vas a aplicar service packs que harán lo mismo?
S: Porque eso aparentemente es lo que minimiza el riesgo ¿Y tu qué es lo que quieres hacer en vez de su propuesta?
C: Lo que minimiza el riesgo (y el coste) es abordar el problema de fondo, que es la falta de mantenimiento de la aplicación; o aplicamos los service packs, o reimplantamos que, además, en jornadas globales es menor. Pero es que no es solo la cuestión de los service packs.
S: ¿Entonces?
C: Es que, además, quieren desarrollos tipo “que al dar a un botón, te calcule el coste de materiales”
C: ¿Usas fungibles?
C: No
C: ¿Usas material externo?
C: No
C: ¿Van a CC?
C: No
C: Entonces, ¿para qué lo quieres?
C: Por curiosidad
C: VETE AL PEO
S: Creo que no estás comprendiendo el proceso de razonamiento que siguen normalmente los clientes
C: Lo comprendo, por eso necesito desarmarlo, las cartas a los Reyes son geniales. pero… hagamos las cosas con cabeza, por favor
S: No lo comprendes. Estás tratando de resolver un problema, lo siento pero aún te falta experiencia como consultor, los consultores no resuelven los problemas, sólo ayudan al cliente a que ELLOS lo resuelvan
C: Yo no les voy a dar la solución, sólo quiero darles unos consejos para solucionar la situación. Ellos, al final, deciden. Pero no se puede dejar que decidan sin darles aviso, porque luego me la como doblada yo
S: Por lo que me has contado, instalar service packs en primer lugar no es una opción viable, porque no es predecible. Arreglar los bugs con desarrollos propios sí es predecible (o al menos lo parece). La predictibilidad es más importante que el coste. Además, los service packs podrían arreglar algunos problemas sólo para crear otros nuevos y desconocidos
C: Es predecible si en vez de un unico entorno se puede tener acceso a dos o más, pero ni eso nos querían dar
S: Si no te dan dos o tres entornos habla con tu jefe y cesad el servicio. Da igual el dinero que creais perder. Si no teneis ni siquiera un entorno de test a la postre perdereis mucho más, sin factores higiénicos no se puede trabajar
C: Es que es más complejo porque, además, si meten service packs o si siguen así, el mes que viene se acaba el soporte técnico. Y, claro, sin soporte técnico a cliente, nosotros no tenemos tampoco. Así que lo ideal es hacer una reimplantación, pero no quieren MOLESTAR al usuario final
C: Pero al usuario me lo he metido yo en la manga, está encantado conmigo y mis soluciones de bala de plata para cualquier problema
S: Reimplantar es la mejor opción pero también la de mayor riesgo
C: No estoy de acuerdo, cubre de forma estándar el 95% de los requerimientos. Permite la limpieza de datos, la creación de la documentación que no ha sido creada, y la garantía de producto por 5 años.
S: ¿Qué coste tiene esa re-implantación? ¿La vais a hacer vosotros o la hará un partner? ¿Qué garantías tiene el cliente de que no será una mierda como la primera?
C: Supongo que la haremos nosotros. Y eso suele ser la garantía. Por eso nosotros hacemos sólo los proyectos especiales. Somos los “Boinas Verdes” del producto
S: Más bien pareceis un grupo de reanimación de urgencia del SAMUR
C: Es lo que, en el fondo, somos. Proyectos chungos, complicados, son los que nos comemos nosotros y aquéllos que el cliente quiere garantizado
S: Pero, según tu, este proyecto es un 95% es estándar y con un usuario amistoso ¿qué tiene eso de chungo?
C: He ahí mi función principal: que el usuario no es nada amistoso. Por eso me han enviado a mi, para que los calme y muestre que nosotros si tenemos conocimientos. Es que los del partner son unos cabrones. ¿Sabes lo que hicieron? El usuario quería una función de acceso remoto que, de forma estándar, existe pues la ocultaron y le dijeron que eso era un desarrollo costosísimo. FLIPA.
S: Típico con hipergate lo hacen mogollón, como es Software Libre le quitan los logotipos y se lo revenden al cliente como si se lo hubiesen hecho 100% a medida
C: Yo es la primera vez que lo veo, así que les hice un truco de magia sacando un interfaz HTTP de una chistera. Y ¡Ta-chán! ¿Cuándo lo queréis en producción?”
S: ¿Y tras cometer tal estupidez con una chistera pretendes que el cliente crea que reimplantar es la mejor opción? Si le das a entender que lo puedes hacer simplemente sacando el boli ¿cómo esperas que crea que necesita reimplantar? Ya se la han colocado doblada una vez, pensará que tu pretendes hacer lo mismo.
C: Eso es lo que necesito que se den cuenta, que nosotros SI somos transparentes. Que no ocultamos cosas, que si las necesitan y las tenemos, son suyas, las han pagado. Y que si yo digo que eso no está, es porque verdaderamente no está.
S: Vosotros no sois transparentes, sois una empresa de software ferozmente privativo, vendeis por dominio del cliente y de la competencia ¿deberas esperas que el cliente confíe en vosotros cuando a) tienes unos partners “cabronazos” y b) le estás amenazando con que si no se actualiza como a ti te conviene le quitas el soporte el mes próximo?
C: Yo no le amenazo, ni mucho menos. Ellos pagaron X años de soporte, y es lo que tienen, Sergio, yo no tengo culpa de las licencias. ¿dejarías de comprarte un BMW porque tú has pagado 2 años de garantía y no te dan 5?
S: Tu no tienes la culpa de las licencias, por supuesto, pero el pato lo paga él, de modo que desde su perspectiva el resultado neto es el mismo. La diferencia es que el coche lo puedo conducir sin garantía del fabricante, cualquiera me lo arregla, el software si pierdo la garantía del fabricante, ya no puedo usarlo, y este fabricante puede negarse a seguirme dando garantía incluso si yo le quiero segir pagando
C: No, en eso no concuerdo. Creo que ellos están conscientes y asumen que tienen, técnicamente, lo que compraron. De hecho, sus técnicos son partidarios de moverse hacia adelante en la dirección de nuestra siguiente versión. Ah, bueno, obviamente, si pagas el soporte, lo tienes, claro que sí. Si quieres seguir pagando el soporte, lo tendrás. Pero ellos no quieren pagar más el soporte. Y ellos pueden seguir usando la aplicación, es suya, pueden desarrollar sobre ella lo que quieran. Ahora bien, si no pagan el soporte, no lo tienen.
S: ¿Están conscientes y asumen que tienen técnicamente lo que compraron? ¿eran conscientes y asumían que no íbais a continuar dándoles soporte cuando os conviniese? ¿eran conscientes y asumían que ellos iban a tener que pagar el proyecto de instalación de los service pack (burdo eufemismo para parche) que soluciona vuestros errores? ¿eran conscientes y asumían que unos de vuestros partners le iba a timar? Compraron la “marca líder” y ahora están bien jodidos. Pero volviendo a la solución operativa al problema, yo no me obcecaría en intentar convencerles de que re-implanten
C: Sergio, nosotros no trabajamos así. En todo proyecto se les dice que han de tener una persona encargada del sistema. Nosotros no cobramos la instalación del service pack, cobramos las jornadas de las personas. Si ellos no tienen una persona encargada siquiera de dar los accesos al sistema, porque prefirieron dejarlos en manos externas, mal hecho. No es cuando nos convenga, es el plazo que ellos han pagado. ¿Acaso cualquier empresa garantiza gratuitamente sus productos de por vida? Lo de los partners, lo entiendo, y lo peor es que no es la primera pifia que veo de ellos, incluso mi jefe dice que la gente de relaciones estratégicas debería ponerse dura con estas cosas, y obligar a los partners a certificar gente y a contratar auditorías nuestras en los trabajos que realicen, pero yo en política comercial no quiero entrar. Y yo no intento ni obligar ni convencer a nadie, lo único que quiero es hacerles ver que escojan lo que escojan, tiene que ser claro, operativo y efectivo, ni más ni menos
S: ¡Juas! Esa si que es buena: no cobrais la instalación del service pack, pero sí las jornadas de la gente que lo instala ¿y cual es la diferencia? si le repercutís los costes de bug fixing al cliente, eso no es garantía, es hacer que pague él vuestros errores, y no se pretende que garantices los productos gratuitamente de por vida, se pretende que los garanticen pagando de por vida pero, claro, mantener versiones antiguas no es rentable es mucho más lucrativo obligar a todos los clientes a usar la misma versión y así reducir los costes de soporte cobrando el mismo fee anual
C: Pero que no son nuestros errores, joder, Sergio, que son errores de las personas encargadas de mantenimiento que, además, no éramos nosotros.
S: Los bugs si son vuestros errores, re-vender el producto a través de partners cabronazo si es vuestro error, y, además, vuestra férrea política de licencia está obstaculizando la resolución
C: No, ni mucho menos. Esos service packs están ahi. Si ellos tienen a alguien que se los instale, que lo haga.
S: Vale, y si llega alguien y aplica uno de los service packs ¿qué puede llegar a pasar?
C: El problema es que no tienen ni un solo administrador de sistema ¡no tienen siquiera personas que den accesos de usuario a la aplicación!
S: Estoy de acuerdo en que la falta de un administrador para el sistema es responsabilidad del cliente. Pero, ¿qué grado de fiabilidad tiene el combo del service pack con los desarrollos a medida del partner mierdero?
C: Hay registros de baja de hace 3 años ¡activos! Un administrador de sistemas digno de tal nombre sabe que se hace un compare, se salvan los proyectos, se aplican los service packs (en segundo entorno) se importan los proyectos y se mira el compare de nuevo. Yo creo que por nuestra parte, lo asumible es que no hay una política de calidad de proyecto de partners. Pero si el cliente no quiere pagar más soporte, ni contratar o formar a administradores de sistemas, o tener un entorno de testeo/desarrollo creo que nosotros ahí no podemos entrar.
S: Tienes razón en que una parte del problema es que el cliente lo quiere todo, pero sin gastar nada de dinero en ello. Pero volvamos a la resolución práctica del conflicto. Hablar de la política de las empresas no nos conducirá a ninguna conclusión útil
C: Sí, sí, y más sabiendo que a mí me paga la hipoteca uno de tus cocos personales o profesionales. Pues eso, que en esta amalgama yo me veo en la tesitura de cómo hacerles ver que las decisiones a tomar han de ser claras, con objetivos únicos, sencillas y fáciles de aprender, y con el menor coste posible
S: Insisto en que creo que aún no has aprendido de qué va el negocio de la consultoría, no estás ahí para solucionar un problema del producto o de la empresa, estás ahi, en primer lugar, para cubrirle el culo a jefecillo de turno del cliente que te paga, cuando empieces a poner los intereses de las personas en primer lugar en la lista de prioridades, empezarás a entenderte mejor con ellos
S: Olvídate para empezar de cualquier consideración de ídole práctica y céntrate en lo que preocupa a las personas que trabajan en el cliente
C: Pero si eso es la petición del jefecillo del cliente que me paga!! que al usuario le haga comprender que pedir peras al manzano mola, pero es caro…
S: El usuario no tiene que comprender nada, el usuario tiene que usar y callar ¿qué coño sabe el usuario de software? es que este problema yo ya lo he visto un montón de veces, con clientes que, en el fondo, no saben lo que quieren y ni siquiera entienden bien cómo funciona su propio negocio, en grandes cuentas pasa mucho
C: Pero si eso es lo que hago.. solo que ellos en vez de decirme “Quiero conocer lo que me cuesta un curso” me dicen “quiero un botón verde, en esta pagina, que me diga X e Y y me tire de la parte Z para ver lo que me cuesta un curso… Necesito decirles que podrán ver el coste del curso, pero que simplifiquen el cómo
S: El mito de que hay que escuchar a los clientes es peligroso, a algunos clientes lo mejor es no hacerles caso en absoluto, porque sólo enredan y la lían cada vez que opinan. Bien, vayamos a lo práctico. Yo les diría, en primer lugar, que cualquier nueva funcionalidad, por pequeña o grande, nimia o importante que sea, debe esperar a que primero se arreglen todos los bugs, eso será lo que menos “moleste” al usuario. Creo que es fácil entender que los errores son más prioritarios que las mejoras. Tener en la base de datos un registro muerto hace 3 años es más importante que cualquier botón que calcule cualquier giliflautez. Hasta un chimpancé podría entender eso.
C: A ver, priorizado está: Bugs técnicos y de funcionalidades, limpiezas de datos, funcionalidad a implantar, desarrollos no críticos (críticos no hay, porque si lo fueran, no habrían podido trabajar estos años) Pero yo necesito que comprendan la necesidad de simplificar las mejoras antes de ponernos a abordarlo
S: Plantéate proponer el uso de alguna metodología de “desarrollo ágil”, primero haz una lista priorizada de nuevas funcionalidades, luego marca un hito de fecha fija cada 15 días en viernes alternos, para cada dos semanas mete la/s funcionalidades de la lista que quepan en esos 10 días laborables, dile al cliente que podrá pedir todas las funcionalidades que quiera a proyecto abierto siempre y cuando siga pagando, haz un cierre y estabiliza cada uno de esos viernes. No te saltes ningún cierre o acumularás deuda técnica
C: Sergio, yo no soy jefe de proyecto, ni decido fechas y/o hitos
S: Si el marrón te lo comes tu, pero no tienes atribuciones para decidir nada, entonces estás jodida
C: por eso necesito que el usuario confie en mi y esté de mi parte viendo la posibilidad de hacer fáciles las cosas que a priori plantean como difíciles, para poder coger el control de la situación
S: Eso se llama fé en los milagros. De ilusión también se vive. Tu jefe de proyecto ¿a qué se dedica? ¿qué metodología emplea?
C: Es que si esto no lo cojo yo con el apoyo de los clientes, estoy más jodida aun, porque el gerente del proyecto es un empanado metemenbroncas que no hace su trabajo. Y no quiero estar en la semana cero de proyecto haciendo ya la técnica de la cacerolada
S: Las caceroladas no son buenas. Desde que se inventó lo de la inteligencia emocional, a cualquiera que tiene tanta razón y está tan solo que lo acaba diciendo a gritos, lo botan. Mejor dále a tu jefe el proyecto masticado en papilla como te he dicho: hitos de duración fija dos semanas, sincronizar y estabilizar para subir a producción cada 15 días, funcionalidades cortas que se puedan implementar en 10 días, o si es algo más complicado cláramente dividido en trocitos de 10 días.
C: Eso no lo había pensado; cacerolada + papilla
S: si no vas a buscar los problemas, ellos vendrán a buscarte a ti, estás sentada encima de una bomba de mierda, si no apagas la mecha, cuando explote te salpicará el marrón. Si tu jefe no hace su trabajo ¡despídele!
C: Es la vida de un consultor con bemoles…
S: Haz tu propia planificación y pasa de él. Imagínate que eres el capitán de un buque de la armada y te dan órdenes peligrosamente suicidas y te haces pirata para sobrevivir.
C: Pero eso es demasiado arriesgado, si me estrello…
S: Mucho más arriesgado es seguir sentado encima de la bomba de mierda. Obviamente no vayas a ponerle la bandera negra con la calavera al barco, se trata de que sigas navegando bajo bandera de la armada pero que gobiernes la nave como te venga en gana. En medio del mar es muy difícil saber dónde estás o qué estás haciendo, corporativismo ante todo, los mejores piratas eran corporativistas, como Nelson.
C: Sigo pensando en la necesidad de aliados
S: No es una guerra, con bandos aliados, es una acción pirata encubierta. Lo principal es centrarse en las escaramuzas y evitar al máximo los enfrentamientos directos con la flota enemiga. Al usuario ya lo tienes en el bote según me has contado, los programadores aplaudirán conocer el hecho de que se está poniendo órden en la planificación y gobernanza de los hitos, si no te desvías demasiado de plazos y presupuesto, nadie dirá nada, y podrás continuar a tu puta bola con tal de que sigas trayendo botín de guerra.
C: Bueno, me pondré el parche y ya te iré contando…
S: Buena suerte . Tengo que dejarte ahora, es viernes y tengo que terminar para el lunes una cosa que el cliente me pidió esta mañana, ya sabes cómo va esto…
C: Adiós

P.D. Por cierto, para otra conversación surrealista, esta de Ángel Medinilla en Presión Blogosférica o este otro compendio de técnicas para volver loco a un colaborador de Raúl Hernández González

Comentarios
Acerca - Contacto - Información legal y técnica - Condiciones de uso - Noticias sobre el mundo del Desarrollo de Software.