Pregunta:
Falta de propiedad de los empleados
Code Project
2019-03-14 22:27:05 UTC
view on stackexchange narkive permalink

Administro 20 ingenieros de software divididos en 4 sub equipos. Todos los equipos tienen buenos estándares de trabajo y un alto nivel de propiedad, excepto uno. Ese equipo tiene un chico senior y tres juniors. Cada vez que hay un error crítico (que afecta a la empresa), este senior siempre lleva el trabajo al día siguiente diciendo cosas como "No puedo terminarlo hoy", "Lo investigaré mañana", "¿ ¿Realmente lo necesito hoy? "o" ¿Cómo vamos a probar eso esta noche? " Incluso cuando le dije que lo necesitaba ahora, dijo que tenía algo más que hacer y se escapó cuando yo no estaba allí. También les dijo a estos jóvenes que también retrasaran su trabajo.

La semana pasada, les dije en una reunión de equipo que esperaba un mayor nivel de propiedad. Si prometen algo, deberían hacerlo. Si hay un error crítico, deben solucionarlo incluso si tienen que quedarse hasta tarde.

Hoy, hubo un error crítico y este senior dijo lo mismo nuevamente: "No puedo terminarlo hoy. Tengo una reunión con amigos y me tengo que ir ". luego se escabulló mientras yo hablaba con mi entrenador.

Esta no es la mentalidad que quiero que tenga mi equipo. Planeo decirle que tiene que cambiar su estilo de trabajo o buscar un nuevo trabajo, y esperé la respuesta. ¿Es demasiado directo para hacer eso? ¿Existe una forma alternativa de solucionar problemas como este?

Actualización

En este ejemplo en particular, el error evita que el 90% de los usuarios inicien sesión el sistema. En promedio, esto ocurre una vez al mes este año, mientras que sucedió dos veces el año pasado. Los errores críticos son errores bien definidos que: 1) impiden que los usuarios inicien sesión en el sistema y 2) impiden que los usuarios compren productos, solo estos dos tipos de errores.

Lo que hicimos para preparar cada lanzamiento:

  1. Teníamos planes exhaustivos en los que todos entendían los requisitos. De hecho, planificamos el nombre del campo y las funciones. Implementé para todos los equipos la regla de que los requisitos no pueden cambiar después del inicio del sprint. También tenemos casos de prueba listos antes del inicio del sprint.
  2. Agregamos búfer a todas las tareas, digamos que si creemos que podemos terminar algo en 1 día, colocamos 1.5 días. Descubrimos que algunas personas siempre subestiman las tareas.
  3. La primera fecha límite fue a fines de enero; es cuando creen que pueden hacerlo con pruebas. Esta es otra regla que implementé en todos los equipos. Las OP nos dicen lo que quieren y nosotros les decimos cuánto tiempo les llevará. Entonces, les dije a otros equipos que todo estaría listo para la tercera semana de febrero.
  4. A fines de enero, dijeron que todas las funciones se realizaron con pruebas en casos de prueba. Los implementamos en nuestro entorno de prueba y encontramos un error en el que el usuario no puede iniciar sesión. Resultó que no escribieron todas las pruebas. Les pregunté cuánto tardarían en corregir los errores y escribir las pruebas, dijeron que dos semanas.
  5. Las primeras dos semanas de febrero, les dije a todos que solo probaríamos y corregiríamos errores críticos en estas dos semanas. Una vez más, los errores críticos son 1. los usuarios no pueden iniciar sesión o 2. los usuarios no pueden comprar productos en la aplicación. Todo lo demás estará en nuestra cartera de pedidos.
  6. Semana 3 y 4 de febrero después de que lo lanzamos a los clientes. Pasamos estas dos semanas arreglando errores no críticos (que registramos desde el n. ° 4) que son bloqueos reproducibles y otros errores menos importantes como el diseño, etc. Nuevamente, todas estas correcciones tienen pruebas.
  7. Lo publicamos a los clientes con todas las pruebas en verde. Después de la implementación, descubrimos que algunos números no eran correctos, por lo que volvimos a probar todo y encontramos que volvía el mismo problema: los usuarios no pueden iniciar sesión.
  8. La última vez que se quedaron hasta tarde en la noche, les di 2 días libres adicionales.
Los comentarios no son para una discusión extensa;esta conversación se ha [movido al chat] (https://chat.stackexchange.com/rooms/91064/discussion-on-question-by-code-project-employee-lack-of-ownership).
¿Puedo sugerir que todos reconsideren sus respuestas a la luz de las ediciones anteriores?
Más preguntas para CodeProject: ¿Este senior al que escribes es la única persona que podría solucionar este error?¿Y quién es responsable de las pruebas previas al despliegue?
¿Me está diciendo (en promedio), una vez al mes, el 90% de su base de usuarios no puede usar su servicio (durante el día) ?.Vaya, tienes que tener un mal control de calidad.¡Debe revisar sus procesos lo antes posible!
@DJClayworth no, no es el único que puede arreglarlo, pero será más rápido porque él lo escribió.El equipo es propietario de todo, desde la escritura de código, las pruebas y la implementación.
@CodeProject ¿Su equipo tiene roles dedicados para probar e implementar, o simplemente tiene un grupo de desarrolladores que hacen todo?
¿Hay alguna consecuencia para este equipo si dejan de hacer lo que están haciendo para intercambiar contextos inmediatamente?Parece que eres muy estricto con los lanzamientos.Si están bajo presión constante y constantemente agotados, y hay duras sanciones por quedarse atrás en algo, o duras sanciones por cometer errores en soluciones críticas.Los haría completamente reacios a saltar a errores críticos.
@17of26 No tenemos probadores dedicados.Los desarrolladores hacen de todo, desde escribir código, escribir pruebas (unidad e interfaz de usuario) y publicar
Ese es uno de tus problemas.Los desarrolladores no son buenos probadores.https://www.joelonsoftware.com/2000/04/30/top-five-wrong-reasons-you-dont-have-testers/ Si en lugar de 20 desarrolladores tuvieras 15 desarrolladores y 5 probadores, tu producto estaría enmejor forma y estarías pagando menos salario.
¿Mide métricas de cobertura de código para las pruebas?
Si el producto es fundamental para su negocio, no entiendo por qué no tiene un equipo fuera de horario en rotación para situaciones como esta.
"Deben arreglarlo incluso si tienen que quedarse hasta tarde".uhh oh no, estás completamente equivocado
Estoy de acuerdo con obtener un conjunto de probadores dedicados, idealmente uno por equipo de desarrolladores.Una cosa que no he visto a nadie mencionar es que el concepto de estimar contra el tiempo está mal visto en Agile, porque los humanos apestan en estimar el tiempo.Esta es la razón por la que las estimaciones se suelen hacer con puntos en relación con alguna secuencia no lineal.La idea es que después de varios sprints, debe tener una idea de cuánto tiempo tomará todo el trabajo en promedio, pero las historias individuales pueden demorar más que sus estimaciones de puntos.Es decir.una historia de 2 puntos tomará un día en promedio, pero puede tomar 3 de vez en cuando.
@17of26 No estoy de acuerdo con su afirmación, como desarrollador en prueba :-) Me parece que haber sido desarrollador durante dos décadas me convierte en un muy buen evaluador: sé cómo piensan los desarrolladores, cómo tomarán atajos y ayudaYo diseño pruebas divertidas para hacerlas tropezar durante las pruebas de integración :-D
@AaronF Eres la excepción a la regla porque realmente te gusta probar :)
"Si hay un error crítico, deben solucionarlo incluso si tienen que quedarse hasta tarde". ¿Es esto una broma OP?Sea menos un esclavista y más un líder.RE: _La última vez que se quedaron hasta tarde en la noche, les di 2 días extra de descanso. Esto también es simplemente estúpido.¿Has considerado que 2 días adicionales no importan si tenían algo importante que les hiciste perder el día que se quedaron hasta tarde?¿Eres consciente de lo mal que se acumula el sueño y el agotamiento al hacer esto?Su obligación para con usted es limitada, está utilizando la propiedad como una especie de arma de culto para controlarlos y parece que el mayor ve a través de ello.
Al leer su actualización, el error crítico aparentemente ha existido durante más de un mes y bloquea una de las funciones más básicas (inicio de sesión).Esto me dice que algo está muy mal en la estructura de sus entornos de desarrollo / integración, arquitectura de servicio y / o planificación.Quedarse hasta tarde arreglando el error no va a funcionar.
"Si hay un error crítico, deben solucionarlo incluso si tienen que quedarse hasta tarde".Es muy probable que el error crítico haya sido introducido por una mala planificación, tal vez no haber realizado suficientes pruebas o haber intentado apresurar a los desarrolladores.Esto es tu culpa.* Usted * necesita asumir la responsabilidad de la mala planificación.Empieza a parecer que el ingeniero senior de ese equipo es el único senior allí, ya que están protegiendo a sus juniors de ti.
@AaronF Creo que la idea central es que un desarrollador es un mal probador * de su propio código *.Me gusta la escritura de Joel, pero la de QA es un poco inestable, incluso si el consejo general es sólido.Tampoco me gusta la idea de que los probadores sean baratos y de alguna manera deberías basar tu decisión en eso.Un buen probador vale su peso en oro.Aparte de la metáfora, en algunas áreas realmente no son más baratos que los desarrolladores, pero tienen el mismo precio.E incluso entonces, no creo que "cuánto tengo que pagarle a la gente" deba ser un factor.Necesita testers, al igual que necesita desarrolladores o escritorios.
_ "el error evita que el 90% de los usuarios inicien sesión en el sistema. En promedio, esto ocurre una vez al mes este año, mientras que sucedió dos veces el año pasado". _ Si puede citar estadísticas sobre un solo error que cubre un período de meses(incluso años), entonces no es crítico, porque aparentemente no ha sido importante arreglarlo en todos estos últimos meses, lo que significa que su senior puede tener razón al ignorar su llamado de urgencia.¿Por qué es crítico ahora, cuando aparentemente no fue crítico todos estos meses?
"Propiedad"! = "Vasallo de la empresa".
@Aaron No entendiste la publicación de Joel.No debe probar su * propio * código, porque la mayoría de las personas evitarán inconscientemente las áreas que saben que son frágiles.Un desarrollador es un gran tester para el código de otras personas por la razón que nombró.Pero considerando la tarifa actual para los desarrolladores en comparación con los probadores, esa es una propuesta bastante cara.
El paso 5-6 es donde te equivocaste.Casos de prueba inadecuados (me doy cuenta de que las pruebas no pueden cubrir el 100% de todo, pero usted indicó que "no escribieron todas las pruebas", lo que supongo que significa una prueba que se planeó escribir, pero no implementar) y luego tomó eldecisión de lanzar de todos modos con solo errores críticos corregidos.Hubiera cancelado / pospuesto esa publicación a favor de una investigación más exhaustiva de las pruebas, etc. (debido a "incógnitas desconocidas").No es una respuesta porque no aborda su problema, pero ¿es esto algo que consideró?
* En este ejemplo en particular, el error evita que el 90% de los usuarios inicien sesión en el sistema.En promedio, esto sucede una vez al mes este año, mientras que sucedió dos veces el año pasado * - ** Diga QUÉ?!?!? ** Su producto ha subido el vientre una vez al mes este año, y un par de veces el año pasado ** Y¿PERMITES QUE ESTO CONTINÚE?!?!? ** *** ¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿¡¿ME ESTÁS BROMANDO?!?!?!?? "*** Su prioridad absoluta es estabilizar este sistema, no solo curarlo, sino hacer lo que seanecesario para que esto no vuelva a suceder.Usted ** NO PUEDE ** bloquear a sus usuarios, o ellos encontrarán a alguien más confiable.¡CUENTA CON ESO!
Esta pregunta parece haber confundido "propiedad" con "estar dispuesto a trabajar arbitrariamente grandes cantidades de horas extraordinarias no remuneradas con poca o ninguna antelación".No son en absoluto lo mismo.Aunque asegurarse de que sus desarrolladores tengan alguna propiedad _real_ (como en acciones / capital en el negocio) puede ayudar.De lo contrario, ¿por qué debería importarles?
@Voo No es solo que un desarrollador pueda evitar un área difícil de probar (cualquiera podría hacerlo).Es que un desarrollador tiene ciertas suposiciones sobre cómo se usarán las cosas que los evaluadores no ("¿Por qué hiciste clic en eso?" "¿Por qué lo hiciste en ese orden") y que si no pensaron en un escenario endev, tampoco lo harán en prueba.Un nuevo par de ojos lo hará.Lo que no significa que el desarrollador no deba realizar pruebas, debe escribir pruebas unitarias.Es solo que las pruebas unitarias no son la única forma de prueba y no se debe confiar en ellas para encontrar todos los errores.O como lo único que haces.Necesita pruebas de integración y humo.
En ninguna parte de su larga pregunta mencionó la causa raíz de * "[Jan] casos de prueba supuestamente terminados. Error encontrado donde el usuario no puede iniciar sesión ... [Feb] lanzado ... [Después de la implementación] volvió a probar todo y encontróel mismo problema vuelve - [hasta el 90% de] los usuarios no pueden iniciar sesión ". * Entonces, ¿cuál es su análisis de la causa raíz de cómo eso pasó de sus pruebas?¿Alguna vez escribiste un caso de prueba que detectara eso?Si no, ¿por qué no?En caso afirmativo, ¿por qué lo lanzó antes de que se corrigiera el error?Por ejemplo, ¿qué diablos hace * "Después de la implementación, descubrimos que algunos números están fuera de lugar (?!) Así que volvimos a probar todo" * ¡¿Qué significa ?!
Honestamente, parece que no eres efectivo para probar cosas, incluso cuando sabes dónde están los errores.Necesita hacer una autopsia con alguien y averiguar cuál fue su falla en el proceso de prueba en ese caso.No azotar a los empleados en horas extra no remuneradas.Tampoco me gusta que cuando mencionas errores que claramente suenan a tu responsabilidad, siempre "nosotros" lanzamos el producto sabiendo que tenía errores graves que los casos de prueba probablemente no cubrieron, o que no puedes medir la cobertura de la prueba con precisión..Eso depende de ti, deja de intentar pasar la pelota.
Las horas extraordinarias no remuneradas, las flagelaciones diarias, etc., no compensan una falta básica de metodología.Si le avergüenza lo que podría revelar una revisión de metodología sobre su proceso, contrate a un consultor externo.Una cosa obvia que ya han mencionado otros es que la gente no debería simplemente probar su propio código.Contratar a un evaluador por equipo también es una buena idea.
Realmente me opongo firmemente a su título.Más como * "Nuestro producto tiene errores graves de usabilidad, nunca hemos escrito casos de prueba que los cubran adecuadamente, nuestras métricas de cobertura no son confiables, pero seguimos publicando código nuevo, ¿qué deberíamos hacer de manera diferente?" *
@seventyeightist Lo descubrí después del lanzamiento de la aplicación y, dado que está en la App Store, está fuera de mi alcance.Nuestro plan para abordarlo es hacer que las pruebas sean más visibles en el tablero.
¿Con qué frecuencia ocurren las emergencias?Si un empleador juega a "debe quedarse hasta tarde para solucionar un problema urgente" * todo el tiempo *, entonces el empleado tiene razón en que no es realmente urgente.
@smci Detectaron el error la primera vez y nuevamente en la nueva prueba.Es el ingeniero en cuestión el que: no es confiable.
@Harper OP dice literalmente que normalmente es dos veces al año, pero este año, con este equipo (no los otros 3 bajo el cuidado de OP), es dos veces al mes.Y si lees la definición de crítico de OP, es bastante crítico ...
¿Los otros equipos también reciben estos "errores críticos" o es solo ese equipo con el desarrollador senior?Supongo (!) Que tiene a cada equipo corrigiendo sus propios problemas (con algún área particular del producto).
@Mars: totalmente incorrecto.El OP dice *** "el error [de inicio de sesión] evita que el 90% de los usuarios inicien sesión en el sistema. En promedio, esto ocurre una vez al mes este año mientras que sucedió dos veces el año pasado" ***.Entonces, cómo lo resumí es totalmente correcto: * "errores severos de usabilidad, nunca hemos escrito casos de prueba que los cubran adecuadamente, nuestras métricas de cobertura no son confiables ..." *.No compre el resto de lo que dice el OP, la semántica sobre "propiedad" es una cortina de humo.Claramente, el producto siempre ha tenido errores críticos en el inicio de sesión, nunca enviaron una versión que lo solucionó, ni nunca escribieron un caso de prueba que lo cubriera
@Mars: ... y la parte decisiva es *** "7. Lo lanzamos a los clientes con todas las pruebas en verde. Después de la implementación, descubrimos que algunos números no eran correctos, por lo que volvimos a probar todo y encontramos el mismo problema que regresa: los usuarios pueden 't login ". *** ¿Puedes detectar los errores de proceso en eso?Las métricas de cobertura (de la funcionalidad de inicio de sesión) son basura.Así de simple.¿De verdad crees que después de un año de esto, tienen un caso de prueba que lo cubre o no?Casi nadie aquí lo hace.¿Dónde habla el OP sobre la causa raíz?En ninguna parte.¿Dónde está el proceso?
@smci Parece que lo estamos leyendo de dos formas diferentes.Creo que OP significa 2 errores críticos durante todo el año, no 2 por mes durante un año.Los errores críticos no necesariamente significan errores de inicio de sesión, por lo que creo que es incorrecto suponer que siempre son los mismos, o incluso errores relacionados.
@smci # 7 dice "no, lo diseñamos bien y alguien lo echó a perder" o dice "el ingeniero senior en cuestión mintió".La razón por la que OP no está hablando de la causa raíz es porque esa es una pregunta separada ... Pregunta a (causa raíz) = ¿Cómo lo arreglamos para que esto no vuelva a suceder?pregunta b (la pregunta que se hace) = Alguien de este equipo se equivocó y la persona responsable no está dispuesta a hacer lo necesario para minimizar el daño
@smci Tengo curiosidad por dos cosas: si el senior TIENE la culpa, ¿cree que debería dedicar horas extra para solucionarlo?(En aras de la indulgencia, digamos OT pagado).¿Y bajo qué condición no es un error de mayor?
@Mars ^^^ No ayuda a nuestra opinión sobre la comunicación básica del OP que los ejércitos de personas aquí todavía no pueden decodificar con precisión lo que dicen que sucedió, y OP ahora no responderá para aclarar los conceptos básicos.^^ Para mí, no, no dice ninguno de esos.Dice que el error existió un año antes de este lanzamiento, nunca escribieron pruebas que lo cubrieran adecuadamente, OP estaba al tanto de eso antes de autorizar este lanzamiento, ahora quieren usar esto tardíamente de alguna manera como un pretexto para la extinción de incendios interminable.Claramente, el OP no tenía un producto liberable.No compre la historia sobre el chivo expiatorio del desarrollador.
@smci No estamos aquí para discutir la realidad, estamos aquí para discutir la historia.Si quieres preguntar lo que pienso si la situación no es como dice OP, entonces debes hacer esa pregunta;)
^^ Dado que es imposible entender con precisión por qué el OP culpa a SrDev, pero que todos los errores deberían haberse detectado con cualquier proceso de software decente, SrDev no es responsable del comportamiento del OP y del desprecio general por el proceso de software.No creo que muchos estén interesados en un espectáculo secundario sobre cuántas noches de horas extra no planificadas el OP cree que tienen derecho.
* "No estamos aquí para discutir la realidad, estamos aquí para discutir la historia." * Es una propuesta muy extraña de hacer.Donde el PO es vago o contradictorio en tantos aspectos básicos que cuestiona tanto su conjunto de hechos como su competencia y comunicación básica, tenemos que tratar de encontrar la realidad objetiva.
@smci Lo siento, no veo dónde se contradice el OP ...
¿Sabes cuál creo que fue la situación más probable?Un conflicto de combinación manejado incorrectamente sin una nueva prueba adecuada.O un error aparentemente no relacionado, donde la persona que lo arregló no imaginó la repercusión y solo probó relacionado con el error.Esto sucede a menudo cuando las pruebas no están automatizadas: prueba solo lo que solucionó (sí, eso no es ideal y presiono por la automatización de pruebas, pero en mi experiencia, no es muy común)
Lo cual es una falla que debe solucionarse mediante un mejor proceso.No cambia el hecho de que fue la falta del senior o que es posible que se requiera una extinción de incendios inmediata.Creo que esta pregunta es el paso 1 y la solución del proceso es el paso 2
@smci * A finales de enero, dijeron que todas las funciones se realizan con pruebas en casos de prueba.Los implementamos en nuestro entorno de prueba y encontramos un error en el que el usuario no puede iniciar sesión.Resultó que no escribieron todas las pruebas * Yo hice A. Oh, en realidad no hice A. Y luego otra vez para este error.Hice B. Oh ... supongo que no hice B.
@CodeProject debe leer https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592 parece que tiene una lucha constante contra incendios y trabajo no planificado en su organización
@Mars: No hay necesidad de que me repita la misma historia poco convincente que ya leí cinco veces antes de que usted la publicara.Tenga en cuenta que cada vez que OP está involucrado en un error, el "nosotros" real se desliza, nunca el "yo".('Sabíamos' que existían errores críticos de inicio de sesión durante un año y nunca los arreglamos (/ ellos), 'nunca' escribimos el caso de prueba, 'decidimos publicarlo,' descubrimos que algunos números están fuera de lugar. En su hipótesis, 'nosotros' no pudimos notar el conflicto de fusión y 'nosotros' no pudimos volver a ejecutar el conjunto de pruebas antes del lanzamiento. Esto es solo una propagación de culpa) ...
En cuanto al OP que decidió lanzar sin todas las pruebas escritas (y deberían tener prioridad, con las pruebas de errores de inicio de sesión en lo alto), ese fue el OP, ¿verdad?Y no me gusta la vaguedad de * "Resultó que no escribieron todas las pruebas" * a) ¿Qué personas específicas?SrDev u otros?b) ¿Cómo diablos no se dio cuenta el OP?c) ¿Cuándo "resultó" - justo antes del lanzamiento?Eso no es un proceso de software.Tratar de culpar de esto a una fusión fallida de una persona no es suficiente.El OP es dueño del proceso).
@smci ¡Toma muy interesante!¡Vi eso como exactamente lo contrario!En lugar de decir "los juniors de SrDev / SrDev no escribieron las pruebas", OP se puso ahí para convertirlo en un "nosotros".para que parezca que OP no estaba echando la culpa.* ¿Cómo diablos OP no se dio cuenta *?OP tiene un equipo de 20. Lo más probable es que OP no sea el que esté revisando el código, o incluso mirando el período del código.Es posible que OP ni siquiera sepa leer el código.Eso * cómo diablos no se dio cuenta el OP * probablemente debería estar dirigido a SrDev ... * OP es dueño del proceso * OP puede no saber nada más de lo que se informa a OP ....
Gran parte de esta conversación solo se proyecta en función de nuestros propios entornos / experiencias y no es realmente útil ... Creo que es hora de dejarlo descansar :)
@Mars: Estoy de acuerdo en que la cuenta del OP y el uso excesivo de 'hicimos X' o la voz pasiva, al describir cosas que salieron mal, hace que sea imposible saber quién hizo / no hizo qué y quién fue / no fue responsable, y haceobjetivamente incontestable.Pero tampoco inspira confianza en la comunicación del OP y, por lo tanto, en su versión de las cosas.De todos modos, sí, bien podría dejarlo.Dudo que OP vuelva y aclare la información que falta.
"Si hay un error crítico, deben solucionarlo incluso si tienen que quedarse hasta tarde". ¿Qué tal usted como compañero gerente?Espero que ** _ tú _ ** los arregles al menos la mitad de ellos antes de preguntarle a otros.Porque usted es un líder y no explicó nada comprensible acerca de cómo mantiene un búfer para errores críticos y cómo paga las horas extras.
21 respuestas:
#1
+341
Jeffrey
2019-03-14 22:37:07 UTC
view on stackexchange narkive permalink

