¿Cuál es el desperdicio de dinero más atroz que haya visto y qué hizo al respecto?[cerrado]

https://softwareengineering.stackexchange.com/questions/18585

22-10-2019
|

Pregunta

A menudo, nosotros, como programadores, vemos grandes organizaciones desperdiciando enormes sumas de dinero en soluciones infladas e ineficientes a los problemas.Esto me duele mucho porque me gusta que las organizaciones se beneficien de las mejores soluciones.Sin embargo, mis habilidades como programador son limitadas cuando se trata de influir en los tomadores de decisiones clave y, a menudo, mi perspectiva sobre el asunto se limita a mi pequeño mundo técnico.

Así que mi pregunta es esta.Después de encontrar un desperdicio atroz de dinero en algún software y/o hardware que realmente le molestó, ¿Qué hiciste al respecto para arreglarlo? ¿O estabas condenado a morder la bala y murmurar para siempre en voz baja?Me interesa escuchar tus experiencias generales. y especialmente qué lecciones aprendiste sobre cómo abordar este tipo de cosas en el futuro..No digamos nombres, la experiencia de cómo abordar el problema es más importante que el producto causante del problema.

Solución

Pagar por productos comerciales grandes, voluminosos y con buggy, en la gama de:

Servidores de aplicaciones;
Herramientas de prueba;
Entornos de desarrollo.

Cuando las alternativas de código abierto o de peso ligero son obviamente superiores.

Mis pasos suelen ser:

Establezca una alternativa como referencia, por ejemplo, "Experimentaré con el servidor de aplicaciones X en lugar del servidor de aplicaciones Y. Tuve buena experiencia con ella, porque (...)";
Venda esta propuesta a mis colegas: "Ahora me estoy desarrollando más rápido ya que Server X se reinicia mucho más rápido y no me puso todo ese tiempo";
Venda esto al gerente inmediato: "Nuestro equipo ahora se desarrolla más rápido ya que estamos usando el servidor X. Todo comenzó como un pequeño experimento, pero a todos les gusta".

Otros consejos

He visto demasiados ejemplos para nombrar un favorito, pero he notado algunas tendencias generales en mi campo principal, el desarrollo web:

Sitios web de tocador. Estos son sitios web que no tienen un propósito útil para nadie fuera de la pequeña organización que los comise y se construyan en torno a una compulsión obsesiva con logotipos, fotos de sí mismos y gofres autocomplacientes. La peor parte es que suelen ser financiadas y encargadas del sector público por personas que no tienen idea de la web. (Por ejemplo, una vez tuvo una confianza hospitalaria del NHS que quería desarrollar una mini versión de Facebook para su propia intranet de personal).
Pagado es el mejor. La mentalidad que insiste en que el software pagado debe ser intrínsecamente mejor que la fuente abierta. Después de todo, se paga, ¿verdad? He visto a muchos clientes insistir en tomar decisiones estúpidas simplemente porque funcionan en una cultura que descuenta automáticamente cualquier cosa abierta como una cuestión de política.
Diseño por comité. Aquí es donde un gran grupo de personas tiene una "lluvia de ideas" y luego intenta incorporar cada idea de crack-pot que hay en el diseño, lo que inevitablemente resulta en un mal pensamiento a través del desastre que se compromete a todo a favor de tratar de complacer a todos ( y para todos se refieren al comité que toma las decisiones, no las personas que tienen que usar la aplicación).
Consultores. Aquí es donde paga a un hombre medio (que no conoce prácticas comerciales ni desarrollo de software) para interponerse en el camino y al dinero crema al priorizar el proceso de desarrollo con confusos techno-babble y negocios de negocios.

No veo que nadie haya mencionado este todavía.

Construyendo su propia solución cuando pueda comprarla.

Variaciones de este patrón:

ni siquiera considerando la compra de compra-vs.-construcción
Refugio de alcance significativo de la solución interna
alcance limitado, pero también utilidad limitada de la solución interna

Mis dos favoritos:

Consultores de contratación (Lanza libre) Solo para agregar más capacidad de producción, mientras deberían invertir en sus propios empleados En cambio, al contratar consultores para traer nuevos conocimientos y entrenar a sus personas existentes.
Contratación de gerentes de proyecto que administran otros gerentes de proyecto que administran otros gerentes de proyectos que finalmente (piensan) que administran el equipo de desarrollo. Si bien deben dejar que el equipo se administre y se concentre en los negocios. He visto proyectos de software en los que tenían más gerentes de proyectos que desarrolladores. Imagina las reuniones.

Limitar aumentos y bonos a largo plazo

Creo que se enseña en el negocio 101 a no Dar aumentos de empleados. Un caso secundario es limitar los salarios de los artistas estelares porque necesitan caber dentro de cierto rango salarial.

Finalmente, los empleados se darán cuenta de que su escala de pago no está en línea con su industria (o producción). Las personas que tienen el currículum y las habilidades eventualmente se irán, y llevarán con ellas todos sus conocimientos y probablemente algunos de sus amigos. Las personas que quedan (que son los desempeños inferiores) tendrán que recoger la holgura y luego pasar más tiempo contratando a una nueva persona (a la tasa de mercado). Por lo tanto, la compañía acaba de cambiar a un empleado estrella por el nivel uno JR, y simplemente perdió todos los "ahorros" de mantener bajos los salarios.

A medida que esto continúa, el equipo de desarrollo tendrá dificultades para mantenerse a la par, y probablemente empeorará cada vez más hasta que se haga algo drástico.

Esta respuesta es algo diferente a la mayoría: no despedir a un empleado lo suficientemente pronto, o declarado de manera diferente, ser demasiado tolerante a los de un empleado ~~errores~~ hábitos. Estas fueron cosas que he observado y no podía hacer mucho como consultor.

El desarrollo que impulsó mal las decisiones de diseño de un proyecto que llevó a su eventual reescritura (fue un completo desastre).
El desarrollador que envió datos confrificados confidenciales a los gráficos de Google porque pensaron que sería genial mostrar un gráfico circular (¿era un requisito de gráfico circular? ¡No!).
El desarrollo que consultó con una empresa en el pasado y aceptó un puesto directamente con ellos. Hizo una cara sobre la cara y se convirtió en una prima donna que buscó la posición de plomo técnico y fue tan lejos como para hablar con el gerente del líder, afirmando que pensó que sería bueno para él asumir el cargo de líder. ¡Habla de audacia! A muchos desarrolladores ya no les gusta el tipo y quemó muchos puentes en sus primeras 2 semanas como empleado. Para colmo, es un desarrollador muy verde que solo se graduó hace 2 años, pero cree que es increíble.

Algunos errores son comprensibles, pero cuando hay un consenso entre muchos desarrolladores sobre la actitud o el nivel de habilidad de alguien, las empresas deben deshacerse de ellas más temprano que tarde.

Varias veces fui testigo de la gerencia trayendo consultores para el único propósito de gastar dinero. La mayoría de las veces esto sucedió a fin de año cuando estaban bajo presupuesto tratando frenéticamente de gastar el dinero. Por lo general, a estos consultores se les pagaría cientos de dólares por hora y pasarían semanas en una presentación de PowerPoint que nunca se utilizaría.

Hay un problema mucho mayor en juego aquí.

Muchas empresas tienen un objetivo: aumentar la riqueza de los accionistas. Lo que producen es irrelevante. Cómo lo producen es irrelevante. La cantidad de desechos que producen es irrelevante. El costo para la sociedad y el planeta es irrelevante.

Entonces, trabaje o inicie una empresa que haga algo de beneficio para la sociedad / el planeta.

Pagando a grandes compañías de software no solo por su producto, sino por su "apoyo".

Estaba trabajando en una agencia gubernamental para un equipo que estaba en la cama con Oracle. En el transcurso de muchos años, les habían pagado bajillones de dólares por su software. Viniendo de un fondo de inicio, esto no tenía sentido para mí: "¿Por qué no usar MySQL o Postgres?" Me dijeron que se debía principalmente al soporte que brinda Oracle, si algo sale mal, te ayudan a encontrar la solución rápidamente.

