Mi jefe decidió agregar un campo de "persona culpable" a cada informe de error. ¿Cómo puedo convencerlo de que es una mala idea?

694

En uno de los últimos movimientos "WTF", mi jefe decidió que agregar un campo "Person To Culpa" a nuestra plantilla de seguimiento de errores aumentará la responsabilidad (aunque ya tenemos una forma de vincular los errores con las características / historias). Mis argumentos de que esto disminuirá la moral, aumentará el señalar con el dedo y no explicaría las características faltantes / incomprendidas reportadas como errores no se han escuchado.

¿Cuáles son algunos otros argumentos fuertes contra esta práctica que pueda usar? ¿Hay algún escrito sobre este tema que pueda compartir con el equipo y el jefe?

MK_Dev
fuente
79
Hola chicos, soy el "jefe" que introdujo el campo WTF. He aquí por qué agregué un campo "Peson to Blame" a nuestro sistema de seguimiento de errores: news.ycombinator.com/item?id=4179298
Jason
98
"¿Podría haberle dado el nombre de algo más políticamente correcto para que el sentimiento no se lastimara? Claro. ¿Pero cuál es la diversión en eso? El punto era dar a conocer la cantidad de errores de producción después de cada lanzamiento, así que ¿por qué no agregar una pequeña dosis? de vergüenza pública en buena medida? Y para ser claros, el propósito del campo y, en última instancia, el propósito de la métrica, no es determinar la causa del error. Mierda sucede y tenemos mejores cosas que hacer. El propósito final de la métrica es un recordatorio para que cada desarrollador sea mejor cada día ". --- Creo que todas estas "razones" son intrínsecamente incorrectas.
ulty4life
31
@ Jason en lugar de inventar los campos de Jira, considere contratar a uno o dos probadores . Por cierto, en su caso, tener un campo de causa raíz (no importa cómo lo nombre) me parece de poca importancia porque ya estableció la conexión entre la ausencia de probadores y el aumento de errores de producción .
mosquito
68
@ Jason El error está en el código, no en un desarrollador. Debe ser una de esas personas que piensa que las revisiones de código son para revisar desarrolladores, no para código.
Danny Varod
81
Su jefe es la "persona culpable",
escriba

Respuestas:

675

Dígales que este es solo un nombre de aficionado para el campo Causa raíz utilizado por profesionales (cuando el rastreador de problemas no tiene un campo dedicado, se pueden usar comentarios para eso).

Buscar en la web para algo así como el software de análisis de causa raíz de errores , hay un montón de recursos para justificar este razonamiento 1 , 2 , 3 , 4 , ... .


... la causa raíz de un defecto no siempre es un único desarrollador (que es el punto principal de este campo) ...

Eso es exactamente por qué la "causa raíz" es profesional mientras que la "persona culpable" es aficionada. La responsabilidad personal es excelente, pero hay casos en los que simplemente queda "fuera" del equipo de desarrollo.

Decirle a su jefe cuando no es un único desarrollador de la culpa, campo de causa raíz que definitivamente cubrir ( "error de codificación hecha por Bob en cometer 1234, se perdió por Jim en la revisión 567" ). El punto de usar el término causa raíz es cubrir casos como ese, junto con casos que están fuera del alcance del equipo de desarrollo.

Por ejemplo, si el error ha sido causado por un hardware defectuoso (con la persona culpable de ser alguien fuera del equipo que lo compró y lo probó), el campo de causa raíz permite cubrir eso, mientras que "el único culpable del desarrollador" simplemente se rompería El flujo de seguimiento del problema .

Lo mismo se aplica a otros errores causados ​​por alguien fuera del equipo de desarrollo: errores del probador, cambio de requisitos y decisiones de administración. Digamos, si la gerencia decide omitir la inversión en hardware de recuperación de desastres, "culpar a un solo desarrollador" por un corte de electricidad en el centro de datos simplemente no tendría sentido.

mosquito
fuente
13
Este es un buen punto. Sin embargo, la causa raíz de un defecto no siempre es un único desarrollador (que es el punto principal de este campo). Como resultado, identificar un solo desarrollador responsable de un defecto hace más daño que bien, en mi opinión.
MK_Dev
326
+1 por redirigir la idea del jefe hacia algo más productivo (siempre más fácil ganar una batalla de esa manera)
benzado
16
"Causa raíz" también cubre (¡con suerte la mayoría!) Los casos en los que no se puede culpar a una sola persona, como "falla del software del proveedor", "error de documentación de la API", "mayor volumen de lo esperado".
James Anderson
29
Excelente. Incluso su ejemplo para una sola persona responsable presenta a dos personas, lo que ilustra perfectamente la estupidez del ejercicio.
Urs Reupke
15
No olvide que las "causas contribuyentes" también serían útiles, ya que a menudo es más fácil hacer algo al respecto. Por ejemplo, si "causa raíz" fue "error de codificación en commit 5678" y "causa contribuyente" fue "commit 5678 no se revisó porque los requisitos llegaron demasiado tarde", entonces no puede evitar todos los errores de codificación, pero puede ser más estricto sobre retrasar la entrega la próxima vez que se retrasen los requisitos.
Jan Hudec
272

Otro resultado probable para dicha política es que las personas no informarán sobre errores si creen que pueden ser la "persona culpable", por lo que en realidad reducirá la cantidad de errores informados por el equipo.

Laurent Parenteau
fuente
300
Bueno, ¡el jefe estará feliz! Habrá menos informes de errores y, por lo tanto, la calidad debe haber aumentado.
nicodemus13
55
El jefe probablemente esté en el pago relacionado con el rendimiento y un indicador clave de rendimiento es la cantidad de errores reportados. Con suerte, él / ella compartirá su bono con el equipo de desarrollo al final del año.
Matt Wilko
54
Por experiencia, este no es un resultado "probable", es 100% absolutamente seguro de que esto sucederá, porque los desarrolladores son personas inteligentes. Lo que también verá es un aumento masivo del tiempo dedicado a discutir violentamente con los evaluadores que sus "errores" no son errores.
Joris Timmermans
Es probable que la persona que informa el error no sea la persona a la que root causequiero decir, ¿pienso en tratar de encontrar un error en su propio código después de 36 horas de escribir código esta semana?
Malaquías
141