Parece confundir dos cosas:

  • Trabajan cualquier cantidad de horas para resolver problemas inesperados o no planificados.

  • Ellos son responsables y brindan un trabajo de calidad de una manera predecible.

La propiedad no se trata de que el equipo trabaje toda la noche para cumplir sus promesas a los clientes. La propiedad se trata de saber qué hay en el código, cómo funciona, tener un plan y poder decirte cómo y cuándo se harán las cosas. La propiedad es que los desarrolladores tomen las decisiones correctas para que el código funcione correctamente no solo esta noche, sino en los años venideros.

Lo siento si esto es un poco difícil, pero muchos gerentes me han dicho variaciones. tu publicación. La mayoría de las veces se reduce a:

  • falta de mandato claro
  • requisitos cambiantes
  • enfoque a corto plazo
  • urgencia constante

¿Podría explicar en la pregunta qué hizo usted, como gerente, para preparar esos comunicados, empoderar a su equipo y cómo escuchó sus comentarios? Entonces podemos hablar de propiedad.

A veces me resulta difícil expresar mis pensamientos con palabras.Lo ha hecho de manera muy sucinta.Gracias.Si pudiera votar esto hasta el infinito, lo haría.
Bien dicho, sobre todo el último punto.Si todo es urgente, nada lo es.
Si bien estoy de acuerdo, en principio, en mi humilde opinión, estamos ignorando un hecho importante.Si su gerente le pide que comience a arreglar algo HOY, HÁGALO hoy.No pospones para mañana porque crees que puede esperar, pase lo que pase.Es posible que no termine (porque, con razón, es posible que no desee trabajar horas extra), pero comienza lo antes posible, no es su decisión.Está cerca de la insubordinación y, como tal, corre el riesgo de ser disciplinado.
@AdrianoRepetti Estoy totalmente en desacuerdo.Una mala planificación por parte de mi gerente no significa una urgencia de vida o muerte de mi parte.Sí, hago lo que mi gerente quiere lo mejor que puedo, pero también trato de mantener las expectativas de mi gerente bajo control.Si me piden que haga algo que no es razonable, no voy a estresarme tratando de hacerlo.
@AdrianoRepetti En la pregunta original se menciona que el empleado dice que "no puede * terminarlo * hoy", por lo que, por lo que sabe, comienza a trabajar en él, pero no es posible terminarlo hasta el final de la jornada laboral..
@AdrianoRepetti Hoy presionaré el botón de tarea "INICIAR", marcando la tarea como "EN CURSO" y mañana pensaré en trabajar en ella.
Sin comentar sobre los méritos de la respuesta, no responde la pregunta que OP (actualmente tiene) publicada.
+1 por la lógica y la explicación.Pero nada aquí tiene que ver con * propiedad *, a menos que los empleados participen en la propiedad (propiedad real) de la empresa.A veces la gente habla vagamente sobre un * sentimiento * de propiedad, es decir, un sentimiento de responsabilidad, pero eso no es propiedad.Un negocio u otro propietario puede querer que otros sientan o actúen como si ellos también participaran en la posesión de su propiedad, pero eso no hace que esa propiedad sea real.Tal uso es esencialmente ideológico.
esto es exactamente lo que siempre quise decirles a mis gerentes pero nunca pude
@david como empleado no _educa_ a su jefe desobedeciendo sus órdenes.La gente está correctamente despedida por eso.Sí, puedo ver que mucha gente sueña con hacerlo, pero eso no lo convierte en un consejo sensato.
@DavidK Lanzar palabras como "mala planificación" cuando se habla de errores críticos es una retórica inútil.Si su gerente * pudiera * planear eso, estaría mejor servido usando sus habilidades precognitivas para jugar en el mercado de valores o para ganar la lotería.La única "mala planificación" es no asegurarse de que siempre haya alguien "de guardia" para brindar soporte fuera de horario cuando (** absolutamente **) sea necesario.(Y "el 90% de los usuarios ni siquiera pueden pasar de la pantalla de inicio de sesión" * es * una situación que yo llamaría "absolutamente necesaria")
¿Cómo se está votando a favor?Esto debería ser un comentario ya que se reduce a pedir reformulación y elaboración.
@LVDV La respuesta completa, incluido "¿Podría explicarme por favor?", Me parece menos una solicitud genuina de reformulación y más un desaire ligeramente velado a la visión del mundo de los OP.Y 'Vuelva a examinar su visión de la situación porque X, Y y Z' es una especie de respuesta ...
@AdrianoRepetti Como gerente, no ignora los comentarios de los empleados.Como gerente, no ignora las limitaciones de tiempo o recursos.Como gerente, no ignora los problemas que surgen durante el trabajo que están bloqueando el progreso, y aun así, todas esas son "prácticas de gerente" muy comunes.Si su empleado no lo está obedeciendo, busque _por qué_.A veces el problema es con ellos, pero otras veces el problema es contigo.
@Chronocidal Los errores críticos en la producción casi siempre se remontan a una mala planificación.Si un error crítico entra en producción, significa que no hay suficiente tiempo o recursos en la fase de prueba.Los errores críticos a menudo llegarán a la fase de prueba porque no se invirtió suficiente tiempo o recursos en el desarrollo.
@17of26 Estás 100% correcto.Diablos, este es un error de _login_ que afecta al 90% + de la base de usuarios. ¿Cómo diablos esto no fue detectado?
@AdrianoRepetti: Ejemplo del mundo real: durante 6 meses, aproximadamente 80 de mis días (= 4 meses) los he dedicado a emergencias de "incendios urgentes".Cada proyecto tiene ausencias del desarrollador _todos los días_ porque algún desarrollador necesita arreglar algo de emergencia en un proyecto anterior.Durante estos 6 meses, la gerencia me ha impedido específicamente implementar cualquier forma de prueba o revisión de código porque "lleva más tiempo".A veces, los proyectos se suspenden intencionalmente hasta que se vuelven más urgentes que los demás.Saltar cuando la dirección te dice que saltes es exactamente cómo se produjo esta situación.
Si bien puedo estar de acuerdo en que asumir la responsabilidad se trata más de brindar calidad que de dedicar horas extras, el resto de su respuesta no se ajusta a la pregunta actualizada.Su metodología y planificación parece acertada.Parece que el equipo y el desarrollador senior en cuestión no mantienen los mismos estándares que los demás al omitir las pruebas obligatorias y socavar la calidad.** Buen gerente, mal desempeño de desarrollo / equipo **
@SørenD.Ptæus La falla de la administración en este escenario es no llegar a las causas fundamentales de los errores críticos que entran continuamente en producción.Hacer que los desarrolladores trabajen horas extra para corregir los errores críticos es tratar los síntomas y no la enfermedad.
El enfoque retrospectivo de "_un error crítico que afecta al 90% de los usuarios no debería haber entrado en producción_" es bueno y todo eso, pero ** No entiendo cómo la mayoría de la gente está de acuerdo con trabajar en sus funciones en lugar de corregir la forma en que la empresahace dinero**.Incluso si toma una perspectiva de "_estoy tratando los síntomas y no la enfermedad_", el desarrollador líder obviamente no volvería a su escritorio para solucionar la enfermedad (eso sería más una obligación del gerente).
Algo como esto: si el 5% de los usuarios no pueden iniciar sesión, eso es un problema del desarrollador (lo escribió de una manera que tiene un mal camino que puede fallar, QA no tenía visibilidad (o tiempo para jugar)).Si el 90% de los usuarios no pueden iniciar sesión, eso se llama "QA no hizo nada".O la experiencia de usuario de la aplicación es horrenda (es decir, el "camino feliz" es extraño y no hay suficiente guía o mensajes de error).
#2
+124
dbeer
2019-03-14 23:42:37 UTC
view on stackexchange narkive permalink

