¿Cómo inducir un cambio de procedimiento cuando es tu jefe el que se resiste?

Trabajo en una pequeña empresa de software en un equipo de 5 personas. Actualmente manejamos una buena cantidad de clientes, pero a medida que incorporamos más, se hace evidente que algunas de nuestras políticas están bastante desactualizadas y necesitan mejoras para ser más eficientes y reducir el tiempo perdido. Las áreas de posible mejora incluyen:

  • Presentamos herramientas de productividad: los nuevos miembros del equipo las han incorporado (Slack, Trello, Basecamp) y es una mejora significativa con la comunicación y el flujo de trabajo diarios.
  • Prácticas de control de versiones erráticas: solo una rama por proyecto, liberando cambios importantes en la rama utilizada para el código de producción en lugar de ramas, sin comunicación de que hay cambios importantes.
  • No ser lo suficientemente estricto con el avance del alcance: gran parte de nuestro negocio se basa en el boca a boca, por lo que se adapta un poco del avance del alcance para dar buenas relaciones públicas, pero a veces la línea se traza demasiado tarde y conduce a retrasos en los proyectos que han comentado nuestros clientes. en.
  • Falta de visibilidad de las horas asignadas a los proyectos: Dificulta saber cómo priorizar y ritmo de trabajo. A veces, los proyectos más pequeños con presupuestos más grandes se realizan con tiempo de sobra, pero otras veces los proyectos más grandes con presupuestos ajustados no se comunican hasta que se convierte en un problema y nos acercamos rápidamente a la asignación de tiempo con más trabajo por hacer.

He hablado con mi jefe sobre cosas en el pasado y he implementado procedimientos que han sido útiles (por ejemplo, reuniones de cierre de proyectos que han ayudado a que los proyectos futuros funcionen sin problemas), pero los puntos destacados, especialmente el uso de herramientas de productividad y versión las prácticas de control parecen ser un punto conflictivo. Mi jefe es muy práctico y se involucra en la entrega de proyectos, por lo que está muy ocupado. Los miembros del equipo han mencionado esto de pasada, así como los colegas que desde entonces dejaron el equipo, pero aún así no incitó a ningún cambio permanente. Es evidente que mejorar en estos puntos ayudará al equipo, ya que entre los miembros del equipo y yo que han adoptado las herramientas de productividad, realmente ha hecho que el trabajo diario sea más eficiente.

Los puntos 3 y 4 están realmente fuera de mi control ya que no tengo voz en la gestión, por lo que no puedo predicar con el ejemplo, especialmente porque son más un esfuerzo de equipo, pero son puntos que creo que podrían abordarse.

Mi pregunta

¿Cómo abordo las inquietudes y mejoras de procedimiento con mi jefe y superior de manera que sean receptivos a las sugerencias?

Me preocupa mencionar esto porque no quiero parecer conflictivo o causar problemas, pero creo que esto debe abordarse a medida que crece nuestra base de clientes. Son puntos conflictivos con los que nos confundimos en el pasado, pero preveo que se convertirán en un problema mayor cuanto más tiempo pase y más ocupados estemos.

Dices que otros miembros del equipo han estado usando las mismas herramientas que tú intentas normalizar. ¿Cómo se sentiría su jefe acerca de que el equipo de desarrollo sugiera colectivamente sus ideas en lugar de que solo provengan de usted? ¿Alguna vez sus colegas le hicieron tales sugerencias a su jefe en el pasado?
@Kozaky, un colega que ahora se fue, intentaba constantemente impulsar mejores prácticas en el pasado. He mencionado el uso de herramientas de productividad en nuestras reuniones de equipo que tenemos semanalmente. Hace un tiempo tuvimos una gran reunión sobre este tipo de cosas y, como resultado, comenzamos a usar JIRA, pero eso se abandonó un par de meses después porque no todos lo estaban usando (el superior y el jefe), por lo que fracasó un poco.
Si no hay nadie más senior que esté dispuesto a anularlos, entonces me parece que las únicas opciones son: 1) dedicar tiempo y esfuerzo a crear un caso de negocios sólido con ventajas, costos, análisis de riesgos, etc., que sea difícil de discutir 2) irse ... Si sus superiores no aceptan buenos consejos y se niegan a ser convencidos, entonces tienen que agruparlo o dejarlo realmente. Ese es el poder que se merecen por ser los únicos responsables de las cosas.
@HelloWorld Creo que irme es un poco testarudo para esto. En general estoy contento con mi trabajo y con cómo van las cosas. Es solo una cuestión de implementar mejores prácticas para que sea más fácil para todos en el futuro :)
@Longisland sí, sé lo que quieres decir, pero quiero decir, es una opción;) A veces es difícil persuadir a las personas a menos que estén abiertas a ello. Trabajando en TI, tengo el carisma de una tabla de madera de todos modos aha

Respuestas (2)