El argumento principal que usaría en su contra es preguntar qué problema está tratando de resolver. Es casi seguro que hay mejores formas de resolver el mismo problema.

Por un lado, ¿hay realmente solo una persona a quien culpar? Si es así, estás haciendo algo más mal. Un buen proceso requiere un trabajo a través de un analista, un programador, un revisor y un probador antes de llegar a la producción. Si no está haciendo todas estas etapas, tal vez esa sea la solución al problema que su jefe está tratando de resolver. Si es así, ¿cuál es el culpable? Puede que ninguno de ellos sea el culpable.

No es bueno que la gente muerda y señale con el dedo, tratando de evitar una marca negra que no desaparecerá una vez que esté establecida. No resuelve nada. Muy pocas personas son maliciosamente negligentes. Debe hacer una retrospectiva adecuada , ver qué salió mal y qué puede hacer para asegurarse de que no vuelva a salir mal.

A partir de eso, verá claramente si una persona tiene la culpa regularmente y ese puede ser un problema diferente para tratar.

El truco para detener a un gerente empeñado en crear responsabilidad es ofrecerlo libremente , pero de una manera que realmente tenga sentido para usted.

pdr
fuente
55
Un proceso realmente bueno evita que el analista y el programador sean dos personas diferentes: mis experiencias con analistas que no pueden programar y programadores que no pueden analizar fueron realmente malas. Sin embargo, +1 por tu respuesta.
Doc Brown
@DocBrown bien, mis experiencias con el analista y el programador para ser dos personas diferentes han sido bastante positivas hasta ahora. Aunque en mi caso fue más bien los analistas que pueden entender la lógica del programa y programadores que pueden participar en el análisis :)
mosquito
@gnat: en mi humilde opinión, hacer que el analista sea uno de los programadores de su equipo puede mejorar su velocidad y calidad de desarrollo en un orden de magnitud.
Doc Brown
3
Este libro lo ayudará a encontrar las palabras para mantenerse firme amazon.com/The-Power-Positive-No-Relationship/dp/0553384260/…
zundarz
2
El enlace para "ofrecerlo libremente" está roto.
Tom Fobear
79

Hay al menos tres problemas con ese campo.

La primera es que culpar a la gente no es bueno para la moral. Okay. Pero tal vez no le importa la moral y quiere despedir a los malos desarrolladores. Difícil de discutir.

La segunda es que acertar en el campo va a ser difícil y se hundirá bastante. Es más complejo que simplemente descubrir quién escribió el código incorrecto. Y cualquier información potencialmente difícil de entender puede ser sacada / engañada. Pero tal vez esté preparado para pagar ese costo y auditar la información. Multa.

El problema más fundamental es que este campo no será una buena métrica para tomar medidas. Claro, tendrá una buena clasificación de cuyo código causa la mayoría de los defectos. ¿Pero adivina quién estará en la parte superior de esa lista? Probablemente el fundador de la compañía, o tal vez un desarrollador superior que tiene una tasa de defectos muy baja pero es tan productivo que escribe una parte desproporcionada del código. Entonces terminará disparando a su mejor desarrollador, o hará que disminuya la velocidad tanto que ya no sea su mejor desarrollador. Y el tipo que escribe una línea de código al mes, preferiblemente comentarios, probablemente será recompensado por sus bajos números de defectos.

Otra falla métrica del software.

ptyx
fuente
16
Me sorprende que nadie más haya mencionado el hecho de que analizar el historial de un error en los intentos de culpar va a ser una gran pérdida de tiempo. Si no hay otros argumentos que muerdan, eso debería.
un CVn
¿Entonces ustedes corrigen errores sin tratar de averiguar el historial y la causa raíz? En ese punto, está reparando los síntomas y posiblemente ignorando los problemas centrales legítimos. Si en realidad es un problema con una persona, es útil saber por qué la persona cometió el error para poder corregirlo. Si se trata de un hardware defectuoso, se puede cambiar por algo más estable.
Jordania
Estoy bien con culpar / alabar a las personas. Pero debe hacerse con mucho cuidado, porque es fácil causar peores problemas al tratar de hacerlo que el problema original. El campo 'culpable' no parece un enfoque 'muy cuidadoso'.
ptyx
68

La causa raíz de un defecto de campo nunca es una sola persona. Las personas perfectamente conscientes cometerán errores, y un proceso que espera que sean infalibles no es razonable. Si no verifica los cambios en los sistemas de producción antes de la implementación, ya sea manualmente o mediante pruebas automatizadas, entonces los errores son inevitables.

Incorrecto:

Bob se olvidó de verificar la entrada y el programa se bloqueó al dividirse por cero.

Derecho:

El código vulnerable a un error de división por cero no se detectó antes de la implementación. Se han agregado nuevos casos de prueba para verificar el manejo adecuado de la entrada no válida. El código fue corregido y todos los nuevos casos de prueba están pasando.

Kevin Cline
fuente
66
Aún mejor: las pautas / estándares de codificación y las listas de verificación de revisión de código actualizadas para evitar que esto vuelva a suceder.
Pensamiento extraño
Entonces, ¿qué pasa si los errores son inevitables? ¿Qué hay de malo en culpar a alguien por ellos? Creo que su opción 'Incorrecto:' es más clara que su opción 'Correcto:'. El equivocado es realmente simple. El 'derecho:' uno es prolijo.
Adam Bruss
3
@ Adam: ¿mi respuesta no responde directamente a tu pregunta exacta "¿Qué tiene de malo culpar a alguien ...?"
Kevin Cline
54

Cambie "Persona a quien culpar" por "Persona a quien alabar"

La persona principal para corregir los errores recibe su nombre.

Noche oscura
fuente
99
No creo que esto responda la pregunta. Es un buen sentimiento, pero no proporciona argumentos en contra de ese campo.
Bryan Oakley
21
Además, sabes que un tipo introducirá cientos de errores "accidentalmente" y luego los arreglará a todos, esperando que algún administrador idiota sea lo suficientemente tonto como para pensar que es el mejor
solucionador de
Muy a menudo, desea saber quién escribió el código y quién está mejor calificado para solucionarlo si sale mal. Parte de la reacción violenta de "persona culpable" es que implica que se culpa a alguien.
Muz
49

Respuesta simple

