¿Cuál es la forma más productiva de manejar las fallas relacionadas con el desarrollo? [cerrado]

Todos hemos estado allí:

• Su proyecto falló o se canceló.
• El código en el que pasó días trabajando fue rechazado por su equipo.
• El patrón de diseño que presentaste al equipo creó el caos.
• Todos ignoran tus ideas.

Mi pregunta es, ¿cuál es la forma más productiva para que un programador maneje fallas relacionadas con el desarrollo como estas?

Tu proyecto falló.

El desarrollo de software es muy propenso a fallas en los proyectos y, dependiendo de la gravedad, la administración lo maneja mejor.

Muchos proyectos han fallado y muchos más fracasarán, ¡así que tome notas! Descubra por qué su proyecto falló para que no cometa los mismos errores la próxima vez. Aprendes mucho más de tus fracasos que de tus éxitos.

Lo que ha pasado codificando días fue rechazado por su equipo.

Guarda tu trabajo (para más tarde). Hay dos posibilidades: (a) Es una mierda, y el hecho de que varias personas respondieron de la misma manera es una indicación de esto (b) Es realmente un trabajo genial, pero muy por delante de lo que las personas están acostumbradas o pueden entender. A las personas generalmente no les gusta lo que no entienden. Quizás sea mejor mostrarlo cuando sea el momento adecuado O en un lugar diferente con una "Cultura" diferente

Nadie escucha tus ideas en tu empresa.

Probablemente sea una mala idea, O la cultura no está alineada con tu pensamiento. O muévase a un lugar que respalde su cultura o evalúe críticamente su idea nuevamente (objetivamente sin su propio sesgo) -> ¿es realmente mi idea tan buena? <- Mata tu ego

El patrón de diseño que introdujo con fuerza en su equipo creó un desastre.

Sea honesto, hizo todo lo posible pero no resultó cómo lo planeó. Puede ser mejor comenzar de nuevo o aprender de los errores cometidos en el diseño como equipo y seguir adelante.

No son fracasos, son experiencias.

Aprendes y creces de tus experiencias al reflexionar sobre cómo te hicieron sentir y si quieres más de ese sentimiento.

Si es una mala experiencia (como la lista que ofreció), entonces el mal presentimiento que acompaña es probablemente algo que querrá evitar (suponiendo que no tenga la piel tan gruesa que no le importe el impacto de sus acciones).

En general, no te involucres demasiado en compararte con los demás, están teniendo tantos problemas para resolverlo como tú .

• Mantén la calma: no entres en pánico, no mejorará nada
• Control de daños: guarde lo que aún se puede guardar
• Aprenda de sus errores: volver a hacer lo incorrecto probablemente no hará que funcione
• Considere un nuevo comienzo: comience su próximo intento sin una mochila de decepciones y sentimientos de culpa
• Mire las fallas más grandes: en comparación con el primer vuelo de Ariane 5 , su falla es insignificante
• Consulte a un psicoterapeuta si no puede manejarlo solo

Tú construyes algo.

Para mí (no creo que sea adecuado para todos), construir algo (cómics, dibujos, pequeños juegos, cualquier cosa) es como construir un poco de confianza para volver a luchar contra el fracaso. También podría ser una buena manera de expresar su enojo o amargura o cualquier sentimiento relacionado con el fracaso, pero de una manera "constructiva".

Eso me funciona de todos modos.

Bueno, preguntaste :) Uno por uno:

* Your project failed.

Eso no es nuevo. Todos hemos fallado en privado, y todos hemos fallado a la vista de nuestros pares. Cualquiera que haya pasado por la educación primaria y secundaria ha experimentado esto.

Si no puedo cometer errores y esperar un empleo estable, debería considerar enviar un memorando a RR. HH. Para que sepan que los seres humanos no podrán ser considerados en el futuro.

Varias fallas seguidas significa que tiene demandas y especificaciones irrazonables, o no aprende de sus errores. Cualquiera de los escenarios exige una acción inmediata.

Es concebible que muchas personas se registren en algo solo para obtener empleo, y luego encuentren alguna forma de cumplir con los requisitos.

* What you have spent days coding was rejected by your team.

Eso pasa. Como otros notaron, guárdelo. Hazlo otra vez. Por eso lo llamamos trabajo. Creo que, en este caso, probablemente no involucraste mucho al equipo en lo que estabas haciendo.