El apoyo fue una broma absoluta. Hubo un problema en el que una aplicación web seguía bloqueando todo el sistema. Parecía ser el resultado de una consulta de base de datos lenta con una combinación de código horriblemente escrito (que fue escrito por un equipo de consultores, que debería ser una respuesta completamente diferente). Se ensambló un "grupo de trabajo" (gemido) para determinar el problema y solucionarlo. En el grupo de trabajo se incluyó un miembro de Soporte de Oracle. Todos los días en EOB habría una llamada de conferencia donde los miembros del grupo de trabajo actualizarían el resto del equipo con los hallazgos. Fue una llamada lo suficientemente larga que nadie quería estar en b/c comenzó a las 5, y la persona de Oracle lo empeoró. ¿Por qué? Bueno, decir "persona" ni siquiera es correcto. Eran varias personas. Parecía que cada dos o tres llamadas de conferencia, el representante de Oracle sería alguien nuevo, quien explicaba que su predecesor ahora estaba en otro proyecto o se había ido de vacaciones. Las nuevas personas nunca fueron informadas por nadie en Oracle, por lo que cada vez que aparecía alguien nuevo tuvimos que desperdiciar diez minutos de la conferencia telefónica que explicaba nuevamente el problema. Sus contribución Luego pediría archivos de registro J2EE, que no solo pueden leer ningún mono, sino que también eran inútiles porque el código horriblemente escrito estaba haciendo cosas como lanzar excepciones índiceutOfBounds cuando el programador encontró errores en el análisis de XML.

Tener programadores para soporte telefónico de primera línea.

Hacer que los programadores realicen pruebas.

Sé que esta es una vieja pregunta y tendré suerte si 3 personas leen esta respuesta, pero es una historia divertida de contar, entonces, ¿qué diablos?

Entré en un proyecto (sistemas integrados, firmware crítico para la seguridad, mucho en juego) y quedé horrorizado por lo que encontré.Personas que usan C (especialmente punteros) incorrectamente, sin análisis estático, sin revisiones de código, sin pruebas más que "integrarlo, ejecutarlo, superarlo, ver qué se rompe".

Escribí un correo electrónico muy largo mi primera semana allí (como consultor).Fue arriesgado porque básicamente decía que estaba mal administrado, que los desarrolladores estaban perdidos, que no se estaba siguiendo ningún proceso, etc.Debería haber ido al vicepresidente corporativo, pero en lugar de eso se lo envié al gerente de desarrollo que me contrató.No se puso del todo a la defensiva al respecto; de hecho, reconoció muchas de las deficiencias y me dijo que yo no era el primero en señalarlas (no es broma, ¿verdad?)

Para responder al quid de la pregunta original:Ofrecí dedicar COMO MÁXIMO 1 semana-hombre para configurar y ejecutar la herramienta de análisis estático Lint de Gimpel (PC-Lint / Flexelint) en su plataforma, y ejecutar un informe completo de todo lo que se encontró.Les dije que estaba absolutamente seguro de que, como resultado, encontraríamos varias "bombas de tiempo" al acecho.

Calcularon mi tarifa por hora, la multiplicaron por 40 y determinaron que era "demasiado caro hacerlo". En pocas palabras, me fui allí dentro de los 60 días.Unos tres años después, me enteré de que habían retirado un producto del mercado y el coste se acercaba a las 9 cifras (100 millones de dólares), sin mencionar el daño a la reputación de la empresa.

No mencionaré la empresa, el producto o la industria, pero todavía me mantengo en contacto con uno de los ingenieros allí, y cuando me explicó qué causó el retiro, mis ojos se pusieron en blanco: era un problema que habría sido detectado incluso por una herramienta básica de análisis estático (acceso a una matriz fuera de límites).Para ser justos, no puedo decir con certeza que el problema estaba en el código cuando estuve allí, pero estoy seguro de que si hubieran gastado el dinero en algún tipo de herramienta de análisis estático, ese error no se habría escapado.

Así que ahorraron $295 al no comprar PC-Lint (OK, también me ahorraron una semana pagándome, como máximo), pero no soy lo suficientemente bueno como para cobrar $100 millones por una semana.

