Portada
mis comunidades
otras secciones
#3:
Yo estuve en un proyecto, sistemas, lo hicimos de puta madre y empezamos a reducir el numero de incidencias al mínimo, hasta nos dieron un premio de reconocimiento por ello.
Pues bien, van los putos subnormales de los directivos y empiezan a decir que hay pocas incidencias que habrá que reducir la plantilla.
Nos enteramos por alguien que tenía un contacto con esos hijos de puta...
Increiblemente se empezó a incrementar el número de incidencias.
Pues bien, van los putos subnormales de los directivos y empiezan a decir que hay pocas incidencias que habrá que reducir la plantilla.
Nos enteramos por alguien que tenía un contacto con esos hijos de puta...
Increiblemente se empezó a incrementar el número de incidencias.
#14:
En una empresa en la que estuve, teníamos un equipo en el que todos nos llevamos genial (aún sigo jugando videojuegos con ellos de vez en cuando), pero la empresa empezó a implantar métricas basándose en el número de tickets que resolvíamos.
Esto se tradujo que en vez de ayudarnos los unos a los otros como hacíamos antes, compartiendo el conocimiento y haciendo sesiones para aprender todos y mejorar las tareas, cada uno se enfocase sólo en sus tickets y sus entregas. Nadie quería ayudar a nadie porque independientemente de que fuese mejor que 4 ojos vieran un problema y la solución en vez de 2, ayudar a otro significa que tú perdías tu tiempo de tus tickets para que otro entregase más rápido y mejor su ticket.
Los tickets se volvieron mucho más pequeños con tareas que muchas veces carecían del contexto y visión en el que se engloban y pasó de ser un ambiente colaborativo enfocado a proyectos a ser un ambiente individualista enfocado a mini tareas.
Y así es como se cargaron todo un departamento y su cultura para que los jefes de la empresa tuviesen un gráfico de tarta en una presentación que hacen una vez al mes y en el cual van a perder 1 minuto.
Esto se tradujo que en vez de ayudarnos los unos a los otros como hacíamos antes, compartiendo el conocimiento y haciendo sesiones para aprender todos y mejorar las tareas, cada uno se enfocase sólo en sus tickets y sus entregas. Nadie quería ayudar a nadie porque independientemente de que fuese mejor que 4 ojos vieran un problema y la solución en vez de 2, ayudar a otro significa que tú perdías tu tiempo de tus tickets para que otro entregase más rápido y mejor su ticket.
Los tickets se volvieron mucho más pequeños con tareas que muchas veces carecían del contexto y visión en el que se engloban y pasó de ser un ambiente colaborativo enfocado a proyectos a ser un ambiente individualista enfocado a mini tareas.
Y así es como se cargaron todo un departamento y su cultura para que los jefes de la empresa tuviesen un gráfico de tarta en una presentación que hacen una vez al mes y en el cual van a perder 1 minuto.
#10:
#3 Yo por estas cosas le taladro el cerebro a mi equipo con que no damos ni los buenos días sin un ticket por delante. Que ser majo está muy bien, pero si resuelves problemas y no queda constancia luego llegan los jefazos que solo saben gestionar a base de excel y dicen "no hay tantas incidencias, sobra gente".
#16:
Bueno, obviamente un incentivo es más potente que la responsabilidad. Hasta tal punto que muchas personas responsables dejan de serlo para obtener el incentivo. Pero sigo pensando que es mucho mejor simplemente buscar personas responsables y pagarlas bien. Tiene varias ventajas sobre los incentivos:
1) La responsabilidad es general y cubre todos los campos de la empresa. Los incentivos provocan que una persona se volque en una cosa concreta y olvide las demás.
2) El riesgo del incentivo mal diseñado es como los bugs de un programa. Siempre existe.
Y el ejemplo es #14
1) La responsabilidad es general y cubre todos los campos de la empresa. Los incentivos provocan que una persona se volque en una cosa concreta y olvide las demás.
2) El riesgo del incentivo mal diseñado es como los bugs de un programa. Siempre existe.
Y el ejemplo es #14
#24:
#3 Yo estuve en un proyecto con una promesa, normalmente era al año de entregar, pues entregamos en menos de 4 meses, porque el equipo que se monto, nos coordinamos genial, el cliente, felicitandonos, y pensando en adjudicar mas proyectos. ya que se había entregado el proyecto con unas incencias muy bajas.
Mi empresa, en vez de mantener el equipo e intentar propagar la misma filosofía , cojió en un año propago al equipo e intento poner a otro equipo mas malo, para intentar dilatar mas el tiempo.. consecuencia el cliente de 20 proyectos comprometidos bajo a 2 ...., pues no echaron a ese jefe que tuvo esa idea.
Y si, la idea es hacerlo mal para dilatar y pagar, justamente cuando debe ser, bien, y al siguiente
Mi empresa, en vez de mantener el equipo e intentar propagar la misma filosofía , cojió en un año propago al equipo e intento poner a otro equipo mas malo, para intentar dilatar mas el tiempo.. consecuencia el cliente de 20 proyectos comprometidos bajo a 2 ...., pues no echaron a ese jefe que tuvo esa idea.
Y si, la idea es hacerlo mal para dilatar y pagar, justamente cuando debe ser, bien, y al siguiente
#6:
#3 te doy el ejemplo contrario en mi empresa, un proyecto que te decian los jefes que era un cliente muy bueno pasando por una fase muy mala, venga chicos arrimad el hombro esto es muy importante. Gente haciendo el esfuerzo y quedándose a trabajar hasta las 8 o las 9. Sin ver un duro por supuesto. El proyecto se relaja y empieza a funcionar. Queda una persona trabajando para ese cliente 
Comentarios
Yo estuve en un proyecto, sistemas, lo hicimos de puta madre y empezamos a reducir el numero de incidencias al mínimo, hasta nos dieron un premio de reconocimiento por ello.
Pues bien, van los putos subnormales de los directivos y empiezan a decir que hay pocas incidencias que habrá que reducir la plantilla.
Nos enteramos por alguien que tenía un contacto con esos hijos de puta...
Increiblemente se empezó a incrementar el número de incidencias.
#3 te doy el ejemplo contrario en mi empresa, un proyecto que te decian los jefes que era un cliente muy bueno pasando por una fase muy mala, venga chicos arrimad el hombro esto es muy importante. Gente haciendo el esfuerzo y quedándose a trabajar hasta las 8 o las 9. Sin ver un duro por supuesto. El proyecto se relaja y empieza a funcionar. Queda una persona trabajando para ese cliente
#6 Vaya, ¿me estás diciendo que a las empresas les importan una mierda sus trabajadores y que si pudieran hacer un proyecto poniendo un gato delante del teclado, no contratarían a nadie?
Me pinchas y no sangro.
#7 no puede ser. No me lo creo. Pero si las empresas son seres de luz que vienen a mejorar y contribuir con la sociedad de la mejor manera posible, anteponiendo el bienestar general a los beneficios, y que tienen a gente en plantilla para garantizarles un plato de comida caliente.
Debe ser fake, un bulo de la extrema derecha. No me lo creo.
#28 ¿Te han contado lo de Papa Noel?
#3 Yo por estas cosas le taladro el cerebro a mi equipo con que no damos ni los buenos días sin un ticket por delante. Que ser majo está muy bien, pero si resuelves problemas y no queda constancia luego llegan los jefazos que solo saben gestionar a base de excel y dicen "no hay tantas incidencias, sobra gente".
#10 Y si no hay tickets es que todo funciona de puta madre, por lo menos en sistemas.
Y eso para los jefes es que sobra gente.
Llamadme loco, pero lo mismo es que en sistemas son unos putos cracks y lo tienen todo maqueao y por eso no falla.
Me cago en todos los putos muertos del que inventó el ITIL.
#3 Tú orgulloso de hacer mal tu trabajo aposta y el comentario en naranja. Maravilloso.
#22 Tu de comprensión lectora lo justo...
No está orgulloso, mas bien asqueado porque ellos han hecho un trabajo ¿y como les recompensan? con despidos. Es la directiva la que no ha hecho su trabajo, no ha sabido ver el trabajo que hacen los que están a su cargo... pues la vida es dura, si lo único que ven son unos gráficos de Excel, pues eso es lo que les dan.
#35 Jijiji, qué bonito es que un tío que tiene "troll" como parte de su nick no pille una troleada tan evidente. Me encantan las vaciladas de buena mañana.
#22 Es el maravilloso mundo de las empresas que crean riqueza, la recompensa por un trabajo bien hecho es que te manden a la calle y los directivos se embolsen un bonus.
Son las consecuencias de la avaricia desmesurada de quien no tiene interés real en que la empresa funcione, que sus trabajadores tampoco.
#3 Yo estuve en un proyecto con una promesa, normalmente era al año de entregar, pues entregamos en menos de 4 meses, porque el equipo que se monto, nos coordinamos genial, el cliente, felicitandonos, y pensando en adjudicar mas proyectos. ya que se había entregado el proyecto con unas incencias muy bajas.
Mi empresa, en vez de mantener el equipo e intentar propagar la misma filosofía , cojió en un año propago al equipo e intento poner a otro equipo mas malo, para intentar dilatar mas el tiempo.. consecuencia el cliente de 20 proyectos comprometidos bajo a 2 ...., pues no echaron a ese jefe que tuvo esa idea.
Y si, la idea es hacerlo mal para dilatar y pagar, justamente cuando debe ser, bien, y al siguiente
#24 pero aqui también tenemos la otra parte, el cliente cuenta con un plazo de 12 meses y 12.000 de gasto y la empresa contrata equipo en base a esos plazos/presupuestos.
Pero si el proyecto sale en 4 la empresa paga 4.000, coñe... paga los putos 12.000 y agradece que lo tienes antes de tiempo, ya que normalmente si el proyecto se alarga o se cambias los requisitos el cliente se lava las manos y te recuerda que eran 12 meses por 12.000.
Por favor, no interpretes esto como una defensa de los vendehumos y cárnicas varias que pululan a millones
#3 para los señores que "hacen números" cuya mentalidad es "número hoy más grande que número ayer" no hay manera de que les entre en la cabeza de que mantenimiento no genera beneficios ni nunca lo hará, su objetivo es reducir pérdidas.
#3 normalmente cuando pasa eso te llevan a otro cliente que le dé más dinero y a ti te sustituye un becario, así el negocio vuelve a "funcionar"
#3 Yo trabajé en un proyecto en el que hicimos TDD DE VERDAD, echando a veces más tiempo en tests (55/60% del tiempo en tests y QA) que en código y con coberturas del 100% en código y branches.
Era C++ y hasta tiempo después de yo dejarlo (años) no tenía ni un solo memory leak ni defecto que no fuera por requisitos incorrectos (el código está bien, hace exactamente lo que se pidió, pero se pidió mal)
Pues cambiaron las cosas, los nuevos PO y PM se pusieron a hacer preguntas sobre porque tanto tiempo en testing y calidad, que éramos lentos, poco agile y que había que agilizar. Ahora tienen más features, y memory leaks, y defectos persistentes que no consiguen arreglar....
En resumen ahora echan 30% en test y 30% o más arreglando defectos (que no consiguen arreglar)
#46 Es el problema de siempre, todos los putos vendehumos que se colocan en la empresa poniendo excels, powerpoints, objetivos, valoraciones y mierdas.
#47 #46 SI en vez de C++ estuviesemos usando Common Lisp con REPLs la mitad de esos vendehumos estaban en la calle y tambien la mitad de jefes intermedios.
#53 Cómo evita el lenguaje usado la proliferación de mandos intermedios con el único objetivo de mirar Jira y Excel?
#55 Los bugs se arregalan en runtime, te ahorras ciclos de compilacion en muchos casos salvo que uses las funciones del entorno de compilar nativamente con opcion 3 de velocidad.
Muchas tareas en bugs se cortarian por lo sano sin necesidad de poner un ticket casi.
Se que LISP era y es algo pesado (esa fama tenia en el MIT vs los PDP11 mas cascadetes rulando Unix y herramientas peladas), pero en maquinas de 64 bit es donde esos entornos de Common Lisp pueden tener mucha mas salida.
Como ejemplo, esta el motor de juegos Kandria:
https://github.com/Shirakumo/kandria
O en CAS, Maxima y Axiom.
Siempre he dicho que una vez que las herramientas son las adecuadas, la mitad de corporatocracia se va a la mierda. Si, por eso tambien odio Red Hat, XML y su insistencia en hacer de GNU un NT.
#46 #3 En Espanya los jefecillos/CEOs son iletrados sin cultura informatica real. Aunque los VC en EEUU tampoco son mejores.
#50 Esto era en UK, en todos lados cuecen habas...
#46 Odio a muerte trabajar con TDD, a muerte total....que asco me da (tambien es verdad que trabajo con Java)
#3 La mayoría de premios y reconocimientos (con valor monetario) que he recibido han sido por resolver una incidencia gorda o apagar algún fuego. Casi nunca hay reconocimientos por haber hecho un buen diseño desde el principio. Eso no lo ven o les da igual.
#3 como una viñeta que vi hace mucho y no he vuelto a encontrar.
Una oficina donde es todo caos y el jefe dice "no se para qué pago a los informáticos"
La misma oficina llena de paz y el jefe dice "no se para qué pago a los informáticos"
En una empresa en la que estuve, teníamos un equipo en el que todos nos llevamos genial (aún sigo jugando videojuegos con ellos de vez en cuando), pero la empresa empezó a implantar métricas basándose en el número de tickets que resolvíamos.
Esto se tradujo que en vez de ayudarnos los unos a los otros como hacíamos antes, compartiendo el conocimiento y haciendo sesiones para aprender todos y mejorar las tareas, cada uno se enfocase sólo en sus tickets y sus entregas. Nadie quería ayudar a nadie porque independientemente de que fuese mejor que 4 ojos vieran un problema y la solución en vez de 2, ayudar a otro significa que tú perdías tu tiempo de tus tickets para que otro entregase más rápido y mejor su ticket.
Los tickets se volvieron mucho más pequeños con tareas que muchas veces carecían del contexto y visión en el que se engloban y pasó de ser un ambiente colaborativo enfocado a proyectos a ser un ambiente individualista enfocado a mini tareas.
Y así es como se cargaron todo un departamento y su cultura para que los jefes de la empresa tuviesen un gráfico de tarta en una presentación que hacen una vez al mes y en el cual van a perder 1 minuto.
Bueno, obviamente un incentivo es más potente que la responsabilidad. Hasta tal punto que muchas personas responsables dejan de serlo para obtener el incentivo. Pero sigo pensando que es mucho mejor simplemente buscar personas responsables y pagarlas bien. Tiene varias ventajas sobre los incentivos:
1) La responsabilidad es general y cubre todos los campos de la empresa. Los incentivos provocan que una persona se volque en una cosa concreta y olvide las demás.
2) El riesgo del incentivo mal diseñado es como los bugs de un programa. Siempre existe.
Y el ejemplo es #14
#14 Justo es lo que esta pasando en mi empresa, somos 2 picando y el jefe y el compañero empeñados en poner Jira y horas estimadas etc..
Santa paciencia.
#25 Coméntale mi ejemplo si quieres, y dile que las empresas que se creen que son Facebook acaban siendo Facebook, pero no por la parte buena precisamente.
Tener Jira o algún otro issue tracker está bien para organizar el trabajo según prioridades y poder tener una visión global de cómo va la cosa, no veo nada malo en ello, sobre todo si hay mucho caos de información y tareas y es difícil organizar las prioridades. No tiene por qué ser Jira, podría ser Asana o un simple Kanban board de trello funciona muy bien si no hay muchas tareas.
Lo de estimar las tareas es hacer un brindis al sol, jamás es realista, te hace perder tiempo que podrías estar usando en sacar el trabajo adelante y además los imprevistos siempre trastocan los planes. Yo conozco a mucha gente que usa éste tipo de sistemas y no conozco ningún caso de éxito en el cual la planificación vaya según lo acordado, son sólo datos para management, pero nunca son realistas.
Yo siempre digo que salvo lo mínimo que necesitas para organizarte, no hay que enfocarse en trabajar alrededor del trabajo, sino trabajar el trabajo que es lo que nos da de comer a todos.
En mi experiencia, es mucho mejor trabajar orientado a hitos en el tiempo y ver qué tareas podrías realizar para llegar a dichos hitos. Que una tarea cueste más o menos es irrelevante siempre y cuando los hitos se cumplan, para eso se puede hacer un roadmap del año con los diferentes objetivos a alcanzar a lo largo de éste, y siempre tirando a la baja, porque siempre surgen cosas. Si luego sobra tiempo y entran más cosas, pues mejor que mejor, siempre va a ser muchísimo mejor cumplir objetivos comedidos o que excedas los objetivos, a que te plantees algo inalcanzable y jamás llegues a cumplirlo, que por desgracia es lo que habitualmente ocurre cuando estimas y sumas.
#32 Correcto, justo es más o menos lo que comentaba en las reuniones. Pero vamos han decidido hacerlo "asin".
Hasta ahora utilizábamos Trello y funcionábamos muy bien.
#14 Y eso sin contar el tema diabólico de los tickets., generalmente cuentan todos los mismo.
Y tienes a personas haciendo 100 tickets simples de 2 min. cada uno.
Y tienes a personas haciendo 10 tickets complejos que requieren 5h. cada uno.
En un ambiente como el que cuentas, nadie coge los complicados y todos se tiran como lobos a por los simples.
Luego el que acaba asumiendo esos termina con estadísticas de mierda en comparacion y es el que "sobra"para los jefes.
Si pagasen mas por tiempo de servicio sin cortes en lugar de por incidencias seguramente que eso no pasaba.
#4 Pero seguramente pasaría otra cosa. Escojas el parámetro que escojas comomo medida, alguien va a encontrar la manera de conseguir que sus resultados sean buenos, independientemente de la realidad
¿Crear bugs a proposito? Demasiado esfuerzo. En mi proyecto metemos bugs como parte del proceso normal de programación. Por amor al arte. Toda esa gente que lo hace por dinero son lo puto peor.
#9 como tester, te lo agradezco.
Entre 2014 y 2016 pillaron a un informático haciendo eso, pues en nuestro país las cárnicas lo llevan haciendo décadas.
* En Ankh-Morpork hay un Gremio de Asesinos y uno de Ladrones, pero el patricio había ilegalizado el Gremio de Bomberos tras multitud de quejas. La cuestión era que, si firmabas un contrato y pagabas tu cuota al Gremio, tu casa quedaba protegida contra incendios. Por desgracia, la ética general de Ankh-Morpork se adueñó de la situación, y los bomberos solían visitar en grupos las casas de los posibles clientes, haciendo en voz alta comentarios como "Este lugar parece muy inflamable" y "seguro que arde como la paja con una simple cerilla de algún descuidado, no sé si me entiendes".
Hay otro caso antiguo. No es mala praxis (técnicamente) pero sí es picaresca. Fue de la época donde los monitores eran monocromos, un desarrollador preparó una aplicación cumpliendo con lo que le pedían, y ya de paso, y con el código en la cabeza, dejó preparada la aplicación para monitores en color, pero dejando esa parte del código inactiva.
Tiempo después, llegarón los monitores en color, le contactaron, le pidieron adaptar la aplicación a monitores en color. El dio un tiempo y un presupuesto. Aceptaron. Cambió la línea de código que activaba la interface en color en cinco minutos y adios. Al cabo de unos días, les dijo que el problema estaba resuelto, pilló el dinero y a otra cosa, butterfly.
#12 That's a feature, not a bug. Las consultoras saben perfectamente lo que hacen, y el cliente a día de hoy también pero prefiere pagar a calentarse la cabeza buscando una mejor opción. Yo he estado a ambos lados de la frontera y todos sabemos a lo que estamos jugando.
Las consultoras saben que el proyecto se lo lleva el proveedor más barato, así que meten juniors a saco. El mantenimiento, cuando se mete porque el cliente lo exige, se cobra también (nuevamente, a precio de junior). Pero es lo mismo, todos los proveedores tienen que meter mantenimiento y el proyecto se lo lleva al más barato (o el segundo más barato si hay chanchulleos).
Y el cliente sabe perfectamente que está comprando mierda. Pero el cliente a su vez tiene a los del C-Suite (CEO, CIO, CTO, CFO) presionando para ahorrar costes, así que palante.
En cliente nadie quiere complicarse la vida porque, como bien explica el árticulo, no hay incentivos para ello. No hay incentivos para hacer las cosas in-house aunque cuesten más en el corto plazo. Y no hay ni medio incentivo para medir como la calidad de los proyectos impacta en la adquisición y retención de clientes. Eso es muy complicado de hacer. Subcontratar con un excel usando el precio como único criterio es mucho más fácil
El propósito de las empresas es ganar dinero, eso es incuestionable.
Que un inversor quiera su dividendo a toda costa también es incuestionable.
Dicho esto, resulta estúpido tener que explicar a un empresario que el propósito de un trabajador, su propia empresa, también sea el lucro. ¿Qué cojones estudian en las escuelas de negocios?
Si hago mi trabajo sin que dé problemas, a nadie le importa. Pero si genero problemas que luego soluciono cuando todo el mundo mira, me valorarán más. Así de estúpidos son los empresarios porque no dan más valor a lo que funciona sin problemas.
#20 El típico pensamiento de empresario:
"Si todo funciona, ¿Para qué te pago?"
"Si todo da problemas, ¿Para qué te pago?"
#26 Vamos, que no les gusta pagar...
#51 Aparte, pero más bien que no saben ni de qué va el trabajo ni por qué se hace lo que se hace.
Efecto cobra https://es.wikipedia.org/wiki/Efecto_cobra
Resumo:
En la india colonial estaban preocupados por la cantidad de cobras venenosas en delhi y ofrecieron recompensas por cada cobra muerta.
Al principio iba bien hasta que algunos listillos empezaron a criarlas para recobrar la recompensa.
Cuando se dieron cuenta y quitaron la recompensa, los listillos liberaron todas las cobras y al final acabaron con mas cobras que antes...
Algo parecido pasó en vietnam con las ratas. En lugar de la rata pedían la cola como muestra, así que en lugar de matar ratas se dedicaban a cazarlas, cortarle la cola para la recompensa y dejarla en libertad para que criaran más.
A veces es la propia empresa la que propicia un software defectuoso para tener al cliente cautivo con contratos de soporte.
#5 DMR lo afirma
#11 ¿DMR? Viejuno detectado
(Te lo dice un ex DMR y ex Everis; vamos, otro viejuno)
#62 Está claro jajajaja pasé por ahí hace unos 20 años... casi nada.
#5 Puede ser, que no digo que no. Pero es más probable que el problema sea que las cárnicas contratan a programadores noveles o poco preparados por que se les paga menos. Y claro, el desarrollo no es el mismo. O por que el departamento de informática de la empresa, subcontrata los servicios, y los kilos de carne solo quieren cobrar mientras buscan algo mejor, en lugar de proponer mejoras de sistemas, de infraestructura o de operativa. O por que se compra software por precio, al mas barato, en lugar de el que mejor se adecua a las necesidades.
Muchas empresas de software ya incluyen el mantenimiento en el contrato, por lo que las incidencias solo son perdidas de horas de sus técnicos.
Uno de esos posts que lo que hace es repetir un twit pero con muchas mas palabras.
Esto sale en Dilbert.
Así se asegura el trabajo de por vida......como los políticos
#21 La política es el arte de crear problemas, hacer un diagnóstico falso y aplicar después los remedios equivocados. Groucho Marx
Esto ya estaba inventado hace décadas por los cerrajeros que jodían cerraduras y que OH CASUALIDAD te encontrabas su pegatina bien visible sobre ésta.
'URGENCIAS 24H'
El economista Gary Becker ganó el Premio Nobel de su disciplina
Por ser precisos, no existe tal premio. Alfred Nobel no dejó en sus voluntades la creación de tal premio para economistas. El premio real se llama Premio de Economía Conmemorativo de Alfred Nobel y empezó a darse en 1968. Mucho después de que existieran los verdaderos premios Nobel.
Yo los genero gratis, a cambio de nada. Si es que soy un sol.
En relación a la métrica de pagar por número de lineas de código programadas, leí una anécdota de un programador que reportó un saldo de lineas de código negativas, ya que había simplificado y optimizados ciertos procesos. Los jefes finalmente entendieron que ese método no era válido para determinar la productividad.
#52 Y como ejemplo podemos poner el medicamento para curar la hepatitis C.
El tratamiento es muy caro, pero menos que un transplante. Y tiene una efectividad del 90% o más.
Se están forrando vendiendo el tratamiento, pero a cambio la enfermedad está desapareciendo.
Trabajé en una cárnica que hacía proyectos para un gran cliente (entre otros). Se había instaurado la costumbre no-oficial de que después de cada proyecto importante, el cliente contrataba en su plantilla a uno o dos miembros del equipo, para encargarse de resolver bugs y el mantenimiento. Esta era la meta a largo plazo de todos los programadores. Yo trabajé un par de años en un proyecto y lo hicimos tan técnicamente sólido y funcionalmente bien planteado, que al terminar, el cliente comprobó que no iba a necesitar a nadie para arreglar errores ni para desarrollar nuevas funcionalidades. Así que no contrataron a nadie.
Los mejores clientes de los médicos, enfermeras, farmacéuticas, etc., son los enfermos crónicos.
#41 Chorrada. Tu como farma vendes un farmaco que cura el VIH o el 90% de canceres de pulmon/cerebro de raiz y tus acciones suben un 200% como poco.
Esto me recuerda a las empresas de antivirus.
¿Esto no era lo que hacían algunos brigadistas en Galicia cuando llegaba el verano?
Cada año sale alguna noticia de alguna empresa o programador que se dedica a crear bugs o bombas lógicas planificadas para que su servicio o trabajo se haga "imprescindible".
Los políticos llevan aplicando esta estafa toda la vida
It’s a reminder that rewards need to be carefully crafted to truly motivate positive outcomes and not just line up with productivity metrics.