Llevo los últimos diez días que parece que vivo el día de la marmota de Bill Murray . Aunque debería decir que más de diez días han sido los últimos tres años con algunos días de pausa. Y es que parece imposible evitar el tema de la situación de la profesión cada vez que tres informáticos están juntos. Quejas y más quejas, anécdotas de compañeros que ahora instalan máquinas de aire acondicionado, fabrican aluminio o incluso plantan lechugas.
Hay para todos los gustos, sólo hay que detenerse a escuchar, pero la quemazón es general en todos aquellos que viven en el sector de la consultoría informática. Y no es que yo tenga la solución, ni mucho menos, pero me voy a permitir dejar aquí mis impresiones.
<disclaimer>Ni mucho menos mi intención es crear un flame, simplemente exponer un punto de vista, el mio. Se debe tener en cuenta también que esto se trata de una generalización, no es aplicable ni a todas las empresas, ni a todos los clientes, ni a todos los trabajadores.El texto puede resultar extremadamente largo, pero es un tema complejo. Sorry.</disclaimer>
Tal y como yo lo veo el mercado esta viciado por las tres partes que lo componen: clientes, empresas consultoras y profesionales. Es curioso, pero aunque una de las partes es claramente la menos perjudicada, parece que las tres partes están “contentas” con el status quo actual, o al menos no hacen demasiado por cambiarlo, nada más allá que una declaración de intenciones.
- Los clientes. Es curioso, pero parece que para pocos de ellos (en especial los grandes clientes) es poco importante la calidad, o incluso cumplir lo pactado porque tropiezan con la misma piedra una y otra vez. Aunque parezca que sí, no les importa demasiado los plazos, la calidad o la idoneidad de la solución, al menos no les importa demasiado en relación al precio. Entiendo que en el pasado se les hicieron auténticas perrerías y pagaron a precio de oro autenticas tonterías y se quieren tomar la revancha, pero si a mi me dieran un coche (por decir algo) con una millonésima parte de los errores, el doble de caro y después del doble de tiempo me mosquearía más de lo que parecen hacerlo ellos.
- Las empresas. Como las empresas aprientan hacia abajo, parece que no les importa que les aprieten de arriba y así siguen batiendo records de resultados, por eso digo que son menos perjudicados. Pero no se dan cuenta que si hicieran las cosas bien, a tiempo, etc. seguramente ganarían más. Les preocupa también la rotación, pero a menudo no hacen nada por mantener al personal contento. Se quejan de como aprientan los clientes, pero parecen no darse cuenta de que no se puede aceptar cualquier cosa a cualquier precio por conseguir un proyecto/contrato. Así nos va, por no saber decir no cuando es no. Total, siempre se pueden congelar los sueldos durante 5 años aunque tus beneficios (gracias a tus empleados) aumenten año tras año.
- Los trabajadores. Los empleados, los pobres empleados. Pobrecitos, explotados, mal pagados. Seguramente, sin duda el eslabón más debil. Pero a veces me pregunto si merecemos otra cosa. Por una parte, ni entre nosotros nos respetamos, y cuando uno sube medio peldaño se encarga a menudo de machacar al que no lo ha hecho. Si pasamos de técnico a gestor, perdemos el respeto por la técnica, o si nos maltratan en el trabajo, simplemente le echamos la culpa a la hipoteca como razón para seguir en ello. Total, ¿para qué vamos a pensar que podemos cambiar algo? (y no, no me refiero a los colegios, no creo que sean una solución a nada. No flame, por favor, reservalo para otro hilo).
¿Cuando cambiará esto?. Pues es difícil. Hace unos días hablaba con alguién optimista al respecto, pero yo no estoy tan seguro. Creo que cada una de las partes implicadas puede hacer algo por mejorar su situación, pero eso no provocará un cambio en el conjunto. Los clientes pueden hacer uso de las claúsulas de penalización y gastar menos (por un software igual de malo, o mucho más tarde), las empresas pueden pagar algo más a los empleados (pero eso sigue sin asegurar que estén más contentos) o los trabajadores pueden ponerse por libre o hacer ebanistas (pero ni lo primero es fácil ni lo segundo no deja de ser una huída), por poner algo. Parches hay muchos (recordad que hablamos del negocio de las consultoras, el que más personal mueve).
Entonces, ¿no tiene solución?. Tampoco es eso. El factor clave para el cambio de la situación, bajo mi punto de vista, es el cliente, él es quién provocará que esto cambie. Este cambio sucederá cuando las malas decisiones repercutan sobre el que las toma, y el primero que toma una decisión en esta cadena es el cliente. Permitidme que me explique.
Ahora mismo un cliente puede contratar un proyecto a una empresa. Este proyecto normalmente está mal planificado, mal dimensionado, no se han pensado demasiado la mayoría de las decisiones y acaba tarde, por más dinero, y con el personal quemado. El cliente pocas veces hace uso de las claúsulas de penalización ya que se llega a algún acuerdo para compensarlo todo en el siguiente proyecto. Con esto conseguimos que el próximo proyecto ya esté hipotecado antes de empezar, ya que el cliente sigue con un mal proveedor, parte de los ingresos de ese proyecto se dediquen a tapar los del anterior, y la bola crece. Consecuencia: nadie paga por ello.
Quiero decir, la persona por parte del cliente que ha hecho la contratación normalmente no sufre castigo alguno (salvo en el caso de ser el empresario final, aunque generalmente repercute a sus propios clientes el fiasco) por la mala elección, los cambios de criterio o por no disponer del tiempo que el proyecto le requiere. Tampoco la empresa contratada sufre un gran castigo por no cumplir, ni mucho menos el jefe de proyecto que ha cometido los errores en la planificación o al gestionar todo tipo de recursos, o el arquitecto que optó por una solución, el analista que no entiende al cliente ni el programador que no sabe como hacer pruebas o usar un sistemas de control de versiones.
Para que todo esto cambie tendremos que pagar todos los que formamos parte de esta rueda por nuestros errores, empezando por el cliente (de ahí la importancia que yo le daba). Si un mal resultado le afecta a él de alguna manera, tendrá bastante más interés en que acabe bien, y por tanto en contratar a quién mejor trabaje. En esa situación la empresa contratada se preocupará por hacer un buen trabajo, para ello teniendo a los mejores profesionales y manteniéndoles contentos. Los profesionales se preocuparán también de hacer un buen trabajo, porque de lo contrario acabarían fuera. Esto obviamente tiene un coste para todos, pero que también beneficia a todos (los empleados cobran más, las empresas cobran más, el cliente cobra más a sus propios clientes, que a su vez son los empleados). Incluso las empresas de seguros saldrán ganando porque veremos como cunde el ejemplo de Garbajosa y el Eurobasket.
¿Es esto una utopía?. Puede ser, pero desde mi punto de vista es la unica forma de que esto mejore de forma general. Tampoco estoy proponiendo nada que no tenga sentido, esto ha sucedido en todas las industrias: clientes exigentes provocan empresas competitivas. Ya que he hablado de coches… ¿que escogerías ser, General Motors o Toyota?.
Seamos optimistas y pensemos que las cosas tienden siempre a mejorar…
Así, si la situación actual es de una forma concreta:
- O es porque ha llegado al óptimo (lo mejor para todos).
- O será porque está de camino.
Me inclino por lo segundo. Aunque, como para muchas otras cosas en el mundo, el cambio es lento, e incluso pueden darse oscilaciones entorno al punto de equilibrio.
Felicidades por tu reflexión y a empujar que la inercia es grande.
Estoy totalmente de acuerdo en tu planteamiento.
Yo hace poco, 3 meses cambié de trabajo. Estoy en una empresa que trabaja directamente con los bancos realizando su software interno. Tenía la esperanza que eso sería otro mundo, lleno de buenos profesionales, buenos procedimientos de trabajo, productos de calidad (el software es para un banco!). Pero en cambio me he encontrado todo lo contrario, mucha rotación de trabajadores, productos realmente mal programados, los bancos están enfadados con ellos ya que notan que se columpian, a la empresa le da igual todo, ni sube sueldos para retener buenos profesionales, ni se preocupa por la calidad de lo que se le ofrece, lo más importante es imputarle horas al banco y todo lo demás es segundario.
Me choca un poco porque para mi lo menos importante es imputar horas sino intentar que el blanco esté realmente contento… que creo que es lo único que será positivo para todos.
Y aquí como tu dices quien tiene la sartén por el mango es el cliente exigiendo. Sobretodo exigiendo calidad. Pero yo me pregunto como una empresa puede pensar únicamente en obtener beneficios en lugar de promover la calidad… como dices, mayor calidad provocará obtener mejor resultados.
Una vez, un ex-compañero me comentó “¿Para qué hacer algo de nota 10 si con un 5 ya te pagan igual?”
Es triste, pero esta es la filosofia de muchas de las empresas que se dedican a esto, y de los trabajadores…
Yo creo que el problema de muchos clientes es que no saben que hay alternativas de calidad paralelas y muchos siguen el principio de “burro grande, ande o no ande” a la hora de escoger una empresa de desarrollo: en muchos casos eso les conduce a “carniceras” que buscan el beneficio a corto plazo dejando a un lado la calidad del producto y la satisfacción de los implicados.
A mí me parece fundamental que los profesionales cuiden -cuidemos- la calidad del trabajo porque de esa forma podemos ofrecer una alternativa a los clientes quienes, de otro modo, pensarán que “la informática es así”, y que la chapuza, los retrasos y el consecuente mal rollo son elementos intrínsecos a este nuestro sector.
Si un cliente que se la ha pegado un par de veces encuentra alguien que le entrega un producto cuidado y de calidad veo difícil que deje de trabajar con este último, pese a que el coste o el plazo sea algo mayor: a estas alturas sabrá que las malas experiencias anteriores le han supuesto costes ocultos y problemas con los que no contaba. Es decir: sabrá que la calidad y el trabajo bien hecho son rentables. Ese es el cliente que queremos los que disfrutamos con este trabajo :)
También me parece que importante el tamaño y la organización de los equipos destinados a cada proyecto: a veces la responsabilidad de un proyecto se diluye en un amalgama de personas implicadas sin que quede claro quién se ocupa de qué. Todo eso facilita que:
a) la gente no vea claras sus responsabilidades y se desmotive: es fácil que entre unos y otros, dejen la casa sin barrer. No hay malicia, pero el proyecto se resiente y puede fallar.
b) sea difícil establecer por qué está fallando el proyecto. Durante el desarrollo esto suele generar reuniones de “qué está pasando” que pueden terminar con los asistentes lanzando y esquivando acusaciones.
c) tras un par de esas reuniones el mal rollo puede convertir el proyecto en un marrón del que todos quieren librarse cuanto antes. ¿Qué proyecto sale bien en esas circunstancias?
Tambián hay algo a tener en cuenta en la relación cliente proveedor que aparece bastante mas de lo que nos gustaría y es el amigismo,muchas veces el proyecto se lo lleva un proveedor determinado por ser amigo de tal o cual no por la calidad y tambien influye en que lo haga lo mal que lo haga a no ser que sea estrepitosamente mal, no pasa nada luego se arregla con una buena comilona entre amigos y ya está.
Saludos
Cuánto tiempo Albero!!
Me ha hecho gracia lo del día de la marmota, porque mi grupo hace un tiempo todos los días por la mañana poníamos la banda sonora del día de la marmota (la marcha de Philadelpia creo que era) en honor a la peli y por similitud a nuestro proyecto.
Estoy bastante de acuerdo contigo en todo. Sólo hay un tema que creo que todavía enrarece más el sector. Son las empresas cárnicas. Cada vez es más difícil escapar a estos intermediarios del trabajo. Es un incremento de coste con pocos beneficios a cambio, y yo cada vez estoy más convencido de que viven gracias al amigismo (que comenta DaniG) y el “unte al personal”.
Saludos.
Hola. La verdad es que el tema del amiguismo, o el tema de las cárnicas no lo he querido tratar por diversas razones (empeoran la situación, pero esta sigue siendo la misma), de modo que la solución seguiría siendo la misma: que cada cual “pague” por sus errores. Eso provocará que el amiguismo se reduzca e imperen otros factores, lo mismo que las cárnicas tenderán a desaparecer (o reducirse su nivel) o reconvertirse en algo más serio porque las “grandes” verán la necesidad de tratar mejor a los miembros del proyecto.
Saludos a los viejos amigos, que son varios en este hilo.
Yo tengo otro punto de vista, distinto pero igual. Creo que la clave está en la calidad del software que se produce. La calidad de este software es la que nos llevaría a rechazar un producto y aceptar otro, y hoy en día en la mayoria de los clientes se evalúa introduciendo campos y púlsando botones o enlaces, lo que nos lleva a una evaluación deficiente, todo ello con la complicidad del equipo que ha realizado el software, que debería de ser consciente de las deficiencias de ese soft (si no es asi, peor todavía).
Todo esto unido al hecho de que los técnicos que deberian evaluar esta calidad estan totalmente minusvalorados, ya que en cuanto se puede se olvida la faceta técnica ya que es para “programadores”, en favor de la faceta comercial. Personalmente lo veo todo muy malito, porque establecerse al margen de esta dinámica me parece complicado, y mejorar las cosas dentro de ella casi imposible, aparte de tener esa sensación de “no sé todo lo necesario para desarrollar mi trabajo y parece que nunca lo sabré”, que creo que es la que potencia las deserciones para reconvertirse en plantadores de lechugas.
Pues yo no creo que el cliente sea el que vaya a cambiar esto, el propio sector debe de hacerlo. Para empezar deberían de crearse una normativa que garantice una calidad mínima. Todas las ingenierias tienen sus normativas que cumplir (densidad del hormigon para construir puentes, temperatura de cocción de secado de barniz en madera para esteriores, así millones de ejemplos) Porque no en la informática?
Como dice “otroAitor” el cliente válida la aplicación pulsando dos botones y haciendo cuatro clicks, espero que los puentes que cruzo no los validen así.
Enrique… no sé si es tu intención, pero me parece que en el último párrafo me estas dando la razón. Parte del problema es que los clientes “validan cuanlquier cosa” (no tomar al pie de la letra, incluyen muchas más cosas), luego tiene que partir de ellos.
Sobre la calidad que comentas… me parece que también me das la razón, y que quién tiene que exigir la calidad sigue siendo el cliente, no nosotros, porque nuestro concepto es distinto (incluso nuestro entendimiento del proyecto es distinto!). Y “ellos” lo saben, pero la forma de abordar el problema ha sido “lamentable”. Consideremos ITIL o Métrica 3, impuesto por dos organismos públicos y convertido, en parte, en estándar de facto a distintos niveles. Lo que controlan es procedimiento, porque no se puede hacer “demasiado más”, pero te diría que incluso eso lo hacen mal, porque al final ni fuerzan que se entregue lo que se debería entregar, ni siquiera miran lo que se entrega si “a peso” da el pego (perdón de nuevo por la generalización).
Sobre la minusvaloración de los técnicos, bueno, es lo que comentaba de los trabajadores, releer el punto. Somos los técnicos al dejar de serlo los primeros que dejamos de valorarnos. Eso me da que pensar. Para otro post, porque me da mucho que pensar.
Estoy de acuerdo con los últimos comentarios, sobre todo con el de Enrique,debería haber una normativa de calidad sobre el software que se produce, el problema viene cuando una empresa adapta una metodología, por ejemplo la del CMMI, en la cual aparte de toneladas de documentación, que desde mi punto de vista son innecesarias, se somete el código a una auditoría interna (se supone que debería medir una calidad de software) y aquí está el problema, la auditoría es interna y por lo tanto yo hasta el momento no he visto a nadie que la haga … Eso sí, luego las empresas venden que aplican tal o cual metodología.
Otro problema, que yo por lo que he visto está bastante extendido, es la reutilización de código de proyectos anteriores y que es de muy muy dudosa calidad, pero la historia ocurre así:
-Gerente/Comercial, etc.: “Chicos hemos vendido XXX a YYY, jefe de proyecto haz una estimación”.
-Jefe de proyecto: “Pues contando con tal y tal unos 4 meses”.
-Gerente/Comercial, etc: “El plazo no es aceptable, tiene que estar en 2 meses y no se hable más”.
Y por este tema, no creo que muchas veces la culpa sea de los programadores, analistas, jefes de proyecto, sino que en bastantes ocasiones te encargan algo que ya está vendido y cerrado el plazo sin tan siquiera consultar. Si otra empresa dice 3 meses la tuya dice 2 y así las estimaciones, en estos casos, sirven para lo que sirven, para cumplir la metodología, porque no tienen nada que ver con la realidad :)
No sé, me parece que la idea del post se ha debido perder en algún momento. Fallo mio, sin duda. Quería plantear la situación (quemazón general), la complicación (nadie paga por los errores) y la solución (que paguemos por ellos), pero no lo he debido hacer bien.
Tengo la suerte (aún no sé si buena o mala) de haber podido vivir todas las partes de este ciclo en mis propias carnes, y tengo claro (yo, Alberto Molpeceres, opinión personal) que esto es algo de lo que todos somos culpables. TODOS. De principio a fin.
Mi planteamiento era bastante sencillo. No pretendía listar todos los errores posibles, ni mucho menos (de sobra sé que existe el amiguismo, que hay una guerra de precios que no beneficia a casi nadie, que hay programadores y metodologías buenos, malos y regulares, que hay clientes que no saben lo que quieren y que hay jefes de proyecto “a ojo”), pero mientras que nadie pague por esos errores, nadie tiene la necesidad de corregirlos (por ejemplo, mientras nadie penalice el mal software, que necesidad de auditorías de calidad hay?).
Espero haberme explicado mejor.
PS: sobre el ejemplo de la calidad del hormigón o el asfalto… el problema es que por lo general tampoco se cumple (tienen niveles de subcontratación que “absorven” calidad en cada margen que se quedan). Simplemente que los obreros de esas áreas tienen otras formas de presión y son menjos llorones que nosotros
@Enrique Rodriguez … es curioso que cites el tema de los puentes, pues incluso con las capacidades de calculo de estructuras existentes hoy en día, los ingenieros siguen pulsando botones como prueba final (esto es cargando el puente con camiones para simular cargas reales en el mismo). Y por otra parte… ¿en que momento el testar la aplicación por parte del cliente se convirtió en algo insuficiente en si mismo para él?.
Cuando alguien compra software, de la misma manera que cuando compra manzanas, el único responsable de la calidad final presentada en el mismo son, a nivel práctico, aquellos que intervienen en su producción y, a nivel legal, aquellos que lo comercializan. Sin embargo, eso no quiere decir que en el proceso global de compra no aparezcan otras responsabilidades, e incluso que la picaresca se haya también instalado (¡como no en este país!) en el sector tecnológico, que cada perro se lama su pijo y que todos echen la culpa a los demás.
Es en este ultimo sentido en el que en Linking Paths tenemos quorum total: todos y cada uno de los miembros de esa cadena productiva tiene un porcentaje de responsabilidad sobre el resultado final. Por otra parte no podemos ser demagógicos al valorar conceptos como la estandarización en el desarrollo de software, pues como todos los que trabajamos en esta industria sabemos, para lo bueno y para lo malo, desarrollar una aplicación no es como levantar una casa, sino más bien como construir un jardín y con los infinitos caminos y posibilidades con los que contamos establecer unos estándares mínimos sobre como se debe desarrollar no va a ser tarea baladí.
De hecho para establecer esos estándares deberíamos primero ponernos de acuerdo en un conjunto de buenas prácticas universalmente aceptadas -algo que en el mundo físico y real del resto de ingenierías es mucho más sencillo- para un medio que todavía estamos empezando a conocer. Hasta ahora se ha atacado, como dice alberto, la procedimentación y así nos luce el pelo… la verdadera madre del cordero es mucho más peliaguda. Sin embargo lo triste es que en nuestro sector en vez de aprovecharnos de la flexibilidad de nuestra disciplina, nos escudemos en ella para echarle la culpa al prójimo e intentar seguir engañando y estafando a todas las partes implicadas.
Cooorrecto. En ningún caso quería esconder la responsabilidad de los informáticos/elementos de la cadena productiva, sino todo lo contrario.
Solo quería decir que en otras ingenierías hay unas leyes que cumplir, y en la nuestra yo al menos no conozco ninguna.
Me encanta me ejemplo del puente y sigo con el ;-) Cuando tras construir un puente ponen camiones para comprobar la carga, es tan solo el paso final, muy similar al que podemos hacer nosotros con pruebas de estrés, pero antes de esa prueba, existen muchos controles, auditorias, peritos enviados por el ministerio de fomento, controles de calidad, etc. También existe una responsabilidad legal por parte del ingeniero ( alguno esta en la carcel por no hacer sus deberes) y yo me pregunto… instituciones penitenciarias debe empezar a recolectar informáticos??
Evidentemente esto es cosa de todos pero alguien debe regularlo y yo entiendo que debería ser el ministerio de ciencia y tecnología junto con empresas, sindicatos y colegios profesionales como en resto de profesiones, no??
No sé, bajo mi punto de vista, Enrique, todo depende de la criticidad de lo que se haga. Siguiendo con los símiles de la construcción.
Yo espero que un sistemas para gestionar un avión se haga más como un puente, con cierta seriedad (a pesar de los camiones), pero me temo que la mayoría del software se hace como una carretera, dónde cada paso (intermediario) rebaja la calidad para ahorrar costes (y aumentar/mantener beneficio), por mucho que haya memorias de calidades, controles (ejem), y muchas otras cosas, porque no se controla su cumplimiento (ni se penaliza su incumplimiento). Vamos, que tampoco creo que la cosa sea muy distinta (salvo en el caso de la presión de los obreros en muchas ocasiones).
De los colegios estoy en contra, porque no me parece que aporten nada, de los sindicatos me puede gustar la idea, pero la “implementación” es un desastre, y bueno, el ministerio de ciencia y tecnología… no sé porque se tiene que meter en una transacción privada (puede dictar sus propias normas de contratación, como lo hace con metrica3). Quién tiene que participar ya participa (ministerio de trabajo), aunque no haga nada más que dictar unas leyes que no se siguen. Resumen, no se trata de regular por regular, porque se ha demostrado que si no se controla, no sirve de nada esa regulación (otro ejemplo: seguridad en el trabajo).
Dejando de lado la definición (ultra difícil y dependiente del contexto) de lo que se podría considerar “calidad aceptable”. La acepción general más aceptable sería en base a entregables (es decir, procedimiento, es decir, lo que ya hace metrica3/ITIL/…), pero eso ya hemos quedado que no garantiza nada, porque es lo que ya tenemos.
Así que vuelvo a empezar, no es una cuestión de procedimiento, es una cuestión de impunidad.
Me queda claro tu punto de vista, pero deberíamos de profundizar en teorias y/o ideas de como superar la situación de actual en vez de seguir quejandonos del tema.
Es que yo no me quejo. He expuesto la situación, y cada cual puede intentar solventar su parte (como individuo o como grupo) como pueda (sindicarse, colegiarse, ponerse como autónomo, irse a plantar lechugas, establecer procedimientos, no subcontratar, etc). Pero eso seguirá sin ser una solución al problema en su conjunto.
Mi “solución” es la ya expuesta, el día que el cliente empiece a tirar d ela cadena de la “calidad”, entonces se moverá la cosa (y ahí se podrá procedimentar, colegiar, sindicar, etc.), pero hasta entonces…
Hola Alberto:
Comparto totalmente tu “solución”, pero le veo una “pega”. ¿Sabe el cliente lo que es la calidad o que algo está hecho con mejor calidad?
Supongo que en determinados proyectos/productos es sencillo comprobarlo, pero en otros no.
Un saludo
Manuel, lo que he comentado es que el termino “calidad” depende del contexto, pero me parece que tienes una visión demasiado técnica de lo que significa calidad. Yo no sé nada de coches, pero sin embargo si tengo un concepto de cuando nu coche tiene la “calidad” que necesito.
Para un cliente la calidad de un proyecto (de un proyecto!, no de un software) será el número de fallos que tenga, plazos de entrega, desviaciones de precio, adecuación a sus necesidades en cuanto a funcionalidad o rendimiento, etc. Las empresas se tendrán que encargar de darles eso, y ahí es dónde empezará el tema técnico, pero al cliente lo más normal es que se le traiga al fresco “como se lo hagan” (siempre que se adecue a lo que tienen en lo posible).
Llego un poco tarde, pero no me puedo resistir a comentar el simil de la construcción, probando puentes con camiones. Eso sería facil si el software tuviera un solo formulario, con un botón, le pegas y listo. Pero es que tienen n formularios, dependiendo de su complejidad. Es como si el puente tuviera miles de bifurcaciones en las que colocar camiones para ver si aguanta, y algunas fueran invisibles, solos las ve el que lo ha hecho, y además los vehiculos casi nunca circulan por esa parte del puente. Eso si, si pasan el puente se cae.
Por otro lado, completamente de acuerdo con el tema de la responsabilidad de los técnicos en este problema, todos queremos ganar tela, sin aprender nada nuevo si es que alguna vez supimos algo, y no tener responsabilidades. Disfrutar de las cosas bien hechas no es una prioridad claramente. Asi que la solución es muchas veces la deserción (conste que no la descarto).
[Las empresas… les preocupa también la rotación…]
La AEC y algunos cargos del sector ya han dado la voz de alarma:
- la importación de licenciados cualificados es un hecho a corto plazo;
- una guerra por captar recursos humanos de la competencia no es una solución sino prolongar un problema endémico, y
- el talento que cada compañías tenga debe valorarse adecuadamente y ponerse en marcha medidas de retención: conciliación vida familiar y laboral, mejora del clima y las condiciones laborales que evite la fuga.
Los bancos de negocios se están convirtiendo es el destino natural para los consultores que se sienten atraídos por su imagen de marca.
Creo que en todos estos argumentos no se incide mucho en un factor que yo veo clave. Entiendo que el cliente es la pieza que empezará a solventar el asunto, es una posibilidad. Pero es que en realidad creo que fue el cliente una de las piezas clave que empezó a estropearlo.
Para mi es cotidiano que me pidan cosas con los plazos cerrados. “Se ha aprobado el proyecto X, tiene que estar para Enero” (Esto es de esta semana, os lo juro). O “lo necesitamos para la próxima producción” (es significa el mes que viene), etc.
Cuando presento un proyecto no falla una en la que no me “aprieten” en las fechas. Parece un método. Y siempre están con el “Si no puede ser pues nada, lo dejamos” o con el “Hacer lo que tengáis que hacer pero tiene que estar en esas fechas” Eso me lo dicen a mi los clientes, no mi jefe o el departamento Comercial, directamente los clientes tiene internamente compromisos y eso se le trasmite al proveedor.
Efectivamente la culpa es nuestra por decir que Si. Pero siempre hay otro que si dirá que sí, y además el cliente difícilmente te vuelve a llamar porque aunque lo otro al final salga mal, caro o lento. No lo reconocerán. No es como decir que no le pasa nada a quien toma esa decisión, es peor. Las organizaciones se anestesian, se venden entre ellos que ha sido un éxito de forma que no consta el fallo por lo que la siguiente vez se llama a “esos que lo hicieron tan bien”.
En este patrón yo pondría no solo a unas cuantas empresas medianas, también a unas cuantas de esas consultoras grandes. Hablas con todos y en privado blasfeman de lo lindo, pero oficialmente nadie critica el proyecto ¿A quien han vuelto a llamar? Ya sabéis. Y de nuevo, hablo por propia experiencia, muy vivida y actual.
1 es posible evaluar la calidad del software si el cliente no se pone de acuerdo sobre lo que se supone que ha de hacer?
2 quien debe llevar a cabo la prueba de validacion el desarrollador del software o el usuario