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

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?

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.}

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.

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.

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.

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.

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

La persona principal para corregir los errores recibe su nombre.

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?

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 ".

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.

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.

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.

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í.

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.

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).

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 ".

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.

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"?

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)

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!

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.

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.

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.

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)

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.

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.

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).

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.

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.