Incluso cuando le dije que lo necesitaba ahora, dijo que tenía algo más que hacer y se escapó cuando yo no estaba allí.

Hoy, hay un error crítico y este senior El chico dijo lo mismo otra vez: "Hoy no puedo terminar. Tengo una reunión con amigos y tengo que irme". luego se escabulló mientras yo hablaba con mi gerente.

En ambos ejemplos, te refieres a él como que se escapó, pero con tus propias palabras te dijo que no estaba iba a hacer este trabajo y luego no lo hizo. Escapar implica que está siendo engañoso o deshonesto, pero parece que está siendo transparente, y debes reconocerlo. He trabajado con personas que dicen que manejarán las cosas y luego desaparecerán, y esas personas merecen ser despedidas. Alguien que le informa sobre su ancho de banda y luego lo sigue es completamente diferente. La integridad de esta persona no es un problema; solo está desempleado si sus resultados no son suficientes.

La semana pasada, les dije en una reunión de equipo que esperaba un mayor nivel de propiedad. Si prometen algo, deberían hacerlo. Si hay un error crítico, deben solucionarlo incluso si tienen que quedarse hasta tarde.

Esta es una declaración razonable y un nivel de propiedad que los ingenieros senior generalmente deberían aceptar con algunas advertencias:

  1. Los errores críticos deben ser realmente críticos. Por ejemplo, en mi propia carrera me he quedado hasta tarde para corregir errores "críticos" que luego no se implementaron en producción durante dos meses. En esos casos, era un gerente que se asustaba por algo y lo quería ahora en lugar de un error crítico. Por supuesto, también ha habido problemas realmente críticos.
  2. Los niveles de personal deben ser generalmente suficientes. Cumplir con las fechas de publicación y solucionar los problemas es importante, pero si siempre llegamos tarde porque tenemos a 3 personas haciendo el trabajo de más de 4 personas, esa es una situación diferente.

¿Existe una forma alternativa para hacer frente a problemas como este?

Algunas metodologías de desarrollo tienen formas integradas de gestionar estos problemas. En el desarrollo ágil, por ejemplo, los sprints son formas de prometer qué trabajo se entregará. También incluye formas integradas de medir la velocidad (la cantidad de trabajo que se realiza) y, por lo general, va junto con el software (creo que JIRA es el más popular) que determina si un equipo o individuos están logrando o no esos objetivos. En el desarrollo ágil, si necesita cambiar el rumbo a mitad de carrera, como tomarse el tiempo para corregir un error crítico, refleja que está cambiando el alcance inherentemente. Normalmente, sacas cosas para agregar lo que sea que se deba agregar. Este proceso hace que sea realmente fácil evaluar si "no puedo hacerlo hoy" es porque está trabajando duro en otros objetivos importantes o porque simplemente está siendo difícil.

En mi opinión, es un método fantástico para desarrollo de software que, lamentablemente, casi nunca se realiza correctamente.

ACTUALIZACIÓN : en respuesta a las ediciones de las preguntas, este error es de naturaleza absolutamente crítica (en la mayoría de las empresas se llamaría showstopper en lugar de crítico) y debe repararse de inmediato. Seguiría la técnica que describí anteriormente: quitar cosas de su plato a cambio de que él trabaje en ello ahora.

Parece que este proyecto ha sido un desastre y muy estresante para todos los involucrados, pero un error eso hace que el 90% de los usuarios no puedan iniciar sesión y valga la pena quedarse hasta tarde. Debe evaluar si este empleado se ha retirado por completo o no (en cuyo caso debe ayudarlo a cambiar a otro empleo) o si el proyecto lo ha agotado y necesita un descanso.

