Portada
mis comunidades
otras secciones
#7:
Creo que ninguno de los comentarios anteriores es de alguien que trabaje en el dector tecnológico... esto no es palabrería, es una metodología, se usa mucho y funciona.
#14:
#7 Agile es, efectivamente, una metodología, un nombre propio, pero la gente que no tiene conocimientos en ese campo (como el periodista del artículo) es normal que lo confunda con ser ágil como adjetivo (algo así como te digan que en tal empresa van a cambiar los coches ejecutivos por ford mustang y haya quien diga que los caballos consumen mucho heno y contaminan con sus heces). Lo de "sin jefes", obviamente viene de haber echado un ojo a la wiki y oír campanas sin saber muy bien por donde suenan, en Agile también hay jefes, directivos, juniors, gente que cobra más y gente que cobra menos...
Por otro lado, Agile es una metodología que funciona muy bien para algunos entornos, como desarrollar para spotify, pero que se adapta con dificultad a otros, donde la transversalidad, por motivos de seguridad, validaciones y demás, no es factible de manera realista.
No es el mejor sistema para construir software médico, militar y vaya, hasta ahora el bancario se ponía también como ejemplo de donde no parece apropiado aplicar metodologías Agile.
Quizás ING demuestre que sí es posible, y eficiente, muchas veces el progreso se da cuando alguien demuestra que lo que los demás decían que no se podía, sí se puede... Pero tampoco hay que olvidar que muchas, muchas otras veces, la realidad es que no se podía así, y el intento se hostia.
La otra posibilidad es que sea solo una pose, igual que cuando su CEO dijo lo de "no somos una empresa de banca, somos una empresa de tecnología que casualmente tiene una licencia de banca", que lo de Agile sea solo una capita por encima, que se limite al frontend más pinturero de su web, pero que, como todo banco, siga teniendo más yayos kobold-eros que devops de golang...
En un par de años se ve.
Por otro lado, Agile es una metodología que funciona muy bien para algunos entornos, como desarrollar para spotify, pero que se adapta con dificultad a otros, donde la transversalidad, por motivos de seguridad, validaciones y demás, no es factible de manera realista.
No es el mejor sistema para construir software médico, militar y vaya, hasta ahora el bancario se ponía también como ejemplo de donde no parece apropiado aplicar metodologías Agile.
Quizás ING demuestre que sí es posible, y eficiente, muchas veces el progreso se da cuando alguien demuestra que lo que los demás decían que no se podía, sí se puede... Pero tampoco hay que olvidar que muchas, muchas otras veces, la realidad es que no se podía así, y el intento se hostia.
La otra posibilidad es que sea solo una pose, igual que cuando su CEO dijo lo de "no somos una empresa de banca, somos una empresa de tecnología que casualmente tiene una licencia de banca", que lo de Agile sea solo una capita por encima, que se limite al frontend más pinturero de su web, pero que, como todo banco, siga teniendo más yayos kobold-eros que devops de golang...
En un par de años se ve.
#6:
#3 Pero la responsabilidad de ¿qué?
Hay muchos tipos de trabajo. Y cada uno es responsable de sus acciones en este tipo de empresas (banco) que está todo registrado y encorsetado.
El mero hecho de tener un jefe no significa que sea responsable de la acción agrupada de todos los que están por debajo de él. Ni el hecho de no tenerlo tiene porqué hacer que la responsabilidad se diluya.
Cuando quitan los mandos intermedios es porque el control ya lo da un ente que se llama: sistema de gestión. Que es el que se adapta a todos los cambios legales de la empresa y es reporgramado continuamente para que los empleados actúen según los protocolos marcados por la directiva.
No hablamos de diseñar y construir un puente.
Hay muchos tipos de trabajo. Y cada uno es responsable de sus acciones en este tipo de empresas (banco) que está todo registrado y encorsetado.
El mero hecho de tener un jefe no significa que sea responsable de la acción agrupada de todos los que están por debajo de él. Ni el hecho de no tenerlo tiene porqué hacer que la responsabilidad se diluya.
Cuando quitan los mandos intermedios es porque el control ya lo da un ente que se llama: sistema de gestión. Que es el que se adapta a todos los cambios legales de la empresa y es reporgramado continuamente para que los empleados actúen según los protocolos marcados por la directiva.
No hablamos de diseñar y construir un puente.
#30:
#14 hasta ahora el bancario se ponía también como ejemplo de donde no parece apropiado aplicar metodologías Agile.
Trabajo desarrollando para banca con metodologías Agile y aquí funciona bien. Pero es verdad que una metodología agile funciona si se aplica estrictamente en todos los sentido y se entiende bien la horizontalidad.
Me explico:
Los Product Owner y Scrum Master hacen las veces de jefes, quieras o no. Pero scrum te habilita a ti como 'currito' a decirle claramente a tu 'jefe' que la descripción que ha puesto de la tarea es pésima y tú no te puedes comprometer (commitment) con esa tarea y con una estimación correcta. Y eso significa que le acabas de echar atras a tu jefe su trabajo. Pero es a lo que me refiero con estrico y horizontal. O todos no comprometemos a ser Agile o falla estrepitosamente.
La primera vez que le dices a tu jefe, 'vuelve a definir esa historia' es raro pero una vez él se da cuenta que dedicando 15 minutos más a dejar todo atado nos facilíta enormemente la vida y hace que se cumplan plazo y estimaciones.
Es un cambio de mentalidad pero bien hecho es muy eficiente. Y ya el tema de transversabilidad y multidisciplinaridad ya lo tratamos otro día que me he cansado
Trabajo desarrollando para banca con metodologías Agile y aquí funciona bien. Pero es verdad que una metodología agile funciona si se aplica estrictamente en todos los sentido y se entiende bien la horizontalidad.
Me explico:
Los Product Owner y Scrum Master hacen las veces de jefes, quieras o no. Pero scrum te habilita a ti como 'currito' a decirle claramente a tu 'jefe' que la descripción que ha puesto de la tarea es pésima y tú no te puedes comprometer (commitment) con esa tarea y con una estimación correcta. Y eso significa que le acabas de echar atras a tu jefe su trabajo. Pero es a lo que me refiero con estrico y horizontal. O todos no comprometemos a ser Agile o falla estrepitosamente.
La primera vez que le dices a tu jefe, 'vuelve a definir esa historia' es raro pero una vez él se da cuenta que dedicando 15 minutos más a dejar todo atado nos facilíta enormemente la vida y hace que se cumplan plazo y estimaciones.
Es un cambio de mentalidad pero bien hecho es muy eficiente. Y ya el tema de transversabilidad y multidisciplinaridad ya lo tratamos otro día que me he cansado
#59:
#22 Twyp se hizo en Holanda y la app española se ha hecho en España con los jefes españoles que son un puto dolor y siguen con la mentalidad caciquil de siempre. No quieren hacer nativo porque no se quien les contó que era mejor no hacerlo así.
De hecho la app holandesa es muy distinta a la española y funciona muy bien. Lo se de primera mano porque he trabajado en varios bancos holandeses haciendo las apps
De hecho la app holandesa es muy distinta a la española y funciona muy bien. Lo se de primera mano porque he trabajado en varios bancos holandeses haciendo las apps
#1:
Mucha jerga molona corporativa, pero esto huele a leguas que no es nada más que una forma para descargar la responsabilidad en los curritos y no tener que pagar mandos intermedios...
#58:
#28 Lo que describes no es un jefe intermedio, eso es un tío que no sabe ni cuál es su trabajo y a todas luces no vale para el puesto. Muy seguramente porque o bien lo han enchufado o bien lo ascendido porque era peor en lo que hacía y es un mal menor así y no podían echarle por diversas circustancias. He visto los dos casos.
#50:
#9 Sin saber muy bien que hace esa persona exactamente, puede no ser lo mismo.
No se si estas familiarizado con la metodologia agil scrum, pero uno de los roles en esa metodologia es la figura del scrum master*, el scrum master es una persona que se encarga de llevar el sprint que es un periodo de x semanas (normalmente 2 pero pueden ser mas o menos) donde a principio del sprint se establece un objetivo o mision para el sprint. En un sprint hay al menos 3 tipos de reuniones, el sprint planning que es donde se establecen los objetivos y se introducen las tareas en el sprint, el stand up diario que es cada dia a la misma hora donde cada persona del equipo dice que hizo ayer, que va a hacer hoy y si tiene algun bloqueo y por ultimo al final del sprint hay un retrospective donde se discute que ha ido bien en el sprint, que ha ido mal y que cosas se deben cambiar para el siguente. Adicionalmente hay una sesion de demos donde se muestra lo que se ha hecho en el sprint al resto de departamentos con el animo de recibir comentarios y ajustar lo que se tenga que ajustar. El scrum master es un poco el organizador de esto, es el que esta en contacto con otros departamentos para saber cuales son las prioridades, es el que se encarga de resolver los bloqueos en el caso de que un desarrollador este bloqueado por otro departamento, es el que facilita las reuniones, el que se asegura que no se extienden en el tiempo.
Como digo al principio del sprint se establece cual es el objetivo del mismo, yo como desarrollador no suelo tener mucho que decidir al respecto, otros departamentos (generalmente el de producto) son los encargados de saber que es prioritario para el producto, pero dentro de una funcionalidad el equipo de desarrollo es el encargado de decidir como se hacer, como se divide y como se implementa dicha funcionalidad y el tiempo que esa funcionalidad se va a llevar en desarrollar, no hay ningun jefe que me diga que tengo que hacer, como o cuando, el scrum master no es mi jefe ni mucho menos, yo puedo decirle al scrum master que algo no se puede hacer, que algo no se va a hacer en el tiempo esperado o que algo no se puede hacer en este momento y es el, el encargado de comunicarselo a otros departamentos para que actuen en consecuencia. No es un jefe, simplemente tiene una responsabilidad distinta a la mia, pero no esta sobre mi. Es en definitiva un coordinador pero sin el poder de imponer nada, solo de coordinar, porque no tiene el conocimiento necesario para decirle a un desarrollador como trabajar.
* Lo siendo por la terminologia en ingles, no se si hay equivalente en Español, yo todo esto lo he aprendido y lo uso en Reino Unido que es donde vivo y trabajo, no es por ser pedante.
No se si estas familiarizado con la metodologia agil scrum, pero uno de los roles en esa metodologia es la figura del scrum master*, el scrum master es una persona que se encarga de llevar el sprint que es un periodo de x semanas (normalmente 2 pero pueden ser mas o menos) donde a principio del sprint se establece un objetivo o mision para el sprint. En un sprint hay al menos 3 tipos de reuniones, el sprint planning que es donde se establecen los objetivos y se introducen las tareas en el sprint, el stand up diario que es cada dia a la misma hora donde cada persona del equipo dice que hizo ayer, que va a hacer hoy y si tiene algun bloqueo y por ultimo al final del sprint hay un retrospective donde se discute que ha ido bien en el sprint, que ha ido mal y que cosas se deben cambiar para el siguente. Adicionalmente hay una sesion de demos donde se muestra lo que se ha hecho en el sprint al resto de departamentos con el animo de recibir comentarios y ajustar lo que se tenga que ajustar. El scrum master es un poco el organizador de esto, es el que esta en contacto con otros departamentos para saber cuales son las prioridades, es el que se encarga de resolver los bloqueos en el caso de que un desarrollador este bloqueado por otro departamento, es el que facilita las reuniones, el que se asegura que no se extienden en el tiempo.
Como digo al principio del sprint se establece cual es el objetivo del mismo, yo como desarrollador no suelo tener mucho que decidir al respecto, otros departamentos (generalmente el de producto) son los encargados de saber que es prioritario para el producto, pero dentro de una funcionalidad el equipo de desarrollo es el encargado de decidir como se hacer, como se divide y como se implementa dicha funcionalidad y el tiempo que esa funcionalidad se va a llevar en desarrollar, no hay ningun jefe que me diga que tengo que hacer, como o cuando, el scrum master no es mi jefe ni mucho menos, yo puedo decirle al scrum master que algo no se puede hacer, que algo no se va a hacer en el tiempo esperado o que algo no se puede hacer en este momento y es el, el encargado de comunicarselo a otros departamentos para que actuen en consecuencia. No es un jefe, simplemente tiene una responsabilidad distinta a la mia, pero no esta sobre mi. Es en definitiva un coordinador pero sin el poder de imponer nada, solo de coordinar, porque no tiene el conocimiento necesario para decirle a un desarrollador como trabajar.
* Lo siendo por la terminologia en ingles, no se si hay equivalente en Español, yo todo esto lo he aprendido y lo uso en Reino Unido que es donde vivo y trabajo, no es por ser pedante.
#9:
"no es un jefe como tal. “Distribuye el trabajo y, sobre todo, prioriza, para saber qué carga de trabajo tiene cada uno”, "
Eso es exactamente lo que hace un jefe, lo puedes llamar coordinador, responsable o como quieras... alguien que dice quién hace qué y cuándo, es el jefe.
Eso es exactamente lo que hace un jefe, lo puedes llamar coordinador, responsable o como quieras... alguien que dice quién hace qué y cuándo, es el jefe.
#5:
Es genial. Así les paga a todos la misma mierda y se acaban los malos rollos para ascender: ¡¡NADIE VA A HACERLO!!
Comentarios
Creo que ninguno de los comentarios anteriores es de alguien que trabaje en el dector tecnológico... esto no es palabrería, es una metodología, se usa mucho y funciona.
#7 Bueno, si y no. Por cada sitio que la aplica correctamente hay 100 que dicen ser agile pero es mentira cochina. Yo curro en uno de esos 100. Dicen que somos ágiles porque tenemos un scrum meeting por la mñn
#13 A que despues de esa reunión agilmente vas a hacerte un cafe?
#43 De hecho voy dando volteretas por el pasillo hasta la maquina de cafe
#43 No, la agilidad le viene después para ir al baño por haberse tomado el "cafe" de maquina...
#43 Eso no exime aplicar un sistema de trabajo Agile.
Yo hago stand diarias y luego desayuno y no hay ningún problema con ello. Lo importante es mantener un sistema de Sprint realistas, tener una buena gestión de grupos de trabajo, de manejo de feedback y delimitar lo más claramente posible como se centraliza la información y que canales se habilitan y para qué.
Hace ya años que trabajo así y no lo cambio por nada y te aseguro que los clientes tampoco.
#13 La mayoría de empresas se unen a lo "nuevo" sin poner suficiente empeño en que funcione. Es lo mismo que pasa con las herramientas de trabajo.
#13 Tres semanas duró el scrum en una empresa que estuve.
- ¿Fulanito, has terminado tal formulario?
- No, porque los DBAs no me crearon las tablas en oracle.
- ¿Por qué no creasteis las tablas, DBAs?
- Porque nos llegó la urgencia de ....
y así todo.
#81 Si hubo un stopper, Fulanito debería haber cogido la siguiente tarea de la pila mientras se resolvía...
#7 Agile es, efectivamente, una metodología, un nombre propio, pero la gente que no tiene conocimientos en ese campo (como el periodista del artículo) es normal que lo confunda con ser ágil como adjetivo (algo así como te digan que en tal empresa van a cambiar los coches ejecutivos por ford mustang y haya quien diga que los caballos consumen mucho heno y contaminan con sus heces). Lo de "sin jefes", obviamente viene de haber echado un ojo a la wiki y oír campanas sin saber muy bien por donde suenan, en Agile también hay jefes, directivos, juniors, gente que cobra más y gente que cobra menos...
Por otro lado, Agile es una metodología que funciona muy bien para algunos entornos, como desarrollar para spotify, pero que se adapta con dificultad a otros, donde la transversalidad, por motivos de seguridad, validaciones y demás, no es factible de manera realista.
No es el mejor sistema para construir software médico, militar y vaya, hasta ahora el bancario se ponía también como ejemplo de donde no parece apropiado aplicar metodologías Agile.
Quizás ING demuestre que sí es posible, y eficiente, muchas veces el progreso se da cuando alguien demuestra que lo que los demás decían que no se podía, sí se puede... Pero tampoco hay que olvidar que muchas, muchas otras veces, la realidad es que no se podía así, y el intento se hostia.
La otra posibilidad es que sea solo una pose, igual que cuando su CEO dijo lo de "no somos una empresa de banca, somos una empresa de tecnología que casualmente tiene una licencia de banca", que lo de Agile sea solo una capita por encima, que se limite al frontend más pinturero de su web, pero que, como todo banco, siga teniendo más yayos kobold-eros que devops de golang...
En un par de años se ve.
#14 Quizás ING demuestre que sí es posible, y eficiente
Como usuario de su app, no van por el buen camino. En cambio la de Twyp sí está currada.
#22 Twyp se hizo en Holanda y la app española se ha hecho en España con los jefes españoles que son un puto dolor y siguen con la mentalidad caciquil de siempre. No quieren hacer nativo porque no se quien les contó que era mejor no hacerlo así.
De hecho la app holandesa es muy distinta a la española y funciona muy bien. Lo se de primera mano porque he trabajado en varios bancos holandeses haciendo las apps
#59 ¿Como que no quieren hacer nativo? O sea que para la aplicacion española han contratado una consultoria española para el desarrollo?
#79 Si lo ha hecho una consultora española entonces habrán trabajado varias en esa app
#79 #103 ING España e ING Holanda no son la misma empresa. ING España tiene directivos Españoles y funciona como cualquier empresa española, no holandesa. No trabajan con consultora, tienen desarrolladores in house. Pero aun así la forma de trabajar no deja de ser la española de que hay un jefecillo que dice lo que hay que hacer esté bien o mal y los demás a callar y hacerlo. La forma de trabajar en Holanda es MUY diferente. Y vamos lo conozco bien porque llevo 8 años trabajando en fintech en Holanda y otros tantos en España antes
#22 Es mas fácil domar a un perro que a un elefante.
#22 Desde que twyp se desarrolla en España (fusionandose con twyp cash) es una auténtica mierda gestionada por jefes impresentables que no tienen ni puta idea de Agile ni les interesa y que solamente quieren ponerse la pegatina de Agile a cualquier precio. Menuda banda.
#14 hasta ahora el bancario se ponía también como ejemplo de donde no parece apropiado aplicar metodologías Agile.
Trabajo desarrollando para banca con metodologías Agile y aquí funciona bien. Pero es verdad que una metodología agile funciona si se aplica estrictamente en todos los sentido y se entiende bien la horizontalidad.
Me explico:
Los Product Owner y Scrum Master hacen las veces de jefes, quieras o no. Pero scrum te habilita a ti como 'currito' a decirle claramente a tu 'jefe' que la descripción que ha puesto de la tarea es pésima y tú no te puedes comprometer (commitment) con esa tarea y con una estimación correcta. Y eso significa que le acabas de echar atras a tu jefe su trabajo. Pero es a lo que me refiero con estrico y horizontal. O todos no comprometemos a ser Agile o falla estrepitosamente.
La primera vez que le dices a tu jefe, 'vuelve a definir esa historia' es raro pero una vez él se da cuenta que dedicando 15 minutos más a dejar todo atado nos facilíta enormemente la vida y hace que se cumplan plazo y estimaciones.
Es un cambio de mentalidad pero bien hecho es muy eficiente. Y ya el tema de transversabilidad y multidisciplinaridad ya lo tratamos otro día que me he cansado
#30 ING no pretende implantar Agile en su desarrollo de SW (donde me parecería viable y hasta oportuno, al menos en zonas concretas de ese SW, como decía antes), sino en TODA su estructura, toda, toda su "banca", y vaya, ahí se me antoja notabilísimamente más complejo.
Soy razonablemente escéptico al respecto, porque algo de como se curra en banca se, pero tengo expectativas y conozco gente dentro de ING, si lo logran de verdad, será todo un hito, y se convertirían en un referente importantísimo, en ese aspecto, para muchas otras empresas grandes, de esas en las que "es impensable".
#30 Bueno, si y no. Lo de mandar a tomar por culo los requisitos que te han escrito en una servilleta de bar y les ha sobrado espacio es tan viejo como el desarrollo de... cualquier cosa. Vamos, seguro en la edad del bronce un herrero ya lo hizo con un guerrero que le pidió "una espada" sin especificar si la quería de una mano, de mano y media o de dos
Vale que agile lo formaliza un poco y queda menos violento, pero vamos, es la misma mierda de siempre. La verdadera ventaja de agile esta en fijar objetivos concretos a corto plazo de forma que tras cada sprint tengas un progreso real en el desarrollo del producto. Y en involucrar al cliente/jefe (product owner) en el desarrollo para evitar lo de "te mando los requisitos (de mierda) y no me vuelves a ver hasta 6 meses después cuando me quejo que lo que has hecho no es lo que yo quería".
Y precisamente es la mentalidad de involucrar al cliente en el día a día del desarrollo lo que cuesta infinito cambiar.
La transversalidad y currar en squads efectivamente es otro tema (relacionado, pero otro tema).
#30 Una de las mejoras del teletrabajo fue que los jefes de proyecto dejaron de contarme los cambios al verme por los pasillos, y tuvieron que mandarme las peticiones por email / tareas internas.
#30 Totalmente de acuerdo. En mi empresa ha supuesto un gran cambio para mejor, lo único que no estamos siendo capaces de de solucionar es el tema de las interdependencias entre equipos, como estemos pendientes de que otro equipo termine una funcionalidad para poder nosotros terminar la nuestra acabamos jodidos cada sprint y rechazando stories a troche y moche, como los PO de cada equipo no se coordinen bien para establecer prioridades es el caos.
#14 en ING y en otros bancos holandeses se lleva haciendo así desde hace años. Lo que ING ha hecho ha sido cargarse a todos sus mandos intermedios que entorpecían esto. Y funciona muy bien al menos en la mentalidad de aquí (Holanda). En España no funcionará a no ser que cambien de mentalidad
#60 100% de acuerdo.
Agile no deja mucho margen al pasteleo, algo que choca de frente con la mentalidad latina en general (Fr, It, y mediterráneos).
En la cultura holandesa por contra es prácticamente intuitivo.
#75 No se cómo es en otros sitios, pero en España tenemos una estructura muy piramidal para trabajar y en Holanda es en general muy horizontal. Y la metodología agile funciona muy bien con jerarquías horizontales como bien dices. Aparte TODOS tienen que poner de su parte para colaborar, que eso tb es muy de mentalidad holandesa. En España somos más de "tu haces lo que yo te diga y a callar que para eso soy tu jefe/el que paga"
#14 efectivamente. Un buen ejemplo es en el sector eléctrico, donde hay sitios donde hay un único departamento de ingeniería para especificación de requisitos. Vete tú a decirles que vas a montar un sistema de control de una subestación eléctrica usando Agile...
#14 Nosotros empleamos LESS en automotive. Y funciona. Y por funciona me refiero a que los proyectos salen adelante.
#14 No es el mejor sistema para construir software médico, militar y vaya, hasta ahora el bancario se ponía también como ejemplo de donde no parece apropiado aplicar metodologías Agile.
No entiendo muy bien la primera parte de la frase...
Es decir, ING no es una empresa que "construya software bancario", es un banco!!
Aunque tampoco puedo negar de forma categórica que algún departamento de ING desarrolle aplicaciones para la empresa, porque no lo se.
Y en cuanto a la aplicación de la metodología "Agile" en el sector bancario... no se si a este banco le irá bien o solo adoptarán aquello que les vaya bien o acabarán regresando al método anterior. Lo que si se es que el método anterior, en lo que se refiere a la interacción con los usuarios, ya era bastante diferente a lo que yo he conocido. Y quizá una de las diferencias esté en la parte en la que llevan años "enseñando" a los clientes a relacionarse con su banco, de otra forma; algo que al ser un banco online con muy pocas oficinas "tradicionales", no tuvieron más remedio que acometer.
Pero supongo que eso ya lo sabes.
#7 Cállate que les jodes el discurso, y si funciona mucho peor aún ya que no tendrían nada de lo que quejarse y les explotaría la cabeza
#7 Me imagino que, como con cualquier idea o método, se podrán hacer implantaciones desastrosas pero me da la impresión de que hay un montón de buenas ideas en ese método de organización y que, a poco que se le ponga un poco de inteligencia a la implantación, puede terminar mejorando mucho el funcionamiento de muchas organizaciones, sobre todo medianas y grandes.
#7 citando a una amiga mía: agile no es waterfall con sprints.
#7 Si y solo si interiorizas la filosofía y no te enfocas solo en los procesos y herramientas.
#7 Pues a ver si tu lo explicas mejor, porque el artículo no me aclara mucho...
Si la gente se organiza en squads (cada una con un jefe) y los squads se organizan en tribus (tambien cada una con un jefe), exactamente como es eso de no tener jefes?
Entiendo que no tienes departamenteos especializados, tienes equipos multidisciplinares, lo que me parece una buena idea, pero tampoco es especialmente original, sinceramente no veo lo revolucionario
#99 Porque ni el PO ni el scrummaster son jefes. El PO se limita a traer al equipo lo que es importante para el negocio y el scrummaster a resolver problemas no técnicos, pero ninguno de los dos puede dar órdenes ni imponer que es lo próximo que se hace ni amenazar a una persona/todo el equipo para que se trabaje más rápido.
#7 cierto, y es un banco muy digitalizado, tiene sentido.
#7 Pero sí de los posteriores y funcionará pero también hace mucho daño en depende qué departamentos, por ejemplo sistemas, conviertes el departamento en un sistema apagafuegos
goto #32
y sí yo, he estudiado Agile y lo usan los de desarrollo de mi curro, como menciono en mi anterior comentario nosotros los llamamos francotiradores y no desarrollan proyectos, los traman no se dan cuenta que estamos en un banco y la improvisación y la agilidad sin tener en cuenta leyes y factores externos (que requiere mucho tiempo analizar, cosa que no se hace en Agile) se riñe completamente con la metodología de un banco precisamente.
Para librarse de jefes no hace falta usar Agile, eso está metido a calzador y no es la causa, con Agile puedes tener jefes o no tenerlos al igual que con otras metodologías
Mucha jerga molona corporativa, pero esto huele a leguas que no es nada más que una forma para descargar la responsabilidad en los curritos y no tener que pagar mandos intermedios...
#1 Si, es eso ¿y?
Si hay jefes intermedios protestamos. Si no hay protestamos.
Otro caso de estudio es el uso de la palabra curritos...
#2 Yo no protesto por que haya jefes intermedios, son muy necesarios. Una cosa esta clara la responsabilidad se paga.
Líder, responsable, o cualquier denominación sin tener la categoría correspondiente es un timo para los empleados.
#3 Pero la responsabilidad de ¿qué?
Hay muchos tipos de trabajo. Y cada uno es responsable de sus acciones en este tipo de empresas (banco) que está todo registrado y encorsetado.
El mero hecho de tener un jefe no significa que sea responsable de la acción agrupada de todos los que están por debajo de él. Ni el hecho de no tenerlo tiene porqué hacer que la responsabilidad se diluya.
Cuando quitan los mandos intermedios es porque el control ya lo da un ente que se llama: sistema de gestión. Que es el que se adapta a todos los cambios legales de la empresa y es reporgramado continuamente para que los empleados actúen según los protocolos marcados por la directiva.
No hablamos de diseñar y construir un puente.
#6 Cuando quitan los mandos intermedios es porque el control ya lo da un ente que se llama: sistema de gestión
Esto suena a que cuando hay algún problema la culpa es del sistema y/o del departamento de TI, nadie toma responsabilidad de los fallos humanos, que haberlos, haylos...
No hablamos de diseñar y construir un puente
No, hablamos de gestionar el dinero y activos de los ciudadanos... cosa que me parece tan seria como diseñar y construir cualquier tipo de obra de ingeniería.
#11 bueno, cuando hay un jefe intermedio lo que suele ocurrir es que es un tío al que le pagan para señalar quien es el culpable de entre los "curritos" de su departamento... ahora ocurrirá lo mismo, pero sin pagar a alguien para que señale.
#28 Lo que describes no es un jefe intermedio, eso es un tío que no sabe ni cuál es su trabajo y a todas luces no vale para el puesto. Muy seguramente porque o bien lo han enchufado o bien lo ascendido porque era peor en lo que hacía y es un mal menor así y no podían echarle por diversas circustancias. He visto los dos casos.
#58 Mis dieses...
#58 esos son los casos que me refería, no estoy negando que haya jefes en empresas serias que sí cometan su función, como han pensado #70 , #73 y #117
#28 Tú nunca has sido jefe...
#28 Un jefe intermedio se encarga de repartir el trabajo y supervisar el resultado de los empleados a su cargo. Que habrá sitios donde baste un tipo que se asoma para mirar de vez en cuando, pero también hay muchos donde su trabajo es imprescindible.
A mí, por ejemplo, me encargan pequeñas tareas que hago sin tener una visión total del problema. Mi jefe sí la tiene y es quien se encarga de que decirme exactamente lo que se me pide, sin necesidad de que yo conozca todo lo demás.
#73 ¡Buena explicación!
#73 A mí lo que me parece es que en muchos casos esa labor de supervisión, control y reporte no es una labor que suponga un 100% de dedicación, yo como jefe de equipo le dedicaba quizás un 30% y era una tárea imprescindible en eso estoy totalmente de acuerdo. Pero el resto del tiempo estaba picando como uno más. Siempre me preguntaba que narices hacían mis compañeros el resto del tiempo en sus equipos. Sacar un par de reportes de JIRA y hablar con la gente para ver cómo va el tema no te lleva 8 horas.
#73 y no te gustaría saber de qué va el conjunto de lo que hay que hacer y poder colaborar con tus aportaciones de una manera activa?
#28 Me parece que solo has visto charcuterías y no empresas serias...
#11 Y ahora quien toma la "responsabilidad" y de qué forma?
Ponme un caso real de asunción de esa "tremenda responsabilidad" que merece un generoso salario....
#6 "Cuando quitan los mandos intermedios es porque el control ya lo da un ente que se llama: sistema de gestión"
Ahí has patinado y mucho, supongo que por desconocimiento.
#6 Algunos no se que entienden por "responsabilidad"....
#3 te acabas de leer un arrículo que explica porque los MI no son necesarios para justo a continucion decir que se necesitan 😳 . ¡No se necesitan!
#2 ¿Quien protesta de que haya mandos intermedios?, si son precisamente esos los que más responsabilidad, presión y estrés tienen para que la empresa funcione.
PD: Ahí no entran los de lo público
#19 la mejor matización que se podía hacer, porque aún está por ver a un jefe responsable por: el accidente de angrois, el del metro de Valencia, los sobrecostes de las chorrocientas obras públicas, y un largo ETC.
En la empresa privada dependiendo del mamoneo también pasa.
#42 Evidentemente tampoco me refiero a los que tienen el puesto por ser familia de... al final esos tienen a otro al lado que es el que hace que las cosas funcionen.
#19 #42 Anda que no hay funcionarios desfilando por los juzgados por informes. Y ahora porque el urbanismo ha muerto, pero en 2008-2010 era raro no pasar a declarar por alguna licencia de obras al menos una vez año.
Y tb está el tribunal de cuentas, que no solo sirve para acojonar a Mas.
#19 En ciertos sectores hay bastante debate sobre la idea de "flat organization" ( https://en.wikipedia.org/wiki/Flat_organization ). Uno de los ejemplos más conocidos es Valve (una empresa líder en videojuegos), con un modelo "sin jefes" que da autonomía a individuos y equipos para autogestionarse. En su manual de empleado lo explican de forma muy ilustrativa (mencionando que no es un modelo que necesariamente sea el mejor para cualquier caso o tipo de persona): https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployeeHandbook.pdf
Otro caso distinto es el de Github que empezó con una organización plana y acabó introduciendo mandos intermedios ( https://github.com/holman/ama/issues/800 )
#2 A qué te refieres con lo de currito? El significado que creo que le da la gente es: Neo-esclavo cuya vida ha sido en un principio dirigida hacia convertirse en un esclavo apto. Después, ya como esclavo en activo, a generar plusvalía para aumentar aún más el dominio del sistema depredador imperante.
A lo mejor otras personas lo usan distinto, pero por el momento esa es la impresión que tengo de su uso.
#2 Se trataba de que los jefes intermedios hicieran bien su trabajo, no de que los hiciérais desaparecer.
#2 los jefes intermedios no desaparecen, solo se adaptan a la nueva forma de trabajar. Siguen existiendo y siguen teniendo las mismas responsabilidades, aunque algunas las comparte con el resto del equipo
#1 Es que si que hay jefes intermedios, solo les han cambiado el nombre:
Esto no significa que no haya responsables. Cada ‘squad’ cuenta con un ‘product owner’ (PO, en la jerga ‘agilista’), que es el encargado de decidir el orden de las tareas, aunque no es un jefe como tal. “Distribuye el trabajo y, sobre todo, prioriza, para saber qué carga de trabajo tiene cada uno”, asegura Sarasola.
Vamos, dice lo que tiene que hacer cada uno y es el responsable de ese equipo, lo que viene a ser un jefe.
CC #2
#95 Ese cambio de nombre muchas veces significa que eres "jefe" de nombre pero sin la categoría (y muchas veces sin el aumento salarial que corresponde)
#95 Perdona pero no. El PO no es el jefe del squad. Ni mucho menos. El PO se encarga del orden de las tareas. Pero el resto del equipo se encarga de estimarlas, planificar como hacerlas y por supuesto, hacerlas. Y créeme que en un Planning es una negociación de iguales entre el PO y el equipo. En mi equipo podemos perfectamente decidir no hacer una tarea si no cumple la definición de Ready y el PO puede decir misa que no se hace.
#2 Pues anda que el becario que ha redactado el publireportaje, con tanto empoderamiento...
#2 La jefatura intermedia no es mala, la mala es la jefatura intermedia que solo sabe reenviar correos y exigir excels a los demás. Esos son los que sobran. A mi me encanta tener un jefe intermedio que me gestione los acessos, las peticiones, las luchas con otros desarrollos, etc, y asi poderme centrar en el desarrollo. ¿Que ha pasado con las metodologías agiles? Pues no sé como será e ING, pero en el banco que estoy yo lo que han hecho ha sido relegar todo el trabajo de secretaria y de gestión a los tecnicos. Entonces nos pasamos mas tiempo haciendo de secretarias que desarrollando. Y de Agile cogen lo que quieren, el nombre de las reuniones y poco más. Luego te encuentras plazos inviolables, documentación necesaria sin hacer y la poca hecha son excels estupidos para jefes que no te ayudan en nada al desarrollo y presupuestos totalmente cerrados. Se han ido varias personas y no se ha movido un solo plazo.
Agile bien implementado es una maravilla, si el equipo está preparado para ello. Porque no todos los estan. Tengo muchisimos compañeros ultradependientes, lo que se habla en las reuniones funcionales quien va no lo transmite a los demas, etc. Aquí son muy dados a poner un tío que sabe con 5 que no tienen ni puta idea. Los 5 no son independientes y entonces al unico que lo es no le dejan trabajar porque tienen que estar consultadolo todo. Eso no se puede hacer en un equipo Agile.
#1 joder espero que no seas tan rancio como tus comentarios y que tan sólo tengas un mal día.
Un abrazo!
#12 No, soy incluso más rancio en la realidad, aquí me modero
#1 bueno si está compensado económicamente lo veo hasta bueno
#16 Jajajajajajajajajaja
Seguro que lo compensan con sueldo emocional.
#16 Iluso, habla de muchas cosas, pero de subir sueldo nada, más responsabilidad, más curro pero dd pasta nada. Por otro lado, puedes poner en LinkedIn cosa muy chulas, con palabros nuevos y ya con eso estás apañado.
#39 No te olvidesla parte en la que dice que hay que entregar algo de valor cada 15 dias, lo que implica bastante más presión...
#65 Y si no parte de la nómina
#1 Los curritos ya se comen la responsabilidad. Ahora simplemente no se pagan innecesarios jefes intermedios.
#1 Esperemos que no leas libros oliendo. Échate un ojo al concepto Agile/Lean. Origenes inspirados en TPS
https://es.wikipedia.org/wiki/Sistema_de_producci%C3%B3n_Toyota
#94 Si si, en papel muy bonito pero pasa tú por las empresas japonesas y veras lo que es la "eficiencia".
A parte que estas comparando un sistema de producción que muchas veces no es aplicable a otros sectores que no sean industriales.
#1 Lo entendemos muy bien , una jerga de la que tu entiendes nada y vas a emitir tus prejuicios en base a tu ignorancia.
#1 En mi empresa no tenemos mandos intermedios y aunque a veces se dan situaciones no deseadas, prefiero este modelo.
Además las empresas nos da las herramientas para solucionar nosotros mismos los problemas y los conflictos.
#1 Hasta que con su supermorro coloquen a su hijo o mujer o cualquier persona afin.
#1 Yo he trabajado con metodologías similares, pero en equipos de desarrollo y si es un cambio sustancial en la forma de trabajar, no son solo nombres molones.
El problema que le veo al aplicarlo a la estructura global de una empresa es el de cubrir ciertos puestos cuando hay una baja o se marcha un miembro del equipo. En programación es más simple porque se promueve que todo el mundo pueda hacer todo (o al menos que haya más de uno que pueda sustituirlo). En este caso por ejemplo si tienen una persona de marketing o un experto en temas legales por squad y se "cae", el trabajo del resto del equipo se resentiría mucho hasta que lo sustituyesen.
#1 El título es sensacionalista, porque utilizar la metodología agile no significa no tener jefes. El que representa las necesidades del negocio es el product owner, que a su vez, por encima suele tener un jefe que sí le pone presión directa para priorizar.
El problema del agile es que si en la priorización de tareas se tiene demasiado en cuenta la parte de negocio y pierde fuerza criterios que requieren de conocimientod mas técnicos como arquitectura, seguridad,... a la larga puedes tener problemas gordos (escalabilidad, mantenibilidad, seguridad)..
La parte positiva es que durante el sprint no tienes interrupciones continuas de un jefe (o no debería). (a eso se refieren supongo cuando hablan de la figura de jefe, a la persona que te está pidiendo cosas continuamente).
"no es un jefe como tal. “Distribuye el trabajo y, sobre todo, prioriza, para saber qué carga de trabajo tiene cada uno”, "
Eso es exactamente lo que hace un jefe, lo puedes llamar coordinador, responsable o como quieras... alguien que dice quién hace qué y cuándo, es el jefe.
#9 es que queda más molón llamarlo "lider" o "scrum master"
#9 Pues ahora todos seran jefes, como cuando los comerciales pasan a ser "director comercial de esta zona".
#9 Hay una gran diferencia.
El jefe distribuye el trabajo ordenando a los empleados que lo hagan, causandose problemas si alguien no acepta la orden. La "distribución" del PO es presentarlo a los equipos y ya decidirán ellos lo que se puede hacer.
#9 Sin saber muy bien que hace esa persona exactamente, puede no ser lo mismo.
No se si estas familiarizado con la metodologia agil scrum, pero uno de los roles en esa metodologia es la figura del scrum master*, el scrum master es una persona que se encarga de llevar el sprint que es un periodo de x semanas (normalmente 2 pero pueden ser mas o menos) donde a principio del sprint se establece un objetivo o mision para el sprint. En un sprint hay al menos 3 tipos de reuniones, el sprint planning que es donde se establecen los objetivos y se introducen las tareas en el sprint, el stand up diario que es cada dia a la misma hora donde cada persona del equipo dice que hizo ayer, que va a hacer hoy y si tiene algun bloqueo y por ultimo al final del sprint hay un retrospective donde se discute que ha ido bien en el sprint, que ha ido mal y que cosas se deben cambiar para el siguente. Adicionalmente hay una sesion de demos donde se muestra lo que se ha hecho en el sprint al resto de departamentos con el animo de recibir comentarios y ajustar lo que se tenga que ajustar. El scrum master es un poco el organizador de esto, es el que esta en contacto con otros departamentos para saber cuales son las prioridades, es el que se encarga de resolver los bloqueos en el caso de que un desarrollador este bloqueado por otro departamento, es el que facilita las reuniones, el que se asegura que no se extienden en el tiempo.
Como digo al principio del sprint se establece cual es el objetivo del mismo, yo como desarrollador no suelo tener mucho que decidir al respecto, otros departamentos (generalmente el de producto) son los encargados de saber que es prioritario para el producto, pero dentro de una funcionalidad el equipo de desarrollo es el encargado de decidir como se hacer, como se divide y como se implementa dicha funcionalidad y el tiempo que esa funcionalidad se va a llevar en desarrollar, no hay ningun jefe que me diga que tengo que hacer, como o cuando, el scrum master no es mi jefe ni mucho menos, yo puedo decirle al scrum master que algo no se puede hacer, que algo no se va a hacer en el tiempo esperado o que algo no se puede hacer en este momento y es el, el encargado de comunicarselo a otros departamentos para que actuen en consecuencia. No es un jefe, simplemente tiene una responsabilidad distinta a la mia, pero no esta sobre mi. Es en definitiva un coordinador pero sin el poder de imponer nada, solo de coordinar, porque no tiene el conocimiento necesario para decirle a un desarrollador como trabajar.
* Lo siendo por la terminologia en ingles, no se si hay equivalente en Español, yo todo esto lo he aprendido y lo uso en Reino Unido que es donde vivo y trabajo, no es por ser pedante.
#50 por fin me he enterao de qué es el scrum
#c-9" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3045210/order/9">#9 Es que eso no es así si esta bien implementado.
Haciéndolo correctamente el PO solo prioriza, luego es el equipo el que decide cuanto trabajo puede acometer de lo que hay en la lista para las siguientes dos semanas y cada persona se autoasigna trabajo según va quedando libre.
Es decir que en este caso solo diría que hay que hacer y cual es la prioridad de cada tarea.
Mas allá de eso es el equipo el que decide quién hace qué.
24# si, pero sigue sin ser un jefe, un scrum master solo facilita el trabajo y indica al equipo las prioridades. No tiene la autoridad que se puede esperar de un jefe.
#9 Lo llamas "el más igual entre iguales" y ya no es un jefe (aunque decida qué haces, tenga más responsabilidad, y cobre más por ello)
#9 No funciona asi. Antes de cada spring se hace una reunión previa.
El project owner dice las prioridades, pero los integrantes del grupo dicen lo que van a hacer.
Es decir se divide todo en tareas. Los componentes del grupo deciden entre todos la dificultad de cada tarea se le da un valor de puntos a cada tarea. Y según el tamaño del grupo y su experiencia dicen este sprint va a ser de 20 puntos por ejemplo-
Cada persona del grupo coge las tareas que cree que va a poder hacer hasta sumar esos 20 puntos entre todos entre las que ha priorizado el owner scrum y el resto de tareas se dejan para el siguiente spring.
Es genial. Así les paga a todos la misma mierda y se acaban los malos rollos para ascender: ¡¡NADIE VA A HACERLO!!
#5 ascender dice... tú debes ser nuevo por aquí.
ING está cayendo en imagen. Y no me extraña sólo hay que ver lo que está pasando con sus SIN comisiones. Antes operar una acción era un 0.25% sin comisiones, luego le pusieron un coste mínimo de 8 euros y ahora ya van por un mínimo de 20€ de comisión, sin poner esa palabra por ningún lado por supuesto
#18 Antes operar una acción...
Creo que no entiendo a que te refieres.
"metodologías ágiles en la totalidad de la estructura." Carlos Marx lo llamó comunismo o algo así
#4 No compares esa basura con el comunismo
#10 No compares las metodologías ágiles con esa basura.
#17 A quien no asistía le daban un pioletazo.
#4 Sí, recuerdo a Stalin y el politburó haciendo la reunión diaria de Scrum
#17 Stalin fue el primer Scrum Master?
#21 El inventor de los purge sprints
#21 Más bien el Product Owner, no?
#21 el resultado de las retrospectivas era siempre el mismo: Al gulag.
#17 Nadie a dicho que Stalin siguiese a rajatabla los postulados y teorias de Marx... porque una cosa es el Stalinismo y otra el Marxismo... es fácil mezclar todo en uno para la manipulacion en los medios y la derecha...
#37 Yo tampoco he dicho que lo hiciese
#17 Que grandes juegos nos dio Scrum.
#17 y no solo stalin, Hitler evaluó el tiempo que le costaría invadir Rusia con los generales echando las cartitas esas
#55 O la maravillosa secuencia de Fibonacci.
#17 En los gulajs hacían kanban.
#17 Típico comentario demagogo. Si es por igno-rancia o por intoxicar no lo sé y no me importa, pero no deja de ser mentira.
#77
#4 Dice que los squads son grupos de trabajo empoderados, se les empodera hasta cierto punto. La totalidad de la empresa se refiere a la parte que trabaja, no a la que recibe rentas del capital.
En mi empresa también hemos aplicado metodología agile en todo la jerarquía. También salió en prensa (la compañía in jefes). Mentira cochina, sigue habiendo jefes categoría y jerarquía, eso sí con post it de colorines.
#68 Es lo que hacen prácticamente todas, añaden tableros y post-it de colores a su modo de funcionar de toda la vida, no pierde la poltrona ni el gato, aunque eso sí, pasan a ser más molones y guays.
" metodologías ágiles" en nuestro curro los llamamos francotiradores y no realizan proyectos, traman fechorías. Un día vamos a ir a tirarles de la pared todos los post-it sólo para ver como se sumen en la desesperación volviendo a intentar pegarlos ordenados, no son nada sin ellos
A ver como aplicas metodologías agiles a un entorno de sistemas sin convertirlo en un sistema "apaga fuegos", las metodologías ágiles van bien para equipos de desarrollo pero no para uno de sistemas.
Que me parece muy bien quitar a jefes pero se puede hacer usando otros sistemas y no esa burrada, es como usar queroseno para aliñar la ensalada
Y sí, yo también trabajo en un banco e incluso tuve entrevista con Ing hace unos años
#32 DevOps es lo que aplican para sistemas en mi empresa con Kanban boards. Y literalmente la peña de operaciones dice que está hasta la polla de saltar de un sitio a otro a arreglar mierdas por falta de planificación.
#69 Pues eso, que las metodologías ágiles están bien para lo que se deben aplicar pero para otros entornos no aplican bien
#74 Pero quedan tan bien para los de Marketing... La empresa sin jefes...
#32 La verdad es que me cuesta imaginar cómo se puede usar AGILE con garantías en algo que no sea desarrollo
Pues a mi me parece un planteamiento cojonudo. En vez de montar una jerarquía llena de jefes potencialmente inútiles en la que se favorece el trepismo y todo funciona de forma lenta e ineficaz, generas un entorno de trabajo en el que cada uno se siente valioso por lo que aporta al equipo, y no existe la posibilidad de que un mal líder bloquee por completo el avance del proyecto. Estoy harto de escuchar quejas de malos jefes que no valoran a sus empleados o que no ayudan a que el trabajo avance, generando frustración entre los trabajadores, que ni logran objetivos ni se ven valorados. Es cierto que puedes tener un buen jefe, pero gracias a métodos como este, no lo necesitas.
Además, esa gente que orienta su carrera profesional a "dirigir equipos"... es que es un puto chiste. Es gente que se aleja del lado técnico porque no quieren mancharse las manos, y que lo único que hacen es decirle a todo el mundo lo que tiene que hacer sin saber realmente en qué consiste esto (considerando la velocidad a la que cambia la tecnología, no puedes mantenerte al día si no estás en contacto con el problema).
#36 el PO es quien lidera. Hay un lider, el problema viene cuando se malinterpreta la """igualdad""" y el equipo se revela. Ya lo digo ojala les vaya bien.
y con la riqueza del idioma que usamos, tenemos que usar vocablos en otro idioma para expresar lo mismo, que suene más interesante o importante o rimbombante o lo que sea... si es que somos tontos.
"No hay un jefe pero cada ‘squad’ cuenta con un ‘product owner" ... que es el puto jefe.
#71 Luego puede haber además un "Scrum Master" que la mayoría de los sitios se convierte en otro jefe . Por encima de la Squad otro grupo, "Tribe" que engloban a varias Squad y ésta tiene un "Tribe Chief" (otro jefe)
.
Tambien otro grupo por encima, los "Release Train" con varias "Tribe" coordinadas por un "Release Train Engineer" (otro jefe) añádele "Agile Coach", "Counselor", "Partitioner", "Deputy" para todas las posiciones y otras tantas posiciones adicionales que se pueden sacar del sobaco (para algo es flexible) y sin tener que usar mucho la imaginación puedes casi casi mapearlo a la organización anterior
Y ahora se entiende porque ING cada vez funciona peor en todos los ambitos.
#33 Como? Eres usuario de ING y te va mal?
#45 Si, personal y de empresa. Lo de empresa es un desproposito. Plataforma caida, envios de cartas a direcciones antiguas dadas de baja, anulaciones de tarjetas sin motivo....
#52 Yo también soy usuario desde hace varios años y no he tenido problema, pero como todo, a lo mejor yo soy el caso aislado o a lo mejor eres tu. Tampoco se como es el trato con las empresas.
#45 En Hipotecas son los más lentos. Me lo dijo la de la inmobiliaria y luego lo comprobé con mis propios ojos. En el Santander corrían a que firmara, en Bankinter fueron más rápidos. En ING se me pasaban los plazos, los llame para decirles que lo necesitaba antes de una fecha... y ellos a su ritmo. No les importa perder ni hipotecas ni clientes con cuentas nomina.
Me jode porque si llego a hacer que iba a firmar con Bankinter, lo hubiera negociado mejor.
#33 A lo mejor han empezado a usar este metodo porque les iba mal de la forma traidicional.
Esto acaban de implementarlo.
Los que trabajamos en tecnología en empresas que no son dinosaurios chapados a la antigua ya hace tiempo que usamos éste tipo de tecnologías y nuestra vida es mucho mejor y la de la empresa también.
Sin ir más lejos el ejército estadounidense lleva décadas usando éste tipo de organizacion por squads, y son profesionales con distintas especializaciones que forman parte de un mismo equipo y que pueden realizar tareas de manera autónoma sin depender de ningun mando intermedio o comunicación externa para lograr sus objetivos.
Si divides tu gran objetivo en pequeñas tareas y asignas equipos multidisciplinares con perfiles especializados para llevar a cabo dichas tareas y les otorgas cierta autonomía, se reducen las congestiones burocráticas, las dependencias departamentales y la información fluye de manera mucho más ágil entre los implicados, sin hacer ruido en las personas que no estan implicadas en el proyecto.
#88 Sí la teoría está muy bien, y funciona, y yo lo he experimentado con éxito en equipos pequeños para proyecto determinados. Pero cuando esto se aplica a toda una organización, con cierta complejidad y muchas interaciones, los jefes no quieren soltar su control del día a día y de la burocracia interna (es su razón de existir en la empresa) así que al final se tiende a mapear y a volver a la estructura jerárquica de siempre. "Yo no soy tu jefe, soy el lider el inspirador" pero te mando igual que antes.
Siempre hay un jefe, otra cosa es que se eliminé el número de personas que pueden tomar decisiones sin consultar al resto.
En otras palabras: se cargan a los gestores, que son en la mayoría de los casos meros intermediarios entre empleado y objetivo.
Mis mejores trabajos son en los que no he tenido a un brasas detrás.
A ver si acaba su subcontratación de IndraBPO.
Tu jefe está en Holanda en lugar de en tu oficina
Pero mientras tanto trabajan con equipos de sobremesa anulando cualquier opción de teletrabajo
Esta peña iba en Patinete dentro de las oficinas en el año 2000. Y tenían Playstations en cubiculos supercuquis. Al final, toda esa mierda, no servia para nada. Los patinetes acabaron abandonados.
Va a ser la risa cuando tomen decisoones en comité, esas decisiones se alarguen meses y el mercado se los coma.
#47 Que mercado, el de los grandes dinosaurios?
#49 el mismo
Menos jefes y departamentos pero más subcontratados. Igual que el resto de banca, una vergüenza.
Verás que divertido ING en unos meses