El campo "Culpa" se usará para nada más que chivos expiatorios y huellas dactilares, la moral se desplomará, la confianza del equipo se destruirá y todos tratarán de encontrar formas de demostrar que algo no es su culpa en lugar de arreglarlo. Las personas también estarán más inclinadas a guardar silencio sobre los errores en lugar de denunciarlos, porque no quieren que un colega se meta en problemas. Es completamente contraproducente.

¿Qué es más importante, victimizar a alguien por cometer un error honesto o solucionar el problema lo más rápido posible?

Su jefe parece pensar que los errores son un signo de pereza o descuido. Ellos no están. Son un hecho de la vida. ¿Cuántos parches saca Microsoft en un año?

GordonM
fuente
8
+1, una cultura de culpa siempre conduce a una cultura de guardar silencio sobre los errores y esperar que nadie más se
45

Si desea un poco de desobediencia civil, haga que el equipo acepte poner una lista de todos los desarrolladores en ese campo para cada error. Si eso no encaja, escribe "¡Soy Espartaco!" en lugar. El punto, por supuesto, es que todos ustedes son responsables de todos los errores, y no están contentos de tener que señalar a la persona que creó cualquier error.

Otra opción: jugar junto. No haga nada en particular, solo haga un buen trabajo y complete el campo con la mayor precisión posible durante unos meses. Luego explique al jefe que asignarle la culpa a cada error hace que todos los miembros del equipo estén descontentos e incómodos. Dígale que todos sienten que hay poca correlación entre los errores creados y cualquier otra cosa (habilidad, esfuerzo, cordura). (Ayudará si puede ejecutar algunos números que muestren que realmente no hay una correlación).

Desobediencia civil de Gandhian: ponga su nombre en cada campo (a menos que otros desarrolladores den un paso al frente y pongan su nombre por sus errores), y acepte la culpa de cada error, sea suyo o no. Nada hará que ese campo o la idea de culpar a alguien sea más inútil que esto. Si su jefe le pregunta por qué es su nombre en cada campo, puede explicar "porque no creo que el desarrollo sea un juego de culpa, si realmente necesita que la gente culpe y crucifique, entonces crucifíqueme por todo y deje que mi equipo trabaje pacíficamente ".

Caleb
fuente
15
Votaría por el primer párrafo, pero el segundo me parece cuestionable. En mi experiencia, el tipo de personas que sugieren ideas como un campo de culpa no son el tipo de personas que se preocupan por incomodar a las personas.
GordonM
@GordonM Realmente depende de la personalidad del jefe. Un tipo sin tonterías, que no sufra tonterías puede que no se vea amablemente en el enfoque de Spartacus, pero aún podría estar dispuesto a admitir que el campo crea más problemas que beneficios. Si el OP y el equipo muestran que respetan al jefe lo suficiente como para probar su idea, él podría respetarlos lo suficiente como para escuchar cuando luego le digan que no parece útil. Además, puede saber algo que el OP no sabe, como que tiene dos herederos de un par de perdedores de otro equipo y quiere estar en condiciones de recopilar algunas métricas.
Caleb
3
Además, el equipo aún sufrirá. ¿Todo para demostrar que el jefe estaba equivocado?
Oleg V. Volkov
29
Siempre ponía el nombre del gerente allí. "En cualquier organización, el trabajo se hunde hasta el fondo, mientras que la responsabilidad flota hacia la cima".
David Schmitt
3
@David: Tanto la crema como la espuma flotan hacia la parte superior. ¿Con qué estás tratando en tu organización?
Donal Fellows
32

Una vez tuve un jefe que implementó un sistema muy similar a este, y aunque no era programación (era diseño de impresión para un periódico diario), el concepto y la respuesta adecuada son los mismos.

Lo que hizo fue, en lugar de agregar un campo de "persona culpable" en nuestro papeleo, le dio a cada uno de los diseñadores un conjunto de pegatinas de colores. Cada diseñador recibió una pegatina de color diferente y se le indicó que para cualquier diseño trabajado o incluso tocado, la pegatina debe agregarse a la documentación de ese diseño.

El objetivo declarado del jefe para "la iniciativa de la pegatina" era establecer la fuente de todos los errores de nuestro departamento (errores en el papeleo, declaraciones incorrectas, copia incorrecta, esencialmente el equivalente impreso de errores)

Lo que hicimos fue darle a cada uno de los otros diseñadores una cuarta parte de nuestras pegatinas para que todos tuviéramos todos los colores, y en lugar de poner solo nuestro color en cada diseño, pusimos los cuatro colores de los diseñadores.

No solo escriba su nombre en el cuadro [Culpa], ponga el nombre de todos los que están en el equipo / proyecto y asegúrese de que todo el equipo haga lo mismo.

Trabajamos juntos contra su perra orwelliana y, como resultado, en realidad terminamos descubriendo los errores de los demás y hablando entre ellos sobre el tema, y ​​finalmente tuvimos una reducción significativa en los errores. Sin embargo, ella era una gerente de mierda, y en lugar de reconocer que su iniciativa terminó uniéndonos y aumentando la productividad, se puso completamente nerviosa y disolvió el sistema de calcomanías y lo declaró un fracaso y nos reprendió formalmente a todos.

fifthestei8ht
fuente
1
La suya fue una historia divertida y casi responde la pregunta. Puede considerar ajustar el tono y la verborrea para una lectura más positiva. De lo contrario, seguirás siendo rechazado. (Voté su respuesta.)
Evik James
20

Terminará castigando a su programador más prolífico. Lo más probable es que una o dos personas sean los mejores empleados que han trabajado en la mayoría de los proyectos. Si tiene, en un departamento de 10 personas, un codificador que es solo una fuente de salida y ha escrito el 60% del código de la interfaz, entonces el 60% de los errores estarán en su código.

Explique que este sistema hará que parezca que la persona que escribe más código es el peor programador, y la persona que escribe menos código es el mejor programador.

Bill B
fuente
20

Esto se parece mucho a cuando Scott Adams señaló la sabiduría fallida de un Bug Bounty cuando el Jefe de pelo puntiagudo en Dilbert. Wally anunció que iba a ir y 'escribirle una nueva Mini Van ".

Historieta de Dilbert para el 13/11/1995 del archivo oficial de historietas de Dilbert.

Recuerdo una vez cuando Snow Skiing que alguien señaló que "no caer" no era la señal de un buen esquiador, pero a menudo la señal de alguien que no intenta nada (o que en realidad no esquía en absoluto).