La gente odia el cambio... Y eso es porque la gente odia el cambio... Quiero estar seguro de que entiende mi punto. La gente realmente odia el cambio. Realmente, realmente lo hacen.

–Steve McMenamin

(Esto es de "Peopleware", no de "El arte de la gestión de proyectos", recomiendo leer ambos)

Ahora, he estado en tu situación, y realmente no creo que puedas manejar con éxito hacia arriba aquí. Incluso si su jefe estará de acuerdo en que "necesitamos cambios X, Y, Z" pero sin compromiso, no se mantendrá.

Lo único que razonablemente puedes hacer es mejorar tu propia vida. Cree un "bolsillo de excelencia" en torno a sus responsabilidades personales.

Comience a escribir más cosas, por ejemplo, al final de cada reunión. Al final de las reuniones, diga en voz alta: "Entonces, ¿cuáles son las decisiones procesables?" Haga una lista en algún lugar en línea (yo uso Basecamp).

Not being strict enough with scope creep

Cuando se reúna con el jefe o simplemente haga una actualización del proyecto, siempre puede abrir la computadora portátil y decir: "Amigos, como lo veo aquí, hace 3 meses decidimos no hacer X, ¿estamos cambiando esa decisión? ¿Por qué?" La lectura en voz alta de la computadora portátil abierta es una táctica muy efectiva.

Intente preguntar de manera proactiva si la característica X es más importante que la Y. Cree listas de tareas ordenadas por escrito, para que pueda consultarlas más adelante.

Lack of visibility on hours allocated to projects

Se beneficiará al poder preguntar: "la última vez que asignamos X tiempo, nos tomó X*2 (o X/2). ¿Estamos seguros de que esta estimación es correcta?" Entonces es el trabajo de su gerente hacer malabarismos con las tareas para que se ajusten a todos los horarios. Puede proporcionar datos del mundo real del desarrollador sobre cuánto tiempo puede tomar algo. Y también puede recordarle al jefe que le dé prioridad a los artículos.

Haciéndote la vida más fácil a largo plazo

Sería genial si mañana tu jefe viera el error de sus formas y comenzara a decirle a la gente que escriba las cosas. No va a pasar. Pero puedes repetir, probablemente hasta el punto de ser molesto, "por favor, ¿podrías escribir esto en Basecamp?".

Cuando le enseñe algo a alguien, o le enseñen, intente escribir parte de esa información de manera pública. Personalmente, me gusta crear hilos de "CÓMO: hacer X" en Basecamp. Incluso las notas pequeñas te ayudarán a recordar cosas.

Sí, HAY personas que odian el cambio. Solo aceptarán el cambio si un jefe los obliga a hacerlo y algunos ni siquiera pueden hacer eso. Sin embargo, hay otros que tienen diferentes niveles de tolerancia que van desde "lo intentaré si hay una ventaja" hasta personas que hacen que los pilotos de prueba parezcan mariquitas. La mayoría de la gente está en el campo de "qué hay para mí". (ver difusión de la teoría de la innovación: en.wikipedia.org/wiki/Diffusion_of_innovations ).
Gracias por toda la información sobre estos puntos. Es mucho para ir. Estoy tratando de hacer lo que ya sugirió al crear un bolsillo de excelencia. Intentaré hablar más sobre eso y ver si eso ayuda a que se entienda. ¡Parece que es hora de desempolvar Basecamp/JIRA e intentar que la pelota vuelva a rodar!
@Longisland, creo que vale la pena recordar que los gerentes no tienen que estar en Basecamp, solo en el grupo de desarrolladores. Y puede hacer que su trabajo sea más eficiente haciendo preguntas a la gerencia ("¿qué es lo más importante?"), en lugar de simplemente proporcionarles respuestas ("esto es lo que pidió, jefe"). ese cambio me ayudo

Me resulta útil con cosas como esta salir de mi mentalidad de desarrollador y, en cambio, centrarme en el problema en términos comerciales.

Por ejemplo, una de sus preocupaciones es el control de versiones. Estima lo que cuesta cada vez que los cambios rompen algo. Haga un cálculo del tiempo (horas-persona) multiplicado por lo que su empleador está pagando debería dar una estimación aproximada. 12 horas x $45/hora = $540 cada vez que esto sucede. Si 3 veces al mes, entonces es un poco menos de $ 20k por un año. Números como este deberían llamar la atención de alguien.

Haga lo mismo para actualizar las herramientas de desarrollo. Si se trata de mejorar las comunicaciones y el flujo de trabajo, calcule lo que esto le ahorrará a su empresa: en mayor productividad y/o menores costos.

Ese es un enfoque interesante. De hecho, acaba de surgir una instancia de esto, así que intentaré documentar cada vez que esto suceda durante un período de X semanas/meses y calcularé los números.
¿Cómo inducir un cambio de procedimiento cuando es tu jefe el que se resiste?
RespuestasAquíPolítica de privacidad1y, 0v