Eso es lo que yo llamo una gran pérdida de dinero.

Me recuerda a un chiste que muchos de vosotros ya habráis oído:

¿Has oído alguna vez la historia del motor de un barco gigante que falló?Los propietarios del barco probaron con un experto tras otro, pero ninguno de ellos sabía cómo arreglar el motor.Luego trajeron a un anciano que se dedicaba a arreglar barcos desde pequeño.Llevaba consigo una gran bolsa de herramientas y, cuando llegó, inmediatamente se puso a trabajar.Inspeccionó el motor con mucho cuidado, de arriba a abajo.

Dos de los propietarios del barco estaban allí, observando a este hombre, esperando que supiera qué hacer.Después de revisar las cosas, el anciano buscó en su bolso y sacó un pequeño martillo.Golpeó suavemente algo.Al instante, el motor cobró vida.Guardó con cuidado su martillo.¡El motor fue reparado!Una semana después, los propietarios recibieron una factura del anciano por 10.000 dólares.

"¡¿Qué?!" Los propietarios exclamaron."¡Casi no hizo nada!"

Entonces le escribieron una nota al anciano diciendo: "Por favor, envíenos una factura detallada".

El hombre envió una factura que decía:

  Tapping with a hammer ........ $ 2.00

  Knowing where to tap ......... $ 9998.00

El esfuerzo es importante, pero saber lo que estás haciendo marca la diferencia.

Equipos de desarrollo hinchados y terrible productividad en compañías de software.

Esto es una consecuencia del patrón común en el mundo de los negocios: la importancia de un gerente se mide por el número de subordinados, por lo tanto, la preocupación número uno del gerente no es productividad, sino todo lo contrario: la pobre productividad es la mejor justificación para contratar a más personas .

En una empresa que vendía software... dar a los vendedores una comisión completa por todas las modificaciones personalizadas vendidas, de modo que vender algo que ya existía y del que podíamos sacar provecho no era tan rentable para ellos como vender productos únicos.Esto se combinó con el traslado del personal de ventas al otro lado del país desde el personal técnico.

Esto también significaba que nosotros en Desarrollo no podíamos cumplir con los plazos de ventas, lo que hacía que los clientes estuvieran descontentos, y teníamos muchas dificultades para realizar cualquier trabajo central que mejorara el producto para todos.El aumento de la presión hizo que la calidad del código disminuyera y dañara la moral, particularmente cuando escuchamos historias sobre la oficina de ventas (que nunca confirmé).

Muchos de nosotros estábamos resentidos con Sales, pero en realidad no fue su culpa.Salían y vendían todo lo que podían, haciendo aquello por lo que eran recompensados de acuerdo con los límites que se les habían impuesto.Fue una mala gestión la que causó todos estos problemas.

Hay dos que he experimentado.

Cancelar un proyecto que tuvo un gran ROI para el negocio que se completó alrededor del 80% y luego entregó 100 iPods grabados y chapados en oro a los ejecutivos superiores.
Disponiendo a varios cientos de personas y luego al día siguiente anunciando aumentos salariales y bonificaciones sustanciales para los altos ejecutivos.

Estos no están totalmente relacionados con la programación, pero ciertamente desperdiciaron mucho dinero, además de proporcionar una bofetada a la cara para todos los involucrados.

No me despedieron, pero tampoco obtuve un aumento o un iPod ...

He visto un par de horribles proyectos de outsourcing que lograron aumentar significativamente los costos al tiempo que no aumentaron o realmente reduciendo la eficiencia.

En el peor de los casos, el nuevo equipo de subcontratación se implementó y fue experto, pero el equipo existente en la costa se mantuvo en su lugar porque no se confiaba en el equipo de subcontratación para hacer ninguno de los trabajos críticos.

En este punto, lo lógico obviamente habría sido aceptar el fracaso y cerrar el equipo de subcontratación, pero debido a que la gerencia no estaba dispuesta a admitir públicamente que no había funcionado ambos equipos se quedaron en su lugar (a un aumento significativo en el costo. sin aumento en la eficiencia o capacidad utilizable) hasta que todo se pueda enterrar.