Los errores se pueden introducir en el código por una mala programación y un diseño deficiente; pero también pueden venir como consecuencia de escribir muchos códigos difíciles. Dinging las personas que producen la mayoría de los errores es tan probable para los desarrolladores pobres como los altamente productivos.

Parece que su jefe puede estar frustrado con la cantidad de defectos. ¿Le apasiona a la gente de su grupo la calidad? Crear un campo 'qué' para la causa en lugar de un campo 'quién' podría ser más productivo. Por ejemplo: cambio de requisitos, falla de diseño, falla de implementación, etc. Incluso esto fallará a menos que haya una intervención grupal para mejorar la calidad del producto.

Mark Hancock
fuente
19

Tal vez deberías verlo como "¿Quién está en la mejor posición para corregir el error?" Una parte de mí también siente, lo rompiste, lo arreglaste. Debería haber cierta responsabilidad.

No estoy de acuerdo con mantener algún tipo de puntaje. Algunas personas crean más errores porque trabajan en partes más complejas del código. Si las líneas de código no son una métrica útil, dudo que los errores por líneas de código sean mejores. El código nunca se registrará.

En algún momento, un gerente debe saber quién está haciendo su trabajo y quién no, y quién lo hace mejor porque el resto del equipo sí.

JeffO
fuente
19

Es extraño que nadie haya mencionado esto antes: agregar tal funcionalidad al rastreador de errores motivaría a los empleados a intentar jugar con el sistema .

Este es un problema común para enfoques como el que presenta la pregunta, entre otras ideas similares (pago por número de líneas de código, pago por número de errores). Esto animará a muchos a centrarse en obtener una buena puntuación, en lugar de resolver problemas relacionados con el software en el que están trabajando.

Por ejemplo, tratar de enviar un informe de error con una redacción para disminuir la culpa de uno mismo, y empujarlo a otra persona puede llevar a los desarrolladores a malinterpretar la causa del problema (o el trabajo que se le está dando a otro desarrollador que no conoce esa sección de un código tan bueno como el que más estaba trabajando en él y quién fue la causa principal del error) lo que lleva a más tiempo y esfuerzo para solucionar el problema.

vsz
fuente
18

Su pregunta real era sobre cómo cambiar la cultura antes de dejar la empresa, convenciendo a su jefe de que agregar una persona para culpar al campo por los informes de errores es una mala idea. Pero, por supuesto, cambiar la cultura requiere que comprenda realmente por qué es una mala idea.

Esta es una tarea difícil. Además del problema de salvar la cara después de cambiar de opinión, existe el problema básico de que las personas que piensan en soluciones principalmente en términos de culpa individual suelen estar bastante establecidas en esa mentalidad.

Solicitó escribir sobre este tema, y Peopleware le viene a la mente. Es muy apreciado y habla en términos generales sobre cómo gestionar a las personas que realizan trabajos creativos donde el resultado es difícil de medir. El problema es que leerlo no ayudará mucho, tu jefe tendría que leerlo y creer al menos en algo.

Curiosamente, dado que el problema aquí es más sobre las personas que los informes de errores, es muy posible que pertenezca más al lugar de trabajo que a los programadores. Pero el éxito de los proyectos de software generalmente se puede rastrear en gran medida hasta la interacción social humana, por lo que las respuestas reales a menudo son principalmente sobre cosas que trascienden el software.

Mi única otra, medio en serio, la sugerencia es decir (o convencer a un compañero de trabajo que decir, ya que va a salir) que usted está dispuesto a asumir toda la responsabilidad por el éxito del proyecto, y su nombre debe siempre ir en el campo , ya que incluso si alguien más cometió el error directamente, usted ha asumido la responsabilidad de asegurarse de que todos en el equipo realicen un trabajo de calidad.

No tiene sentido, por supuesto, ¿cómo podría respaldar eso, pero algunas personas (especialmente las personas a las que se les echa la culpa) realmente comen esas cosas? Ronald Reagan solía aceptar públicamente la responsabilidad personal cada vez que un miembro de su administración quedaba atrapado en un escándalo (y había bastantes) y en realidad todo salía bastante bien políticamente. La mejor parte para usted es que la responsabilidad generalmente no tiene consecuencias reales, simplemente piensan que usted es un hombre de pie por asumir la responsabilidad.

O tal vez no sea así como se reducirá. No tiene ningún sentido para mí, así que es difícil para mí predecir cuándo funcionará, pero he sido testigo de que funciona cuando parecía no tener que hacerlo (en el lugar de trabajo, no solo el ejemplo de Reagan).

psr
fuente
+1 por sugerir que se explique positivamente cómo gestionar a los trabajadores de la información, en lugar de simplemente atacar esta idea.
Pensamiento extraño
14

Las personas no van a trabajar con la intención de cometer errores, y cualquier estrategia establecida para atribuir específicamente la culpa de lo que puede haber sido o no un error humano es ridículo, sin mencionar que es extremadamente poco profesional.

Por lo menos, una "parte responsable" asignada para hacerse cargo y "arreglar" el problema, o elaborar un plan para rastrear y / o prevenir eventos similares, sería bueno. A veces la solución no es más que capacitación adicional. He trabajado para varias compañías donde era parte de la descripción de su trabajo, para obtener una educación de "compañía pagada / tiempo de la compañía". Un lugar incluso construyó un "centro de capacitación" completo, que la universidad local "presta" en ocasiones, para sus cursos de tecnología industrial.

He trabajado en un entorno de fabricación durante los últimos 20 años, donde los errores de programación no solo causan errores, sino que destruyen físicamente las cosas y / o peor, lastiman a las personas. Sin embargo, una constante en cada campo de la fabricación que se mantiene fuerte es que nunca, bajo ninguna circunstancia, hay alguien a quien culpar. Porque es un defecto en el sistema, simple y llanamente, no un defecto en las personas. Míralo de esta manera, el uso del corrector ortográfico, una herramienta muy efectiva para aquellos menos afortunados en el área del virtuosismo textual, o tal vez solo para los que están un poco sobrecargados ... pero de ninguna manera es un método de culpa o responsabilidad.

Un ambiente de trabajo, sin importar de qué tipo o para qué sirve, es un sistema. Un sistema compuesto por componentes individuales, que si está "en sintonía", funciona en armonía total, o algo parecido.

