¿Cómo mantenerse firme cuando los colegas están descuidando el proceso?

¿Todos realmente están de acuerdo?

Una vez tuve una situación en la que queríamos mejorar los procesos. Hicimos una propuesta de un Proceso diferente, y todos parecían estar de acuerdo.

Pero luego, cada vez que quería seguir este proceso, se llamaba una excepción, debido a "asuntos más importantes", que siempre sonaban razonables a primera vista. Entonces, en Efectivo, el proceso nunca se siguió de facto, pero todos pensaron 'en principio, estamos siguiendo el proceso'.

El problema era: si propones una mejora, no hay nadie que no esté de acuerdo (¿a quién no le gustan las mejoras?). Pero si presenta los costos, por lo general, hay mucho desacuerdo. Y perder la forma conveniente de hacer las cosas es un costo enorme para la mayoría de las personas.

Para demostrarlo, expresé la pregunta de manera diferente: 'Por favor, priorice todas las cosas que se supone que debo hacer (implementar funciones, eliminar errores, seguir el proceso mejorado, limpiar el escritorio, llegar a tiempo)'. >

El proceso finalizó después de limpiar el escritorio y no llegar 5 minutos tarde. Así que, básicamente, acordaron algo completamente diferente de lo que yo propuse.

El problema puede ser que no quieren pagar los costos de la calidad. Eso puede llevarlos a racionalizar su criticismo como lloriqueo, pero en mi experiencia, no lo es. La deuda técnica puede no ser tan visible, y es fácil atribuirla a las circunstancias, pero eventualmente, la realidad se produce.

Esperemos que, hasta entonces, se hayan dado cuenta, o hayas cambiado de trabajo.

Quizás eres tú

Pareces estar a favor de una forma muy estructurada y organizada de codificación, tus compañeros de equipo parecen tener un enfoque más "de hacer las cosas". Ahora mencionas que conduce a un montón de "tiempo perdido", por lo que quizás algo de estructura está en orden y no hay excusa para el trabajo descuidado. Sin embargo, los proyectos de software tienden a ser fluidos y imponer demasiada estructura también causará una gran cantidad de gastos de organización.

Quizás todos deberían reunirse en el medio y probar un enfoque más ágil e interactivo, pero estructurado.

¿Quién es responsable de estas personas? Alguien los contrató y alguien puede despedirlos / responsabilizarlos.

"Mi compañía requiere ..." no tiene sentido sin un poco de cumplimiento.

No puede hacer demandas de tiempo que no permitan el proceso de producción.

Parece que esta falta de control y expectativas poco realistas son las razones de la mala calidad.

Puede: dejarlo, convertirse en el desarrollador principal, no hacer nada o comenzar a trabajar con aquellos que se sientan como usted. Asegúrese de que todos sepan que va a seguir los procedimientos correctos hasta que alguien encuentre una manera mejor y los cambie. Suena como "Las reglas de la sidrería".

Parece que no quieres que tus compañeros de trabajo sigan un proceso completamente diferente, solo quieres que tomen decisiones diferentes en él. Claro, hay reglas (¿pautas?) Sobre lo que deben hacer, y las ignoran. Pero el problema que describe es que tienen que tomar una decisión (comenzar a trabajar en el proyecto o rechazar una especificación) y deciden seguir adelante. Esa decisión no cambiará si sigues recordándoles las reglas; simplemente no les importan tanto las reglas como tú . Quieren sentirse útiles, y decir que no no les hace sentirse útiles .

Si desea que su comportamiento cambie, entonces recordarles continuamente las reglas probablemente no sea muy efectivo; es más probable que conduzca a que te ignoren. Trate de encontrar una manera de cambiar el proceso para que se sientan más útiles mientras sigue el proceso. ¿Puede implementar algún tipo de revisión de código, verificando el código de cada uno y aprendiendo el uno del otro para evitar que los hackeos lleguen al código de producción? ¿Puede cambiar la forma en que las especificaciones (docs / ext.interfaces / front-end) se manejan desde una decisión en blanco y negro con acabado / sin terminar a un proceso más cooperativo, donde casi al final de la especificación se le pide a un desarrollador que lo haga? ayudar a terminar? (Y, debe aceptar que los requisitos cambiarán )

Principalmente no eres tú, no son ellos, es el proceso. Si tú (y tu PM) pueden encontrar una manera de organizar las cosas donde las personas no tienen que ir tan en contra de su carácter, el proceso se seguirá mucho más rápido.

Esto es sobre el punto en el que me registraría con una sesión a puerta cerrada con el líder de mi equipo. Esperamos que tenga una relación de trabajo suficientemente buena con el liderazgo que pueda hacer que sea muy informal.

El propósito de la reunión es averiguar por qué el equipo está haciendo las cosas como lo está haciendo. Si todos se juntaron, asintieron, sonrieron y aceptaron un nuevo proceso, ¿por qué siguen sin cambiar? Hay muchas posibilidades de que sea mucho más profundo que la simple falta de atención o la incompetencia. Es probable que haya conductores en el trabajo que no sean visibles a simple vista.

Comience la reunión asumiendo que sus compañeros de trabajo, si pudieran, seguirían un proceso que conduce a menos pánico, menos endeudamiento técnico y mayor calidad del producto. Después de todo, ¿quién no quiere eso? Entonces, ¿cuál es la fuerza invisible?

Parece que hay mucha implementación / integración antes del trabajo inicial de diseño y prototipo de interfaz de usuario. ¿La empresa no cuenta con personas que puedan hacer ese trabajo inicial? Tal vez usted podría ser voluntario. ¿Hay algún problema para obtener consenso con las partes interesadas? Tal vez su equipo puede encontrar una nueva forma de comunicarse con ellos o puede adoptar un nuevo enfoque para documentar las suposiciones.

Si comienza con uno a uno en el que le pregunta a su interlocutor por qué , puede abrir la puerta a una discusión que evite la actitud defensiva y se centre en los problemas y las soluciones.

Otro truco podría ser preguntar si puedes iniciar una nueva forma de hacer las cosas. Obtenga el respaldo de su líder de equipo para forzar un poco el problema y le permite adoptar el enfoque que está defendiendo; probablemente se presentarán problemas a medida que se oponga al "sistema", por lo que querrá que la administración lo respalde. Pero si se vuelve más productivo y libre de estrés, es un buen caso para cambiar el modo de las cosas y es probable que gane defensores.