En otro caso, el desarrollo fue subcontratado y el equipo original despedido. Dos años más tarde se dieron cuenta de que no había funcionado y pagado para volver a poner todo el lote nuevamente solo para encontrar que, además de los costos muy significativos de otra entrega, el impacto del conocimiento perdido, las tarifas de reclutamiento, las terminaciones de contrato y así. En On, la organización de subcontratación había perdido una parte significativa del código fuente.

(Nota: No digo que la subcontratación no pueda funcionar, solo que demasiadas veces las personas son seducidas por posibles ahorros y no consideran las realidades de su nuevo mundo, el cambio para procesar y las prácticas de trabajo, etc. proyectos jodidos principalmente)

Deuda técnica

He visto que es el crónico "Beating the Dead Horse" de Legacy Code. O más hasta el punto, desde el punto de vista de las trincheras, innumerables horas en modo de mantenimiento cuando todo el equipo sabe que debemos estar en modo de reemplazo.

Lo que hemos hecho ... todavía está en marcha. Tratando de invocar un cambio positivo desde dentro

Pruebas de rendimiento

Simplemente, no hacerlo. Nuevamente, todavía trabajando en el cambio positivo desde adentro.

He estado trabajando con algunos instituciones del Estado Y son increíbles desperdiciando dinero en ello. Desde comprar el middleware hinchado para resolver problemas extremadamente simples hasta pagar miles y miles de dólares a un proveedor para que creen un CSV. Sin personas internas con experiencia suficiente, parece que seanananan en el costo inicial o en el mantenimiento.

En compañías que no son de software (bancos, seguros) con TI internamente, el dinero proviene de varios grupos empresariales. Los grupos empresariales obtienen directamente el argumento de venta de los proveedores y lo empujarán a la TI. Están pagando el software/hardware y su salario para que sus protestas no sean a dónde.

Pagar por aplicaciones hinchadas y middleware que cuesta a mediados de las cinco cifras y ni siquiera se ajusta a la arquitectura del sistema existente
Uso de software costoso como HP QualityCenter, BMC Remedy, HP LoadRunner, etc., donde hay opciones mejores y más baratas disponibles
Con los equipos de múltiples ciudades de la ciudad, muchos costos de viaje, a veces solo por unas pocas horas de reunión
Pagar por la licencia de Windows 7 que algunos con máquinas nuevas y luego pagar nuevamente a la degradación de Windows XP como el nuevo SOE (diseñado en 2010) sigue siendo XP
Sobre capacidad en hardware

Trabajo en la profesión de pruebas de rendimiento y soy testigo de cómo las organizaciones tiran (literalmente) millones de dólares al año por cuatro razones.