Lectura sugerida por parte de su jefe: Los 7 hábitos de las personas altamente efectivas

Parece que podría usar un poco de humildad, si no una comprobación de la realidad. Es tan parte del equipo, como todos los demás, y necesita darse cuenta de eso, o simplemente no funcionará, y al final, sostendrá la bolsa de todos modos.

Lectura sugerida y / o investigación de su parte:

Analice 5 por qué el análisis, el análisis de causa raíz ... cualquier cosa que lo coloque en una mejor posición para ofrecer una solución, no un problema . Y su desacuerdo con su jefe, es solo eso, un problema, no una solución. Ofrézcale algo mejor, algo que tenga sentido, e incluso esté preparado para permitirle tomar el crédito por la idea.

En este momento no parece que esté preparado para arreglar nada, porque no tiene una comprensión firme de lo que está roto, si es que hay algo roto, aparte de su mentalidad de "Yo soy el jefe".

¡Buena suerte! Espero que logren superar esto, de una manera que sea aceptable para todos, especialmente en estos tiempos.

EDITAR: Personalmente, desde mi propia experiencia ... "Adelante, culpen a mí. Porque efectivamente, lo arreglaré, y en el futuro, cuando vuelva a suceder, ¿quién estará allí para salvar el día? Sí, tú lo adiviné ... yo, con una gran sonrisa ".

tahwos
fuente
"lo coloca en una mejor posición para ofrecer una solución, no un problema". - Sí, que es el punto principal de esta publicación. No esperaba que explotara así.
MK_Dev
Al final, será un éxito del equipo o un fracaso del equipo, y no importa cuál sea el curso de acción (incluido el juego de la culpa) no funcionará, o incluso se demostrará que es una mala idea, si no se sigue hasta fructificación o fracaso. En otras palabras, la alternativa al motín, de hecho, puede ser simplemente seguir el plan de sus jefes al pie de la letra, con la participación activa de todos, hacia la inevitable recopilación de datos duros, sopesar a favor o en contra de continuar por ese camino de la razón.
tahwos
10

Para rendir cuentas, no querría un person to blamecampo, me gustaría un Person who knows the codecampo o un person who can fixcampo, para saber a dónde enviar el ticket de soporte.

Esto aceleraría el proceso de reparación del error en sí y daría responsabilidad, algo así como matar dos pájaros de un tiro. Yo personalmente le diría esto y le dejaría decidir si esto ayudaría a aumentar la moral y la responsabilidad sin hacer que nadie sienta que fracasaron. Las pruebas extremas no detectan todos los errores, de lo contrario no habría informes de errores.

Malaquías
fuente
9

Dile que "la culpa" es negativa. Cámbielo a "persona para arreglar", entonces al menos se enmarca de manera positiva, y el mismo trabajo aún se hace. ¿Cómo pueden trabajar las personas si se les "culpa"?

José
fuente
2
No se puede "arreglar a una persona" ...
SandRock 02 de
1
Tenemos el campo "persona para arreglar". No es suficiente
MK_Dev
9

Si mi jefe hiciera eso, sucedería lo siguiente, en este orden exacto:

1) Inmediatamente comenzaría a buscar un nuevo trabajo.

2) Cada vez que se informa un error con una persona culpable, el nombre de mi jefe aparece allí, y un comentario sobre por qué un mal proceso en el equipo es responsable de ello. Y CC eso a su jefe (preferiblemente en un lote). ¿Tienes pruebas unitarias? Si no, significa que el proceso de desarrollo está roto, por lo tanto, el error. ¿Tiene pruebas constantes de integración automatizada con todos los sistemas externos? Entonces el proceso de desarrollo se rompe, por lo tanto, el error. ¿Tiene la capacidad de hacer que cada entorno sea idéntico en producción a través de un script para no permitir errores humanos? Entonces el proceso de desarrollo se rompe, por lo tanto, el error. ¿Es terrible un desarrollador? Entonces el criterio de contratación es malo, por lo tanto, la culpa del jefe. ¿Todos los desarrolladores están cometiendo errores estúpidos debido a la falta de descanso porque trabajan 12 horas al día? Entonces el proceso de desarrollo se rompe.

Como nota al margen: todo buen gerente de desarrollo es consciente de lo que escribí anteriormente. Y las estrategias ágiles están destinadas a señalar al jefe o sus superiores por qué el desarrollo se está ralentizando: Mira, estamos gastando el 50% de nuestro tiempo reparando errores. Veamos estrategias para reducirlos, de modo que podamos pasar el 40% del tiempo reparando errores, y luego revisemos este problema para llegar al 30%. etc.

Desafortunadamente, parece que no tienes un buen gerente debido al campo. Entonces sugiero hacer (1) y no mencionarlo al gerente (excepto en la entrevista de salida)

Dmitriy Likhten
fuente
8

Parece que su jefe no tiene una comprensión profunda del software y tal vez tampoco tiene la intención de hacerlo. Entonces él tiene un idioma diferente, una cultura diferente.

Renunciar a un trabajo por un problema como este, incluso antes de intentar dar un paso adelante para encontrar una solución, es simplemente dejarlo. Dejar de fumar es dejar de fumar. No renuncies hasta que él te asegure de que nunca puedes entenderte. Para estar seguro de eso, primero debe intentarlo.

Como no conoce nuestro idioma y es el jefe, el primer paso aquí sería tratar de hablar con él en su idioma. ¿Qué quiero decir con lenguaje? Pensemos juntos:

Somos personas de software, la mayoría de nosotros amamos el trabajo que hacemos, tenemos una conexión profunda con lo que estamos haciendo. De lo contrario, no funciona y uno no puede continuar en este negocio por mucho tiempo sin amarlo o ser un completo ... usted llena los espacios en blanco ...

Él, sin embargo, ve las cosas de manera muy diferente. Con cada informe de error, aunque la mayoría de nosotros nos entusiasmamos para que funcione mejor (no, incluso si a veces es muy estresante, nos encantan los problemas, ¡solo admítelo!), Lo ve como un fracaso, una medida de ser fracasado. Lo primero que debe querer entender es que los errores son buenos. Bugs hace que los clientes amen la compañía. (Ahora este es su lenguaje) Cuando un cliente informa un error, o cuando lo encontramos nosotros mismos, después de que se resuelve, es mucho mejor que la situación que nunca sucedió. Los errores crean lealtad del cliente (¡lo digo en serio!), Los errores crean una gran excusa para la comunicación entre el consumidor y el productor del software.

