"...es la repetición sistemática de un hecho falso, adjudicándole la categoría de indiscutible para impedirnos reflexionar sobre su contenido. De estas repeticiones supuestamente indiscutibles, resultan beneficiadas las clases dominantes, no haciendo posible que logremos advertir ese perjuicio propio e intentar acciones para revertirlo..."
La industria de software, a su manera, está repleta entonces de estas zonceras. De hechos que todos repetimos, o con los cuales convivimos sin cuestionar, y que bajo un análisis crítico u objetivo (si se quiere ser optimista en cuanto al objetivismo, caso contrario léase como "en otro contexto más general"), no cierran ni un poquito.
Veamos una lista de estas zonceras de la mano de un PM/manager:
- Desarrollo distribuído: para abaratar costos podemos construir un sistema/producto con 2 personas en India, 3 en EE.UU., 5 en Argentina y 1 en China. Y de hecho, estamos siendo eficientes. Porque podríamos armar una rueda de trabajo continua con diferentes zonas horarias. El obrero que se va a las 18hs de Argentina, es reemplazado por el de China que llega fresco para retomar lo pendiente.
- Los managers/gerentes no necesitan ser técnicos: el manager o gerente, como uno, no necesita saber/entender qué es lo que hacen los miembros de su equipo, léase, en qué lenguaje programan, con qué criterios de calidad, etc.
- Los managers no necesitan ser técnicos, sin embargo podrán opinar y tomar decisiones sobre lo técnico: Por supuesto que el no entender no quiere decir que no podamos opinar. Porque nuestra opinión (de los managers) es la que realmente vale. Es la que hace a la diferencia. Es la que realmente hace mover las ruedas de la compañía. Porque todos sabemos que los desarrolladores son vagos, y si fuera por ellos nunca se tomaría ninguna decisión.
- Se puede aplicar scrum sin cambiar la forma de vender software: o sea, scrum es una boludez, un jueguito con papelitos y reuniones estúpidas que quieren utilizar los desarrolladores, porque son vagos, y porque, como sabemos, les gusta jugar, y hacer de la vidad un juego, para evitar los compromisos, las urgencias y las responsabilidades de la gente grande. En realidad nosotros (los managers) sabemos que el vendedor consigue la venta, como siempre lo hizo, haciendo lo que haga falta para conseguirla, y prometiendo lo que haga falta. ¿El producto no lo soporta? No importa, ya veremos. ¿El cliente no sabe lo que quiere? No importa, ya veremos. El producto todavía no existe y se lo estamos contando como que es lo más maduro del mercado? Ya veremos. Total después pasa a ser problema del equipo de desarrollo. Y sí, usen scrum pibes, usen lo que quieran.
- OpenSource+Libre = Malo/Feo/Caca, Herramientas Privativas = Bueno: el producto es siempre demasiado crítico e importante como para depender de una serie de hippies y locos que, quién sabe, quizás de un día para el otro dejan de agregar bugs, o hasta se les ocurre incluir vulnerabilidades a las librerías. En cambio es mucho más "coherente" pagarle un dineral a una empresa privada, por un producto de increiblemente inferior calidad y con aún peor soporte que el de los hippies, claro.
- El cliente siempre tiene la razón: Como los managers, no importa si no es técnico, o ni siquiera sabe qué funcionalidad quiere, lo que importa es lo que quiere, y que lo quiere YA !
- Si se quiera arreglar un problema, hay que hacer una reunión: aparece un problema urgente y pum, inmediátamente hay que hacer una reunión si se lo quiere solucionar. Y así sacar teorías apresuradas, sin previo análisis de hechos, causas, etc. Acá es importantísimo incluir a esos managers que no hace falta que sean técnicos, para que nos ilustren con sus locas teorías, o bien a los que "vienen del palo técnico", que nos enriquescan con esas anécdotas tan útiles de COBOL o assembler.
- Si se quiere ser "eficiente" a la hora de resolver un problema, hay que hacer una reunión, e involucrar a tantas personas como sea necesario (Task Force): y sí, los programadores son vagos, ya lo decía Taylor y Ford. Si aparece un problema, los tipos no se involucran. Nadie se va a hacer cargo, nadie va a mover un dedo. En cambio bien que se la pasan tomando caffé y charlando de series y jueguitos. En fín, entonces, para encarrillar a todos estos proletarios que esquivan al trabajo, y para, de hecho, garantizar que ante un problema URGENTE, se responde de manera URGENTE y "eficiente", es decir sin perder tiempo ni dinero (ejem), lo mejor es armar un grupo especial, llamado "task force" y encerrarlos a todos en una sala con mucho caffé (acá sí está bien el caffé porque queremos hacerlos laburar sin parar).
- Estimaciones rápidas y bien por arriba: Otra característica del programador/QA, en general el ingeniero de software, es que le esquiva a las estimaciones. Nuevamente, porque, como dijimos, es "vago". Entonces no se quiere poner a estimar esa idea, esa ideiiita que le tiramos, que nos dijo el cliente un día mientras almorzábamos, entre copas. O bien que la anotó en una servilleta, con dibujito y todo. Siempre intentará excusarse con que no los requerimientos no están claros, con que son ambiguos. Con que falta nivel de detalle, y que pequeñas alteraciones en las definiciones podrían significar desvíos del 400%, 1000% de la estimación. Ante esos casos, hay que meterles más presión, pedirles un número, y aclararles que no se les está pidiendo una "promesa", que nadie luego les va a recriminar si se desvía o no. Obviamente que sí, haremos eso, llegado el momento, pero a no avivarlos !
Quizás lo haga en otro post a futuro.
Saludos