También podría ser que los requisitos cambiaron ayer o hace una hora. Sin embargo, esto debería ser una excepción, no una norma. La revisión por pares es tan brutal como útil. Si su código se descarta constantemente como 'inadecuado' (o algo así), debería pasar más tiempo seleccionando cerebros e involucrando a otros. Creo que esta pregunta es una falacia en la mayoría de los entornos de equipo, a menos que el "equipo" sea todo menos autodescriptivo.

* Nobody listens to your ideas in your company.

Nuevamente, esto necesita contexto. ¿Cuanto tiempo has estado ahi? ¿Cuánto confían tus compañeros hackers en tu habilidad? ¿Ha considerado que las ideas que resultan en más trabajo para muchas personas podrían invitar a CUALQUIER razón para descartarlo? Una vez tuve que descartar algo porque no estaba listo para IPV6, pero usó un socket de dominio simple en el dispositivo de bucle invertido (exclusivamente). La persona que lo hundió simplemente no pudo soportar más trabajo.

Además, ¿qué tan bien te articulas? ¿Puedes hacer amigos e influir en las personas?

* The design pattern you introduced with force in your team created a mess.

Por eso la fuerza debería haberse evitado. Poder hablar no es un requisito previo para poder escuchar. No hay otros comentarios.

¡Oh muchacho, eso es mucho si realmente quisiste decir que todo te sucedió!

ADVERTENCIA : en muchos de los puntos a continuación, puede sentir que lo critico y que quiero responsabilizarlo por los errores y no tener en cuenta los factores externos. Yo no. Es solo que no das muchos detalles, y yo solo proporciono listas de verificación de acciones para asegurar que las cosas no salgan mal. Sé que he cometido muchos errores (todos lo hacen) y solo mejoramos si aprendemos de ellos. Y para aprender de ellos, debemos comenzar a verlos como errores en primer lugar, y aceptar la responsabilidad de lo que salió mal de nuestra parte. Demonios, acepta la responsabilidad de lo que salió mal en las partes de otras personas, también puedes aprender de eso.

Tu proyecto falló

No hay mucho que puedas hacer para mitigarlo ahora.

Sin embargo, puede hacer mucho para evitar que se reproduzca en el futuro. Sugeriría tratar de mejorar su proyecto y sus habilidades de gestión del tiempo.

Uno de los libros con la mejor relación ((consejos válidos) / páginas) que he leído sobre el tema, aunque quizás no sea el mejor, es la Gestión de proyectos radicales de Rob Thomsett .

Realmente no especifica qué falló su proyecto, pero supongo que una combinación de cosas que desequilibró en el triángulo costo / tiempo / calidad habitual . En mi opinión, el factor más importante es liderar el proyecto y el desarrollo estando siempre en contacto con sus actores técnicos (desarrolladores y evaluadores) pero también con sus partes interesadas. Demasiados proyectos fracasan porque no escuchan a los patrocinadores o partes interesadas y no los presionan para que se involucren en el proceso.

Si no están involucrados, no puedes saber lo que quieren. Si no puede saber lo que quieren, no puede entregarlo. Si no lo entregas, serán infelices. Eso es un fracaso. Además, si no involucra a sus partes interesadas, se desconectan de la realidad de la ingeniería de software, lo que significa que no entienden sus problemas. Si a menudo están en contacto con usted, obtienen una mejor comprensión de lo que tiene que enfrentar. Serán más capaces de entender cuando les diga que una característica "pequeña" [risas] llevará meses. Pueden confiar mejor en su planificación porque ayudaron a construirla. Un proyecto no puede tener éxito con solo "especificaciones al principio, desarrollo, pruebas, entrega al final". Simplemente nunca lo hace. Puede entregar lo que se solicitó en las especificaciones,

Lo más importante también es hacer una retrospectiva y asegurarse de que no tenga ego y no sea un juego de culpa. Solo identifica los problemas.

Lo que ha pasado días codificando fue rechazado por su equipo

He estado en esa situación. Nuevamente, no puedes hacer mucho para mitigar eso, excepto:

• Guárdelo en el SCM para más tarde.
• Tal vez intente introducir pequeños fragmentos en la base de código principal en lugar de una gran refactorización.

Pero hay cosas que puede hacer nuevamente para evitar este tipo de situación:

• ¿Por qué sucedió? ¿Cuál es la razón del rechazo?
• La mayoría de las veces cuando veo que esto sucede (y ese fue el caso para mí también), significa que el desarrollador se fue solo o en modo de codificación de cowboy y produjo cosas que nunca se pidieron. El código que no proviene de los requisitos comerciales puede ser elegante y "mejor", pero a menudo es una pérdida de tiempo y dinero. Además, costará aún más si lo integra, ya que necesitará probar nuevamente. Piense como las personas que le reparten el dinero: también debe ser eficiente en ese nivel.
• ¿Fue satisfactoria la calidad del software producido? ¿Cumplió con las normas y convenciones de actividad en su empresa?
• ¿Reportó periódicamente (y con frecuencia) a los gerentes directos sobre esto? ¿Intercambiaste ocasionalmente con otros desarrolladores del equipo? Si no, no saben nada al respecto, les costará mucho tiempo evaluarlo y revisarlo ahora. NO cuenta al mismo tiempo al final. Es como siempre tratar de posponer la limpieza de su apartamento de alquiler y luego tratar de limpiarlo solo cuando se mude: es un trabajo horrible, es agotador, es más difícil de lo que hubiera sido si se hiciera regularmente, y a menudo no se hará derecho.
• ¿Produjiste pruebas de producción? Pruebas de unidades? Pruebas de integración?
• ¿Se revisó su código en el SCM regularmente? ¿Estaba en una rama diferente? ¿Necesitaba una rama diferente o podría haberse hecho en el tronco? Aplazar el código de confirmación suele ser una mala señal. Obviamente, a veces estás tentado a hacerlo, pero solo te disparas en el pie.

Nadie escucha tus ideas en tu empresa

Bueno, hay 2 opciones aquí, y veremos ambas:

• Tus ideas eran malas.
• Tus ideas eran buenas.

Comencemos asumiendo que eran malas (una vez más, reflexionar sobre eso y aceptar su idea era simplemente malo, podría ser difícil, lo sé). ¿Qué haces para cambiar eso?

• ¿Por qué se te ocurrió la idea? ¿Cuál es la razón ? ¿Existe una necesidad real de lo que su idea intenta traer a la mesa?
• ¿Cómo se te ocurrió la idea? ¿Lo hiciste por tu cuenta? ¿Compartiste? ¿Idea genial? ¿Plan? ¿Prototipo? (haga esto en el orden correcto. Si falla en el camino, descarte la idea, no continúe. O al menos no en su horario de trabajo).

Las ideas son solo ideas. Si solo los sugiere como ideas y son rechazados, no veo por qué se sentiría mal por eso. Sin embargo, si actúas sobre ellos sin notificar a nadie y ENTONCES solo envías tus ideas y son rechazadas, obviamente siento la frustración perdida en el momento. ¡Y tus gerentes lo hacen!

Asumiendo que tus ideas eran buenas:

• ¿Fue buena tu presentación?
• ¿Fue buena su forma de hacer la presentación? (Soy un desarrollador, sé de lo que estoy hablando: somos PITA gruñones, arrogantes y pedantes que siempre tenemos razón y con quienes es difícil trabajar debido a nuestros egos desproporcionados ).
• ¿Tienes un plan para implementarlo? ¿Pensaste en el costo y el tiempo? ¿Pensaste cómo beneficia a los usuarios / clientes? ¿Pensaste cómo afecta las ventas? ¿Pensó cómo trabajar en esa idea podría afectar otros proyectos y prioridades? Me vas a decir, "¿por qué debería hacer todo esto, son el trabajo de mi gerente y los equipos de marketing o ventas?" Excepto en este momento, estás tratando de hacer parte de todos sus trabajos.

El patrón de diseño que introdujo con fuerza en su equipo creó un desastre

• ¿Por qué introdujiste el patrón?
• Si creó un desastre, entonces probablemente:
  • no era el patrón correcto
  • no se implementó correctamente,
  • no estaba integrado bien.
• ¿Cómo lo introdujiste? ¿Cómo define exactamente el estado "desorden"?
  • código menos legible?
  • menos mantenible?
  • las construcciones están rotas?
  • Hay diferentes tipos de "desorden". Saber lo que el lío se podría ayudar a saber qué fue el fracaso de allí, y si era culpa del patrón de diseño.