Para "aumentar el beneficio de los errores", debe ofrecer que los informes de errores sean aún más abiertos. Con cada informe de error y su solución rápida, limpia y buena, los clientes sienten y ven que "¡guau, estos tipos son increíbles! Trabajan realmente duro. Mira estas cosas que están resolviendo. Ni siquiera sabíamos que el software era tan complejo ¡cosa!" bla bla y bla ...

Haz tu movimiento, habla en su idioma. Los errores son geniales para una compañía de software, no son un problema. Nos hacen la vida.

Para la ética del equipo, la eficiencia o cualquier tipo de charla que podría hacer podría funcionar de la manera opuesta a la que pretendía. Si quiere dejar de fumar, él pensará "¡Ajá, mi solución comenzó a funcionar desde el primer día! ¡Los enlaces defectuosos ya han comenzado a caer por sí mismos antes de ser expuestos!" Él cree en su idea de encontrar a los chicos malos en la empresa y es muy difícil convencerlo de lo contrario. ¡Especialmente cuando podrías ser uno de esos chicos malos!

Entonces, concéntrate en su verdadero problema: los errores. Muéstrele que los errores pueden ser muy útiles. Sin ningún problema, una relación es aburrida. Todo lo que no te mata te hace más fuerte. Cada error es una gran oportunidad que puede usar para aumentar la felicidad del cliente.

Esto es solo una cosa que puedes decir. Piense en sus preocupaciones y encontrará muchos otros artículos para agregar a su lista. ¡La CLAVE DE ORO es ofrecer una cosa alternativa en lugar de luchar con su idea!

hasanyasin
fuente
55
No es el votante negativo, pero la pregunta decía explícitamente que se hicieron múltiples intentos para convencer al jefe de que era una mala idea, por lo que el segundo párrafo de su respuesta no era apropiado.
Larry Coleman
8
Estoy muy en desacuerdo con la idea de que hay algo malo en dejar un trabajo cuando la empresa está haciendo las cosas es una tontería. No es su problema arreglar la empresa. Si mi renuncia confirma la propia lógica del jefe en sus ojos, ese es su problema; dejó de ser mío en el momento en que salí por la puerta.
Nate CK
Prefiero tratar de resolver todo lo que pueda. En tal situación, si renuncio, la compañía quedará sin solución, al menos por mí. Si puedo arreglar fácilmente algo en lugar de comenzar desde cero desde cero, prefiero tratar de arreglarlo. Para mí, en esta situación específica, se trata del cálculo de la diferencia de esfuerzo, tiempo y estrés / inversión psicológica que de cualquier manera requiere y también el resultado que puedo alcanzar ... Muchas gracias por su comentario. Es hermoso que todos tengamos diferentes visiones del mundo :)
hasanyasin
Obviamente, si quisiera dejar de fumar, esta publicación no existiría. Dicho esto, @hasanyasin, gracias por la publicación - perspectiva interesante. Sin embargo, el jefe es una persona de tecnología / software / desarrollador, lo que solo hace que este problema sea más problemático.
MK_Dev
@hasanyasin Sobre la bondad del error - ¡Es excelente! ¡Estoy triste porque no puedo poner dos votos a favor! ¡Yo también lo usaré!
Gangnus
8

Si estás haciendo Agile, y parece que eres del comentario de las características / historias . La persona culpable sería la persona de control de calidad que dejó pasar el error o el propietario / cliente del producto que aceptó la característica / historia como completa con el error.

Hice una composición tipográfica en el pasado, aquí está mi opinión al respecto.

Esto es como culpar a un maquinista por faltas de ortografía y otras cosas que un corrector de pruebas debería haber encontrado pero fallado. El tipógrafo hizo la falta de ortografía, pero el corrector de pruebas se lo perdió, por lo que es el corrector de la culpa el que cometió el error de imprimir, no la persona que cometió el error en primer lugar.

En un entorno ágil, es responsabilidad de las personas de control de calidad detectar errores (errores) y es responsabilidad del propietario del producto no aceptar cosas que no son correctas. Estos son dos niveles de lectores de pruebas que deberían aislar a los desarrolladores de las cosas que se liberan, que es la única forma en que algo debe clasificarse como un error en un entorno ágil.


fuente
3
Para empeorar las cosas, los desarrolladores ahora también son QA. Lo sé ...
MK_Dev
Qué actitud tan inquietante.
pdr
1
Haciendo ágil, todo el equipo es "la persona culpable". Agile valora al equipo sobre los individuos y es todo el equipo el que desarrolla la aplicación, por lo que cada error es el problema de todo el equipo. Piense en la situación cuando falla una compilación en un servidor CI. Todo el equipo debería dejar de trabajar y ver si hay que hacer algo. ¡Al menos esto es lo que debería ser!
Sgoettschkes
@Sgoettschkes teóricamente estoy de acuerdo con usted al 100%, el equipo en su conjunto es responsable del producto que se produce. Pero si está tratando de identificar a un individuo específico, las personas que verifican el trabajo son las más responsables de dejarlo pasar.
7

Creo que su gerente está tratando de resolver un problema con la solución incorrecta. Creo que tal vez hay un problema de que se están lanzando demasiados errores y su gerente quiere que los desarrolladores se responsabilicen y se responsabilicen más del código que escriben.

El uso de un desarrollo basado en pruebas y la configuración de un servidor de integración continua (como Jenkins ) ayudará a resolver este problema, sin introducir el "juego de la culpa". Un servidor de integración continua es importante para esto porque cuando alguien comete un código que "rompe la compilación", se envía un correo electrónico al equipo que muestra a la persona culpable. Dado que este código no se ha lanzado a un entorno de producción, este tipo de culpa es más proactivo y alentador (¡y divertido!).

El resultado es que los desarrolladores tomarán más posesión, se sentirán más seguros y habrá menos errores en el código de producción.

Andrés
fuente
Estoy de acuerdo con su primera declaración al 100%. Esas fueron más o menos mis palabras cuando hablé sobre el tema.
MK_Dev
7