Estoy de acuerdo con la mayoría de sus comentarios, pero no estoy seguro de que Agile se aplique aquí.Supongo que cuando el OP dice "error crítico", se refiere a algo que ha surgido en el software publicado que realmente debe arreglarse en este momento (por ejemplo, la reciente interrupción de Facebook ...).Es cierto que Agile le permitirá medir el impacto en el horario, pero OP ni siquiera menciona el horario de trabajo existente.
+1 para "Los errores críticos deben ser realmente críticos".La semana pasada vi un elemento "crítico" que finalmente ocupó el sexto lugar en prioridad ... He aprendido, para bien o para mal, que "crítico" es una palabra que puede simplemente ignorarse.
@DaveG No sé si están usando Agile o no;Lo recomiendo como un proceso que deja en claro cuál es el impacto de pedir un error hoy más claro para todas las partes.Mi experiencia es que todas las partes involucradas tienen una mejor experiencia cuando el impacto de escalar un error es más transparente.
Para agregar a esto, la mayoría de los ingenieros son flexibles en cuanto a trabajar horas adicionales para errores genuinamente "críticos".Pero, OP, ¿entonces les da tiempo libre hora por hora en lugar de hacerlo?Si no es así, espere que su personal comience a trabajar para gobernar como lo hace este equipo, porque romper las tripas de la empresa no tiene ningún sentido al final si la empresa no devuelve nada.
Me encanta tener 5 defectos "altos" y "espectaculares" que se reducen a "este menú es lima, pero se supone que es chartreuse".
@Graham Muy bien.Una vez trabajé para una empresa donde el director ejecutivo reprendió a mi equipo por llegar a las 11 a. M. Después de trabajar hasta la medianoche de la noche anterior para cumplir con una fecha límite impuesta por la dirección.Le respondí que si él no estaba contento, todos estaríamos felices de seguir trabajando estrictamente nuestras horas contratadas.Por suerte para él, tuvo el suficiente sentido común para callarse y no volver a criticar a ninguno de nosotros por llegar tarde.
@Graham La pregunta se ha actualizado;"_La última vez que se quedaron hasta tarde en la noche, les di 2 días libres adicionales"
"Si prometen algo, deberían hacerlo".- Parece que este tipo es el único que realmente está a la altura de eso, al * no * prometer cosas que no va a hacer.Si "haz lo que te comprometes" es el OP estándar que quiere imponer, es probable que * todos los demás * necesiten hablar con ...
Si bien estoy de acuerdo con su respuesta, el hecho de que el error impide que el 90% de los usuarios inicien sesión en el sistema.En promedio, esto ocurre una vez al mes este año` significa que no se dedica tiempo a probar funciones críticas.Ese tiempo no asignado es un problema de gestión con "haz esto en su lugar, es más importante".Si eso sucedió donde trabajo / hice más de una vez y les he advertido, no me quedaré hasta tarde la próxima vez que no hayamos tenido tiempo para asegurarnos de que nunca vuelva a suceder (por ejemplo, pruebas unitarias y funcionales).
@zarose que se llama "inflación prioritaria".Pones en marcha un proceso de prioridad: Normal (5 días) Alto (1 día) y crítico (dentro de una hora) y comienza a ser abusado.Una vez que las personas se enteran, obtienen el servicio más rápido, de repente todo comienza a ser crítico.Donde trabajo, logramos poner en marcha un proceso para showstoppers, donde para cada problema crítico se formó un equipo para solucionarlo, con un gerente a cargo de la supervisión.Y para mucha molestia de la gerencia, seguí ese proceso al pie de la letra ... "¡pero solo quiero que lo arregles!"yo: "pero proceso".Redujo los problemas críticos en un 90%.
Creo que OP significó que OP se acercó a su jefe para que su jefe pateara el trasero del subordinado ... y mientras hacía eso, el subordinado abandonó las instalaciones de inmediato.Esta no es la primera vez que se hace este tipo de cosas, por lo que OP supuso razonablemente que el motivo del subordinado para irse era evitar las patadas en el trasero.Por lo tanto, "escabullirse".
@PieterB ¡Oooooooo, ese es un proceso bastante ingenioso que no había considerado antes!Definitivamente metiéndolo en mi bolsillo trasero.
#3
+76
Helena
2019-03-15 04:49:06 UTC
view on stackexchange narkive permalink

En mi oficina, solemos citar lo siguiente:

"Una mala planificación de su parte no requiere una emergencia en la mía".

En mi experiencia, los desarrolladores a menudo están motivados para ayudar con un problema que apareció debido a un error de su lado o algo imprevisto.

Pero a menudo surgen problemas que no solo no son sorprendentes Antes de decidir darle un ultimátum a su desarrollador y hacer que busque un nuevo trabajo, debe preguntarse lo siguiente:

  • ¿Ha hecho lo suficiente para evitar "críticas "bichos en primer lugar? ¿Les dio a los desarrolladores el tiempo suficiente para implementar pruebas, revisiones de código, refactorizaciones y monitoreo?

  • ¿Se está asegurando de que las nuevas funciones se activen cuando haya tiempo suficiente para corregirlas? (a diferencia de tarde en la noche o un viernes).

  • Si los errores críticos son comunes, ¿está pagando lo suficiente por horas extras o servicio de guardia?

  • ¿Los desarrolladores que desea tener la propiedad "son dueños" del proceso de lanzamiento? ¿Podrían detener el lanzamiento de una función, si creen que tiene errores?

  • ¿Son sus plazos realistas y acordados con el equipo de desarrollo?

Si todas las preguntas se pueden responder con un "sí" claro, entonces es posible que deba despedir a su desarrollador senior.

Si alguna de las respuestas es "No" o "No estoy seguro", entonces comenzaría a buscar el problema en la administración y solucionaría estos problemas primero.

He enumerado las cosas que he hecho para evitar errores críticos, pero obviamente no es suficiente.Por supuesto, les doy suficiente tiempo porque me dicen cuándo creen que pueden terminarlo y esta vez incluye pruebas de redacción y revisión de código.Además de eso, agrego 30-40% de tiempo de búfer más otras 2 semanas para la prueba.Los errores críticos no eran algo común hasta hace poco, cuando los tuvimos dos veces durante meses.Y sí, el equipo es dueño del proceso de lanzamiento a través de ci / cd.Creo que la fecha límite es realista porque todos están de acuerdo con ella desde el principio hasta el final del sprint (reviso cada vez que tenemos una reunión de pie
> "¿Ha hecho lo suficiente para evitar errores" críticos "en primer lugar? ¿Les dio a los desarrolladores el tiempo suficiente para implementar pruebas, revisiones de código, refactorizaciones y monitoreo?" Esto está muy de acuerdo con este punto.Hay procesos que garantizan un software de buena calidad.Si un gerente impide que sus ingenieros completen estos procesos, entonces las crisis que ocurren como resultado son problema del gerente, no de los ingenieros.
El desarrollador que dice "no es mi error, no me importa cuánto pierda la empresa por eso" es ... una mala persona para tener en un proyecto, sin importar cuán técnicamente buen desarrollador sea.Cualquier desarrollador al que no le importe debería buscar un nuevo trabajo en el que le importara y / o donde las emergencias no sucedan realmente y / o la empresa haga un mejor trabajo para evitar emergencias.Quedarse sin preocuparse no es bueno para nadie.
@hyde: Por otro lado, algunas empresas se destacan en la creación de este tipo de desarrolladores.Y la empresa en la pregunta parece una.Puedes pedalear a la gente, pero eso no resolverá el problema.Terminas creando más cínicos.
@CodeProject * "Y sí, el equipo es dueño del proceso de lanzamiento a través de ci / cd" * - eso ... no es lo que quiere decir Helena.Estás hablando del equipo que controla el * mecanismo * mediante el cual se implementa el código.Helena está hablando de que el equipo tiene la * decisión * sobre si lanzar, sobre que ellos puedan decidir si es aconsejable lanzar una función tal como está y decidir no hacerlo (y dejar pasar una fecha límite) si creen que no lo es.Listo.Su comentario, que se centra principalmente en defender los plazos que les impone, me sugiere que, de hecho, no tienen tal propiedad.
TL; DR: "Espejo. Aquí. Úselo".
#4
+47
Sefe
2019-03-15 13:53:06 UTC
view on stackexchange narkive permalink

Afirmas que el equipo no tiene propiedad . Todo lo que construyen sus desarrolladores es propiedad de la empresa, no de ellos. Cuando dice que sus empleados deben "ser dueños" de los resultados de su trabajo, ¿significa también que recibirán las ganancias que esos resultados generen para la empresa? Si no significa eso, realmente no son dueños del trabajo y no puedes pedirles la propiedad.

Si hay un error crítico, deben solucionarlo incluso si lo han hecho. para quedarse hasta tarde.

Su solución para solucionar problemas críticos haciendo que su gente se quede hasta tarde es conveniente para la empresa y los empleados pagan el precio. Nuevamente, eso estaría bien si también obtienen una parte de las ganancias. ¿Lo hacen?

En este ejemplo en particular, el error evita que el 90% de los usuarios inicien sesión en el sistema. En promedio, esto sucede una vez al mes este año, mientras que sucedió dos veces el año pasado.

Cuando esto sucede con tanta frecuencia y no instala procedimientos organizativos para reducir el impacto de esos errores, ¿Es usted como organización la culpable?

En realidad, su enfoque actual para solucionar problemas "críticos" y su contemplación de despedir a su empleado podrían considerarse un signo de una organización disfuncional. El comportamiento de su empleado podría ser su forma de reaccionar ante eso. Su actualización de la pregunta original con una lista de lo que cree que está haciendo bien (en lugar de pensar en lo que podría estar haciendo mal ) también muestra que podría tener una problema al aceptar que usted, como gerente, es parte del problema.

Hay muchas cosas que la administración puede hacer para mejorar la calidad y reducir la urgencia antes de pedirles a los empleados que se queden hasta tarde:

  1. No importa lo bien que crea que se ha centrado en la calidad, los resultados muestran que no es así. Tiene que mejorar seriamente la calidad de su proceso de desarrollo, lo que podría significar medidas como revisiones, inspecciones, programación de pares, aumento de pruebas, rediseño de componentes críticos, arquitectura y diseño mejorados, etc. Será mejor que comience a analizar los problemas organizacionales que causan esos problemas. de escribir la lista de medidas que ya ha implementado. Obviamente, no están funcionando.
  2. ¿Por qué su empleado tiene que quedarse hasta tarde para corregir el error? ¿Puedes hacer tus lanzamientos temprano en la mañana para darles a tus desarrolladores todo el día de trabajo para solucionar problemas?
  3. ¿Has pensado en usar funciones alternas u otras medidas para volver rápidamente a la versión anterior de la función y ofrecer ¿Tiene tiempo de su equipo para solucionar el problema?
  4. No puede culpar a sus empleados por tener planes para la noche cuando surgen problemas con poca antelación. Puede instalar un sistema de servicio en espera los días de lanzamientos críticos. Entonces las personas saben de antemano que es posible que tengan que quedarse hasta tarde y pueden prepararse en consecuencia.
El tercer punto sobre esto es muy estándar para funciones críticas en todos nuestros programas de lugar de trabajo.+1
Por favor, no haga el punto 3. En su lugar, envíe su solicitud.Implemente una nueva versión cuando esté listo.Si tiene errores, puede volver a implementar instantáneamente la versión anterior.La alternancia de funciones es una excelente manera de tener código inútil flotando porque nunca se usa / "enciende".+1 para el resto de la respuesta :)
@rkeet: está totalmente en desacuerdo.Es extremadamente importante poder activar / desactivar funciones específicas en tiempo de ejecución sin tener que volver a implementar nada.Y esto no tiene absolutamente nada que ver con tener sus aplicaciones en contenedores o no.No quiero tener que involucrar a terceros / administradores de versiones / partidarios de la plataforma solo para deshabilitar / habilitar una función simple que está causando estragos si puedo evitarla.
@devouredelysium Si es necesario desactivar una función porque está causando estragos, significa que ha interrumpido la producción.Si ha interrumpido la producción, toda la construcción no está lista.Si una compilación no está lista, no debería estar en producción.Suponiendo que la compilación anterior funcione, vuelva a implementarla y repare su producción rota.De todos modos, la implementación en contenedores toma como 2 segundos.Si los terceros que eliges / rm's / plataformas de apoyo son tan poco confiables como crees que son, debes reevaluar tu elección en el software.
@rkeet: sus puntos tienen sentido en un entorno del lado del servidor, pero como ha ido saliendo gradualmente en los comentarios, la pregunta es en realidad sobre una aplicación móvil, que es una situación en la que las actualizaciones del lado de iOS tienen que pasar por la latencia de aprobación de la tienda de aplicaciones.y en el lado de Android hay una * variedad incontrolable * de implementaciones de plataformas, y en ambas donde la instalación de actualizaciones está sujeta a la aprobación manual del usuario final.Las funciones alternan o incluso "esta versión está rota, * debes * actualizarla para llegar a cualquier otra pantalla", las respuestas del servidor son intentos inteligentes de lidiar con estas realidades.
@rkeet: así que según su razonamiento, si le duele el brazo derecho, ¿debe ser porque todo su cuerpo está dañado?Si la característica A es problemática (e incluso puede deberse a que * otro * sistema no funciona correctamente y es preferible deshabilitar también esta funcionalidad, solo por seguridad), entonces apaga la característica A, no revierte todo un sprint de funcionalidad.
@ChrisStratton no había leído en ningún lugar relacionado con tiendas de aplicaciones / aplicaciones móviles.Entonces, y solo entonces, supongo que podría tener sentido.Es mejor asegurarse de que nunca llegue a producción.
La biología de @devouredelysium no entra en juego aquí.Pero jugando con eso, sí, si te duele el brazo, es el cuerpo el que está dañado, ¿no es tu brazo parte de tu cuerpo?Extraña analogía.Lo que sea.Y sí, revertiría toda una serie de funciones.No tirarlo, simplemente bajarlo para arreglarlo.(En su analogía, aparentemente le arrancaría el brazo para arreglarlo en un hospital, o le pondría una torniquete hasta que esté arreglado ...).De hecho, recientemente revoqué un lanzamiento con 3 semanas de trabajo.Causa errores (aunque corregibles) que habría causado horas extra.No es necesario, retrocede, mañana nuevo día
@rkeet es un poco difícil tener clientes si su aplicación móvil nunca "llega a producción", por lo que los mecanismos propuestos están destinados a hacerlo en su mayoría.Podría decirse que el autor de la pregunta podría considerar ir más allá y hacer que su aplicación sea esencialmente un visor de contenido dinámico descargado de un servidor y, como mucho, almacenado en caché;entonces realmente * pueden * revertir los cambios a gran parte de lo que importa fácilmente.Pero se puede demostrar matemáticamente que es el extremo de hacer que todo sea una colección de conmutadores de grano fino.
@rkeet: y ¿los clientes (y los propietarios de otros servicios) estarán dispuestos a que su versión anterior se ejecute durante horas (o incluso días) hasta que encuentre el problema, lo solucione y lo pruebe correctamente?¿Qué pasa si entonces no está realmente arreglado y tienes que revertirlo una vez más?lol.Entonces, ¿su plan es que toda la oficina lo cuide en lugar de aislar adecuadamente el problema (apagarlo) y solucionarlo con calma mientras todo lo demás funciona sin problemas como siempre?Buena suerte.
@devouredelysium Supongo que no le importa mirar las páginas en blanco, no cargarlas.O "500 Error interno del servidor".O "Inicio de sesión incorrecto, inténtelo de nuevo" o cualquier otra cosa.Prefiero una versión funcional.Si una función está rota, sí, desconecta al bugger y arréglalo.No dejes que tus defectos, usuario, me preocupen.
@rkeet: si la función está rota, como se indica en el OP original, * deshabilita toda la función *.El usuario no lo verá.No lo dejes roto.Esa es precisamente la idea de tener un * killswitch *.
@devouredelysium ¿Te das cuenta de que si implementaras una versión anterior, todo el asunto roto no está en ella, verdad?Luego, lo arregla ** sin molestar a los usuarios finales que lo juzgan a _ usted_ por su experiencia **.Cuando lo haya arreglado: vuelva a implementarlo.
@rkeet: He escrito * funciones alternas u otras medidas para volver rápidamente a la versión anterior *.Mi punto principal es facilitar la reversión.Cómo hacerlo debería ser decisión del OP, pero definitivamente debería encontrar una solución.
¿@rkeet: y deja todas las características de todos los demás equipos, posiblemente incluso con otras correcciones de errores menores incluidas, paralizadas?lol.No continuaré esta discusión.Absolutamente nadie en el negocio hace nada ni remotamente similar a lo que estás describiendo (como testifica la publicación que comentamos) si pueden evitarlo.
@rkeet su solución a este problema requiere un proyecto específico y una configuración ci / cd.¿Qué sucede si no es seguro revertir la migración de db?¿Qué sucede si otros servicios ya implementados dependen de alguna otra característica nueva creada correctamente?¿Qué pasa si la nueva compilación solucionó algún error crítico?Etcétera etcétera...
#5
+40
JazzmanJim
2019-03-15 00:20:15 UTC
view on stackexchange narkive permalink

Trabajar en software es muy común.

Tratas a tu gente como profesionales. Estás hablando de propiedad, pero luego dices demandas de que un error 'crítico' debe arreglarse AHORA.

¿El error es realmente 'crítico'? ¿Es el resultado de requisitos poco claros? Nuestro viejo amigo 'scope-creep '?

En cada uno de estos, usted (como gerente) necesita manejar las expectativas. No todos los errores son "críticos". Los requisitos pueden apestar. Cambios en el alcance del proyecto.

En lugar de exigir que lo abandonen todo por algo "crítico", trabaje con sus equipos hasta que se solucione. Entonces manténgalos en esta estimación.

He estado poniendo 'crítico' entre comillas porque después de más de 30 años en este campo (¡ay, soy viejo) este término se usa muy mal. No todo puede ser 'crítico'.

Hacer que las personas sigan su estimación no tiene sentido: se llama estimación porque en realidad no saben cuándo se arreglará.
@Erik En ese caso, deberían saber exactamente qué salió mal para hacer que su estimación sea incorrecta.
@JMac cuando se resuelva * sabrán * qué estaba mal y dónde pasó el tiempo, si desea tener una retrospectiva.Pero * hasta que * se resuelva, solo pueden decirle cuánto tiempo ha pasado para intentarlo (o qué otras obligaciones se han interpuesto en el camino), y tal vez su corazonada actual sobre qué verificar / probar a continuación.Alguna discusión a lo largo del camino puede ser productiva y la comprensión puede provenir incluso del acto de la conversación;pero hay un punto en el que la discusión y los informes en sí se convierten en una fuente de retraso contraproducente.
@ChrisStratton Sin embargo, no hace que sea "inútil" mantener a las personas en sus estimaciones.No estoy diciendo que necesiten tomarse un tiempo de la solución para articular dónde se fue su tiempo;pero cuando alguien proporciona una estimación, se le debe obligar, en una medida razonable.Si mantener a las personas en sus estimaciones no tiene sentido, también lo es obtener la estimación.El hecho es que las estimaciones son útiles y de uso común, a menudo necesarias para organizar el trabajo de manera que se cumplan los plazos.En su mayoría, estaba llegando al punto en el que debería poder respaldar su estimación y los cambios en ella.No es una suposición.
De hecho, las estimaciones sobre problemas complejos no suelen ser significativas, y todo el que tenga sentido común lo sabe.En el mejor de los casos, para algo grande con el factor multiplicador de conjetura correcto, puede resultar aproximado en promedio, pero los sumideros de tiempo específicos rara vez son los esperados, por lo que en realidad es solo una prueba de la habilidad de pesimismo.
@ChrisStratton Yo diría que hay un mundo de diferencia entre "a menudo incorrecto" y "no significativo".No importa cuán incorrectas sean sus estimaciones, aún debe haber un significado detrás de ellas, y cualquier estimación que proporcione definitivamente se interpretará con significado.La persona que da la estimación no es la única responsable de que la estimación sea correcta, el sistema es demasiado complejo para eso, pero definitivamente debe someterse a él hasta cierto punto, o de lo contrario la planificación del proyecto se vuelve esencialmente inútil.La mayoría de los clientes no aceptan "terminaremos cuando terminemos".
En ese caso, desea que la gente haga una estimación honesta, luego multiplique eso por 5 y luego le diga esa cantidad de tiempo, solo para asegurarse de que sea probable que el problema se solucione dentro de ese período de tiempo.Eso ya no es una estimación, sino una gestión segura de las expectativas.
Aquí hay una buena charla sobre estimaciones: https://www.youtube.com/watch?v=QVBlnCTu9Ms (No estoy de acuerdo en todos los aspectos con todo, pero tiene algunos buenos puntos).Pista, el título es "#NoEstimates"
`" Ay, soy viejo "` - Eso significa que tu opinión es muy valiosa.
@DT Si bien estoy de acuerdo con JimmyB, eso no es necesariamente cierto.He conocido a algunos desarrolladores, gerentes y jefes más antiguos.Muchos de ellos podrían haber estado alrededor de la cuadra, eso no significa que hayan aprendido de eso;) (aunque JimmyB parece haber captado las cosas;))
@Erik Yo diría que hacer que las personas cumplan con las estimaciones es razonable porque las estimaciones siempre deben estar sobrestimadas.Si estima 2 semanas y entrega en una, nadie se va a quejar de que tiene una semana para hacer pruebas adicionales o que tiene una semana para dedicarla a otro proyecto.La planificación del proyecto depende completamente de este hecho;y si quiere que un director de proyecto sea su amigo, no entregue tarde.Si, por el contrario, entrega tarde, no sabe qué impacto tendrá en el resto del proyecto, lo que puede resultar en un problema urgente.
@UKMonkey una vez que un gerente nos dijo que todas las estimaciones tienen que ser precisas y absolutamente tenemos que terminar dentro de ese plazo.Desde ese día hasta que dejó la empresa unos dos meses después, todas mis estimaciones eran "dos años". Logré terminar todas las tareas dentro de ese período de tiempo, lo que me da un 100% de exactitud de las estimaciones.Por alguna extraña razón, hasta donde yo sé, ninguna de mis estimaciones se comunicó al cliente.Me pregunto porque.
@Josef por suerte para ti no lo hicieron.Se espera que los ingenieros de servicios profesionales ganen de 3 a 5 veces su salario de los clientes;y no hacerlo pone en riesgo su salario.La forma habitual de calcular es "cuánto tiempo cree que le llevará x 3"
@UKMonkey pero si alguien me pide que dé un "estimado" que es el máximo absoluto, se lo daré.Si calcula tres veces lo que piensa cuánto tiempo lleva, habrá tareas en las que llevará más tiempo que ese estimado.
@Josef nunca ha estado en la situación en la que el número que ha proporcionado ha sido enviado al cliente y se ha cobrado dinero en base a eso - usted reconoce esto;pero si lo hubiera sido, el cliente siempre habría rechazado su número y, como ingeniero, al no llevar dinero a la empresa, su contrato se habría rescindido. Una estimación es una estimación segura;pero si estás eligiendo números estúpidos, en el mejor de los casos no estás haciendo amigos, y en el peor, puedes arriesgar tu trabajo.
@UKMonkey esas no son estimaciones, son fechas pesimistas de "terminado".Si las personas las necesitan, deben decírmelo y les daré mi estimación normal x 5. Pero si me piden una estimación, le daré una estimación honesta.Si los números deben ir a personas que fundamentalmente no entienden qué es una estimación, la persona a la que le estoy dando la estimación debe aplicar las tonterías que quiera a mis números.Prefiero ser honesto con las personas con las que trabajo.
@UKMonkey A menudo me encuentro en la situación de que los números que doy se envían a los clientes.A menudo hablo de números con los clientes en los proyectos que gestiono.Nunca reconocí nada más.Si alguien me pregunta por una fecha de caducidad en el peor de los casos, obtienen el peor de los casos.
#6
+35
17 of 26
2019-03-15 17:40:10 UTC
view on stackexchange narkive permalink

Con la pregunta actualizada, ahora está claro que está intentando solucionar el problema incorrecto. El comportamiento del ingeniero senior es un síntoma de un proceso de desarrollo de software fundamentalmente roto y / o una empresa disfuncional.

Si tiene errores críticos que entran en producción todos los meses, entonces tiene al menos uno de los siguientes problemas:

  • Ingenieros incompetentes
  • Base de código no mantenible
  • Pruebas inadecuadas

Dada la cantidad de mano de obra que tiene a su disposición (20 ingenieros son MUCHOS recursos), es probable que sea una combinación de los tres.

Mi conjetura es que el ingeniero senior está harto de la constante lucha contra incendios, y con razón.

Debe profundizar más y solucionar los problemas subyacentes que crean la necesidad de que las personas trabajen continuamente hasta tarde. Convencer a un ingeniero de que trabaje hasta tarde más a menudo no ayudará a la imagen general.

Ahora, qué hacer al respecto ...

Paso 1: Descubra por qué probar no es detectar estos errores críticos

Lo primero que debe hacer es evitar que estos errores críticos lleguen a producción. Cada error que llega a producción es una falla en el proceso de prueba.

Repase cada error crítico que se descubrió en producción y determine exactamente por qué no se detectó en las pruebas. Agregue más cobertura de prueba automatizada, cobertura de prueba manual o recursos de prueba según sea necesario.

Paso 2: Determine la causa raíz de cada error crítico

Para cada error crítico, averigüe:

  • Quién creó el error
  • Cuándo se creó el error
  • Por qué se estaba modificando el código
  • Dónde se introdujo el error en el código

Al hacer este análisis, descubrirá algunos patrones. Quizás hay uno o dos desarrolladores que siguen introduciendo estos errores. Quizás hay un módulo de código que es muy difícil de modificar sin causar problemas. O es posible que el código en su conjunto sea muy difícil de manejar.

¡Y DEJE DE AGREGAR MÁS CARACTERÍSTICAS ROTAS hasta que se solucionen los errores críticos en el código existente!
A veces, estos problemas ni siquiera son "errores", sino un diseño fundamentalmente incorrecto, incompatible con el entorno en el que se ejecuta el código;puede corregir un * interminable * flujo de "errores" surgidos por la nueva forma que causa roturas cada vez que el código se encuentra con un comportamiento nunca antes visto (pero perfectamente compatible) de sistemas interactivos o capas de sistema operativo, o puede tomarse un tiempo para arreglar el diseño subyacenteerrores.
@ChrisStratton Exactamente, por lo que es absolutamente necesario comprender la causa raíz de estos errores críticos.
Me gusta mucho esta respuesta, pero esperaría que un ingeniero SENIOR vaya al gerente para discutir el problema cuando esté "harto" de algo, dejar de hacer "extinción de incendios" no es en mi humilde opinión la respuesta que quiero ver de un profesional.ingeniero experimentado.
`Cada error que llega a producción es una falla en el proceso de prueba` - Casi correcto."probar" es parte del desarrollo.Con 20 desarrolladores, debería emplear pruebas unitarias / funcionales (preferiblemente ambas).Como tal, las pruebas son una parte integral de todo el proceso de desarrollo, no un proceso independiente.Se reformularía como: "Cada error que llega a producción es un fallo en el proceso de desarrollo".Además, creo que te estás perdiendo "la administración quiere características XYZ de ABC".Siempre un domper gigante en el trabajo adecuado.Entonces obtienes OP exigiendo que te quedes hasta tarde ... luego buscas un nuevo trabajo.
@AdrianoRepetti: ¿quién dice que no lo hicieron?Los desarrolladores suelen entrar en esta fase cínica cuando se enteran de que la dirección de su empresa no escucha.
@Davor porque OP no lo mencionó (y probablemente ni siquiera necesitaría preguntar si alguien lo hizo).Estamos haciendo demasiadas suposiciones aquí, me encantaría mantenerlas al mínimo siempre que sea posible.A juzgar por lo que OP escribió, todo lo que puedo decir es que el proceso debería mejorarse (siempre puede serlo) pero tienen un problema (técnico) serio con este _senior_ (si OP tiene derecho o no a esperar horas extra, realmente depende de la cultura).
Quiero decir: código que escribiste y tuviste mucho tiempo para probar ... ¿detuviste al 90% de los usuarios para usar el servicio?S * sucede, pero como desarrollador me avergonzaría responder "veamos mañana", no importa cuáles sean mis razones (especialmente si no hablé de antemano).
@AdrianoRepetti tal vez lo haya hecho, y no pasó nada.Solo estamos viendo un lado aquí
@user definitivamente.Por eso estaba hablando de _supuestos_.Literalmente, todo o nada podría ser cierto, entonces en mi humilde opinión deberíamos (en su mayoría) apegarnos a lo que sabemos porque OP lo escribió.
@AdrianoRepetti Estoy de acuerdo con eso para los comentarios (y tenga en cuenta que su comentario sobre "expectativas" SE basa en algunas suposiciones).Pero las respuestas deberían ir con diferentes supuestos para ampliar la ayuda a otras personas además del OP.Fwiw, diría que lo único que SABEMOS es que hay una falla en las pruebas y hay una falla en el diseño.El hecho es que lo más importante a corregir ahora son las pruebas y las prácticas de diseño AMPLIAS, no el desempeño de un empleado (de 20)
#7
+29
The Gilbert Arenas Dagger
2019-03-15 05:14:01 UTC
view on stackexchange narkive permalink

Quiero hacer un punto adicional. Apresurar una corrección de errores a menudo conduce a una deuda técnica. Si su desarrollador senior se pregunta cómo se probará esta noche, ¡esa es una buena pregunta que debería hacer un desarrollador senior! He trabajado en lugares donde se prioriza la urgencia sobre la calidad y esto ha tenido consecuencias negativas a largo plazo. En última instancia, su equipo tendrá una capacidad reducida porque siempre está combatiendo incendios.

Sí, y no asuma automáticamente que solo porque los otros equipos trabajarían y arreglarían el error, tienen razón en esto.Incluso pueden sentir lo mismo, pero no quieren pelear con la gerencia por eso.
La pregunta sobre cómo vamos a probar que se hizo hace unos dos meses y la solucionamos haciendo que las pruebas se ejecuten en todas las confirmaciones y prs.
@CodeProject la secuencia de eventos en su edición es en realidad un buen ejemplo de lo que advierte esta respuesta.Las pruebas que realizó a fines de febrero no detectaron este problema, por lo que no, el problema de las pruebas no se solucionó en realidad.Es probable que haya áreas de su base de código (o su interacción con el sistema operativo móvil subyacente o los servicios remotos) que aún no se comprenden correctamente y, como resultado, las correcciones de errores continúan conteniendo suposiciones inseguras que se rompen en situaciones fuera de las que pensaba.hacer una prueba por.** Tomarse el tiempo ** para comprender realmente será necesario, las pruebas no pueden atraparlo todo.
Si realmente desea "propiedad", es probable que tenga que estar abierto a permitir que sus personas mayores determinen más de la agenda para incluir las cosas que necesitan hacer para realmente manejar los problemas subyacentes.Por el contrario, si dictas los objetivos en la medida en que solo pueden abordar * síntomas *, en realidad * te has hecho cargo * de una manera que les impide tener la oportunidad de hacerlo.
@ChrisStratton Estoy de acuerdo con la parte en la que necesitamos tomarnos un tiempo para comprender nuestro código base.Para el segundo comentario, en realidad tuvimos 2 sprints en los que decidieron en qué querían trabajar, que eran refactorizar código, corregir errores, agregar más pruebas.¿Alguna idea sobre cómo abordar este problema?
Admitamos que el proceso definitivamente se puede mejorar.También seamos honestos y admitamos que existe la remota posibilidad de que el equipo no sea lo suficientemente competente.Tos.
Apurar una solución también puede tener consecuencias catastróficas a corto plazo,
#8
+23
Qwertie
2019-03-15 10:01:45 UTC
view on stackexchange narkive permalink

Parece que tiene un gran problema de prueba. Usted pregunta por qué no todos abandonan todos los compromisos externos de apagar un incendio, pero la verdadera pregunta es ¿por qué comienzan los incendios todos los meses?

¿Tiene algún control de calidad / prueba? ¿Por qué no encontraron que el primer y más básico paso (iniciar sesión) no funciona? ¿Cómo se envió a producción algo que no funciona?

Además, ¿por qué su respuesta a que los usuarios no pueden iniciar sesión para que todos se queden hasta tarde apresurando arreglos "críticos" en lugar de tener un sistema? admin revertir la actualización y la actualización se puede intentar de nuevo más tarde después de que se hayan solucionado los problemas.

"¿Cómo vamos a probar eso esta noche?" Ésta es la respuesta correcta. Cuando hay un problema crítico y se le presiona para que lo solucione ahora mismo, ¿cómo reservarán los desarrolladores tiempo para revisar adecuadamente que los cambios sean correctos / de alta calidad y cómo se pretende QA para verificar que todo lo demás sigue funcionando después del cambio? Parece que también está pidiendo estos cambios al final del día, cuando todos están cansados ​​y su capacidad de pensamiento está en su punto más bajo, lo que hace que sea aún más probable que otros problemas se filtren en esta solución crítica.

La pregunta y sus actualizaciones dejan en claro que * hay * pruebas y que las pruebas fueron críticas para la decisión de lanzamiento, pero también que las pruebas que hay no detectan los defectos.Algunos entornos modernos tienen suficientes partes móviles distintas, por lo que esperar que las pruebas detecten todo es ingenuo, ya que el código inseguro puede funcionar o romperse según las condiciones fuera del entorno de prueba.Eso apunta a un sistema con aspectos que ninguna persona del equipo comprende completamente.
@ChrisStratton Si sus probadores no pueden probar cosas, sugeriría que eso es un problema en sí mismo.Eso tampoco explica por qué no existe un proceso para simplemente revertir los cambios que salieron mal.Es probable que los desarrolladores no tengan control sobre los procedimientos de prueba y operaciones y estén hartos de tener que lidiar constantemente con fallas en el proceso.
No, ni los probadores ni los arneses de prueba automatizados pueden cubrir todas las eventualidades.Tienen su función, pero el conjunto de posibles interacciones es más grande de lo que puede enumerar y fácilmente involucra más variedad física de la que puede comprar o simular razonablemente para incluir en la cobertura de su prueba.Parchar lo que rompió las pruebas la última vez no es suficiente; tiene que ser correcto * por diseño * y no tener partes fundamentalmente inseguras que simplemente funcionan en todas las pruebas probadas.El software implementado * para los clientes * no es necesariamente tan fácil de revertir como algo del lado del servidor.
+1 esta es la respuesta que estaba componiendo en mi cabeza
@ChrisStratton Ambos son ciertos, pero deben conocerse y explicarse.Si no puede obtener una cobertura de prueba suficiente y no puede revertir la implementación, debe hacer arreglos con anticipación para que un desarrollador esté disponible para hacer frente a cualquier problema que pueda surgir.Reacciono mucho mejor a '¿Puedes trabajar hasta tarde el próximo viernes para cubrir cualquier problema que surja del lanzamiento?', Que 'Todo se fue al infierno nuevamente, cancela tus planes'.
@ChrisStratton leyendo los comentarios adicionales de OP, parece que su idea de prueba se limita a que los desarrolladores escriban pruebas unitarias.
@Aaron no es cierto, describieron las pruebas en varios modelos de teléfonos.Pero ninguno protegerá contra malentendidos fundamentales del sistema operativo móvil.
@ChrisStratton [este es el comentario] (https://workplace.stackexchange.com/questions/131620/employee-lack-of-ownership/131655?noredirect=1#comment423006_131620) al que me refería.Me parece que no hay probadores y no hay muchas pruebas en curso.Necesitan un equipo de control de calidad, ya que no los mismos desarrolladores que escribieron el código también lo prueban.
@user87779, no tanto como podría pensar, cuando una aplicación móvil se encuentra entre un sistema operativo móvil y servicios remotos que a menudo se malinterpretan, el alcance de la interacción supera fácilmente la cobertura de prueba alcanzable.Puede notar que el autor de la pregunta ha descrito una situación que * pasó las pruebas * pero aún tenía errores de una manera que solo apareció después del lanzamiento.Eso es bastante común: el código fundamentalmente incorrecto parece funcionar hasta que se expone a las circunstancias adecuadas para exponer la falla.O algún dispositivo móvil en particular implementa incorrectamente una API; eso es menos común, pero sucede.
@user87779: veo muchos de ambos.Pero luego, a menudo me comprometo específicamente a * resolver * este tipo de problemas, es decir, el código de otros con suposiciones inseguras que no se activaron en las pruebas originales, o situaciones en las que la plataforma se desvía de su especificación.
#9
+10
paulj
2019-03-15 00:39:26 UTC
view on stackexchange narkive permalink

¿Cuándo las personas son más productivas? ¿Cuándo es el equipo más capaz de manejar errores críticos? Se han realizado estudios que responden a dichas preguntas sobre cuándo los humanos son más capaces de manejar ciertas tareas.

Tienes un error crítico y quieres que a) Sr. para cambiar de marcha mental, b) nueva tarea "crítica", c) trabajar "hasta cuando" para solucionarlo. ¿Y espera que este parche crítico funcione? Honestamente, ¿qué esperas del producto, el equipo, los miembros del equipo si tus deseos fueron satisfechos?

Suelta tu ego y tu fuerte > creencias irracionales.

Entonces es tarde y encuentra un error en el que el 90% de los usuarios no pueden iniciar sesión en PROD ... está diciendo que si los estudios muestran que su mejor trabajo se realiza a las 10 a.m. de la mañana, debe esperar hasta entonces paratrabajar en esto?¿Eso no te suena tonto?
@Jeffc Si el 90% de los usuarios no pueden iniciar sesión, ¿por qué no se detectó durante las pruebas antes del lanzamiento?Eso no es un error, es un error del sistema.¿Dónde está el equipo de soporte dedicado de los cuatro equipos mencionados anteriormente?Incluso si gira.
No estoy en desacuerdo con tu comentario ... pero no estoy de acuerdo con tu respuesta.De cualquier manera, el punto es que cuando se encuentra el problema PROD es el momento de solucionarlo, no de esperar hasta el momento óptimo y más productivo para los empleados.
@JeffC Yo diría que es hora de retroceder desde la rama experimental en la que deberían implementar este código.Luego, solucione metódicamente el problema sin apresurarse y posiblemente introducir otros errores
#10
+10
Gregory Currie
2019-03-15 14:01:00 UTC
view on stackexchange narkive permalink

El término que busca es Esfuerzo discrecional , no Propiedad 0000-.

Supongo que sus empleados están cumpliendo con sus obligaciones contractuales (de lo contrario, su El curso de acción es claro).

No tiene derecho a esperar un esfuerzo discrecional. Eso es lo que es por definición. Básicamente, esto no es algo de lo que puedas hablarles y esperar un cambio. Es probable que obtenga la respuesta opuesta. No tienen la obligación de darlo. Es probable que las amenazas de despedirlos tengan una respuesta deficiente tan abrumadora, además de ser ilegales.

No tengo buenas sugerencias sobre cómo se pueden mejorar las cosas. El mero hecho de que pueda confiar en el esfuerzo discrecional de parte de su gente me sugiere que la cultura no está necesariamente rota.

Arreglar esto llevará tiempo, así que en cambio, puedo ofrecer medidas provisionales:

Corrija el factor de bus de 1

¿Por qué solo un empleado puede resolver este problema?

Tenga un -la lista de llamadas

De acuerdo con el reembolso acordado con los empleados individuales, no lo que usted cree que vale.

Implemente actualizaciones en mejores momentos

Puede que no sea posible, pero implementar las cosas en mejores momentos puede aumentar las posibilidades de que alguien lo ayude.

El valor de su software depende de lo bien que esté compatible, por lo que no debe utilizar el esfuerzo discrecional como muleta. Si desea que su software sea compatible a un nivel, debe asegurarse de tener las cosas en su lugar para garantizarlo.

Te perdiste la parte donde el OP dijo que el senior le dijo al equipo que se fuera a casa.Factor de bus> 1. Además, tengo curiosidad por todo este asunto del "esfuerzo discrecional".Cualquiera que sea el término que elija usar, en los EE. UU., Los ingenieros son profesionales, lo que significa que esencialmente se les paga por hacer un trabajo, no por trabajar durante X horas (ellos deciden, o en la mayoría de los casos renuncian al derecho de decidir) cuánto tiempo debentomar.Los ingenieros entregaron un producto que dieron luz verde, que resultó ser defectuoso.Si ese es el caso, creo que un empleador tiene legalmente el derecho a esperar OT, incluso OT no remunerado ...
Pero si tienes información que diga lo contrario, soy todo oídos
No puedo hablar por los Estados Unidos, pero en Australia los "trabajadores" se dividen en dos categorías, empleados y contratistas.Los ingenieros pueden emplearse como cualquiera.La mayoría de las veces, los trabajadores son empleados.Según mi leal saber y entender, todos los ingenieros (más de 200) con los que he trabajado han sido empleados.
Con respecto a las horas extraordinarias no remuneradas, en Australia, obligar a un empleado a trabajar horas extraordinarias no remuneradas, incluso si cometiera un error, se consideraría ilegal.
Interesante.En los EE. UU., Los ingenieros de software no tienen derecho al pago de horas extra (aunque creo que al menos es una práctica común que haya una cláusula de pago de horas extra en su contrato)
Creo que los dos términos que los separan en los Estados Unidos son "ingenieros contractuales" e "ingenieros asalariados".Es muy posible que tenga razón en que la mayoría o todos los ingenieros son ingenieros contractuales.(También algo que puede ser interesante es la definición legal del término "ingeniero" - en Europa tiene un significado específico bien definido - esto puede no ser cierto para EE.UU. y "cualquiera" puede ser un ingeniero)
Interesante.He trabajado en los EE. UU. Y Japón y veo a una persona que dijo que entregó X, pero entregó Y. Espero que cambie X a Y lo antes posible o acepte que ya no los emplearé para no darme lo que me prometieron.Pero, ¡aparentemente diferentes culturas y leyes!
Un "profesional" (una subcategoría de empleado asalariado) está exento de las restricciones de horas extra, ya que se considera que tiene el conocimiento suficiente para determinar su propia carga de trabajo / saldo de pago.
Por lo que recuerdo, ingeniero no tiene un significado legal en los EE. UU.
El significado legal de "ingeniero" varía según el estado de EE. UU.En cuanto a los ingenieros de software, es muy común que seamos contratistas o empleados en los EE. UU. Y recientemente trabajé con un contratista con sede en Australia.(El contrato involucrado todavía no permitiría "forzar" a trabajar horas extras).
"Profesional" no tiene nada que ver con eso.Si está asalariado y gana una cierta cantidad (~ 40k, creo, aunque esos números están cambiando según la discreción de las órdenes ejecutivas), entonces no tiene derecho legal a pagar horas extra (aunque su empresa aún puede optar por tener unpolítica de horas extras que incluye pago adicional, no es requerido por ley).
#11
+8
Brandon
2019-03-15 21:02:42 UTC
view on stackexchange narkive permalink

Entonces, ¿espera que sus empleados renuncien a su vida social y / o familiar en un abrir y cerrar de ojos para solucionar problemas?

¿Son realmente tan críticos? fuerte>

Los gerentes siempre parecen pensar que todo es fundamental porque decir no es difícil. Esta es una fuerte razón potencial por la que su desarrollador líder está retrocediendo. Están tratando de proteger sus límites porque tú no lo harás. Y están tratando de proteger los límites de su equipo porque tú no lo harás.

Si realmente son tan críticos, entonces ¿qué está fallando que permita que ocurran estos problemas?

Si la calidad de su producto es tan mala, entonces debe moverse y dejar que sus desarrolladores elaboren un plan para que el producto vuelva a encarrilarse. La mala calidad no se trata solo de errores. La mala calidad hace descarrilar la previsibilidad. Si constantemente se sale del plan porque su calidad es tan mala, entonces corrija su calidad. Y no lo arregla pidiendo a los desarrolladores que lo hagan en su tiempo personal. Si esa es la expectativa que establece, entonces le está diciendo a sus desarrolladores que la empresa no se preocupa por la calidad y, por lo tanto, no valora la previsibilidad. Si no valora la previsibilidad, deje de quejarse.

Si realmente son todos críticos, ¿por qué no planifica una rotación de guardia?

Esto no solo protege el tiempo personal de los empleados y protege las necesidades de la empresa, sino que también crea un incentivo para que los desarrolladores solucionen los problemas sistémicos que les están causando tantas luchas. (tal vez necesite más o mejores pruebas, tal vez tenga un código heredado roto, etc.)

¿Por qué no se queda hasta tarde y arregla las cosas?

Te estás quejando de que alguien no trabaja durante la noche para solucionar un problema. ¿Por qué no trabajas toda la noche para arreglarlo? Creo que encontrará las mismas conclusiones que el líder de su equipo.

Su comportamiento

Ha amenazado con despedir a sus empleados por no hacer algo que usted mismo se niega a hacer. Se queja de que esto sucede a menudo, pero no lo ha planeado con una rotación de guardia o mediante el pago de la deuda técnica.

Al leer su lista de pasos para planificar un lanzamiento, lo que me llama la atención es el uso frecuente de "Les dije que ..." y la granularidad de la planificación hasta los nombres de las funciones. Planifica los detalles menores que se pueden cambiar fácilmente, pero no planificará un proceso de soporte para su producto.

Este es 100% su problema.

Su equipo fuerte>

Me parece que tiene un grupo de profesionales inteligentes y honestos que saben cómo hacer un buen software, pero a su gerente le gusta dictarles cómo hacer su trabajo y cuándo el enfoque del gerente causa un problema, obligarlos a trabajar más horas.

¿Ha dado un paso atrás y le preguntó a su equipo cómo detectar errores menos críticos? ¿Le ha preguntado a su equipo cómo creen que deben manejar la responsabilidad por problemas críticos inesperados?

El líder de su equipo tiene razón al hacer retroceder sus expectativas. Y me alegra saber que está animando a su equipo a decir que no a las cosas. Él está tratando de proteger al equipo porque tú no lo estás.

En mi tiempo como líder de equipo, puedo decirte que una de las lecciones más difíciles pero más importantes es aprender a decir que no. Tal vez puedas aprender algo de este empleado tuyo.

1. Son críticos.Estos dos incidentes que hemos tenido fueron a) los usuarios no pueden iniciar sesión yb) los usuarios no pueden comprar productos.Como escribí en mi pregunta, solo estos dos temas se clasifican como críticos.
2. Lo que estaba fallando era que no probamos en todos los dispositivos como estábamos de acuerdo.Esta es una aplicación móvil y las reglas se prueban en 6 dispositivos * 4 SO (24 en total)
3. Esta es una aplicación móvil y la rotación de guardia no ayudará, ya que ya está disponible en la AppStore.
4. Me quedé y solucioné el problema esa noche con los otros tres; pasé 2,5 horas
Digo mucho NOse y muchas personas en mi empresa saben que es mi respuesta predeterminada.Este problema puede ser de mi parte y estoy buscando una forma de mejorarlo.
Estos problemas de compatibilidad en varios dispositivos son una fuerte evidencia de que su base de código tiene problemas de diseño profundos.Arreglar las fallas * específicas * es un proceso interminable, porque siempre habrá un teléfono que exponga una posibilidad permitida en la que nunca había pensado.Lo que debe hacer es alinear el diseño del código con la forma en que se supone que las aplicaciones en esa plataforma interactúan con el sistema, que * no * es lo que el que hizo la arquitectura original pensó que era, y a menudo no es fácil de entender en absoluto..Es bastante fácil detectar aplicaciones publicadas con grandes bases de usuarios con este problema.
Si el problema fue la falta de pruebas, la solución es probar más.No obligue a sus desarrolladores a trabajar horas extras.Si elige no probar lo suficiente, siempre tendrá problemas críticos y sus desarrolladores siempre tendrán que trabajar hasta tarde.Tu desarrollador principal lo ve y está tratando de evitar sentar un precedente de "Bueno, la última vez que no probamos, nos salvaste Joe, así que ...".Los desarrolladores talentosos se convierten rápidamente en superhéroes y depende de ellos proteger sus límites.
Si usted y 3 personas se quedaron hasta tarde para solucionarlo, entonces el problema está resuelto, ¿no?Me concentraría en mejorar las pruebas para que esto no vuelva a suceder en lugar de castigar a un desarrollador por no trabajar lo suficiente.
Los puntos 3 y 4 están en conflicto.Dice que no puede solucionar el problema fuera del horario laboral debido a las limitaciones de la App Store, pero luego dice que lo solucionó fuera del horario laboral.
@Brandon: no, las tiendas de aplicaciones no impiden la creación de una solución, pero hacen que una reversión instantánea y una actualización instantánea sean un desafío y potencialmente imposible.Si bien no estoy de acuerdo con la mayor parte de lo que dice el autor de la pregunta, ir a la cama con la sensación de que un problema está resuelto tiene ventajas, incluso si * implementar * la solución puede tener varios días de latencia de revisión externa en la tienda.Pero las soluciones nocturnas tienden a abordar los síntomas y los errores simples, no las causas fundamentales.La * comprensión * nocturna de problemas profundos puede ser gratificante, pero aún se necesitará mucho esfuerzo para convertirse en soluciones.
@CodeProject ¿Quién elige la prueba?Desde su publicación, parece que el senior en cuestión también fue el responsable de diseñar las pruebas ...
@ChrisStratton Estoy de acuerdo contigo en que algo no está bien en el código base.Pasé medio día revisándolo y hay parte del código que nadie sabe por qué está escrito de la forma en que está.Será una gran refactorización
@Brandon No diría que es falta de pruebas.Normalmente gastamos 1: 1 dev: test pero en este caso gastamos 1: 1,5 dev: test.Así es, sabemos que necesitamos más tiempo para realizar las pruebas.Lo miro como dijeron que el producto está listo y no lo está, por lo que deben mantener sus palabras.
@Mars, todos en el equipo deciden juntos las pruebas.Sí, el chico también está al tanto y es parte de todo el proceso, incluido el diseño de prueba.
@CodeProject Actualicé mi respuesta con su nueva información :)
"Lo veo como dijeron que el producto está listo y no lo está, por lo que deben mantener sus palabras".Esa actitud será la muerte de su relación con su gente.
Sí, en este punto, sin que yo esté realmente allí observando y escuchando todos los lados del conflicto, no puedo ofrecer más consejos.He dado sugerencias.Lo que me preocupa en este momento es el enfoque que sigo escuchando en la culpa más que en las soluciones, incluso de personas distintas del OP.Creo de todo corazón que mientras sigas enfocándote en culpar y coaccionar a la gente, entonces tú eres el problema.Necesita tener una conversación sincera con su equipo, tanto colectivamente como 1: 1 y escuchar de verdad.No para comprobar si están de acuerdo contigo.Pero escucharlos de verdad.
#12
+4
sf02
2019-03-15 21:01:10 UTC
view on stackexchange narkive permalink

Si el 90% de los usuarios no pueden iniciar sesión y los usuarios no pueden realizar compras (es decir, se están perdiendo las ventas), debe revertir la actualización a la versión de trabajo anterior de inmediato. Esperar a que sus desarrolladores solucionen y corrijan el error puede llevar mucho más tiempo y causar un impacto más negativo en el usuario que simplemente volver a una versión anterior.

Más importante aún, es menos probable que sus desarrolladores quieran seguir trabajando para usted si se ven obligados a realizar horas extraordinarias cuando hay una mejor solución disponible. Si valora a sus empleados, debe respetar su tiempo fuera del trabajo.

Si se tratara de sitios web o servicios de backend, lo habríamos revertido.Desafortunadamente, esta es una aplicación en AppStore.
@CodeProject Existen limitaciones, pero hay formas de acelerar la reversión (en realidad, solo una actualización) de sus aplicaciones en la tienda, ¡si aún no lo ha hecho!
#13
+4
CharonX
2019-03-15 19:26:50 UTC
view on stackexchange narkive permalink

Respondiendo a la pregunta actualizada:

Su gran problema no es la falta de propiedad. Esto parece ser un síntoma de un problema subyacente más profundo: el hecho de que su proceso de desarrollo parece estar sustancialmente roto.

En teoría, su proceso (es decir, pruebas automatizadas, cobertura de pruebas de &, planificación en sprints, no cambios en los requisitos) debería evitar la mayoría de los problemas que ve.

Según su propia declaración, se encontró con varios problemas "Showstopper" con el programa incluso cuando se implementó en el cliente y algunos de ellos incluso fueron regresiones. Los sprints no terminan a tiempo (las pruebas son parte del sprint). E incluso cuando se escribe, la prueba no proporciona suficiente cobertura para detectar esos errores. También dijo que ya tuvo una situación de "quedarse hasta tarde" (por lo que les dio días libres después).

Necesita descubrir qué está fallando. Solo al encontrar y resolver el problema subyacente, puede esperar arreglar las cosas.

Ni siquiera es un problema de cobertura ... Han vuelto a realizar las pruebas y los errores vuelven a aparecer.En otras palabras, ¡alguien arruinó las pruebas O las correcciones causaron regresión!Entonces, ¿quién es el responsable de las pruebas fallidas?¿El senior que lo dio luz verde o el gerente que creyó al senior?
#14
+4
DigitalBlade969
2019-03-15 13:57:35 UTC
view on stackexchange narkive permalink

No puede obligar a alguien a hacer horas extras (depende del país y de circunstancias potencialmente extremas como excepción a las leyes)

Si la persona no puede o no quiere hacerlo Es su responsabilidad encontrar un empleado dispuesto o contratar ayuda externa si la tarea es vital y necesita atención inmediata.

Pregunte a un abogado laboralista en su jurisdicción para aclarar.

En cuanto a la propiedad y el seguimiento de las tareas asignadas o prometidas, tiene su arsenal disciplinario hasta la finalización de los contratos de trabajo.

Además, ¿qué Sefe dijo ...

Muy buena respuesta, y creo que se reduce a lo que creo que es el meollo de la cuestión. Además, si el OP quiere garantías, debe contratar contratistas, que no cobran salario.Los contratistas estarían obligados a entregar sin importar qué (como mejor les parezca).
Además, solo quiero decir, es probable que un empleado que no cumpla con una tarea asignada / prometida sea un problema de desempeño, más que un problema disciplinario, asumiendo que el empleado trabajó en ello lo mejor que pudo.
@GregoryCurrie estuvo de acuerdo, podría convertirse en disciplinario si se hace a propósito.
Nadie capaz desarrolla aplicaciones móviles con un contrato de precio fijo, * precisamente * debido a problemas como estos.
@ChrisStratton No creo que hayas comentado la publicación correcta ... no he visto a nadie hablar sobre desarrollo móvil de precio fijo ...
La respuesta fue al primer comentario que proponía la idea rota de que usar contratistas en lugar de empleados cambiaría esto.
@ChrisStratton a Creo que lo que quiso decir con el comentario fue, en lugar de utilizar empleados, conseguir trabajadores autónomos u otros contratistas que estén obligados por contrato a entregar el hito X en la fecha Y. Sin tener que cumplir las leyes de horas extraordinarias.(menos con los autónomos, ya que todavía no pueden ser obligados a trabajar si no quieren)
No encontrarás personas capaces dispuestas a firmar contratos tan absurdos.Aquellos con conocimientos reales entienden que los plazos inflexibles conducen a una falta de calidad inutilizable, porque las cosas * saldrán * mal y cuando lo hagan * algo * tiene que ceder.Para llegar a cualquier lugar, la estructura debe permitir trabajar juntos hacia los objetivos y a través de lo inesperado.
@ChrisStratton lamentablemente no es cierto. Las empresas contratistas con demasiada frecuencia anteponen la necesidad de clientes nuevos y recurrentes, el dinero o el prestigio a plazos razonables. Algunas incluso aceptan pérdidas financieras a corto plazo si aseguran un flujo de caja a medio / largo plazo.Por otro lado, por ejemplo, trabajar con tarifas diurnas y aceptar horas extraordinarias o trabajos de fin de semana / días festivos mientras están excluidos de los privilegios de los empleados y muchos cobran una prima por el trabajo urgente, ganándose la vida bien solo con eso.cuesta decenas de millones.
No. La realidad es que los plazos se retrasan o se entrega una falta de calidad inusualmente baja, con frecuencia ambas cosas.Y además, no puede tener una fecha límite contractual a menos que tenga una declaración significativa de trabajo y especificaciones.La mayor parte del problema del autor de la pregunta surge de la dificultad (se podría decir casi imposible) de determinar mediante pruebas * externas * si el código funcionará en * todas * las situaciones en las que se podría desear que lo hiciera.Juegue el juego de los plazos y puede obtener algo que * parece * que funciona * hoy * pero * descubrirá * en un mes que no satisface sus necesidades reales.
En contraste, cuando las personas que realmente entienden el tema trabajan juntas, como gerente y empleado, o como contratista y cliente, ellos * comprenden * dónde están los desafíos y riesgos, comprenden que algunos no se pueden predecir, comprenden que elLas especificaciones que se pueden escribir nunca capturan todos los detalles de la necesidad y, por lo tanto, trabajan juntas para resolver los problemas, en lugar de quemar la relación con demandas insatisfactorias.
@ChrisStratton Estoy de acuerdo, pero luego tiene las finanzas sopesando y la junta directiva / administración establecerá con mayor frecuencia los enfoques más baratos y las entregas más rápidas para que los ingresos se generen antes y el ROI se logre más rápido.un lanzamiento con errores y algo de reacción, así como los costos adicionales para arreglarlo mientras ya está obteniendo ganancias. No están interesados en su enfoque porque cuesta más por adelantado y retrasa los lanzamientos. He visto esto en innumerables ocasiones.
@DigitalBlade969: el punto es que si alguien presiona para lanzar software con componentes internos fundamentalmente rotos, entonces * ellos * tienen que aceptar el riesgo.No puedes decir "esto tiene que salir el viernes pase lo que pase" y luego "si se rompe, debes hacer magia" y hacerlo una y otra vez.Elija su punto sobre la compensación costo / beneficio, pero * sea honesto al respecto *, * acepte las consecuencias * y tenga una * actitud productiva * para trabajar juntos para recuperarse de lo que es inevitable - ** empujar la culpa cuesta abajo no es productivoactitud de recuperación **.
#15
+2
Alex KeySmith
2019-03-16 02:23:26 UTC
view on stackexchange narkive permalink

Respondiendo a la pregunta actualizada,

Parece que se han seguido buenas prácticas de trabajo:

  1. sprints
  2. bloqueo de funciones cerca de la implementación
  3. estimación de tiempo de los desarrolladores
  4. pruebas automatizadas

Estoy parcialmente de acuerdo en que existe una cultura positiva de corregir errores críticos en el tiempo. Sin embargo, la cultura también necesita Reflejar ningún código es perfecto, a menos que gastes mucho dinero en él, hay un antiguo piso que dice que la NASA gastó alrededor de $ 1,000 por línea de código. No comentaré mucho sobre el aspecto cultural, ya que eso ya ha sido cubierto por otros, en cambio, algunas sugerencias de metodología:

Una estructura de equipo que está de moda en este momento son los escuadrones de características que poseen de un extremo a otro. finalizan la entrega y la responsabilidad operativa de la vertical aislada que escriben. Si sale mal, ellos son los que se despiertan por la noche, sin embargo, sería cauteloso al introducir esto en un entorno heredado, ya que prestará atención al disgusto si un equipo no tuviera la oportunidad de presentar la calidad que desean desde el principio. -Vamos. Y los roles de Operaciones tradicionales con contratos / pago según convenga probablemente estén más abiertos a la forma de trabajar de guardia.

Una mejor idea sería introducir la idea de campeones de control de calidad dentro de un equipo y los "3 amigos" El enfoque, es decir, el producto, el desarrollador y el miembro de control de calidad, escriben juntos la especificación de características (diseño impulsado por el comportamiento). Esto asegura que "cómo un miembro de QA lo rompería" se contabiliza desde el principio y debe ser lo suficientemente detallado, es decir, una especificación a modo de ejemplo. No es necesario que el miembro de control de calidad sea la persona que escribe la automatización, pero debe revisar el código. Como la gente ha mencionado anteriormente, el autor del código no debería ser el único responsable de acreditar su calidad y presentar a un tercero lo antes posible en el proceso es un paso positivo.

Quizás también sea necesario mejorar el entorno de producción y la gestión de versiones. Las "implementaciones azul / verde" y las "pruebas en producción" son prácticas comunes para implementar cambios gradualmente a una audiencia cada vez más amplia solo cuando las métricas se prueban. Idealmente, su entorno de ensayo debería detectar errores críticos, pero siempre hay algo diferente en la producción, por lo tanto, nunca debería ser un lanzamiento espectacular.

A juzgar por el período de tiempo, aunque esté utilizando una cadencia de liberación típica, es posible que desee considerar la liberación con más frecuencia. Las versiones más pequeñas y frecuentes pueden conducir a un menor riesgo si se combinan con una buena automatización de pruebas y versiones. Esto se puede combinar con interruptores de funciones para que las funciones se puedan activar por completo cuando se completen las historias de usuario de redacción.

#16
+1
gnasher729
2019-03-16 02:29:18 UTC
view on stackexchange narkive permalink

Leí tu actualización. Su problema es que envió un producto roto. Eso es. Eso es en lo que necesita trabajar: no envíe productos rotos.

Su queja es ridícula. USTED decidió enviar un producto cuando estaba roto. Ahí es donde se detiene la pelota, contigo.

Luego cometió dos errores: Primero, parece que el momento de su lanzamiento fue tal que se le informó a las 4 pm. Lanzamiento media hora antes de que los desarrolladores lleguen al trabajo. Solución muy simple, es su trabajo saber esto. En segundo lugar, no parece haber ninguna motivación para que el empleado trabaje horas extraordinarias. Pagar horas extras suele funcionar bastante bien. Un entorno en el que permite que el código roto se envíe con regularidad no lo hace.

¿Qué?Parece que OP implementó un producto que el senior marcó como todo verde.Es posible que el OP ni siquiera tenga antecedentes técnicos (aunque en este caso parece que sí), pero el ingeniero senior es el responsable aquí ... Es posible que OP ni siquiera sepa qué significan algunas de las pruebas, pero la persona quese paga para saber lo que quieren decir dijo que estaban bien, luego, después de la liberación, dijo "ah, en realidad .....!"OP decidió enviar un producto "funcional", no un producto roto.
"Parece que no hay motivación para que el empleado trabaje horas extras" Um ... ¡está claro que eso va a ser una condición para mantener su trabajo!Tampoco se dice que sea OT no remunerado, y se dice explícitamente que la última vez que trabajaron un poco más, obtuvieron MUCHO tiempo libre adicional.
@Mars Apple lanza mis aplicaciones en la AppStore cuando _i_ presiono el botón.Totalmente bajo mi control.También puedo entregar primero a un pequeño porcentaje de clientes.Play Store hace lo mismo.
¡Mi error, no estaba al tanto de la liberación manual!Pero los otros puntos siguen en pie.Además, suponiendo que el lanzamiento fue alrededor de las 4 pm es principalmente una proyección: publicar a las 9 y obtener informes a las 10 todavía deja solo 7 horas para diagnosticar, corregir y volver a probar.Si se necesitan más de 7, entonces eso significa OT ...
Además, OP puede no ser responsable del lanzamiento, ese podría ser el cliente.En ese caso, necesitan hablar con el cliente sobre el uso de esa función, pero incluso sacar el tema probablemente no resultará bien con un cliente menos que experto en tecnología ... ("¿Qué quieres decir con retrasar el lanzamiento?¿Dijo que lo probó? Le pagamos para que lo probara. Si no puede tenerlo listo para un lanzamiento completo para este día, tal vez deberíamos tener a alguien más que pueda ... ")
#17
+1
Joe
2019-03-16 17:17:42 UTC
view on stackexchange narkive permalink

A la luz de la pregunta actualizada, sugiero que si bien es posible que tenga un problema de actitud de empleado en sus manos, lo que realmente tiene es una calidad de software problema:

  1. No existe un proceso de garantía de calidad independiente de los desarrolladores que escriben estas funciones. Los desarrolladores son notoriamente malos probando su propio código, en gran parte porque, naturalmente, comienzan con la suposición de que todo lo que escribieron funciona y debería funcionar de la forma en que pretendían que lo hiciera, en lugar de cómo el usuario final espera que lo haga.

  2. Cualquier entorno de prueba que tenga no es adecuado para reproducir los problemas identificados por sus clientes. Identificó errores que impidieron el inicio de sesión en varias etapas del proceso, pero la verificación final no identificó este problema.

  3. El desarrollador senior está dispuesto a ignorar los problemas críticos que en realidad son fundamentales . "Amigo, mis amigos y yo íbamos a hacer algo genial esta noche" no es el tipo de reacción a "nadie puede iniciar sesión, por lo tanto, nuestro negocio está perdiendo el 100% de los posibles ingresos de estos productos que usamos". para pagar tu salario ”quieres ver. Si así es como reacciona ante una emergencia, ¿cómo crees que lidia con cosas menores? ¿Con más atención a los detalles o menos?

Hay una parte específica de tu historia actualizada que me plantea muchas más preguntas y creo que debes investigar en detalle: en En un punto del proceso, el equipo dijo que escribieron todas las pruebas y no hubo problemas. Luego, dice más tarde, se descubrió que no todas las pruebas se escribieron después de todo, que el error de inicio de sesión no se identificó y que dedicó tiempo adicional a escribir esas pruebas y solucionar el problema de inicio de sesión, que luego se demostró en producción para no ser reparado.

  1. Cuando dijiste que las pruebas no estaban escritas después de todo, ¿por qué no estaban escritas? ¿Fue que el caso en cuestión fue un descuido o el equipo tergiversó la finalización de su trabajo? Es razonable esperar que lo primero suceda ocasionalmente, lo último es un comportamiento inaceptable que debe dejar claro que no será tolerado en el futuro (a menos que haya sido un malentendido de su parte).

  2. Una vez redactadas las pruebas, ¿cómo sabe que estas pruebas son correctas? ¿Revisaste las pruebas? Claramente no funcionan; todos pasaron, pero el problema que se probó explícitamente y se dijo que estaba solucionado aún llegó a producción. No es extraño que personas sin escrúpulos escriban pruebas de manera que siempre pasen, especialmente si hay presión de fecha límite. Si no puede revisar las pruebas usted mismo, debe buscar a un técnico en otro equipo para que las revise por usted.

También hay algo más que escribió, que el El número de errores críticos ahora es de hasta una vez al mes, pero antes era más como una o dos veces al año. ¿Porqué es eso? ¿Ha investigado por qué está sucediendo eso ahora? ¿El producto o el equipo cambió significativamente en ese período de tiempo? Parece que la calidad está disminuyendo.

Esto es lo que creo que debería hacer:

  1. Contratar a un evaluador de control de calidad bueno y experimentado y someter todo el trabajo de este equipo a pruebas de control de calidad independientes (debe hacer esto en toda su empresa, pero este equipo en particular lo necesita porque la calidad está disminuyendo).

  2. Revise el entorno de prueba y compárelo con la producción para asegurarse de que el entorno de prueba aún refleja la producción.

  3. Revise las pruebas y el código que su equipo está escribiendo para determinar la calidad y la corrección de manera regular y con más detalle de lo que está haciendo actualmente.

Es posible que tenga un problema de actitud en su equipo con el senior, pero definitivamente tiene un problema de calidad. Los problemas de actitud son difíciles de solucionar, pero los problemas de calidad son más fáciles de solucionar y tienen la ventaja adicional de hacer que la actitud de un chico del equipo sea irrelevante si lo haces bien.

#18
  0
Ibraheem
2019-03-16 15:22:24 UTC
view on stackexchange narkive permalink

Siendo yo mismo un miembro senior del equipo y teniendo que lidiar con situaciones de este tipo una y otra vez, solo puedo decir que un tipo en el que siempre puedes confiar también necesita algo de motivación. El tipo seguramente es honesto y tiene derecho a su vida personal después de la oficina, pero se quedará y arreglará errores si hay una mejor motivación para él, o si logras crear un ambiente amigable para él.

Piensa al revés: qué pasa si el tipo se enferma o deja el trabajo o tiene alguna emergencia y tiene que dejar la oficina por un tiempo. Actualmente, su tiempo con sus amigos parece ser un problema para usted, pero puede tener todas las necesidades legítimas para salir de la oficina incluso durante las horas de trabajo (y pasar tiempo con sus amigos después de la oficina también es una necesidad legítima).

Una actitud gerencial muy común es siempre pasar por alto al tipo que puede hacerlo . Ahora bien, esto varía de persona a persona, pero al ser un empleado, esto puede generar frustración y tal situación surge cuando el empleado comienza a decirle no .

Entonces, en mi opinión, debe hacer dos cosas:

1: ) Debería crear una plataforma de aprendizaje para el personal subalterno y delegar gradualmente las cosas para que en momentos de necesidad crítica no tenga que mirar el mismo chico cada vez.

2: ) Siempre que dentro del horario de oficina el chico esté haciendo lo que se supone que debe hacer y cumpliendo con sus KPI, está bien y debe ser tratado de manera amistosa. conducta.

#19
-2
Keith
2019-03-14 22:38:11 UTC
view on stackexchange narkive permalink

Me parece que él simplemente valora más estar fuera de la oficina que en ella.

Hay muchas razones por las que, y un buen administrador no asumiría simplemente lo peor. Quizás esté teniendo problemas personales en casa, ya sea una relación, una enfermedad o cualquier otra tensión.

Quizás esté cada vez más insatisfecho con el trabajo y simplemente ya no le importa.

Hay muchas razones por las que puede estar actuando como lo hace. Te sugiero que veas si hay algo por lo que querrías darle más gracia antes de desgarrarlo demasiado o disciplinarlo.

Los comentarios no son para una discusión extensa;esta conversación se ha [movido al chat] (https://chat.stackexchange.com/rooms/91182/discussion-on-answer-by-keith-employee-lack-of-ownership).
#20
-5
Mars
2019-03-15 15:03:53 UTC
view on stackexchange narkive permalink

Bienvenido a WorkPlace, donde todo es culpa del gerente. Todo.

Lo miro como dijeron que el producto está listo y no lo está, por lo que deben mantener sus palabras. - Proyecto de código

Enmarca la pregunta de una manera diferente .
Tienes un ingeniero senior al que se le ha asignado la responsabilidad de una función, es responsable de las pruebas y ha pasado el producto final. Ese producto con luz verde tiene problemas de calidad críticos. (¡Y estoy de acuerdo en que su definición es bastante crítica!)
En otras palabras, tiene un ingeniero senior de bajo rendimiento que no desea hacer horas extras para corregir sus propios errores (o, como usted dice, cumplir con sus promesas).

Pero la clave aquí no es que el ingeniero no haga horas extras - según los comentarios, tienes una aplicación móvil, por lo que no es como si pudieras lanzar una solución rápidamente de todos modos.
El problema clave es que el ingeniero senior está dando luz verde a estos productos rotos en primer lugar.

Las expectativas / legalidades aquí dependen en gran medida de dónde se encuentre ubicado, pero en una cuenta personal, nunca he trabajado en una empresa (EE.UU. o Japón) donde se aceptaría la falta de propiedad de su ingeniero superior. Ya sea que tenga la culpa o no, es un hecho que un error crítico debe solucionarse lo antes posible. Afortunadamente, tampoco he trabajado en una empresa en la que al menos no me pagarían (dentro de lo razonable) por mis esfuerzos para corregir mis propios errores.


El siguiente paso aquí es revisar y encontrar por qué ocurren estos errores. La mayoría de las respuestas aquí sugieren que el problema es algo sistémico; yo diría que el hecho de que solo uno de sus múltiples equipos tiene el problema sugiere lo contrario.

Aún así, debe revisar, encontrar la causa e intentar arreglarlo. Si se trata simplemente de un ingeniero senior de bajo rendimiento, entonces se deben tomar medidas para que ese ingeniero esté a la altura o para contratar a otro ingeniero que pueda hacer el trabajo correctamente.

Las diferencias culturales son interesantes (Reino Unido).Me considero dedicado.Felizmente trabajo en horas impares para acomodar a las personas con las que trabajo Y, en realidad, mi contrato establece que debo trabajar mis horas "para satisfacer las necesidades de la empresa", pero si me dicen, en un momento, que debo trabajar horasarreglar el error X, estaría a mitad de camino a casa antes de que la puerta dejara de moverse, actualizando mentalmente mi CV a medida que avanzaba.Una historia diferente si se me pregunta y obviamente tomé la decisión de hacerlo por mi cuenta.Afortunadamente, existen empleadores y clientes que respetan el equilibrio entre la vida laboral y personal de los empleados y tuve suerte.
@BrentHackers Oh, ciertamente reconozco que las horas extras forzadas y las horas extras que TÚ decides que son necesarias se sienten diferentes.Pero al mismo tiempo, si yo fuera ese ingeniero senior, me sentiría como "oh, mierda, mis errores o los errores de mi equipo pueden costarle clientes a esta empresa. ¡Mejor hago mi parte para arreglar eso!"
Sin embargo, es una historia diferente cuando sientes que la culpa pertenece a otra parte.Puse mi parte de OT por los errores de otra persona y eso se siente horrible.Salí de allí muy rápido
"Bienvenido a WorkPlace, donde todo es culpa del gerente. Todo".-- Completamente de acuerdo.Leí la pregunta y luego me preparé para la avalancha de respuestas que declaran que OP es el peor administrador del mundo.No me decepcionó.
@Graham Si Live se interrumpe varias veces al mes y no han introducido medidas para evitar que eso suceda, ¿a quién más responsabilizas?
@UKMonkey ¿Qué tal el probador que dijo que estaba bien?¿O el que revisa el trabajo del probador?
¿@Mars o el que observa las críticas todos los meses pero no exige que el equipo haga algo al respecto?
@UKMonkey No hay información aquí que sugiera que no están haciendo nada al respecto ... Sin mencionar que la tasa de críticos no fue un problema particular hasta hace muy poco y parece ser un problema muy localizado.Pero como sugiere mi respuesta, estoy de acuerdo en que el mayor problema es que este ingeniero senior está lanzando críticas en primer lugar.
@UKMonkey En realidad, hay 2 preguntas aquí: ¿Debería esperarse que un ingeniero deje todo para corregir errores críticos inesperados?Culturalmente hablando, esa es la norma aquí.Sin embargo, no puedo decir que sea igual en todas partes.¿Debería esperarse que un ingeniero deje todo para arreglar un error crítico que fue su error?Yo diría que sí, si quieren mantener su trabajo.
"No hay información aquí que sugiera que no están haciendo algo al respecto" seguro que la hay, sigue sucediendo.La reacción correcta es ver que hay un problema, tener una reunión de equipo y establecer por qué los errores están pasando y solucionarlo.La tasa no es importante, porque CADA vez que hay una falla, se deben tomar medidas para garantizar que no vuelva a ocurrir;
@UKMonkey ¿Qué tan rápido debe resolverse el problema?Ha estado sucediendo ESTE año.Es el tercer mes del año.Aquí no hay evidencia que sugiera que no tuvieron una reunión de equipo, o establecer por qué los errores se están pasando
@UKMonkey Está asumiendo que también están cometiendo los mismos errores cada vez ... mire cuánto OP ha publicado.No parecen ser estúpidos ni albergar mala voluntad, ¿así que trata de no asumir lo peor de ellos?
@Mars No estoy asumiendo el peor de ellos en absoluto: la causa por la que el usuario no puede iniciar sesión puede ser diferente, pero claramente la prueba de que el usuario puede hacerlo no es suficiente.Si yo fuera el gerente, habría llamado a los evaluadores y les habría preguntado qué medidas han tomado para evitar que esto vuelva a suceder.Intentar culpar al ingeniero por querer irse a casa cuando no le pagan es lo que yo definiría como abuso de posición.
@UKMonkey Creo que el probador y el ingeniero son las mismas personas ... Y los probadores detectaron el error (¡pruebas no insuficientes!), Afirmaron haberlo solucionado y aprobaron el lanzamiento del producto.1) Nadie dijo que el OT no fue remunerado (de hecho, aparentemente por un poco de OT el ingeniero fue recompensado con muchas vacaciones extra), y 2) ¿Por qué se le paga al ingeniero en primer lugar, si no lo están haciendo?su trabajo correctamente?Sí, se deben tomar medidas para ayudar al ingeniero a hacer su trabajo correctamente en el futuro, pero lo primero es lo primero: arreglar la liberación y minimizar los daños
#21
-20
Bill Leeper
2019-03-15 00:41:08 UTC
view on stackexchange narkive permalink

Parece que es hora de avisar a todo este equipo. Si no comienzan a cumplir con las pautas, pautas claras, se cancelarán.

Puede lograr esto estableciendo pautas sobre errores / problemas que se informan contra lo que admiten. Por ejemplo, un error de prioridad 1 debe comenzar a funcionar dentro de 1 hora, el progreso se debe informar a la gerencia (usted) cada hora después de eso, hasta que el error se solucione o se implemente una solución a su satisfacción. Su satisfacción es clave, y debe apoyarlos a ellos y a los otros equipos para que hagan las cosas cuando el trabajo fluye más allá de las horas normales de trabajo estando presente o muy disponible usted mismo.

Cuando se vayan a casa , luego no cumplieron con sus requisitos para trabajar en el problema y registrarse cada hora. Esto ahora es medible. Estos lineamientos también tendrían que ser cumplidos por otros equipos.

Ahora, cuando no cumplen con estos requisitos una vez, notifican, notifican formalmente por escrito, CC a su gerente y a RR.HH. que no cumplieron sus obligaciones. La segunda vez, vuelve a informar, informa al equipo que un tercer incidente es motivo de despido. Tercera vez, despedido.

Ahora supongo que este desarrollador senior tiene algunos conocimientos críticos que supone que los hace invaluables. Nadie es tan valioso y esto envía ese mensaje. No están apoyando a la empresa, la empresa ya no los apoyará.

Espere algunas consecuencias si se trata de la rescisión. De hecho, poseen un conocimiento que requerirá cierto esfuerzo para ponerse al día con los demás. Asegúrese de que los desarrolladores de Jr. conozcan estas políticas, si pueden comenzar a hacer el peso incluso si su Sr. los abandona, entonces podrán mantener las cosas en marcha cuando elimine al alborotador.

Este enfoque es una forma segura de ganar a su tienda la reputación de ser un gran lugar que los desarrolladores de software deben evitar."Construya proyectos alrededor de personas motivadas. Bríndeles el entorno y el apoyo que necesitan, y confíe en ellos para hacer el trabajo".(agilemanifesto.org) Ese es el camino a seguir.
Normalmente, podría estar de acuerdo contigo.Sin embargo, la declaración de OP "Cada vez que hay un error crítico ..." deja dolorosamente claro que esto sucede con bastante frecuencia.Y eso me dice que es muy posible que el OP esté fallando en su trabajo y ejerza presión en lugares a los que no pertenece.Personalmente, creo que el OP necesita reevaluar por qué están implementando un código que tiene este error en producción y tal vez descubrir cómo solucionarlo antes de despedir a la gente.En otras palabras, estoy tratando de entender por qué un lugar con 20 desarrolladores no tiene las pruebas adecuadas o incluso un equipo de producción real para manejar estos problemas.
Si realmente implementa el procedimiento descrito en el segundo párrafo, espero que las "consecuencias" consistan en que los otros tres equipos renuncien para salir del control de un dictador de hojalata.
Recuérdame que nunca trabaje en una empresa en la que tengas autoridad administrativa
@NotMe ¿El ingeniero senior que diseña, desarrolla, prueba y lanza el producto no es la razón por la que ocurren estos errores críticos?Estoy de acuerdo en que un equipo de producción / prueba sería un formato de equipo mucho mejor, pero tal como está (que también es bastante común), es el caso de alguien responsable de un producto que no lo entrega correctamente ...
@Mars: basado en la actualización de los OP, parece que la razón de estos errores críticos es que su entorno de prueba en realidad no usa una copia de los datos en vivo.En otras palabras, su entorno / plan de prueba es basura.Necesitan arreglar eso primero.
@NotMe Si ese es el caso, estoy totalmente de acuerdo.Pero parece que eso es solo un problema para ese equipo, lo que significa que es el líder de ese equipo el que tiene el entorno insuficiente ... Pero no me sonó así.Parece más bien que afirmaron haberlo solucionado, pero perdieron la solución en algún momento del camino (no se corrigieron realmente, o se perdieron durante las fusiones, etc.)
Si despide a todo su equipo de desarrollo, o incluso amenaza con hacerlo, tenga la seguridad de que nadie se quedará hasta tarde para corregir errores críticos.
@Mars Creo que es solo ese equipo el que no se queda hasta tarde para corregir errores críticos, aunque realmente no especificó si los otros equipos los tienen o no.
Cierto.Creo que ambas partes están haciendo suposiciones aquí; esta pregunta me parece demasiado cargada culturalmente.Lo leí (ya después de la actualización) y mi impresión fue que la persona no está ni remotamente calificada para estar en un puesto de responsabilidad, sin embargo, mi respuesta y esto son hasta ahora negativas, ni siquiera es gracioso jaja


Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 4.0 bajo la que se distribuye.
Loading...