Pregunta en HN: ¿Cuál es el proyecto más inútil en el que han participado?

Reflexión sobre el trabajo innecesario

• La experiencia de un empleado que trabaja en el departamento de automatización de pipelines de la empresa.
• El equipo decidió descartar una herramienta interna por problemas de mantenimiento y creó un pipeline que automatiza la implementación de esa herramienta por si otro equipo la llegara a necesitar.
• Este mes, uno de los miembros del equipo detectó una posible mejora en la automatización, y se eligió a ese empleado para aplicar cambios a la herramienta anterior.

La contradicción de la automatización de pipelines

• Después de aplicar los cambios, un pull request no fue aprobado debido a ajustes solicitados en detalle por otra persona del mismo equipo.
• Esos ajustes buscaban aumentar la resiliencia de la automatización del pipeline ante escenarios muy poco frecuentes.
• Sin embargo, esa misma semana el líder del equipo informó a otros equipos que la herramienta interna había sido descartada y que ya no debía usarse.

La carga de un trabajo sin sentido

• Se cuestiona la necesidad de una automatización de pipeline que implementa el uso de una herramienta descartada.
• Como la herramienta fue descartada, también se cuestiona por qué hacen falta ajustes para una automatización que nadie va a usar.
• Hay confusión sobre por qué se asignó un trabajo que parece una pérdida de tiempo.

La opinión de GN⁺

• Esta situación deja en evidencia la falta de comunicación dentro de la organización y problemas en la gestión de procesos. Por un lado, hubo un aviso oficial de que la herramienta había sido descartada, pero por otro lado todavía se seguía trabajando en mejoras relacionadas con ella.
• Este problema provoca desperdicio de recursos y puede generar confusión y descontento entre los empleados. Eso puede afectar la moral del equipo y, a largo plazo, impactar negativamente en la productividad de la empresa.
• Para evitar este tipo de situaciones, hacen falta lineamientos claros sobre el estado y la importancia de los proyectos, y es clave mantener una comunicación continua con todos los equipos involucrados. Además, se necesita un enfoque estratégico al momento de definir prioridades.
• Este caso muestra un problema común que también puede darse en otras organizaciones o equipos, y ofrece una oportunidad para revisar y mejorar sus procesos.
• Para los empleados que atraviesan una situación así, es importante verificar periódicamente si su esfuerzo se está usando en una dirección valiosa y con sentido y, si hace falta, plantear el problema a sus superiores o al área de recursos humanos.

[GN⁺]

Opiniones de Hacker News

• Experiencia desarrollando un sistema ERP

  • Experiencia trabajando en un sistema ERP interno desarrollado durante 15 años por distintos desarrolladores.
  • El sistema era el núcleo de la empresa, pero la gerencia lo señaló como la causa de los problemas.
  • La nueva gerencia impulsó su reemplazo por una solución estándar de la industria.
  • El CTO y el autor insistieron con fuerza en que el proyecto se pasaría del presupuesto y fracasaría, pero la gerencia creyó en el proveedor y siguió adelante.
  • El proveedor no entendió la magnitud del proyecto y, aun así, se mostró confiado mientras omitía funciones importantes.
  • Al final, después de 5 años, el proyecto terminó en fracaso tras desperdiciar millones de dólares.

• Intento de entrar al negocio de medidores inteligentes de energía

  • Experiencia en una gran empresa de medios que intentó entrar al negocio de los medidores inteligentes de energía.
  • Ya habían comprado, etiquetado y almacenado miles de medidores en una bodega.
  • El desarrollo del API estaba terminado, pero la UI tenía problemas y necesitaba correcciones.
  • Había un presupuesto de millones de dólares listo para el lanzamiento de marketing, pero el mismo día del lanzamiento la junta directiva canceló todo por la imagen de marca y el riesgo de fracaso.

• Experiencia con un proyecto sin sentido

  • Desarrollo de un sistema llamado "EnGUAGEment meter" para instalarlo en cada pasillo y mostrar el estado de ánimo de los empleados.
  • En el cumpleaños del CEO había que aumentar la participación.
  • Al final, apenas lograba una participación diaria de 30-40%.

• Proyecto de control de acceso a la red de un gran minorista

  • Le asignaron construir ACLs en routers Cisco, pero se supone que el proyecto fue cancelado a mitad de camino.
  • El autor construyó un sistema automatizado, pero después nunca volvió a saber cómo siguió el proyecto.

• Degradación intencional del rendimiento para dejar de usar una herramienta interna

  • Por pedido del VP, realizó un trabajo para volver deliberadamente más lenta una herramienta interna antigua.
  • Se agregaron mensajes de error falsos y retrasos aleatorios para provocar quejas de los usuarios.

• Migración urgente a AWS en una empresa SaaS

  • Después de una adquisición, recibió la orden de migrar a AWS, pero por los altos costos que eso generó, al final volvieron a mover todo a un centro de datos.

• Proyecto de actualización de pruebas unitarias en una empresa de software y hardware de Nueva Zelanda

  • Con un presupuesto de 10 millones de dólares, el objetivo era actualizar las pruebas unitarias, pero el proyecto cambió de rumbo a mitad del camino y pasó a desarrollar una herramienta de inspección de paquetes.
  • El líder del proyecto renunció a mitad del proceso y, aunque el resultado no sirvió para nada, la empresa evaluó el proyecto como exitoso.

• Desarrollo de un simulador en una clase universitaria de programación

  • Después de la primera clase, quiso hablarle al profesor sobre desarrollar un simulador, pero el profesor le dijo que lo eximiría de asistir a clases y le pondría una A.
  • Al final del semestre, el profesor no recordaba la promesa, y solo después de ver el simulador le cambió la calificación.

• Desarrollo de un sitio para jugar Magic: The Gathering en línea

  • Desarrolló un sitio mejor que las opciones existentes, pero no lo publicó por problemas de derechos de autor.

• Desarrollo de equipo de prueba para una placa de control satelital

  • Desarrolló equipo para probar una placa de control satelital, pero el programa fue cancelado, así que el equipo nunca se usó y terminó desechado.