Señale que si el error de una sola persona hace que un error termine en producción, entonces hay algo mal con su metodología o su forma general de desarrollar software. Señale que evitar que los errores lleguen a producción es responsabilidad de todo el equipo.

Usando cualquiera de estos dos argumentos, vea si puede persuadir a su jefe de que tener el campo "a quién culpar" como un campo de selección única sería engañoso; y que, por lo tanto, es necesario asegurarse de que el campo "a quién culpar" sea un campo de selección múltiple. Una vez que haya logrado esto, asegúrese de que por cada error, el nombre de todos esté en el campo. Su jefe eventualmente verá que cualquier informe sobre el terreno es inútil.

Dawood ibn Kareem
fuente
6

Para darle algo de crédito al jefe, el concepto de "asignación de culpa" ya está integrado en herramientas como SVN , y el uso apropiado de los datos puede ser constructivo para los desarrolladores al "averiguar con quién hablar" durante la depuración, por ejemplo: http: / /www.codinghorror.com/blog/2007/11/who-wrote-this-crap.html

Si bien estoy de acuerdo con la respuesta de gnat anterior de que un campo de causa raíz es algo bueno, esta no es la misma información y "desnormalizar" el campo para asignar a veces los nombres de desarrollador anteriores para la fuente afectada, y a veces tener un La descripción técnica (p. ej., "no escala a 10000 usuarios") simplemente enturbiará las aguas. Yo abogaría por mantener una causa raízIndique claramente una descripción técnica (por ejemplo, incluso cuando se trata de un error claro del programador, haga que capture detalles como "Excepción IndexOutOfRange cuando fooData = 999"). Esto puede proporcionar algunos comentarios útiles cuando se revisan en masa, y permitir que se tomen algunas medidas correctivas para resolver clases enteras de problemas con cambios arquitectónicos o de marco (por ejemplo, mejorar las clases de contenedores personalizados, entrega de excepciones de nivel superior)

Dicho esto, agregar un campo Person To Blame claramente puede enviar un mensaje muy malo y un mensaje destructivo a un equipo de software que la gerencia quiere señalar y castigar a los desarrolladores individuales que rompen el código con mayor frecuencia. Sospecho que el gerente cree que este escrutinio público hará que los desarrolladores sean más cuidadosos y autorregulados para evitar poner sus nombres en este "muro de la vergüenza", y no entiende por qué los desarrolladores se sentirían amenazados por esto, especialmente si se agrega genéricamente a cada informe de error.

Los problemas para agregar esto como un campo de error / métrica potencial son fáciles de comenzar a enumerar:

  1. Los errores son muy variables en la dificultad de resolver, y una estadística simple de conteo de errores / desarrollador no reflejará esto.
  2. Los desarrolladores son altamente variables en capacidad "" "" "" "" "" "
  3. Muchos sistemas de software tienen componentes que necesitan refactorización, sin embargo, la refactorización de componentes heredados (particularmente si la base heredada no tiene instalaciones de prueba de unidades limitadas) inicialmente introducirá errores. Es probable que los desarrolladores se desanimen de esta "buena" actividad, si existe un estigma / miedo asociado con la generación de nuevos errores (incluso si estos son triviales de resolver y el resultado final es una mejora importante en el sistema).
  4. Los probadores pueden presentar un número muy variable de errores relacionados con el mismo problema, lo que resulta en un recuento de errores / desarrollador muy sesgado, a menos que se realice un análisis más detallado.

Eso es solo la punta del iceberg. Combine esto con la señalización de quién esperaba qué comportamiento de API, resultados esperados incorrectos en las pruebas y problemas "anteriores en la cadena" con requisitos incorrectos / faltantes, y debería ser obvio que una métrica como esta está condenada como sin valor (a menos que El objetivo es dañar la moral y provocar un éxodo masivo.)

Volviendo al punto de vista del jefe, está bien que él / ella quiera averiguar si hay desarrolladores que están rompiendo el código repetidamente, y tratar de hacer algo (con suerte constructivo) al respecto. Intentar obtener esta información agregando un campo a los informes de errores no proporcionará información significativa por los motivos enumerados anteriormente. En mi experiencia, esta información se puede aprender conectándose con el equipo, participando en la mayoría de las reuniones del equipo, integrando (cuidadosamente) la información aprendida en reuniones individuales con los miembros del equipo y familiarizándose con los subsistemas en el código (incluso si no pueden leer el código)

holtavolt
fuente
6

Solo déjalo ir. Su jefe descubrirá por sí solo que causa un problema, si lo hace.

Seamos francos, tienes una opinión y él también. Él es su gerente y su opinión es la que gana.

Sí, puedes ir a la guerra por este problema, pero ¿realmente vale la pena? Dudo que dure más de 3 meses antes de que caiga en desuso.

Pero sabotear esto activamente o gritar sobre eso solo usa capital político que se ahorra mejor para pedir ese tiempo libre adicional, el próximo aumento, la promoción o cuando se va a tomar una decisión de diseño realmente crítica.

En ese momento, cuando realmente cuenta, no quieres que el jefe recuerde que fuiste la persona que saboteó activamente su idea de "persona a la que culpar".

Respeta la oficina incluso si no respetas la decisión.

Ahorre el estrés y el golpeteo de la mesa para decisiones que serán mucho más duraderas.

Palmadita
fuente
+1 para una solución sensata (aunque he agregado una respuesta propia) :-)
Homer6
2
Ese tipo de personas toman la cortesía y la sensibilidad por la debilidad. La próxima vez vendrá con algo mucho peor. Y estará aún menos ansioso por escuchar opiniones. Incluso ahora dice que lastimar a las personas es divertido. Si trabaja junto con esas personas, también deberá convertirse en sádico o masoquista.
Gangnus
5

Dígale a su jefe que desarrollar un equipo necesita habilidades sociales. Incluso podría asentir.

Pero el problema es que esto es algo con lo que los desarrolladores son extremadamente malos. Agregar herramientas que sugieran que culpar es más importante que un análisis adecuado de problemas es contraproducente.

En cambio, necesita incentivos para mejorar las habilidades sociales, y la infraestructura de comunicación que tiene debería respaldar eso. Por ejemplo, acuérdelo positivamente: nombre a una persona responsable de un boleto, que se encarga de él.

También comience con revisiones de código para que puedan aprender unos de otros. Eso ahorra las culpas más adelante.