Además, estoy un poco sorprendido por el enfoque en sí. ¿Tuviste que presionar para que se introdujera un patrón de diseño? Eso parece bastante extraño. Ya existe un patrón, o debe refactorizar una parte de su solución de acuerdo con el patrón. No lo empuja como lo haría con la adopción de un marco o tecnología (como las personas presionaron realmente para tener XML en todas partes, y ahora como las personas comienzan a presionar para poder escribir HTML5 en la cubierta de sus productos en letras grandes y brillantes).

¿Por qué tuviste que empujar? ¿Por qué hubo resistencia? Tal vez estaba justificado.

¿Pudiste proporcionar ejemplos de que este patrón particular ayudaría a mejorar tu base de código de manera significativa (por ejemplo, combinándolo con un ejemplo de Refactorización a Patrones ).

Nota completamente fuera de tema, pero eso es lo que pensé por primera vez cuando leí el título de la pregunta, ya que pensé que se refería a fallas de software ... Tenía un software que implementó una clase BlackHole para gestionar un tipo muy especial de excepciones en una de las componentes. Puede parecer (y realmente lo es) un truco obviamente extraño y sucio, pero el nombre en sí fue tan excelente que todos lo apreciamos por una manera bastante genial de manejar una falla. :)

Paso 1: ¡Está bien enojarse!

Primero, es comprensible estar molesto o enojado cuando se encuentra con un fracaso. Si le da consejos a alguien en tal situación, lo más probable es que no quieran escuchar "Solo supéralo y sigue adelante" o "Piensa en ello como una oportunidad de aprendizaje".

De hecho, creo que puede ser saludable y productivo enojarse y desahogar sus frustraciones, siempre que lo haga en privado o con un amigo. Las personas tienen diferentes formas de hacerlo, pero creo que una de las formas más productivas es escribir una carta falsa de enojo (¡Importante! No envíe esta carta a nadie ). Explique sus sentimientos, como por qué siente que lo que sucedió fue injustificado.

Paso 2: Tómese un tiempo para calmarse.

Asegúrate de haber expresado todo lo que sientes, y después de desahogar tu ira, tómate un tiempo para calmarte. Tal vez solo necesite unos minutos, o tal vez unas pocas horas.

Paso 3: revise lo que sucedió en el paso 1

En este punto, esperamos poder pensar de manera más objetiva sobre la situación. Si escribió una carta, léala para usted. Si confiaste en alguien, entonces trata de recordar lo que dijiste. Si imaginaste gritarle a alguien, entonces solo revisa eso mentalmente.

A menudo escribo una carta cuando estoy enojado y luego, después de calmarme, trabajaré para refinar la carta para comunicar más claramente lo que estaba tratando de decir originalmente hasta que esté satisfecho de que alguien que lo lea entienda lo que era. sentimiento en el momento.

El punto es tratar objetivamente de elegir cuáles fueron tus puntos. ¿Tenían sentido? Quizás necesiten aclaraciones o más detalles. ¿Son infundados? Si te pusieras objetivamente en los zapatos de otra persona, ¿entenderías los puntos que hiciste? ¿Estaría de acuerdo con esos puntos? Puede aprovechar esta oportunidad para evaluarse a sí mismo. ¿Qué hiciste bien? ¿Cuáles fueron algunas cosas que podrías haber hecho mejor?

Paso 4: decide un curso de acción

¿Hay algo que se pueda hacer para remediar la situación o al menos mejorarla? Tómese un momento para considerar si hay algo realista que se pueda hacer para arreglar o mejorar la situación. A menudo no existe, pero a veces sí.

Si tiene la culpa de algo, entonces eso podría ser tan simple como una disculpa formal a alguien, explicando claramente qué salió mal, qué hizo, por qué lo hizo y qué hará para solucionarlo o evitar que suceda en el futuro.

Luego, considere lo que puede hacer para mejorar el futuro. ¿Qué puede hacer para evitar que vuelva a ocurrir lo mismo? Decida qué es lo que quiere lograr y use lo que aprendió del paso 3 para crear un plan para usted.

Si todo lo demás falla, intente reiniciar:

        try
        {
            // ...
        }
        catch (OhNoes111Exception)
        {
            // reboot fixes everything!
            System.Diagnostics.Process.Start("ShutDown", "/r");
        }