¿Cómo mantenerse firme cuando los colegas descuidan el proceso?

El problema al que me enfrento:

1. Los miembros de mi equipo comienzan a trabajar en proyectos sin tener listos los documentos funcionales / técnicos, incluso si el proceso de nuestra compañía dicta que estos deberían estar allí antes de comenzar.
2. Los miembros de mi equipo aceptan soluciones baratas y no estructuradas e implementarán hacks realmente malos en el software sin pensarlo dos veces cuando la gerencia del proyecto tenga en cuenta que tienen "tiempo limitado".
3. Los miembros de mi equipo comienzan a trabajar en proyectos que funcionan junto con un proyecto sin terminar de otro equipo, que no ha sido probado ni terminado. (causando mucho trabajo extra).
4. Las mejoras y la (s) fase (s) completa (s) del software no se planifican adecuadamente, y a menudo dan como resultado que el diseño / front-end no esté terminado cuando el desarrollador de back-end tiene que comenzar a trabajar.

Estos problemas se han discutido infinitamente varias veces desde que comencé a trabajar aquí. Todos estuvieron de acuerdo y la conclusión fue que debemos hacer cumplir el proceso, eso significa que el desarrollador de back-end no comenzará hasta que todo esté resuelto.

Estos problemas continúan sucediendo, y me estoy desmotivando hasta el punto de que estoy realmente molesto con el trabajo en sí y con algunos de mis colegas.

Los miembros de mi equipo se quejan mucho, pero solo el uno hacia el otro. They keep on going - whatever the situation is. ¿El resultado?

1. Me vuelvo inseguro, ¿tal vez soy yo?
2. ¿Es así como se supone que van las cosas?

¿Mi pregunta? How can I say no against work ignoring the process if everyone else seems to mindlessly accept?.

Eso es sin parecer un desarrollador molesto que solo está buscando algo para quejarse todo el tiempo.

¿Todos realmente estuvieron 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 sonaba razonable a primera vista. Entonces, en efecto, el proceso nunca se siguió de facto, pero todos pensaron 'en principio, estamos siguiendo el proceso'.

El problema era: si propone 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, formulé la pregunta de manera diferente: "Por favor, priorice todas las cosas que se supone que debo hacer (implementar características, eliminar errores, seguir el proceso mejorado, limpiar el escritorio, llegar a tiempo)".

El seguimiento del proceso terminó detrás de la limpieza del escritorio y no sonó 5 minutos tarde. Entonces, básicamente, acordaron algo completamente diferente de lo que propuse.

El problema puede ser que no quieren pagar los costos de calidad. Eso puede llevarlos a racionalizar su crítica como una queja, 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, se produce la realidad.

Con suerte, hasta entonces se dieron cuenta, o cambiaste de trabajo.

Tal vez eres tu

Parece favorecer una forma de codificación muy estructurada y organizada, sus compañeros de equipo parecen tener un enfoque más de "hacer las cosas". Ahora mencionas que conduce a una gran cantidad de "tiempo perdido", por lo que tal vez es necesaria alguna estructura y no hay excusa para un trabajo descuidado. Sin embargo, los proyectos de software tienden a ser fluidos y hacer cumplir demasiada estructura también causará una sobrecarga organizativa.

Quizás todos deberían encontrarse en el medio e intentar 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 empresa requiere ..." no tiene sentido sin alguna aplicación.

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.

Puedes: irte, convertirte en el desarrollador principal, no hacer nada o comenzar a trabajar con aquellos que se sienten como tú. Asegúrese de que todos sepan que va a seguir los procedimientos correctos hasta que alguien encuentre una mejor manera y los cambie. Suena como "Las reglas de la casa de la sidra".

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 (para comenzar a trabajar en el proyecto o rechazar una especificación) y deciden seguir adelante. Esa decisión no cambiará si sigue recordándoles las reglas; simplemente no les importan tanto las reglas como a ti . Quieren sentirse útiles, y decir que no no los hace sentir útiles .

Si desea que su comportamiento cambie, entonces recordarles continuamente las reglas probablemente no sea muy efectivo; es más probable que les haga ignorarlo. 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 del otro y aprendiendo unos de otros para evitar que los piratas informáticos lleguen al código de producción? ¿Puede cambiar la forma en que se manejan las especificaciones (docs / ext.interfaces / front-end) de una decisión terminada / no terminada en blanco y negro a un proceso más cooperativo, donde cerca del final de la especificación se le pide a un desarrollador ayuda para terminar? (Y, usted debe aceptar que los requisitos serán cambiar)

Principalmente no eres tú, no son ellos, es el proceso. Si usted (y su PM) pueden encontrar alguna forma de organizar cosas donde las personas no tengan que ir en contra de su personaje, el proceso se seguirá mucho más rápido.

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

El propósito de la reunión es descubrir por qué el equipo está haciendo las cosas de la manera en que las está haciendo. Si todos se han reunido, asintieron, sonrieron y aceptaron un nuevo proceso, ¿por qué todavía no están cambiando? Es muy probable que sea mucho más profundo que la simple falta de cuidado o 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 los llevaría a menos pánico, menos deudas técnicas y una 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 tiene pocas personas que puedan hacer ese trabajo inicial? Tal vez podrías ser voluntario. ¿Hay algún problema para llegar a un consenso con las partes interesadas? Quizás su equipo pueda encontrar una nueva forma de comunicarse con ellos o adoptar un nuevo enfoque para documentar los supuestos.

Si comienza con uno a uno donde le pregunta a su líder por qué, entonces 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 puede ser pionero en una nueva forma de hacer las cosas. Obtenga el respaldo del líder de su equipo para forzar un poco el problema y permitirle adoptar el enfoque que está defendiendo: es probable que surjan problemas a medida que se resista al "sistema", por lo que desea que la administración lo respalde. Pero si resulta ser más productivo y libre de estrés, proporciona un buen caso para cambiar la forma de las cosas, y es probable que gane defensores.