Contratar a un subcontratista basándose únicamente en el precio, sin calificar las habilidades y sin auditar periódicamente las habilidades de los evaluadores de desempeño.Contratar a un evaluador de rendimiento aficionado es muy parecido a contratar a un plomero aficionado o a un electricista aficionado: les llevará mucho más tiempo realizar las tareas básicas, se pierden muchos controles y equilibrios en el proceso, y cuando descubres cómo Lo malo es que eran terriblemente costosos de arreglar (en producción).Como moderador de media docena de foros en este campo observo regularmente la aparición de personas que carecen de habilidades fundamentales en pruebas, comunicación, gestión de proyectos, desarrollo, análisis de sistemas, etc...y simplemente les han arrojado una herramienta.Para la persona que anteriormente señaló que LoadRunner era una pérdida de dinero, si le lanzas un tonto a una herramienta, solo hay un resultado que debes esperar.La ironía es que las herramientas de código abierto requieren un conjunto de habilidades aún más maduras para tener éxito con ellas.
No recopilar requisitos de desempeño.Esto afecta a toda la organización porque tendrá una perspectiva diferente sobre el rendimiento en arquitectura, ingeniería de plataforma, ingeniería de aplicaciones, control de calidad funcional y control de calidad del rendimiento, ninguno de los cuales puede coincidir con las partes interesadas del negocio (y con frecuencia no lo hace).Este es un problema de proceso porque en muchas organizaciones se pide al equipo de pruebas de desempeño que recopile los requisitos de desempeño y los pruebe.Para realizar controles y contrapesos adecuados, debe hacer uno y no el otro.Relacionado con 1 anterior con el personal inmaduro, tendrá personas que ni siquiera pueden reconocer un requisito de rendimiento adecuado, no tienen un punto de medición para validar con un perfil de carga y, sin embargo, todavía están construyendo "scripts para ejecutar". Esta es una pérdida de tiempo y esfuerzo colosal y hace poco para mejorar la calidad.El desempeño necesita una perspectiva común en toda la organización y no es algo que pueda simplemente agregarse al final si no fue diseñado desde el principio.
Gestión del entorno de pruebas de rendimiento.No puedo decirle cuántas organizaciones se retrasan porque los entornos de prueba no están listos para ejecutarse en el momento en que la organización de prueba está lista para continuar.Solo en un cliente puedo ver esto como un problema multimillonario en términos de horas perdidas esperando
Gerentes de proyecto que no entienden qué son las pruebas de desempeño, qué tareas están involucradas o el nivel de esfuerzo realizado, pero que dictan cuánto tiempo deben llevarse a cabo las actividades.Esto conduce a variaciones en el cronograma del proyecto que están completamente relacionadas con la forma en que se programaron los elementos (y, como resultado, sobrecostos).Esto también está directamente relacionado con el punto 1 anterior, ya que los evaluadores inmaduros no pueden proyectar con precisión ni el número ni los tipos de tareas ni cuánto tiempo deberían tomar las tareas.Es un axioma que si permites que alguien que no entiende lo que haces y por qué lo haces te dicte cómo trabajar y cuánto tiempo te llevará, entonces este camino te llevará al fracaso.Sucede con demasiada frecuencia en las pruebas de rendimiento.

Sistemas de control de versiones patentados. Dado el estado de Git y Mercurial, no veo por qué la gente iría por algo con un portero.

No solo tiene que pagar por los VCS, sino que también debe pagar por usuario. Además, su flexibilidad recibe un disparo en el pie. Bien podrías usar una camiseta que diga "¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡.

Siento que es solo loco en estos días no usar un VCS (D) gratis. Si desea muchas ventajas complementarias para acompañarlo, hay cosas como Kiln disponibles.

No creo que iría a trabajar para alguien que insistió en Bitkeeper o similar.

Casi dije lo mismo sobre los emuladores, pero productos como Simics continúan ofreciendo ventajas significativas sobre alternativas gratuitas.

Reuniones de estado e informes semanales

Una organización en la que trabajé se trataba de informes semanales de estado: enrollada en 3 niveles diferentes. Los lidera de desarrollo y los liderazgo de prueba para cada uno de los 4-6 proyectos en vuelo informan su progreso en un largo correo electrónico, que luego es enrollado por el próximo gerente, que a su vez es resumido arbitrariamente por el siguiente.

El siguiente día hábil, todos los líderes del proyecto se reúnen en una reunión de 1 hora para repasar el informe.

Efectivamente, se dedica un día a la semana en informar el progreso de esa semana. Tenga en cuenta que todo esto está separado de los standups diarios y las reuniones semanales de demostración / retrospectiva.

Trabajo para un organismo público. Realmente no hay forma de explicar adecuadamente el nivel de residuos que pueden continuar cuando el lugar de trabajo está tan legislado y sindicalizado que despedir a alguien es prácticamente casi imposible.

Los gerentes juegan pasan el paquete con un mal personal y esperan eliminarlos a todos a la vez al cubrir de reestructuración. Se promueve a algunos malos empleados, solo para sacarlos de un área que necesite mejoras. Cualquier buen personal termina luchando constantemente solo para compensar el trabajo del mal personal. Personal que no conservaría durante 3 meses Forge 40 años de carreras. La cantidad de dinero que desperdician sobre tales carreras es astronómica.

Trabajé en el sector privado anteriormente y vi muchos desechos, pero el desperdicio del sector público es un deporte completamente diferente, y mucho menos el juego de pelota.

