Trabajar en una gran empresa de software (no cárnica) me ha hecho entender por qué las grandes empresas están condenadas al fracaso, y en cierta forma es entendible. Mi empresa es un monstruo de más de 100 mil empleados que cotiza en bolsa.
Todo el mundo tiene un título, todo el mundo es responsble de algo, para cualquier tema hay "equipos expertos" o "equipos centrales" a los que debes consultar antes de ensuciarte los dedos, todo tiene que ser aprobado por alguien, cualquier cambio ha de ser supeditado por un responsabale, las reuniones se usan como un fin y no como una herramienta, la calidad de los power points es más importante que la calidad del desarrollo, las convenciones de desarrollo (por ejemplo para nombres de variables, campos, UX, o temas de internacionalización) son tan extensas que acaban contradiciéndose, nadie quiere tomar riesgos, a cualquier cosa la llama innovación, el nivel técnico de los desarrolladores llega a ser tan bajo que cuando creas más de tres clases empiezan a llamarlo "framework", y por supuesto debe ser aprobado por algún "equipo central", los equipos están tan bien estructurados (con un SCRUM-Master, PO, Arquitecto, UX-Designer y desarrolladores) que en muchos casos los roles son meros artificios inútiles y la estructura del equipo no es más que un artificio ad-hoc inflexible que no aporta nada.
Me gusta mi empresa, pero me temo que caerá por su propio peso, y es entendible. La empresa necesita responsables, necesita procesos y necesita convenciones, debido a que tiene desarrolladores en muchas partes del mundo. Su maquinaria bucrocrática es necesaria y al mismo tiempo destructora.
Comentarios
#3 Trabajo en una entidad pública. Fiscalizados hasta las trancas, papeleos para cualquier cosa, plazos eternos, etc etc.
La parte buena es que como cuesta tanto hacer cualquier cosa, lo pensamos y planificamos todo muy bien, porque ciertas equivocaciones pueden suponer un año tirado a la basura, o comerse una infraestructura inadecuada, etc etc.
Vamos, que somos Ents, sólo abrimos la boca si vale la pena.
Bienvenido al maravilloso mundo de "corporate América".
La burocracia corporativa es tremendamente frustrante, es cierto, pero piensa también en lo que se convierte la empresa cuando los 100000 empleados empiezan a trabajar en sus cosas a su rollo. A los dos meses a cerrar porque la única solución al pifostio creado es pegarle fuego a todo y volver a empezar.
Ahora, la clave está en encontrar un equilibrio entre "cada uno hacemos lo que nos sale del higo" y "rellene este formulario de 27 páginas para ir al baño". Encontrar ese equilibrio es muy difícil y las empresas tienden a sobreburocratizar porque el riesgo percibido es menor.
Vivo una realidad similar pero en otra industria. IMHO y sin animo de faltar, contribuye mucho a esto los que yo llamo "los chicos de la MBA", gente que se contrata para las capas medias y ejecutivas que puede o no que tengan el conocimiento tecnico del sector, pero normalmente no a un nivel profesional, salvo casos puntuales. Aqui tambien entra gente con el mismo nivel tecnico que los anteriores pero sin MBA pero que les encanta reunirse y hablar el 80% del tiempo de la reunion para decir cosas obvias y que se pueden decir en 1 minuto. Este tipo de personajes inundan la empresa de ideas evidentes que no van mas alla de una organizacioón alemana y lineal que mata todo tipo de libertad y creatividad. Al final, la empresa se convierte en una empresa de "gestores tecnicos" donde la parte tecnica real la acaban conociendo solo los subcontratados y los proveedores. (si aun no habeis llegado a este punto en en vuestras empresas, estais leyendo vuestro futuro.). Por ultimo, llegareis a una fase en la que las habilidades de patio de instituto seran mas utiles y valoradas que las tecnicas.
En ese momento os entraran unas ganas locas de cambiar de empresa y buscar algo mejor, pero las 4 perras extra que ganais os atan.
#12 Estás equivocado. Soy Sr. SDE en Amazon, y la autonomía de los equipos (que no pueden ser de más de 8-10 personas) es sagrada. Trabajes para el equipo que trabajes se te alienta a innovar de manera independiente (esto es, sin tener que pedir permiso a nadie) y sólo se involucran a otros -en especial managers- cuando se identifican lo que se llaman "one-way-doors" (situaciones en las que una decisión es potencialmente irreversible) para decidir la opción a tomar, utilizando datos para cuantificar el riesgo que entablan las diferentes alternativas disponibles. Si una decisión es una "two-way-door" (situaciones en las que hay posibilidades de volver atrás) se te alienta a avanzar por tu cuenta. A esto súmale una cultura de reconocer los errores sin echar culpas ni balones fuera, y de buscar todo el tiempo la mejora -de sistemas, de procesos, de conocimientos, de resiliencia-, y tienes la fórmula para continuar innovando incluso "a escala Amazon".
El problema de las grandes empresas que menciona el autor es que a medida que crecen se ven "obligadas" a implementar estándares (ISO 9000/9001/27001) y/o sistemas de gestión como ITIL (que se ven bien en papel pero cuando las vas a implementar necesitas MUCHO margen para saber qué tomar a pecho y qué dejar de lado), el decir "hacemos DevOps!" a la vez que atan las manos de los desarrolladores y los operadores para hacer cambios en los sistemas con los que trabajan, etc, etc, etc. Cuando todo este paripé falla, empiezan las demoras, los amiguismos, las acusaciones, las cacerías de brujas, los peces gordos tratando de cubrirse el culo y/o esconder evidencias, etc etc etc. Estas compañías terminan cayendo por su propio peso, y por culpa de aquellos que llevan 20 años dentro y que no aceptan ningún tipo de cambio de esquemas.
#11 Las empresas que citas suelen tener productos punteros bien por absorción de empresas que trabajan exclusivamente con sus productos o bien de equipos pequeños dedicados a eso.
El resto está para mantener la maquinaria del mastodonte empresarial.
Y eso que es de desarrollo de software... si trabajaras en un mega-monstruo industrial de la alimentación, como este que se escribe, lo flipas...
No sé si llevas mucho tiempo o poco tiempo, yo conozco realidades parecidas por trabajar durante más dediez años en pequeñas y en granges empresas no-carnicas. Hay que entender que una empresa de miles de empleados tiene que tener una estructura fuerte, que es un coñazo, sí, que a nivel burocrático hay incongruencias y que se cambian las prioridades cada dos días, sí, que hay que acostumbrarse a eso, sí.
Por muy malo que parezca hay que nadar en esa corriente en lugar de hacerlo en contra; aprovechar esas reuniones sin sentido para subterfugiamente cambiar el tema y que se hable de cosas que te interesan a tí y a tu equipo, detectar quienes son las personas y los roles claves en un equipo y dirigirte a ellos en lugar de los roles intermedios, sin eso sí ;quitarlos de hilos de mails o de reuniones.
Lo que quiero decir es que si eres inteligente utilízalo, intenta cambiar pequeñas parcelas de tu trabajo y haz que tu equipo, tus compañeros y tú una voz con confianza entre el mar burocrático, y utilízalo para trabajar mejor.
En una ocasion un sysadmin de otra empresa me tenia que pasar una BBDD y yo restaurarla en mi sistema, rutina.
Pues me sorprendio verme en una call para planificar tan complicada tarea con hasta 4 managers, incident manager, QA supervisor... y no se que mas.
Luego vi la factura del asunto y claro... hay mucha Charo que colocar y RRHH ya se queda pequeño
Yo tengo un familiar que tiene una consultoría informática con un socio de bastante éxito que trabaja en proyectos gordos para multinacionales aún más gordas por toda Europa y él, que empezó desde muy abajo como currito de una "cárnica", lo vio meridianamente claro para prosperar:
- como técnico/programador es muy bueno en su área, pero le falla el "márketing"/relaciones sociales. Para eso está el socio, que es mucho mejor "comunicador/conseguidor" que él, aunque sigue siendo ingeniero con estudios y se comunican a nivel técnico entre ellos perfectamente.
- no tienen estructura fija, simplememente para cada proyecto hacen un estudio muy minucioso de costes, recursos y personal necesarios y DIMENSIONAN lo más ajustado posible al mismo, subcontratando lo que haga falta. Él trata directamente con los equipos de trabajo del proyecto mientras el socio se coordina con el cliente. Cuando termina el proyecto, se deshace todo y vuelta a empezar, pero siempre mantienen contactos con tales o cuales especialistas que saben que funcionan bien para futuros proyectos. Ídem para largar a los que no rindan...
- su carta de presentación son los proyectos que han finalizado y cómo han sabido mantener los costes y los tiempos controlados, incidiendo especialmente en eso. Puede que no tengan el renombre de consultoras prestigiosas, pero pueden garantizar que van a cumplir salvo casos de causa mayor, que todo puede ser, y no hay costes extras por tener que mantener al ejército de turno de burócratas/MBAS/Comerciales ni plazos/costes irreales que han "vendido" esos mismos "gominas" trajeados sin tener idea de lo que hablan en su mayor parte.... lo cual les hace poder ser muy ágiles también porque ellos dos sí saben de lo que hablan...
Y ya está, gracias a esa estrategia nunca les han faltado proyectos ni trabajo, ni siquiera con la crisis de 2008 e incluso ahora con la pandemia ha seguido teletrabajando coordinando equipos por videoconferencia (él encantado por otra parte pues siempre ha defendido que el teletrabajo se tendría que haber implantado hace muchos años en proyectos informáticos si no fuera por la cabezonería de los clientes que querían verte el careto y calentar la silla por narices....)
Y sin embargo, a otros monstruos como Alphabet, Apple o Amazon, el ingente número de empleados y el estratosférico volumen de negocio no les impide ser punteros en tecnología e innovación.
Yo creo que el problema es que en el ámbito de la gran empresa predomina una mentalidad conservadora (efectivamente, es más "seguro" tener todos los procesos supervisados, auditados e incluso redundantes para evitar "errores", que permitir a la gente innovar y aportar algo aún a riesgo de que no conduzca a nada).
#11 Efectivamente, yo en el pasado he trabajado en empresas muy tochas (NASDAQ) que no son como las que describe #0 (aunque sin llegar a los 100k trabajadores, pero cerca). La clave está en no dejar que los jefes intermedios bloqueen todo el trabajo de los desarrolladores. ¿Cómo? Pues lo que yo he vivido (y no sé si será lo mismo en otras) es que hay jefes de grupo que hacen de paraguas de toda la mierda que llueve de arriba y así los que de verdad crean y generan novedades son completamente libres.
Un ejemplo, en cierta ocasión detectamos que había un componente software de un tercero que nos estaba ralentizando muchísimo por sus constantes fallos y problemas de comunicación con los desarrolladores. Había dos opciones: (1) escalarlo y esperar a que alguien de arriba se pusiera en contacto con algún mando intermedio de la otra empresa, decidieran qué hacer, se lo pidieran a sus programadores, lo corrigieran y volviera a nosotros o (2) hacerlo nosotros. Lo hablamos con nuestro jefe de programación y decidió cubrirnos para que dos miembros del equipo lo hiciéramos. Resultado: se agilizó el proceso de producción a partir de ese día, la empresa se ahorró miles de dólares al año en royalties y todos fuimos trabajadores más felices porque la frustración que producía ese software mal hecho desapareció. Creo que la clave es confiar plenamente en el personal que contratas, pero eso no todas las empresas pueden hacerlo.
#10 Yo trabajo en una pyme de 50 empleados y pasa eso mismo: cuando se va un cargo intermedio, en lugar de ascender a uno de los que estábamos bajo su supervisión, buscan a otro de fuera. Porque los que estamos, si hacemos bien nuestro trabajo, mejor no tocarnos.
Te acompaño en el sentimiento aunque mi sector sea otro.
A eso sumarle los trepas, los jefazos de Powerpoint, reuniones eternas, los fanáticos de los indicadores, los fanáticos de las ISO xxxxxx, los cansinos de la imagen corporativa, los perros guardianes de lo políticamente correcto, todo lo ven acoso laboral, sexual, etc...
#2 le veo y lo doblo. Trabajo en IT en un mega-monstruo industrial de la alimentación...
Es una mentalidad de cuando no te dedicas mucho a organizar el trabajo de los demás.
Cuento mi experiencia haciendo seguimiento y control de varios grupos, en total menos de 50 personas:
- cada cual te cambia el formato del documento que le pides por que le parece más cómodo. Tú lo homogeinizas
- cada equipo decide incluir lo que le parece relevante, de forma de unas cosas vienen informadas en algunos informes y otras no.
- los plazos solo los cumplen algunos equipos, así que la información está actualizada parcialmente.
Y un largo etc de cosas más triviales.
Y ahora extrapola esto de 50 a 100.000 a ver que sale.
#1 las grandes empresas y los estados se parecen mucho amigo. burocracia everywhere.
#15 es interesante lo que dices. Era una de las ideas del post, intentar encontrar alternativas que puedan funcionar para empresas tan grandes. Gracias por el aporte!
Yo soy Senior y líder de equipo, por detrás del arquitecto, pero el arquitecto en nuestro equipo ni pincha ni corta, lo mismo que yo. Hemos intentado desarrollar una app nueva siguiendo los estándares de "modernización" de la empresa, es decir las arquitecturas nuevas que hay que usar, entre otras cosas mucho más orientadas a extensibilidad y objetos. Pues bien, hemos sido frenados por el equipo central (que es el mismo que anima a "innovar" con estas nuevas arquitecturas) porque dicen que aún no hay suficiente madurez como para empezar con eso.
Hablando con otros equipos antiguos, son aún peores. No es que no tengan el Know-How para hacerlo así, es que ni siquiera se les espera ni tienen iniciativas para ello.
Toca decir que el equipo en el que estamos es muy nuevo, hemos empezado todos en la empresa en diciembre/enero, yo antes era líder de desarollo en una empresa de unos 5000 trabajadores y tenía muchísima libertad para innovar, casi siempre salió bien. Ahora me encuentro muy atado, pero bueno intento entender cuál es la mejor forma de aportar algo...
#3 Yo trabajo en el sector de la mejora y lo que cuentas no solo es cierto sino que además está extendido. Las empresas, cuanto más grandes son, más dadas son a hacer estructuras de personal cada vez más profundas, con más capas intermedias, y tienen capacidad financiera suficiente como para contratar gente en exclusiva para la metodología de moda olvidando totalmente la función última de cualquier empresa, contentar al cliente y que te pague. Esas estructuras intermedias tienen varios efectos, por un lado crear silos casi independientes donde se reporta de abajo a arriba y los indicadores son los únicos referentes a seguir, y en el medio nivel hay una sobrepoblación de pequeños tiburones titulados que quieren ser más tiburones que los demás, y apretarán más a los que les reporten para que su foto sea mejor que la del vecino y sea mejor considerado por si se libera algún puesto del nivel superior. Otro resultado es la desmotivación de muchos, sobre todo de las capas más operativas donde sólo se tendrá en cuenta parte de las operacioens más productivas, es decir, si eres bueno en algo te machacarán para que siempre acabes haciendo eso, sólo porque eres bueno... En el ámbito de empresa familiar, cooperativista y público la cosa es incluso peor. Es una generalización, pq hay de todo, pero hay un inmenso campo de mejora. Alguna cosa más me dejaré en el tintero.
Tengo ya muchos años como Solution Architect y mi vida son las reuniones, Soy el nexo de unión entre todos y el responsable de cada cambio, pequeño o grande que hay en los sistema. Responsable de requerimientos funcionales y no funcionales, definición de SLAs, de APIs, ETLs, WS, de integraciones, de definir arquitecturas, estrategias de integración y un largo etc. Estoy comtamente moviéndome entre dos mundos y viendo como uno no entiende al otro y haciéndolos entenderse. De la parte de cliente y sus pajas mentales podría hablar mucho, pero me voy a ceñir al desarrollo que de lo que aquí se habla.
Yo no sé en que tipo de aplicaciones os movéis, pero en las que yo me muevo son grandes y muy críticas y no exagero si digo que se integran con 40 o 50 sistemas más (ya si vamos a microservicios mejor no os cuento). Esa visión, como la que dice #59 al decir "añadir un campo a un formulario" es la que precisamente no hay que tener. Ese campo servirá para algo ¿no? y se hará algo con él ¿no? ¿Y quien lo va usar y para qué? ¿Se relaciona de alguna manera con otros datos? ¿No tendremos algo que ya posea esa información y estamos haciendo el tonto? ¿Impacta en otras funcionalidades de la aplicación? ¿Si lo subo a producción no le pegaré una hostia a otro sistema que no espera ese dato? ¿Lo puedo subir a producción sin impactar en el servicio o en los SLAs? ¿Sabe la gente de operaciones para que sirve y lo que a ellos les puedes suponer? ¿Esta la aplicación de incidencias preparada para él? Y así puede seguir con muchísimas otras preguntas, pero creo que como muestra ya está bien. El "en hora lo hago y lo subo a producción" si QA, sin informar a otros y yo a mi bola, solo y aun así difícilmente, sería posible para solución de una gran incidencia crítica o algo así. Y puedo asegurar que en los sistemas en los que yo trabajo no entra nada sin que un SA le eche un ojo y se lo piense bien, por qué muchas veces "un solo campo en un formulario" supone un cambio de copón por muy sencillo que le parezca al desarrollador, y lo que parecía una chorrada a ojos del desarrollador es un trabajo mucho más grande en otros sitios de los que el desarrollador no sabía de su existencia.
#29 Trabajé muchos años haciendo programas para la red de venta del sector farmacéutico. No se os puede dejar libertad porque a la media hora ya habéis liado el pifostio.
#31 Vamos, lo normal. Yo he llegado a gritarle a un jefe de proyecto que me tenía hasta las narices: "¿pero qué quieres que haya avanzado desde la última vez que me preguntaste hace una hora? Déjame trabajar, que ya te avisaré yo cuando esté terminado, coño". Balbuceó "sí, sí, perdona", y se metió en su despacho.
Si no puede con la presión, que deje el puesto. Lo que no puedo es pasarme más tiempo enseñando lo que he hecho, que haciendo.
#33 En mi empresa hay un tipo que lleva 20 años haciendo informes de crystal report. Dice que el día que lo echen, se ahorca como el preso de la peli "Cadena perpetua".
#2 sí... sospecho que en otros sectores debe ser parecido.
Es entendible, puesto que una empresa debe dar una imagen corporativa, estandarizar procesos y demás, pero como digo, la burocracia que se requiere para hacer cualquier cosa es brutal y frena mucho las iniciativas, el desarrollo y la innovación. Eso sí, cada vez que tienen oportunidad sueltan la palabra innovación para todo.
Mientras sigan vendiendo aplicaciones a bancos con un 40-60% de beneficios y BPO externalizadas a la India con más de eso se pueden permitir los sobrecostes internos.
Os contaré una historieta del ágüelo. Yo trabajaba para uno de los grandes bancos de UK y sacamos a concurso la impresión y distribución de toda la correspondencia en papel. Se lo llevó una empresa de servicios por un precio ridículamente bajo. Lo que hacían era imprimir y ensobrar en India, traer las cartas a UK por avión y distribuirlas como correo local. Por qué ganaban dinero, porque los de offshore trabajaban por cuatro rupias y hacían horas a destajo
Bienvenido a las corporaciones, yo trabajo en una de 150k empleados, por todo el globo.
Y esto no cae ni por asomo. Tienen proyectos que llevan desde hace 20 años con clientes que se comen cualquier mierda y la pagan como oro.
La burocracia sale de esos proyectos.
En la parte de innovación debe haber menos del 5% de la plantilla, son los proyectos de los que fardan, pero no de los que vive la empresa.
Esto es inmortal e inamovible, 0 crecimiento personal y laboral, 0 aprendizaje, y un puesto de trabajo comodo hasta el día de la jubilación sin comerse la cabeza, cobrando "meh" pero de sobra para vivir.
#23 Nosotros estuvimos semana y media con reuniones scrum diarias. Luego pasaron a ser dos veces por semana, y finalmente desaparecieron. Vieron que paralizar durante tres cuartos de hora a todo el equipo de desarrollo no servía para nada. Que era mejor que un fulano fuese preguntando a cada uno cómo iba y qué le retrasaba, y diese prioridades.
#4 #44 Si no te pueden sustituir, no te van a promocionar.
#38 si es en el departamento de research no vas a tener estos problemas... Como han dicho por arriba, las empresas tochas suelen tener un departamento para crear cosas chulis y nuevas, de las que suelen fardar en todas las presentaciones globales. Este departamento suele ser minúsculo en comparación con la empresa, y la empresa no vive de lo que ahí se hace, pero a veces suelen salir cosas muy interesantes y a veces, al cabo de los años, empiezan a usarse en toda la empresa.
En cualquier caso es un puesto muy interesante, seguro que te lo pasas bien. Te animo a que cuando lleves un tiempo nos escribas diciendo qué impresiones tienes A mí me puedes contactar por privado si quieres!
#68 User-eXperience, normalmente encargados de diseño de interfaces útiles o cómodas para el usuario final
#19 He estado en empresas así, y he aprendido que ese tipo de empresas se mantienen trabajando de esa manera porque muchos de los que están dentro se encuentran cómodos en ese mar de burocracia. Es extremadamente difícil -quizás imposible, salvo un cambio drástico de liderazgo que afecte a todos los niveles- cambiar las cosas para mejor, porque esta misma gente suele usar ese mar de burocracia para frenar el progreso y exponer a aquellos que buscan un proceso más ágil.
Es difícil encontrar una mejor forma de aportar algo en situaciones así. En mi opinión, si te encuentras incómodo trabajando de esa manera, tu mejor opción es buscar una alternativa en la que se valore tu ánimo "progresista". En el 99% de los casos, sin acceso a influenciar al liderazgo, estarás remando contra la corriente... te encontrarás frustrado, viéndote obligado a trabajar de manera ineficiente, ineficaz, poco innovadora e incapaz de cambiar nada para mejorar la situación.
Recuerdo un proyecto de software que estuve que había que hacer una mierdecilla y me pusieron un project manager, que lo único que hacía y con toda su buena intención tocarme los testículos, que si estimaciones, que si cuanto porcentaje había completado, que si necesitaba a un compañero para ir al doble de velocidad. Luego necesitaba algo de el y tardaba días en darme la solución.
#65 Esa es otra: no hay que irse a una sala de reuniones, la reunión se hace en el sitio en el que está la gente trabajando. Se levantan y se hace 5 minutos de reunión de pié. Y no se espera a nadie, la hora de la reunión es sagrada, el que esté ocupado que mande un mensaje rápido en cuanto termine.
#3 No, otros sectores son peores. Date cuenta de la falta de regulación en el desarrollo de software.
Imagina que, como en otros sectores, todo proyecto ha de ser validado por un ingeniero en la rama.
#0 o eso o hace como spotify adaptar el modelo Scrum a las necesidades particulares de la propia empresa. No existe único modelo y para encontrar el tuyo o mejorarlo hay que elegir bien qué parámetros vas a medir.
#32 700 euros le cobraron a un cliente por añadir un campo en un formulario. Presupuestada una hora de DBA, dos horas de programador, dos horas de jefe de proyecto, dos de tester,...
El jefe mandó un correo y en media hora ya le estábamos preguntando si subíamos a producción.
Yo empecé en una empresa cuando tenía unos 300 empleados. Casi nos conocíamos todos y sabías a quién llamar cuando tenías un problema o a quien consultar cuando se te ocurría algo que podía afectar a otro departamento. Y sin problemas. Ahora, con el doble de empleados, la burocracia se ha incrementado y todo tiene que hacerse por escrito a través de una aplicación interna. Pero ahora no sabes a quien le llegan tus escritos, así que todo se ralentiza y si se encalla no hay manera de saber con quien tienes que hablar para desencallarlo. Procesos que funcionaban, pero que no escalaban bien, se han cambiado, se ha añadido burocracia y se han hecho más largos y complicados. En fin, a veces es desesperante.
Entiendo que al crecer se hayan buscado maneras de repartir el trabajo, es lógico, pero se deshumaniza el trabajo (ya no lo hace una persona, lo hace "un equipo" así, indeterminado) y todo se vuelve más lento.
#2 o en un colegio, que para mover a un crío despistado de las filas de atrás a las de adelante, para que se entere de más cosas, tenemos que abrir un PAP, notificarlo por la web de conselleria, poner por escrito el seguimiento de la medida...
#89 ¡Eso no existe!
Creo que conozco a departamentos de "antiUX", porque interfaces mal diseñadas e incómodas son las normales.
Me gusta mi empresa, pero me temo que caerá por su propio peso, y es entendible.
Bueno, es precisamente al revés. Las grandes empresas, con su burocracia, son más potentes y crecen más.
Está claro que en una empresa de 10 personas cada uno aporta más valor a los productos y servicios. Cada uno aporta el 100% al producto y servicio pero con ese número empieza a volverse inmanejable.
A poco que crezca, necesitas más burocracia para mantener una cierta cordura. Quizás los trabajadores ahora aporten el 80% a producto y servicio y el 20% a burocracia. Pero es un mal necesario si no quieres pasar a productividad 0 porque cada uno hace una cosa diferente.
Cuando es una empresa de cien mil trabajadores, todo DEBE estar encorsetado si no quieres que se caiga todo al suelo.
Esta burocratización, por cierto, es muchas veces conveniente para los clientes. Muchos, con razón, huyen de las pequeñas empresas donde no hay mecanismos burocráticos de control y todo depende de quien te coja el teléfono y el humor que tenga ese día. También las hay, las menos, las que prefieres trabajar con empresas más pequeñas y adaptables.
#7 Yo me siento el de la subcontrata y la verdad que como odio trabajar me iria a cualquier otro sitio por 4 perras extras porque como dijo un genio "Yo trabajo por dinero"
La japonizacion de España. Empresas inoperantes que sobreviven a base de crédito barato y que acaparan los recursos materiales y humanos imposibilitando a nuevas empresas aparecer.
Deberían dejarlas caer y usar el dinero público que se derrocha en ellas en rescatar y formar a los trabajadores de las mismas.
#61 No hace falta ser tan complicado. Hay una frase que es oro, "no despiden a nadie por contratar a IBM".
A la hora de buscar un proveedor los responsables se juegan su nombre y su validez laboral. Su trabajo está sobre la mesa. Y a nadie despiden si eliges a IBM. Como elijas esa empresa pequeñita y lugeo haya un problema alguien te va a preguntar "por qué".
#7 Acabas de describir perfectamente a mi anterior empresa. Pero yo conseguí huir a tiempo.
La burocracia muchas veces responde a egos y a chiringos.
Más control no debería implicar más permisos y más burocracia.
Muchas empresas se crean ellas mismas problemas con metodologías que exigen tareas que no aportan nada positivo al producto ni a sus procesos.
Yo lo veo mucho con agile, esos scrum masters que no valen para hacer la o con un canuto, pero que se saben de memoria toda la teoría y hacen perder el tiempo a los demás hasta que asumen que la teoría se tiene que amoldar a la realidad.
#33 Por cómo hablas, parece que estás de funcionario en una administración pública.
#130
Menos mal!!
Si las grandes empresas no tuvieran esos defectos, estaríamos perdidos!! No habría alternativa ni esperanza!!
#74 Y a eso sumale la experiencia y el know how que suelen tener las grandes empresas de cada sector, para resolver los problemas de clientes grandes o gigantes (qué suelen ser problemas con riesgos a la medida).
Esa es una gimnasia que una pequeña empresa difícilmente tenga como afrontar sin fisuras proyectos de gran escala.
En el fondo, creo yo, el futuro de la empresa que comenta el autor del post dependerá de su capacidad para adaptarse a los cambios vertiginosos que suelen ser la tónica de los tiempos actuales y venideros.
Pero yo no me atrevería a asegurarse que esas empresas están heridas de muerte.
Una gran empresa es una estructura mastodónica que necesita que todos sus engranajes encajen a la perfección para poder seguir funcionando. Cualquier inútil colocado en un puesto clave que actúe a su libre albedrío puede cometer un error que haga colapsar no solo a su departamento si no a toda la maquinaria. Además los ascensos se suelen dar por pelotilleo y antiguedad más que por méritos por lo que hay una gran cantidad de inútiles en puestos clave; por ello se hace necesario crear procedimientos hiperrigidos que requieran aprobaciones en cadena y definen hasta la fuente a utilizar y la imagen de fondo de los power points. Algo muy parecido ocurre en el ejército o en la administración.
cc #4 #5
#0 Solo te puedo decir que yo he trabajado para startups en silicon valley (esperando tener menos burocracia) y a todos los problemas que has mencionado (en menor escala al ser una organizacion mucho mas pequenya) le tienes que anadir los egos de la gente, con la titulitis de Stanford.
Ahora bien, un minimo de burucracia y orden bien implementado es totalmente necesario para profesionalizar el trabajo, sino los proyectos no salen, y lo que sale es un churro.
#19 estoy seguro de que tu frenas los pies a gente de tu equipo, pues los otros departamentos están haciendo lo mismo contigo. Entiendo la frustación pero es mejor así, harás menos cagadas, y si las haces, podrás echarle la culpa a otro
#34 Yo no hablo de MBA, ni de las habilidades que importan.
Yo lo que digo es que hay que usar el escenario que tienes en tu beneficio, si voy a salir a correr y está lloviendo, puedo buscar otro sitio donde no llueva o ponerme un chubasquero. Y créeme en todos sitios llueve, y si no llueve hará mucho calor, o viento...
De todas maneras yo creo que es una discusión que no tiene dos partes, yo soy técnico y me encuentro a diario con gente que por no tener habilidades sociales no se enteran bien de lo que le piden, imponen su criterio frente al cliente, impide que su solución sea entendible por otros compañeros por no usar el estandar y cavan su propio hoyo explicando que ellos son los especiales y los demás los equivocados.
No digo que haya que ponerse gomina y chaqueta y hablar con siglas en inglés para vender humo, digo que si de verdad somos inteligentes juguemos con las cartas que nos tocan, aprendamos a usarlas y crear un círculo de compañeros donde eso no sea lo importante.
Subir en la empresa no vamos a subir mucho, pero crear un entorno más agradable y de compañerismo sí.
#48 Es que un scrum diario de 45 minutos es una animalada.
Según mi experiencia las de 5 minutos sí que sirven, pero siempre hay alguno al que le encanta oírse hablar y un par que aprovechan cualquier excusa para discutir algo irrelevante que hace perder el tiempo a todo el equipo, y ahí es donde tiene que estar atento el jefe técnico o de equipo para cortar rápidamente esas tonterías.
En una empresa en la que estuve currando arreglaron el tema de los scrums eternos obligando a que fuesen en inglés además de hacerlos de pié. El hacerlos de la forma más incómoda posible para que la gente quiera terminarlos rápido es clave.
#74 No puedes jugar contra "los maletines" y "contactos" de los grandes. No es solo por una razón "de nombre".
#17 efectivamente, muchas grandes empresas no pueden confiar en el personal que contratan porque no consiguen cobrar una vacante al precio indicado y te meten a un licenciado en historia a picar código.
Con todos mis respetos a los licenciados en historia... si por lo menos fuera uno que se ha preocupado en reconvertirse y le gusta... pero ni siquiera, es a uno que han visto en el paro y le han dicho... vente a programar que nosotros te damos el cursillo.
Pues imagínate lo que sale de ahí. Y lo peor de todo es que no pasa nada, porque importa más el reporting que el trabajo de esa pobre criatura.
#22 gracias por el aporte! Es exactamente como dices, la impresión que tengo es que los colegas de otros equipos que llevan más tiempo tienen todos un "cargo" en no sé qué equipo de validación de no sé qué cosa, "aprover" para no sé que otra, responsables de no sé que otra (y tienen que estar siempre en CC aunque jamás respondan un puto mail), mentores de no sé qué tema... y parecen bastante cómodos haciendo eso, que al final es un trabajo puramente burocratizado.
Por el momento todo nuestro equipo es nuevo y todos tenemos un poco una mentalidad "progresista", también es lo que intentamos transmitir el arqutecto y yo sobre todo a los desarrolladores no juniors (porque los Juniors vienen con muchas ganas a pesar de no tener mucha idea de nada), pero como dices a veces quedamos de ovejitas negras y vamos a contracorriente. A ver si duramos y al final podemos aportar algo en todo este mar de burócratas.
Los dinosaurios necesitan un meteorito para extinguirse.
Mientras seguirán viviendo porque tienen una cosa que el resto no, muchos clientes.
#96 estoy de acuerdo contigo; en mi caso, que soy desarrollador de backend, también me como este tipo de asuntos. Por desgracia esa figura solo existirá en empresas muy grandes y que puedan permitirse ese nivel de especialización. Pero es cierto que cuando hacen un buen trabajo, se nota desde lejos.
), y es que yo prefiero iOS frente a Android exclusivamente por sus interfaces y facilidad de uso. Si le quisiera dar un uso más intensivo a mi móvil, esto no sería suficiente; pero esa facilidad de uso (en cualquier aplicación/sistema) puede que retenga a muchos usuarios.
Voy a poner un ejemplo controvertido (
#59 #81 700 Euros pueden ser de 0,5 a 2 jornadas incluyendo el coste de hacer la propuesta.
Si no tienes ni idea de lo que supone hacer el cambio es una temeridad hacerlo por menos.
#17 Buen punto para tu jefe y para vosotros. Y además sumas una experiencia distinta en el acervo del equipo.
El mundo esta lleno de gente que sabe llevar una empresa mejor que las empresas mas exitosas de sus mercados correspondientes.
Normalmente, es gente que ni sabe por donde sopla el viento en lo referente a organización y dirección de una empresa.
#70 Entendible si se piensa a corto plazo pero a medio plazo lo que va a ocurrir es que esa persona que no quieres promover porque hace muy bien lo suyo al final cambiará de empresa para optar al puesto que tú no le ofreces y perderás todo su conocimiento. No hay solución perfecta pero si la gente percibe que no merece la pena hacer las cosas bien porque corres el riesgo de estancarte... pues no las hará bien.
#15 No me ha quedado claro si eres de Amazon o de AWS pero en cualquier caso en mi empresa hay varios buenos técnicos que han huido de AWS por lo mal que funcionaba.
#101 yo también he trabajado en un banco (si no trabajas en uno, en algo similar andas), y bueno, si estás tocando el código de, yo qué sé... hipotecas... vale, te compro que tienes que tener un buen control de qué se cambia y cómo.
Pero casi el mismo control lo tienes para el formulario de contacto que hay en la web si quieres añadir un campo de número de teléfono, y si lo metes directamente en producción y funciona mal, la pérdida es menor que todo lo que has invertido en asegurarte de que todo va bien y tiene sentido y tardar 3 meses en subir ese cambio a producción.
Y ya te digo, conozco esos sistemas y gran parte del problema es el cómo se interrelacionan entre sí. Hay fallos gordos de diseño, a veces causados por los controles que se imponen para evitarlos.
Muchas veces tienes aplicaciones consumiendo de otras de formas que no tienen sentido y creando dependencias absurdas. Otras veces tiran de ti 50 aplicaciones cuando 1 es productiva y las otras 49 son la cadena de aplicaciones legacy de la productiva.
Pero en el fondo, el principal problema es que no hay una estrategia clara de gestión del dato, y tienes soportados cientos o miles de aplicativos y cada uno tiene su "golden copy" de su dato, y si necesitas ese dato te tienes que conectar con ese aplicativo... y así es como conviertes en sistema crítico un aplicativo que recoge datos de la campaña de Navidad, y no puedes modificarlo para las siguientes Navidades porque de él cuelgan otros 20 aplicativos a los que les ha parecido interesante el dato.
Evidentemente no todos los bancos pecan de todo esto, pero estoy seguro que muchos de estos ejemplos factuales les son familiares a muchos meneantes.
#139 He trabajado mayoritariamente en telco, ojalá fuera banca
Y ahí están medio locos. Prima la velocidad por encima de todo, se hacen workarounds que si lo piensas son una puta locura. Te puedo contar que es habitual incluso desarrollar en soporte y luego oficializar en desarrollo, si tienen que meter a 40 usuarios a las 4 de la mañana a hacer pruebas de aceptación al paso se meten. Proyectos planificados a tres meses se hacen en unas horas o se hace un workaround hasta la entrega buena, es una locura de sector. Y eso se hace por decisiones de marketing, no por que se vaya a caer algo o por incidencias.
Pero lo que si que se hace siempre es pasarlo por un Solution Architect para detectar impactos (internos y externos) y posibles consecuencias y se habla con mucha gente, muy rápido, eso si (y sin importar horarios). Pero nunca un desarrollador solo es el responsable de cualquier cambio. Varias veces ha tocado hacer desarrollos rápidos en 12 horas, por ejemplo, pero no exagero si te digo que mientras se desarrolla te toca hablar con 40 personas para no liarla.
Resumiendo, los costes no son solo "meter un campo en un formulario", es eso, mas SQA, más mis horas, más las horas de la gente con la que hablas (SAs otros sistemas, prepro, aseguramiento de servicio, operaciones, responsables del paso, responsables del cliente, etc, etc, etc.) y todo, absolutamente todo pasa por un SA y por una aprobación del cliente. Eso alguna gente, con una visión más cerrada como un desarrollador, no lo ve (y tampoco tiene que hacerlo, no es su responsabilidad) y lo llamarán burocracia y sobrecostes . Pero es la diferencia entre hacer las cosas medio bien o te salten correctivos con coste, joder los SLAs y que un evolutivo termine palmando dinero y la gente a la calle. y si eso ocurre ahí estas tú para dar la cara y también la aprobación del cliente asumiendo los riesgos.
PD: de sistemas legacy mejor no hablar, el carajal es inmenso. Me he comido un par de migraciones de sistemas gordos (de hecho sustituían a varios legacy) que al repasar los ETLs, por ejemplo, se ha visto que se mandaban datos a sistemas que hace años nadie recoge, pero como nadie protestó ... y aún así se han mantenido porsiaca
#44 Bueno, es hasta entendible. Si no, corren el riesgo del principio de Peter.
#154 gracias por la referencia. Lo pongo en la lista, me interesan este tipo de libros!
#46 "por mis cojones" se hacen muy poquitas cosas, sobre todo al nivel profesional donde me muevo yo. El respeto es máximo y todos escuchan, aportan y están abiertos a críticas.
#111 sí, se puede decir. Pero no es el punto del artículo.
#8 Si la validación fuera "real" y no un paripé, me ahorraría ver las mierdas que veo, pero intuyo sería un trámite más, para justificar a todavía más inútiles.
#14 son más potentes y crecen más
No lo compro. Tienen más "contactos" por lo que pueden vender su mierda mejor. ¿Cómo era aquello de "yo te la chupo, tu me la metes?
#9 se me fue el dedo, te compenso en otro
#47 ¿UX?, ¿qué leches es UX?
#56 o de cualquier otra similar. Mira los comentarios, y verás que no todos son de la misma empresa, y todos tienen problemas similares.
#59 Seguramente es un campo en un formulario y una columna en una tabla, y poder grabarlo y recuperarlo. Sigue siendo una chorrada si no tiene complicaciones, pero tiene que hacerlo un experto para estar seguros de que no casca. No me parece mucho dinero. Se ven precios muchísimo, muchísimo más altos
#36 Soy muy partidario de tu visión, pero en mi caso la adaptación se parece muy sospechosamente a "van entrando gallinas por un lado y van saliendo por el otro", lo cual no me tranquiliza especialmente.
#3 Aquí uno en el sector farmacéutico.
Como sector tan sumamente crítico que somos, tenemos unos protocolos hiper-cerrados para hacer cualquier cosa, aquí la improvisación no tiene lugar, pero ni nosotros tenemos tanta tontería como en tu empresa. En este sector el trabajo es A, B y C, auditado por numerosas agencias nacionales e internacionales (en 15 días viene una auditoría muy tocha, no digo de quien porque entonces se sabría que empresa es).
Incluso a nosotros en nuestros sistemas se nos deja algún margen (ligero) a la imaginación. Afortunadamente los scrum master no se han apoderado de esto (aún). Lo siento por tu empresa, cada vez se oye más de ese tipo de trabajo.
#24 A la gente se lo tienes que dar mascado. No puedes pedir que cada cual te indique su progreso, o pase tareas a otro equipo, mediante documentos word, porque pasa eso que dices, que cada cual lo hace como se le antoja. Hay que crear una herramienta informática que obligue a meter la información de cierta forma, y que sea ella la que homogeinice.
#45 Eh eh eh, que esos son los de ventas, que han visto mucho Mr. Robot, en la fábrica somos buenos y cumplimos todo.
Escrito con guantes de nitrilo, barbera y mono de protección 1.
#62 No es sólo el tiempo de scrum en neto. Súmale el tiempo de mover a toda la gente a la sala de reuniones. Que si fulanito está acando nosequé, ahora viene. Menganito está hablando con fulanito, ahora viene. Y acaba la reunión, y mucho se van directos a la máquina del café, o se quedan charlando en un pasillo.
#101 Era un campo simplón para meter un texto, no relacionado con otros campos. No afectaba a ninguna otra parte de la aplicación. 700 euros es el sueldo de medio mes de un programador, 88 horas de trabajo. A mí me parece un abuso, por un campo de esas características.
#110 Toda esa información ya llega cuando te piden crear el campo y añadirlo al formulario: si es obligatorio, tamaño, si hay que rellenar los registros existentes con un default,... No te dicen "mete un campo nuevo" y ya, como es natural. Nuestros jefes de proyecto no son ninguna maravilla, pero hasta ahí llegan.
Los peores: lo jefes que te sueltan una perorata sobre SCRUM o alguna mierda parecida, y luego vas a la wikipedia a refrescar un poco tus conocimientos y resulta que la sabiduría del jefe es una copia exacta, hasta la última coma, de lo que dice la wiki. Puta bida.
#60 bueno, el día que lo echen, habrá otro tipo en cliente que tomara una decisión similar.
Es duro vivir en un curro obsoleto.
#11 Creo que se apalancan mucho en la tecnología para conseguir unas ratios EBIDA/empleado muy altas.
Estas compañías no pueden entrar en un mercado que te obligue a tener a una persona atendiendo al cliente por cada 10.00-10.000 pedidos así que estandarizan mucho, tienen sistemas de calidad muy fuertes, y cuando llegan oportunidades pequeñas tiran de partner (es infinitamente más fácil gestionar la relación con un partner, que con las 50-100 cuentas pequeñas que te puede traer).
#54 Es más importante no pisar callos, que hacer según que cosas.
Y hacer cosas en las que otros han fallado es pisar un callo muy gordo. Ojo!
#109 tengo dos amigos profesores y siempre comentan eso mismo .. lo de las PAP.
#129 no, que trabajar trabajo.
#19 yo lo que veo ahí es falta de confianza y descentralización.
Yo estoy en una empresa grande y cada equipo es autónomo, con mucha libertad para elegir cómo hacer las cosas porque se espera que dentro de tu campo sepas qué estás haciendo
Pues yo he trabajado en una gran empresa de software y para nada he tenido estos problemas. No digo a decir que fuera perfecta ni mucho menos pero no había la burocracia que indicas, era Americana e Internacional.
yo voy a entrar en una empresa con 400k empleados en todo el mundo como pre-development researcher (investigador para futuros productos) y vengo de una startup.... y lo que decís me interesa ya que la burocracia de donde vengo es nula.... consejos?
#8 Segun en que área, el SW esta muy regulado.
#0 Yo trabajo en una pequeña y los problemas son muy diferentes pero, observando decisiones o actitudes de de algunos proveedores me da por pensar que a veces esas empresas "inventan" su propia realidad y crean su propio mundo y, en ocasiones, mueren por desconexión con el mundo real.
¿Has notado cosas así o son tonterías mías?
Gracias por el articulo
#71 ¿Lo dices por el autor del artículo?
Claramente, habla de ING.
Sustituye desarrollo de software por cualquier otra cosa.
#48 #62 No sé como serán vuestros esquipos de grande, pero las reuniones de Scrum son de 15 minutos donde cada miembro debe decir lo que hizo el día anterior y lo que hará el resto del día, si tiene algún problema que lo diga y pregunte si alguien le puede ayudar, y nada más; normal que lo quitaran.
#0 IBM, HP, General Motors, Volkswagen, Mitsubishi, etc, etc (por no mencionar empresas de servicios como Western Union o bancarias como JP Morgan), dicen que o te equivocas o se tarda más de 100 años en fracasar.
#113 Yo estoy en el equipo de plataformas para dispositivos de salón (PS4/5, Xbox, AppleTV, Roku, SmartTVs, reproductores tipo NVIDIA Shield, etc) para apps como Prime Video.
Amazon no es para cualquiera, pero de ningún modo me parece que vaya mal AWS o Amazon. Hay que ver lo que entienden tus colegas por “que vaya mal”. Evidentemente tan mal no va Amazon