Portada
mis comunidades
otras secciones
#1:
"además hemos procedido a pagarte todas las horas extra que has hecho ya que el mismo algoritmo ha confirmado que fuera de horario accedías también a esos sistemas".
No, eso no...
No, eso no...
#6:
"Los despidos afectaron principalmente a los empleados de base, no a los altos directivos, cuya eficiencia el CEO no cuestiona. Además, al analizar el desempeño de los empleados, no se tuvo en cuenta el tiempo dedicado a Git IDE."
No vamos a hurgar en lo que hace la dirección y altos cargos, no sea que se aprecie cómo se rascan los huevos.
Sólo apretamos hacia abajo, e ignorando tiempos que podrían joder nuestro cherry picking.
Anda y que les den...
No vamos a hurgar en lo que hace la dirección y altos cargos, no sea que se aprecie cómo se rascan los huevos.
Sólo apretamos hacia abajo, e ignorando tiempos que podrían joder nuestro cherry picking.
Anda y que les den...
#57:
#14 #19 Es un clásico. Yo sustituí a uno que se fue por esto, y por algo aún más surrealista.
- ¿Te quejas de que llego un cuarto de hora tarde? ¿Y las horas extras que he tenido que echar?
- Yo no te pedí que las echases.
Ni que decir tiene que o se echaban o la entrega no se hacía a tiempo. Lo que el palurdo del jefe no calculó es que este hombre no tardó ni un mes en darle "la carta".
- ¿Te quejas de que llego un cuarto de hora tarde? ¿Y las horas extras que he tenido que echar?
- Yo no te pedí que las echases.
Ni que decir tiene que o se echaban o la entrega no se hacía a tiempo. Lo que el palurdo del jefe no calculó es que este hombre no tardó ni un mes en darle "la carta".
#8:
Si para despedir desarrolladores "no se tuvo en cuenta el tiempo dedicado a Git/IDE" la métrica empleada es una putísima mierda, consideraciones éticas aparte.
#7:
Jira y Confluence como base para establecer si trabajas o no, ... para mear y no echar gota.
#72:
#63 Lo fue cuando unos meses después yo también me fui.
Por eso me río yo de estos "sistemas automáticos". Son un síntoma de empresas que no saben evaluar a sus empleados (ni a sí mismas, por supuesto).
Algún caso conozco de empresas que se pusieron a analizar también la rotación y las renuncias. Resultado: aflojaron las evaluaciones en general porque "no convenía levantar la alfombra".
Evaluar es muy difícil. Y si no se hace bien, el resultado es una catástrofe (para la empresa).
Por eso me río yo de estos "sistemas automáticos". Son un síntoma de empresas que no saben evaluar a sus empleados (ni a sí mismas, por supuesto).
Algún caso conozco de empresas que se pusieron a analizar también la rotación y las renuncias. Resultado: aflojaron las evaluaciones en general porque "no convenía levantar la alfombra".
Evaluar es muy difícil. Y si no se hace bien, el resultado es una catástrofe (para la empresa).
#82:
#1
- He visto que desde todo este año que llevas en la empresa te has dedicado todos los días a hacer tus 8 horas de rigor y ni una más, me preocupa que no estés comprometido con la empresa.
- ¿Cómo?Pero si me pagáis 8 horas, qué cojones voy a hacer más. ¿Dónde has visto eso?
- Pues fácil, en Jira has imputado 8 horas todos los días.
- Ah, no sabía que podía imputar todas las horas reales que hacía, pensaba que no podíamos registrarlas pues eso supondría que tendríais que pagarme horas extra.
- Sí, claro que se puede, ¿pero cómo se yo que has hecho horas de más?
- Bueno, pues hay un sistema de tornos a la entrada donde se registra cuando entramos y cuando salimos hasta para hacer una pausa y tomar un café gracias al cuál a algunos compañeros les amonestasteis por hacer horas de menos.
- Pero es que a ese sistema no podemos tener acceso, solamente nos llega un aviso cuando se hacen horas de menos, pero no podemos utilizarlo para ver cuántas horas ha estado cada uno.
- Ya...
- He visto que desde todo este año que llevas en la empresa te has dedicado todos los días a hacer tus 8 horas de rigor y ni una más, me preocupa que no estés comprometido con la empresa.
- ¿Cómo?
- Pues fácil, en Jira has imputado 8 horas todos los días.
- Ah, no sabía que podía imputar todas las horas reales que hacía, pensaba que no podíamos registrarlas pues eso supondría que tendríais que pagarme horas extra.
- Sí, claro que se puede, ¿pero cómo se yo que has hecho horas de más?
- Bueno, pues hay un sistema de tornos a la entrada donde se registra cuando entramos y cuando salimos hasta para hacer una pausa y tomar un café gracias al cuál a algunos compañeros les amonestasteis por hacer horas de menos.
- Pero es que a ese sistema no podemos tener acceso, solamente nos llega un aviso cuando se hacen horas de menos, pero no podemos utilizarlo para ver cuántas horas ha estado cada uno.
- Ya...
#21:
#11 Git es un software de gestión de versiones de código.
IDE es un nombre genérico para "entorno de programación" (Integrated Development Environment).
O sea, las dos herramientas que más usa un programador. Sin embargo les han medido el rendimiento comprobando el tiempo utilizado en herramientas de comunicación y de gestión de incidencias.
No tiene mucho sentido, en mi opinión.
IDE es un nombre genérico para "entorno de programación" (Integrated Development Environment).
O sea, las dos herramientas que más usa un programador. Sin embargo les han medido el rendimiento comprobando el tiempo utilizado en herramientas de comunicación y de gestión de incidencias.
No tiene mucho sentido, en mi opinión.
#49:
#8 Aquí el auténtico problema es el intentar cuantificar "el trabajo" de un programador como si fuera un obrero de fábrica sacando planchas de acero de una máquina herramienta, algo que se intenta desde hace décadas y que jamás ha funcionado ni funcionará. Básicamente porque escribir código suele ocupar la menor parte del tiempo de la jornada de trabajo de un programador.
Ahora con todas estas "herramientas online" se pretende, o más bien te quieren vender las empresas que las comercializan (Atlassian, GitHub...) que se puede medir si un programador "ha trabajado mucho o poco" en base exclusivamente a la utilización que el trabajador ha hecho de su herramienta en concreto.
De las horas (y horas y horas y horas...) que te pasas a la semana pensando delante de una libreta y un boli en la solución al problema que te han dado, reuniéndote con Producto para que te expliquen qué es lo que quieren, ayudando a compañeros más jóvenes o, lo peor de todo, resolviendo incidencias en código heredado o mirando la pantalla intentando entender qué cojones hizo el Javero/Pythonero que escribió estas 10.000 líneas hace 7 años y que ya no está en la empresa desde hace 5 y cómo le puedes meter mano para implementar eso que te han dicho que tiene que hacer ahora la aplicación que se suponía "no había que tocar ya más"... de todas esas horas no dan cuenta NINGUNA de todas esas herramientas ni existe métrica alguna capaz de medirla racional y justamente ni existirá jamás por pura teoría del caos.
Sí, todos hemos estado en esas situaciones.
Ahora con todas estas "herramientas online" se pretende, o más bien te quieren vender las empresas que las comercializan (Atlassian, GitHub...) que se puede medir si un programador "ha trabajado mucho o poco" en base exclusivamente a la utilización que el trabajador ha hecho de su herramienta en concreto.
De las horas (y horas y horas y horas...) que te pasas a la semana pensando delante de una libreta y un boli en la solución al problema que te han dado, reuniéndote con Producto para que te expliquen qué es lo que quieren, ayudando a compañeros más jóvenes o, lo peor de todo, resolviendo incidencias en código heredado o mirando la pantalla intentando entender qué cojones hizo el Javero/Pythonero que escribió estas 10.000 líneas hace 7 años y que ya no está en la empresa desde hace 5 y cómo le puedes meter mano para implementar eso que te han dicho que tiene que hacer ahora la aplicación que se suponía "no había que tocar ya más"... de todas esas horas no dan cuenta NINGUNA de todas esas herramientas ni existe métrica alguna capaz de medirla racional y justamente ni existirá jamás por pura teoría del caos.
Sí, todos hemos estado en esas situaciones.
#43:
#15 Eso está muy bien, pero hay que tener cuidado con eso de los objetivos, puesto que puede ser una navaja de doble filo.
No son raros los casos en los que se ponen objetivos imposibles para tener más trabajo en muy poco tiempo, a costa de quemar a la gente, aunque ello implique luego reciclar personal.
O el gran problema de siempre en el desarrollo: Que los clientes/stakeholders son los que te imponen los tiempos de desarrollo, sin tener en cuenta la complejidad técnica que su idea de bombero torero pueda acarrear.
El calientasillismo, por supuesto, es una gilipollez feudal. Pero los objetivos no son la panacéa. Hay que encontrar un balance intermedio.
No son raros los casos en los que se ponen objetivos imposibles para tener más trabajo en muy poco tiempo, a costa de quemar a la gente, aunque ello implique luego reciclar personal.
O el gran problema de siempre en el desarrollo: Que los clientes/stakeholders son los que te imponen los tiempos de desarrollo, sin tener en cuenta la complejidad técnica que su idea de bombero torero pueda acarrear.
El calientasillismo, por supuesto, es una gilipollez feudal. Pero los objetivos no son la panacéa. Hay que encontrar un balance intermedio.
#96:
#14 Salvo que te paguen por objetivos, hacer eso como desarrollador no tiene ningún sentido. Yo he visto a jefes que en esa situación le han dicho al trabajador "nadie te ha pedido que te conectes fuera de horas". Y tristemente, es así. Las horas que echas fuera sin que te obliguen son en última instancia decisión tuya, y muchas veces lo que hacen es perjudicar al resto de tus compañeros porque establece expectativas de producción por encima de las horas que se oficialmente se trabajan.
#111:
#14 Ese joven de la caricatura cometió un monstruoso error producto de la ingenuidad e idealismo juvenil. Con el tiempo corregirá esos errores y debe proceder así:
1. Si detecta algún fallo en el software sea vulnerabilidad, lentitud, mal diseño, etc.. debe documentarlo primero. Comunicar eso al superior inmediato usando estrictamente los canales oficiales de la empresa.
2. Si esa falla puede corregirse porque hace parte de sus tareas y responsabilidades, procede al arreglo exclusivamente en tiempo laboral.
3. Si no hace parte de sus tareas y responsabilidades, deberá esperar el comunicado de respuesta por escrito del jefe inmediato. No hacer absolutamente nada mientras tanto.
4. Si recibe respuesta afirmativa para corrección, se deberá generar un plan acordado y aprobado para el arreglo del fallo. Plan + acuerdos + aprobaciones + arreglos todo exclusivamente en tiempo laboral de la empresa.
Si lo que quiere el joven es progresar, NUNCA debe actuar como el de la caricatura: NO se debe regalar tiempo para que un software propiedad exclusiva de una empresa esté "mejor". Si quiere el joven progresar, debe por su propia cuenta hacer un software completamente distinto, publicarlo en GitHub y que le reconozcan a nivel mundial por un producto propio.
1. Si detecta algún fallo en el software sea vulnerabilidad, lentitud, mal diseño, etc.. debe documentarlo primero. Comunicar eso al superior inmediato usando estrictamente los canales oficiales de la empresa.
2. Si esa falla puede corregirse porque hace parte de sus tareas y responsabilidades, procede al arreglo exclusivamente en tiempo laboral.
3. Si no hace parte de sus tareas y responsabilidades, deberá esperar el comunicado de respuesta por escrito del jefe inmediato. No hacer absolutamente nada mientras tanto.
4. Si recibe respuesta afirmativa para corrección, se deberá generar un plan acordado y aprobado para el arreglo del fallo. Plan + acuerdos + aprobaciones + arreglos todo exclusivamente en tiempo laboral de la empresa.
Si lo que quiere el joven es progresar, NUNCA debe actuar como el de la caricatura: NO se debe regalar tiempo para que un software propiedad exclusiva de una empresa esté "mejor". Si quiere el joven progresar, debe por su propia cuenta hacer un software completamente distinto, publicarlo en GitHub y que le reconozcan a nivel mundial por un producto propio.
Comentarios
"además hemos procedido a pagarte todas las horas extra que has hecho ya que el mismo algoritmo ha confirmado que fuera de horario accedías también a esos sistemas".
No, eso no...
#1 Algo mas o menos así
#14 hostia yo me largue del último curro por eso exactamente
#14 #19 Es un clásico. Yo sustituí a uno que se fue por esto, y por algo aún más surrealista.
- ¿Te quejas de que llego un cuarto de hora tarde? ¿Y las horas extras que he tenido que echar?
- Yo no te pedí que las echases.
Ni que decir tiene que o se echaban o la entrega no se hacía a tiempo. Lo que el palurdo del jefe no calculó es que este hombre no tardó ni un mes en darle "la carta".
#57 Su cara debió ser un poema.
#63 Lo fue cuando unos meses después yo también me fui.
Por eso me río yo de estos "sistemas automáticos". Son un síntoma de empresas que no saben evaluar a sus empleados (ni a sí mismas, por supuesto).
Algún caso conozco de empresas que se pusieron a analizar también la rotación y las renuncias. Resultado: aflojaron las evaluaciones en general porque "no convenía levantar la alfombra".
Evaluar es muy difícil. Y si no se hace bien, el resultado es una catástrofe (para la empresa).
#72 Yo curre en una donde el que mas luchó por no poner esos sistemas de control era el director nacional, y no era precisamente por la bondad de su corazón.
#86 A saber por qué , pero me lo imagino. Las razones suelen ser las mismas.
En España no se quería poner el registro de horas por no destapar las horas extras no pagadas. Hace ya tiempo ya hubo casos de jefecillos diciendo "voy a poner control de tiempo porque me consta que no cumplís". Alguno le avisó, "no lo hagas", y hubo que empezar a pagar horas extras.
Luego están otros clásicos como destapar a charlatanes que se venden muy bien pero luego no pegan un palo al agua, y parecidos.
Pero lo más dañino de una evaluación mal hecha es lo que decíamos antes. Como le toques las narices a un trabajador competente con evaluaciones mal hechas... se te va a ir antes de que te des cuenta. Por eso ya he visto muchos casos de "sistemas de evaluación" que se han cambiado mil veces o se han abandonado.
#91 pues yo llevo a tres echados, de un equipo de 16, y (oh sorpresa) el resto se han puesto las pilas: curran 8 horas (clavadas) y la productividad ha subido.
Que sí, que sobre el papel aquí todos nos dejamos la piel, nunca timamos tiempo, etc.
#57 que utilicen el algoritmo con los funcionarios de este país, que te puedo asegurar poniendo la dos manos en el fuego que ninguno realiza horas extras fuera del horario de 8:00 a 15h
#14 The image failed to load
#25, dale a F5.
#14 conozco a uno que los jefes celebraron que se cambiara de empresa por eso mismo.
El celebró el cambiarse mucho más, a su vieja empresa no le está yendo tan bien.
#14 Salvo que te paguen por objetivos, hacer eso como desarrollador no tiene ningún sentido. Yo he visto a jefes que en esa situación le han dicho al trabajador "nadie te ha pedido que te conectes fuera de horas". Y tristemente, es así. Las horas que echas fuera sin que te obliguen son en última instancia decisión tuya, y muchas veces lo que hacen es perjudicar al resto de tus compañeros porque establece expectativas de producción por encima de las horas que se oficialmente se trabajan.
#96 creo que la empresa tiene que vigilar te y amonestarte si haces horas de más para no meterse en un problema legal con inspección de trabajo.
Lo de decir "las haces porque quieres" no cuela.
#14 Ese joven de la caricatura cometió un monstruoso error producto de la ingenuidad e idealismo juvenil. Con el tiempo corregirá esos errores y debe proceder así:
1. Si detecta algún fallo en el software sea vulnerabilidad, lentitud, mal diseño, etc.. debe documentarlo primero. Comunicar eso al superior inmediato usando estrictamente los canales oficiales de la empresa.
2. Si esa falla puede corregirse porque hace parte de sus tareas y responsabilidades, procede al arreglo exclusivamente en tiempo laboral.
3. Si no hace parte de sus tareas y responsabilidades, deberá esperar el comunicado de respuesta por escrito del jefe inmediato. No hacer absolutamente nada mientras tanto.
4. Si recibe respuesta afirmativa para corrección, se deberá generar un plan acordado y aprobado para el arreglo del fallo. Plan + acuerdos + aprobaciones + arreglos todo exclusivamente en tiempo laboral de la empresa.
Si lo que quiere el joven es progresar, NUNCA debe actuar como el de la caricatura: NO se debe regalar tiempo para que un software propiedad exclusiva de una empresa esté "mejor". Si quiere el joven progresar, debe por su propia cuenta hacer un software completamente distinto, publicarlo en GitHub y que le reconozcan a nivel mundial por un producto propio.
#14 Buenisimo. Me lo guardo, gracias.
#123 He sido jefe de proyectos TIC en alguna ocasión con más de 20 personas en diferentes proyectos. El resultado y estar en contacto directo con la gente fue suficiente para tener claro que hacía cada persona.
Si un jefe de Proyecto requiere de ese tipo de herramientas de control es que algo está haciendo mal, yo las veo más como herramientas de control corporativo, como las herramientas para la gestión comercial, que se venden como apoyo y acaban siempre siendo de control. En todo caso la alienación capitalista es una mierda, menos mal que tuve opción de poder salir de ahí.
#14 En la última empresa en la que estuve como jefe de proyecto RRHH me dijeron que tenía que decir a mi equipo de desarrollo, que estaba en Albacete, que tenían que recuperar las horas gastadas por la comida de empresa que se hacía en Madrid, le dije que se lo dijera él, bueno ella, que era una chica.
#1 Me imagino que en las entrevistas de trabajo también explican esa política empresarial...no creo.
Es como Amazon,..
#1 hombre, a eso también me apunto yo. No trabajar en horario laboral. Lo hago después y me lo pagan como horas extra.
Está claro que hay mucho aprovechado, y el teletrabajo permite darse más lujos y aprovecharse más.
Aquí hay de todo, puede que ya hayas finalizado el trabajo que tenías previsto y puedas darte el lujo de chatear o visitar cualquier página de entretenimiento. En este caso no debería haber pegas.
#1
- He visto que desde todo este año que llevas en la empresa te has dedicado todos los días a hacer tus 8 horas de rigor y ni una más, me preocupa que no estés comprometido con la empresa.
- ¿Cómo?
Pero si me pagáis 8 horas, qué cojones voy a hacer más.¿Dónde has visto eso?- Pues fácil, en Jira has imputado 8 horas todos los días.
- Ah, no sabía que podía imputar todas las horas reales que hacía, pensaba que no podíamos registrarlas pues eso supondría que tendríais que pagarme horas extra.
- Sí, claro que se puede, ¿pero cómo se yo que has hecho horas de más?
- Bueno, pues hay un sistema de tornos a la entrada donde se registra cuando entramos y cuando salimos hasta para hacer una pausa y tomar un café gracias al cuál a algunos compañeros les amonestasteis por hacer horas de menos.
- Pero es que a ese sistema no podemos tener acceso, solamente nos llega un aviso cuando se hacen horas de menos, pero no podemos utilizarlo para ver cuántas horas ha estado cada uno.
- Ya...
#82 manual del buen mando intermedio, capítulo 1
"Los despidos afectaron principalmente a los empleados de base, no a los altos directivos, cuya eficiencia el CEO no cuestiona. Además, al analizar el desempeño de los empleados, no se tuvo en cuenta el tiempo dedicado a Git IDE."
No vamos a hurgar en lo que hace la dirección y altos cargos, no sea que se aprecie cómo se rascan los huevos.
Sólo apretamos hacia abajo, e ignorando tiempos que podrían joder nuestro cherry picking.
Anda y que les den...
#6 casi quedaria agradecido si me despiden de esa empresa
#52: Sí, bueno, salvo por la parte de que te quedas sin ingresos.
Si para despedir desarrolladores "no se tuvo en cuenta el tiempo dedicado a Git/IDE" la métrica empleada es una putísima mierda, consideraciones éticas aparte.
#8 ¿Traducción al muggle?
#11 Git es un software de gestión de versiones de código.
IDE es un nombre genérico para "entorno de programación" (Integrated Development Environment).
O sea, las dos herramientas que más usa un programador. Sin embargo les han medido el rendimiento comprobando el tiempo utilizado en herramientas de comunicación y de gestión de incidencias.
No tiene mucho sentido, en mi opinión.
#21 Vamos, que básicamente es como si a un cocinero le miden el tiempo que pasa pidiendo comandas en vez del tiempo que pasa cocinando, ¿no?
#28 Sí, se podría decir así.
#28 Pidiendo comandas, hablando con otros cocineros, comprobando los pedidos...
Hay programadores que usan el email casi todo el día y otros no lo miran casi nunca a la semana. Depende mucho de las necesidades de la empresa y del puesto.
Pero por norma general lo que dices es correcto, igual que asumimos que el trabajo principal de un cocinero es estar frente al fogón
#54 yo procuro mirarlo dos o tres veces por jornada. Si lo tienes abierto es una sangría de concentración
#28 Super buen ejemplo. Tienes mis dieses.
#11
Confluence -> wiki interna donde se comparte conocimiento
Jira -> herramienta donde gestionan las tareas que hay que hacer
IDE -> donde los desarrolladores desarrollan, o sea resuelven las tareas que hay en el JIRA
Git -> herramienta donde los desarrolladores guardan las soluciones de las tareas del JIRA para que se puedan utilizar en el producto final o usarse por otros compañeros.
Un desarrollador "normal" lee la tarea del jira y se pasa trabajando en el IDE la mayor parte del tiempo, y sube el trabajo a GIT (o se baja cambios de compañeros, o revisa subidas de otros compañeros o lo que sea) según va trabajando en el IDE.
Y cuando acaba la tarea (o necesitas pedir ayuda, o aclaraciones de algo) añade comentarios en el JIRA o cambia los estados de la tarea.
El tema de confluence dependerá de la política de la empresa, pero normalmente cuanto mas bajo en el escalafón, menos aportas.
Pero vamos, que a mi me hacen esa métrica y me echan por incomparecencia, si me quitan IDE/Git, me han quitado de todas maneras mas del 70% de la jornada... (Y si me descuentan también MNM el 100% )
#26 es que si alguien que desarrolla da buena metrica sin contar ide o git es aue no es un desarrolador
#11 que si para despedir desarrolladores no se tiene en cuenta el tiempo que se dedica al programa con el que se desarrolla o donde se sube el código desarrollado, y se toma en cuenta el tiempo que se dedica al repositorio de documentación o al de pruebas, pues estás haciendo el tonto
#8 A mi que me midan el que paso en Stack Overflow
#22 Pues la cantidad de contribuciones a SO deberia ser una gran metrica
#22 #97 En muchas empresas "serias", no payasadas como esta en la que para medir tu rendimiento ni miden los commits que realizaste ni el tiempo que usas el IDE , me gustaría ver cómo está esta empresa en uno o dos años
. Pues como decía, en las entrevistas de trabajo de muchas empresas de desarrollo (fuera de España, se entiende cuando dije "serias" bueno, alguna habrá no se me enfaden ) te piden el usuario de Stackoverflow para ver tu puntuación y tu actividad, es muy valorado si está relacionado con las tecnologías que piden... y yo gastando las horas en Mnm 
#7 no se tuvo en cuenta el tiempo dedicado a Git IDE
Porque claro, todos sabemos que los desarrolladores son mucho más productivos en tareas burocráticas que haciendo su trabajo
Edito: Acabo de leer a #8 y #24 que comentaron algo parecido.
#36 Ya, pero es que esas dos herramientas tampoco es que digan por si mismas digan mucho.
Jira como mucho, cuando empiezas y acabas la tarea, y si quieres ir añadiendo comentarios sobre lo que haces, pero luego se te quejan Y su utilidad siempre ha sido más ver como está la tarea en el tablero correspondiente.
* Se me ocurre medir la horas empleadas con respecto a las estimadas, ..... pero eso es un infierno.
Y Confluence es para compartir conocimiento, que esta ya ni se para que pinta para evaluar a un programador.
Y si ya no metes Git (como indica la noticia), tiene pinta de que son requisitos puestos desde arriba, que son quienes explotan Jira y confluence.
#47
#50 Se me hace raro. Una empresa de 600 trabajadores despedir a 150 programadores.
Que puede ser, sin duda. Pero creo que es más probable que dentro de esos "programas rastreados" entre el navegador web. Por poner un ejemplo.
También es cierto que lo ha hecho una IA, entiendo que no es nada tan simple como parece. Por ejemplo, que deje un mensaje a medias, pase dos horas, y luego lo termine. O que tarde días en responder a una citación en el gestor de.tareas por lo que la comunicación no le llega. O que no siga determinados protocolos o procedimientos, por.ejemplo que en las PR siempre le de al OK y nunca escriba un comentario
Por supuesto, especulación. Siempre habrá empresaurios idiotas. Pero con lo caro que están los programadores, 150 de.golpe... Creo que es más factible que hayan razones reales
#60 Conozco algún caso aquí tras una absorción, y quitarse a mucha gente, aunque no de golpe, sin o ser un ERE
Pero lo raro es que lo suyo es que la IA de un aviso, y el gerente de turno de el toque de atención.
También es cierto que lo ha hecho una IA, entiendo que no es nada tan simple como parece. Por ejemplo, que deje un mensaje a medias, pase dos horas, y luego lo termine. O que tarde días en responder a una citación en el gestor de.tareas por lo que la comunicación no le llega. O que no siga determinados protocolos o procedimientos, por.ejemplo que en las PR siempre le de al OK y nunca escriba un comentario
Hay gente que hace su trabajo sin meter comentarios y que se olvida de cerrar tarea en el jira, por ponerte un ejemplo que veo mucho.
Lo de los comentarios, pues depende, que entre correo, teams, slack, menciones en jira, en confluence, pues puede que se te pasen notificaciones. Y si ya lo que hacen coger y llamarte ¿cómo verifica la ia que se trató tal tema o aquel?
#50 Exacto, han evaluado más las herramientas de gestión que las de desarrollo. Yo sufrí algo así hace años y es absurdo, si evalúan el número de tareas que completas en Jira te puedes dedicar asubdividir tareas. Si evalúan el número de líneas de código este puede crecer exponencialmente para cada tarea y así sucesivamente. Al final tienes unos mecanismos de control uqe lo único que hace es dificultar el trabajo y meter burocracia en vez de facilitar las tareas
#8 Aquí el auténtico problema es el intentar cuantificar "el trabajo" de un programador como si fuera un obrero de fábrica sacando planchas de acero de una máquina herramienta, algo que se intenta desde hace décadas y que jamás ha funcionado ni funcionará. Básicamente porque escribir código suele ocupar la menor parte del tiempo de la jornada de trabajo de un programador.
Ahora con todas estas "herramientas online" se pretende, o más bien te quieren vender las empresas que las comercializan (Atlassian, GitHub...) que se puede medir si un programador "ha trabajado mucho o poco" en base exclusivamente a la utilización que el trabajador ha hecho de su herramienta en concreto.
De las horas (y horas y horas y horas...) que te pasas a la semana pensando delante de una libreta y un boli en la solución al problema que te han dado, reuniéndote con Producto para que te expliquen qué es lo que quieren, ayudando a compañeros más jóvenes o, lo peor de todo, resolviendo incidencias en código heredado o mirando la pantalla intentando entender qué cojones hizo el Javero/Pythonero que escribió estas 10.000 líneas hace 7 años y que ya no está en la empresa desde hace 5 y cómo le puedes meter mano para implementar eso que te han dicho que tiene que hacer ahora la aplicación que se suponía "no había que tocar ya más"... de todas esas horas no dan cuenta NINGUNA de todas esas herramientas ni existe métrica alguna capaz de medirla racional y justamente ni existirá jamás por pura teoría del caos.
Sí, todos hemos estado en esas situaciones.
#49 por no decir que las nuevas metodologías se comen gran parte del tiempo del programador en Dailys, sprint reviews, restrospectivas, etc...
En mi equipo cuando estimamos capacidades para encajar tareas en los sprints tenemos muy claro que el tiempo REAL de horas/desarrollador dificilmente llega al 50% de su jornada.
Estimar más es batacazo seguro.
#49 por no hablar de la cantidad de problemas que hay que resolver en el día a día y que no mete nadie en Jira ni en ningún sitio
Jira y Confluence como base para establecer si trabajas o no, ... para mear y no echar gota.
#7 ". Además, al analizar el desempeño de los empleados, no se tuvo en cuenta el tiempo dedicado a Git IDE."
Empresa tóxica claramente a evitar, no me extraña que hayan dejado de crecer. Al final los despedidos van a tener hasta suerte...
#7 ... Y otras herramientas. Lo pone en la noticia.
Es muy raro, insólito, que despidan a 150 programadores sin tener bien claro lo que hacen.
#36 Si vienen vacas flacas para esa empresa, a lo mejor esas estadísticas en Rusia son suficientes para hacer un despido objetivo (si es que existe esa figura allí) y sirve de aviso a navegantes para que acepten ser explotados (y así amortiguar la perdida de programadores). Una especie de ERE, pero echándole la culpa a los trabajadores.
#7 Además de verdad. Igual te toca un desarrollo tocho que es una tarjeta de Jira y otro que tiene más tarjetas de Jira hechas donde escribe "hola mundo" se queda en la empresa jajajajaj.
(algoritmo analizando la actividad de los directivos)
"FUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU"
Ajá, mejor pasar el tiempo escribiendo comentarios en los Jira que resoviéndolos
#10 es un grave error no comentarlos, por mucho que al que lo programa le parezca lo contrario.
Muy grave.
#13 será a ti. A mí me pagan por objetivos y vamos de puta madre.
#15 Pues me alegro por ti. En esta empresa es diferente y en los convenios tambien.
#33 y así les va.
#37 No digo lo contrario
. Cada uno hace lo que cree mejor. Si ellos piensan que esto es lo mejor. Genial por ellos.
#15 Eso está muy bien, pero hay que tener cuidado con eso de los objetivos, puesto que puede ser una navaja de doble filo.
No son raros los casos en los que se ponen objetivos imposibles para tener más trabajo en muy poco tiempo, a costa de quemar a la gente, aunque ello implique luego reciclar personal.
O el gran problema de siempre en el desarrollo: Que los clientes/stakeholders son los que te imponen los tiempos de desarrollo, sin tener en cuenta la complejidad técnica que su idea de bombero torero pueda acarrear.
El calientasillismo, por supuesto, es una gilipollez feudal. Pero los objetivos no son la panacéa. Hay que encontrar un balance intermedio.
#43 De hecho esto es lo que me ha pasado en todos los sitios donde he trabajado por objetivos y el ejemplo clasico tener algo listo para la reunión del lunes a las 10am. Otro clásico es decirte que tienes vacaciones ilimitadas siempre que no haya trabajo, lo cual nunca pasa
#43 Y el justificalismo también es un problema. "No importa el tiempo que necesites, pero tienes que justificar el tiempo..." Y claro, luego habría que meter el tiempo dedicado a justificar el tiempo.
El micromanagement puede llegar a ser la mitad del tiempo de trabajo.
#15 A ti te pagan por horas como a todo asalariado salvo que tengas un contrato/acuerdo ilegal. Otra cosa es que te paguen un plus por los objetivos, que eso sí es legal, o que al acabar las tareas asignadas te dejen irte a tu casa. Pero las horas de tu jornada no te las puede quitar nadie.
No me parece mal método, incentiva a los trabajadores y asegura los números de la empresa. El problema es que hay mucha gestoría espabilada que pretende convencerte de que la paga de objetivos cubre las horas extra o que es legítimo que en tu contrato ponga 10 horas y trabajes 50 porque la diferencia se paga "por llegar a los objetivos".
#61 España es uno de los países europeos donde más hora se trabaja y menos se rinde. Por tanto, mayor número de horas de trabajo no es sinónimo de productividad. Aprender a trabajar por objetivos es uno de los grandes retos de las empresas para poder empezar a hablar de eficiencia y competitividad, reto que muy pocas parecen querer asumir.
#79 'donde más horas se trabaja'
Bienvenidos al feudalismo del siglo XXI
Así conseguirán unos excelentes escritores de paja en Confluence y Jira además de buenos spammers en Gmail. Es más, seguro que más de uno se programará envíos de varios emails al día de "Buenos días!" ó "Voy a comer, hasta luego" y mierdas así.
Otro robot que escriba y borre en alguna parte remota de su Confluence.
Es lo que tienen esas métricas absurdas, que se pueden falsear con chorradas
#29 De hecho es lo que ellos han hecho, falsear las métricas excluyendo el tiempo de desarrollo a los desarrolladores, para que dijera lo que ellos querían que dijese y tener una excusa para echar al 30% de la plantilla.
Pero son tan cutres que la IA "solo" ha dado un 40% de falsos positivos...
#39 hombre a ver, puedes hacer un cribado con un algoritmo tranquilamente. Ahora, cuando a tu jefe le lleguen los resultados, es casi seguro que ya los sepa de antemano. Simplemente tendrá una prueba que respalde su opinión. Si trabajas por 8 tranquilo, que no hará nada. Si acaso, y es una persona inteligente, buscará motivarte para que trabajes por 16 en vez de por 8
#80 jajaja. efectivamente trabajes por 16 y cobres por 1. De todos modos he visto de todo en esta vida.
si tienes dos dedos de frente pues si, revisaran esto, pero me he encontrado casos de jefecitos de turno donde a un crack le hicieron la vida imposible porque no se quedaba ni un minuto de mas....
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
Bill Gates
Mientras leía, pensaba, verás como a los parásitos lameculos encargadillos,ceos, jefes de proyecto, etc etc , no los han metido en el estudio. A mitad de lectura, lo confirma.
Cuando dice lo de trabajar menos y cobrar más, también pensaba en los jefecillos.
Abundando aún más, que vergüenza si te preguntan ¿Donde trabajas? . En xsolla. ¡Pues tríncame lo que rima!
Pues se crea un algoritmo que envíe emails solos y a echarse la siesta
#12 AHK es tu amigo
Que triste es ver como se busca humanizar a las máquinas y a su vez transformar las personas en máquinas.
Sin defender al 100% los criterios usados para evaluar el rendimiento de los programadores. Es verdad que pasamos la mayor parte de la joranda en git y en el ide. Pero JIRA puede dar muchas pistas:
- Si trabajan en SCRUM cada ticket tiene una estimación antes de comenzarlo
- Conforme cambia de estado, podemos hacernos una idea del tiempo invertido por el programador
- Si son sistemáticos, cuando el ticket llega a QA, el QA puede añadir información sobre los findings. Eso puede también proporcionar información estadística sobre la calidad del código de cada developer
- El sprint puede ser un éxito. Y es verdad que es un trabajo de equipo... pero a veces es curioso analizar el reparto de tickets entre los miembros del equipo
#51 Jira es una herramienta valiosísima. Es totamente simplista y de novato pensar que es perder el tiempo mantenerlo actualizado.
Quizás en proyectos de mediopelo pueda ser menos necesario. Pero 3n macroproyectos de años, con decenas de inplicados, rotaciones, etc... es vital. (JIRA o similar)
#87 Una vez vi en un proyecto una tarjeta en Jira que ponía "hacer el backend", así tal cual
Empezó en el sprint 1, saltó al 2, saltó al 3, saltó al 3 (es que el 3 lo abrieron y lo cerraron en falso), saltó al 4, saltó al 3 de nuevo, luego al 5, luego al 6 y me parece que luego en el Burndown Chart (una gráfica que siempre tiene que ir bajando) se habían cambiado tantas veces las estimaciones y se habían metido tantas tareas a lo loco que habían logrado dibujar un perro
Obviamente es una herramienta maravillosa, si sabes qué coño estás haciendo (con la herramienta y así en general)
"La carta está firmada por el CEO y fundador de la compañía, Aleksandr Agapitov"
Agapitov
Bueno, ya cierro yo la puerta. Ciao.
Pues bien me parece si eso ayuda a fomentar el teletrabajo, tiene en cuenta la normativa respecto al descanso / pausas en la jordana de trabajo y de paso se usa para controlar las extras gratis.
#2 pues a mi me parece una puta mierda. LO que hay que hacer es valorar si se cumplen los objetivos o no y si cumplen los criterios de calidad, no fomentar el calientasillismo, que anda qu eno hay trepas que no hacen una puta mierda y saben fingir que lo hacen.
Esto es un jodido retroceso.
#5 Te pagan por trabajar X horas. No por trabajar lo mismo que tu compañero en menos tiempo.
#13 y si tu en 3 horas haces el trabajo de 20 personas cobrando lo mismo que cualquiera de ellas? Yo creo que hay que no es tan medible... Eso si... es como cierta empresa que enviaba un informe de los minutos en que no había pulsación de teclado o movimiento de raton...
#16 pues pide un aumento. Pero normalmente lo que se establece en los contratos y convenios es un número de horas, no un número de objetivos cumplidos.
#27 Ya, pero entiendo que para evaluar eso tambien dependerá de criterios subjetivos. Igual te compensa un trabajador que hace el trabajo de 2 cobrando lo mismo aunque trabaje 6 horas en vez de 8 ¿no?
Solo decía que evaluar eso en un algoritmo no es tarea facil.
#13 visto así, deberían pagarte también por convenio.
¿A que ya no hace tanta gracia?
#31 Como minimo si, deben pagarte segun convenio, de la misma forma que tu como.minimo tienes que trabajar segun convenio. Todo ello salvo que la empresa y/o tu decidais otra cosa dentro de la legalidad.
#35 pues nada, todos como gilipollas a estar calentando do la silla por lo mínimo posible.
#46 No se como es en tu empresa, pero en la mia hay trabajo para 3 vidas. Eso de calentar la mesa solo ocurre cuando el trabajo no es infinito, lo cual es el caso de la mayor parte de los informaticos. Calentar la silla no es posible.
#13 si eso fuera así, nadie esperaría de ti que cuando las cosas van mal, te sentirás delante del pc fuera de horario.
Te pagan por hacer algo en un tiempo determinado, siempre que ese tiempo determinado sea realista. Unos días rendirás más, otros menos y al final se verá si vales lo que pagan.
#34 Tu asumes que esta empresa pide que trabajes extras no remuneradas, lo cual es ilegal. No tiene porque ser el caso.
#38 la gran mayoría de las empresas no lo piden, lo esperan.
#13 Y eso es un mal modo de medir la productividad, muy malo. Es más va en contra de ello.
#13 A mi en teletrabajo me pagan por objetivos.
#13 el mundo al revés
#2 #5 Yo creo que el teletrabajo se va a convertir en nuestra trampa. Me copio a mi mismo de otra noticia de hace dos meses (el primer punto viene "al pelo" aquí:
Los jefes listos prefieren que estés en casa. Así:
- Los objetivos los marcan como les da la gana. O cumples jodiéndote, o te despiden porque no trabajas.
- No existen horas extra.
- La desunión con los compañeros es total. Todavía más libertad para pactar todo tipo de condiciones individuales. Difícil unirse para plantarle cara. El divide y vencerás en su mayor amplitud.
- Se ahorra un pastizal en infraestructuras. Basta con "cuatro" camas mesas calientes.
- Se ahorra mucho dinero en consumo de energía, limpieza, etc.
En resumen, en la práctica, lo más parecido a los falsos autónomos. Tiempo al tiempo...
Que está bien cierto teletrabajo, pero es que no estamos poniendo demasiado cachondos con esa opción y se nos va a dar la vuelta a la tortilla (con cebolla y sin cebolla).
#44 Yo no estoy de acuerdo, todo depende de si se cumple la regulacion o no en cuanto a los gastos de agua luz e internet por ejemplo. Ademas, respecto a la.carga de trabajo, en cuenta que para despedirte la carga de prueba esta en la empresa y demostrar que el trabajo que te han dado se puede hacer en el tiempo que ellos han dicho no es tan sencillo (por no decir que imposible).
#75 No te entiendo. Yo no hablo de los gastos o regulación del puesto de trabajo, por ejemplo. Eso es otra historia...
Efectivamente, la carga de la prueba está en la empresa. Como la empresa va a terminar desconfiando por que no te ve, te va a pedir resultados. Y a ver cómo mides resultados en ingeniería (por ejemplo): los objetivos los marca un comercial/jefe de proyecto (quizás con variable por contratación, no por resultados finales...); el jefe desconfía... Y tú a la calle porque no has hecho el trabajo en el tiempo que otros han determinado.
Si estás en la oficina, es más fácil que se vea en qué "jardín" en que te ha metido el posible vendehumos de turno.
#81 Si tu jefe te dice: tienes que hacer X en Y horas y tu tardas Y+10. Es el jefe el que tiene que demostrar que se podia hacer en Y de cara a un despido procedente. Sin mas. Tu no tienes que demostrar nada en un juicio, es la empresa la que tiene carga de prueba.
Lo que se suele hacer en estos casos es medir cuanto trabajo hacen tus compañeros y en caso de que el tuyo esta claramente por debajo entonces es cuando es procedente despedirte por productividad. Hacerlo de otra manera es practicamente imposible.
#5 Jira & Gmail Actions random generator y listo
#5 hombre... habría que ver qué evalúa concretamente ese algoritmo. Lo mismo sirve para valorar el trabajo de una manera más objetiva y evitar arbitrariedades en evaluaciones realizadas por humanos.
#5 seguro que cumplian objetivos, la empresa iba de puta madre y decidieron echar a 150 porque un algoritmo dijo que habia que echarlos.
#2 La venganza de los supervisores tras el fin de la presencialidad: ¿Creías que mi trabajo de vigilar si se curraba era inútil? Pues toma algoritmo un tanto aleatorio para comprobar si calientas la silla apropiadamente.
Espero que los demás tomen nota y a partir de ahora pongan todo su esfuerzo en satisfacer al algoritmo en lugar de en hacer un buen trabajo.
"No obstante, desde la empresa han aclarado a Forbes Rusia que es probable que unas 60 personas se queden después de hablar con sus responsables más directos."
Vamos, que luego la realidad es otr cuando vienen las incidencias y no hay gente para atenderlas.
Que esos que no rellenan una mierda en Jira o no hacen 3500 commits con cambios absurdos luego son los que resuelven la papeleta.
Si estás validando un equipo de soporte se puede entender pero el desarrollo es un trabajo creativo, es imposible de medir aunque algunos lo intenten porque necesitan ver métricas para justificar su puesto
#76 eso es un error. De los gordos. Si no rellenas nada en Jira, cuando vuelva a pasar lo mismo o relacionado, alguien tendrá que empezar desde 0.
Igual ni es un error de codigo. Y por la vagueria de no comentarlo, habra que volver a evaluar si es una configuracion q no se debe tocar, si es un tema funcional o desconocimiento de usuario...vamos...a quemar pasta de otros que no son el programador, que tambien cobran.
#90 bueno, no me refería a tickets de soporte si no el panel scrum y derivados (yo tengo de ambos).
Para el tema de ticketa de soporte da para abrir una enciclopedia de lo que no hace bien la gente.
A lo que iba es que sigue siendo subjetivo, no es algo que una "IA" pueda decidir si alguien es productivo o no porque por la base que va a medir es la subjetividad del interesado que hace el modelo
No sé, parece un artículo de EMT, menudas perlas tiene.
El recochineo en el te echamos pero te ayudamos a encontrar un trabajo en el que cobres mas y trabajes menos.
El canteo de excluir del análisis de la eficiencia de los desarrolladores el tiempo de desarrollo.
Lo de no analizar a los directivos, no fuera a verse que si se aplica la misma vara de medir habría que echarlos a todos...
En fin, y al final solo para disimular una excusa para echar gente porque no pueden seguir creciendo al ritmo (ojo al dato) del 40% anual.
#18 y el CEO se llama Agapitov... parece de Mortadelo y Filemon
#55 Pensé lo mismo, pero yo ya ni sé...
He leído la noticia, y viendo la opinión que la empresa tiene de si misma y sus valores, todo me encaja.
Hay empresas que llegan a ser auténticas sectas. Crean una "cultura" interna muy cerrada donde te hacen sentir alguien importante y muy capacitado por haber sido contratado. Un auténtico crack.
Después, empiezan las exigencias que te absorben la vida y no te da tiempo para cosas fuera de ese entorno. Ni pensar en tus necesidades propias ni tener tiempo de reflexión. Durante las vacaciones que por ley te tienen que dar obligatoriamente, estás tan aletargado que apenas tienes tiempo para recuperar tu ego y algo de sentido crítico. Estás tan atorado que sólo puedes mirar al infinito sin articular el menor pensamiento mientras te bebes un tercio de tu cerveza favorita (o la que sirvan en tu destino).
Este párrafo es el más esclarecedor:
De hecho, asegura que “exigimos mucho y damos mucho a cambio”, algo que no solo es “un intercambio justo” sino “parte de nuestra cultura y está claramente articulado desde el primer día de trabajo en la empresa”.
Por otro lado, cualquier métrica sin contextualizar es basura inservible. Hay auténticos trastornados con TOC que quieren medir el rendimiento, pero es técnicamente imposible usando medidas y ratios matemáticos sin más. Lo suyo es tener esos números, más la razón de los mismos. A lo mejor la baja productividad es porque esa burocracia que toooooooodas estas empresas dicen que se ahorran y no tienen, a lo mejor sí que la tienen, pero de otra forma aceptada por la secta y por tanto incuestionable. O mil razones más.
Esto huele más bien a limpieza ideológica, a barrer a los que no bailan el agua a la cultura sectaria. Una forma de autoconfirmación.
Les han hecho un favor. Y la empresa se acaba de meter un tiro en el pie.
Que no hayan tomado en consideración Git para la métrica no es excusa.
Un programador cuya actividad en Jira es escribir “problema resuelto” no está haciendo bien su trabajo, está haciendo trabajar 2 veces a sus compañeros.
Por otro lado, tener en consideración Git tampoco aportaría objetividad. Muchas veces la solución es tocar una línea y le has estado dando vueltas 2 horas.
Pero entonces el seguimiento de las horas extras que hicieron, supongo que tambien se lo remuneraron no? no? no? a no espera que eso no
.
Espero que no salga un listo juez diciendo que es despido procedente.
A ver… he visto de todo, desde convocatorias teams en la que se autoconvoca la gente, gente que ha puesto usb que mueve el ratón (se pillan con facilidad por administradores) y estar en una reunión y escuchar sintonía de sálvame de fondo (siendo directivo). La gente profesional se nota, pero hay que entender que hay de todo, no todo el mundo está preparado para teletrabajar y fastidian al resto…
Que me miren a mí, que trabajo en cliente y no arranco el portátil de mi empresa desde hace meses...