Se sugirió en un comentario que el establecimiento de SINECURES para el personal de bajo rendimiento ayudaría. Ayudaría a que limitaría el daño que podrían hacer, pero no afectaría las causas fundamentales del problema. Creo que lo mejor sería la adopción de algunos procedimientos de contratación y gestión del sector privado, y los cambios en la legislación para facilitar que los organismos públicos permitan que el personal que tenga un rendimiento inferior vaya. Los sindicatos también deberían cambiar sus políticas en consulta con el gobierno: su papel de proteger a sus miembros es importante, pero deben reconocer que a veces sus miembros están realmente fuera de su profundidad y deben avanzar.

Un proyecto en el que trabajé con una gran institución financiera. Hubo grandes cantidades de llamadas de conferencia diariamente, y estimé que quemaron alrededor de $ 100k por día solo en llamadas de conferencia. El proyecto duró unos 2 años. Tenían toneladas de sistemas heredados y cuando los cambios de ahorro para la luz del día se hicieron hace un par de años, le pagaron a Microsoft alrededor de medio millón de dólares para crear un parche DST para NT 3.51.

Estábamos teniendo una pequeña cantidad de trabajo y apenas haciendo facturas y nómina en una pequeña tienda en la que trabajaba. La solución: contrate a un consultor de eficiencia y un secretario personal para el jefe para poder realizar más trabajos de "carne y papas".

Resuelva un déficit presupuestario aumentando el gasto ... falla.

En el lado positivo: el experto en eficiencia proporcionó un tablero de borrado en seco donde rastreamos nuestras horas facturables y pagamos horas ... adivina quién tenía la menor cantidad de horas facturables.

Veamos, una vez gastamos más de medio millón de dólares haciendo el trabajo para ganar un contrato de un millón de dólares. Demasiado para las ganancias de eso. Algunos de nosotros en el Equipo de Desarrollo de Propuestas de Proyecto intentamos señalar esto, pero se había convertido en un orgullo para nuestra pequeña compañía para ganar las compañías Fortune 500 con las que estábamos compitiendo. Ganamos y perdimos dinero por el contrato de Fist Onteh por eso y otras razones, pero teníamos derechos de fanfarronear.

Como contratista gubernamental una vez, me vi obligado a trabajar horas extras no remuneradas porque el contrato lo permitió y al contratista recibió el pago de mis horas extras. No solo me quedé atrapado en mi trabajo y pasé 4 horas todos los domingos navegando por Internet sin trabajo que hacer. No hace falta decir que me mudé muy rápido después de que comenzaron esas tonterías.

Comprar claridad como nuestro sistema de gestión de proyectos, una aplicación comercial que es tan mala, el 100% de las personas que lo usan han rogado que regresen a nuestro antiguo sistema de cultivo en el hogar (el tipo que le gustó y eligió que se mudó a otros. Compañía), las personas incluso se ofrecieron como voluntarias para trabajar en su propio tiempo para agregar los informes que querían a nuestro antiguo sistema. Pero hemos invertido el dinero, así que estamos atrapados con él. En otras palabras, negarse a abandonar algo que no funciona solo porque era costoso.

Puro desperdicio. Un gasto de TI que tuvo que ser cortado por muchos millones. Entonces, la forma de hacer esto era volar a las personas de TI de todo el mundo. Póngalos en un hotel flash durante una semana. Luego, en el edificio donde se celebraron las reuniones, colocara un piso nuevo. Mármol, por supuesto. Y durante la noche, entre las reuniones cada día, el edificio fue redecorado. Eso es todas las noches durante una semana.

Err ... ¿Prioridades alguien?

Tierra de fantasía.

La compañía para la que trabajo pagó $ 800 por una licencia de gráfico FX: ni siquiera es mi dinero, pero me siento robado.

http://www.softwarefx.com/sfxnetproducts/chartfx/

Solo para patadas, su software colocará archivos por todo el lugar, incluido el registro y los archivos de programa ... sí, todo eso para algunos gráficos de aspecto naff.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a softwareengineering.stackexchange