hakre
fuente
Recuérdele que en la mayoría de los casos puede ser la persona culpable. Presión de tiempo, miembro del equipo, prioridades administradas, herramientas seleccionadas / aprobadas ...
BillThor
Oh hombre, conozco desarrolladores. A menudo buscan la causa por otra persona. Y no son tímidos para discutir. Yo diría que los desarrolladores necesitan buscar de manera proactiva para mejorar sus habilidades sociales y su responsabilidad. El campo de la culpa solo puede ser un síntoma de que en el proceso de desarrollo algo va mal. Apuesto a que los desarrolladores tienen su responsabilidad en ese problema. El gerente también tiene, parece que los errores están creciendo sobre sus cabezas. Por lo tanto, es mejor que hagan un análisis de por qué el bugrate los ha sacado del desarrollo enfocado.
Hakre
44
-1 por sugerir eso developer == no social skills. Los dos no están relacionados por completo. Puedes ser bueno en uno o en ambos, y ser malo en uno o en ambos, y no hay conexión.
Daenyth
@Daenyth: Fue una provocación, tan agradable que te veo provocado. De que estas correlaciones son, naturalmente, no verdadera, y es tonto decirlo (prejuicio). Sin embargo, a menudo los desarrolladores no tienen habilidades sociales. Especialmente aquellos que trabajan en una empresa que se gestiona de la forma en que OP lo describió, supongo.
Hakre
@hakre: Si es el caso donde él trabaja, entonces es solo porque los más hábiles han abandonado la compañía debido a la administración
Daenyth
2

Envíele esta pregunta SO por correo electrónico. Si está abierto a la razón, los comentarios aquí proporcionarán controles de cordura para su razonamiento. Si no es razonable, es poco probable que lo convenza con razones que tengan sentido. Además, podrá leer los motivos fuera de una conversación (que a veces puede ser más convincente debido a la motivación eliminada de "estar en lo cierto" en el fragor de una conversación).

También podrías intentar darle la vuelta. El campo podría ser "posibles pasos para evitar que ocurra un error similar", o algo más corto para ese efecto. Luego, podría agrupar soluciones y votar cuáles implementar para mejorar su lugar de trabajo. Quizás un enfoque orientado a la solución sea más productivo y probablemente mejor recibido (siempre que haya un seguimiento real de la revisión de las sugerencias).

Homero6
fuente
1

Veo dos posibilidades aquí: quiere castigar a las personas que cometen errores, o simplemente no lo ha pensado. Hágale saber que la percepción para todos será que tiene la intención de castigar a quienes cometen errores. Pregúntele si esa es la cultura que quiere alentar.

mi jefe decidió que agregar un campo "Person To Culpa" a nuestra plantilla de seguimiento de errores aumentará la responsabilidad

En mi experiencia, cuando la gerencia quiere "hacer que las personas sean más responsables", lo que quieren decir es que quieren poder imponer un castigo por el fracaso. Ya sea para despedir a los artistas de bajo rendimiento, o simplemente dejar que los critiquen en la revisión salarial anual ("Lo siento, Bob, tuviste 17 errores marcados como tu culpa, y eso supera el límite de 15"), es un castigo.

Probablemente dirá "Oh, no, no queremos eso", entonces pregúntele cómo se usarán esos datos. Recuérdele que no agrega puntos de datos a una base de datos a menos que la vaya a usar. ¿Desea seleccionar según un criterio dado ("Mostrarme todos los errores abiertos en el subsistema creador de informes"), para que pueda trabajar en cosas o para obtener datos agregados ("Qué subsistema ha tenido más errores "), para que pueda hacer un análisis post-mortem. ¿Se imagina algún tipo de tablero de fracaso donde las personas pueden ser humilladas públicamente?

Entonces, ¿qué pretende? ¿Quiere poder decir "Muéstrame todos los errores que son culpa de Bob?" ¿Por qué? ¿O quiere poder decir "Muéstrame quién tiene la culpa la mayor parte del tiempo"? ¿Por qué? El primero no tiene sentido, y el segundo es solo punitivo. O la tercera opción es que no tiene una razón real.

Admito que existe la posibilidad de que él esté buscando a aquellos programadores del equipo que necesitan ayuda para mejorar sus habilidades. Si es así, hay mejores formas de capturar esta información que no crean una cultura de señalar con el dedo.

Andy Lester
fuente
-3

Creo que el aspecto clave a tener en cuenta aquí es cuán abierta es la comunicación en el equipo hacia el 'jefe' y al revés. Sin embargo, señalar con el dedo nunca es bueno desde la perspectiva de la administración, si uno de sus desarrolladores cae en el mismo problema varias veces, podría ser el momento de intervenir e intentar ayudarlo a superar este problema repetitivo (por ejemplo, John no está probando correctamente el código: 3 errores de producción en los últimos 3 meses, vamos a darle una lista de verificación para que recuerde cómo se supone que debe ser su código y cómo debe probarlo).

Desde el punto de vista del desarrollo, 'culpar' ya está incorporado en una herramienta convencional como SVN, por lo tanto, realmente no veo ningún daño al decir "John, por favor, arregla esa basura que escribiste" y pon un nombre al lado de eso. JIRA también incorpora el nombre de una persona cuando presenta un error (sin embargo, el campo en realidad no está destinado a la persona responsable de él, es más bien para que alguien lo solucione).

Sin embargo, aquí está la cosa, como muchos mencionaron anteriormente, si surge un error, es una responsabilidad compartida: desde el desarrollador, los evaluadores, el control de calidad y los gerentes. Si su jefe en algún momento maneja a un cliente enojado por teléfono con cosas como " Lo siento mucho, John nunca lo probó correctamente ", entonces definitivamente estaría buscando otro trabajo. Un buen jefe debería decir "nosotros nos encargaremos de esto". Sin nombres, sin señalar con el dedo, solo soluciones.

Nuevamente, creo que todo se trata de comunicación. Quizás lo único que quiere hacer tu jefe es ver quién tiene problemas en el equipo de desarrollo, o qué tipo de problemas tiene el equipo (¿quizás para las sesiones de entrenamiento?), Pero no creo que descubras exactamente qué hay detrás de su equipo. decisión (o mejor dicho, nosotros carteles / lectores) a menos que hable con su jefe y todo su equipo.

Osvaldo Mercado
fuente