¿Cómo puedo lograr que mis compañeros de trabajo acepten algunas de mis ideas? [duplicar]

Soy muy nuevo en mi lugar de trabajo y me gustaría mencionar algunos cambios. La mayoría de estos cambios llevarían el entorno a los estándares de la industria para este campo, el desarrollo de software.

¿Cómo puedo sugerir estos cambios y obtener la aprobación/acuerdo de mis compañeros sin alienarme tan pronto en nuestra relación de trabajo al parecer que estoy tratando de tomar el control?

Puede encontrar esta respuesta útil en el lugar de trabajo.stackexchange.com/questions/9703/…
@gnat similar pero no duplicado, esto cubre un alcance mucho más amplio de cómo en lugar de solo debería . Las respuestas a esto pueden tener un alcance mayor que solo para los 'recién llegados', creo.
Tenga mucho cuidado de no terminar insultando a sus compañeros de trabajo. Considera que puede haber muy buenas razones para que las cosas sean como son. Apréndalos y luego considere qué fruta al alcance de la mano podría realmente ayudar a sus compañeros de trabajo. Esas cosas probablemente serán muy bienvenidas.
@SpikyBlue según mi lectura, las respuestas en el engaño sugerido se centran en cómo en lugar de debería (y esto me parece correcto)
si quieres que otras personas compren tu idea, debes venderla (juego de palabras intencionado)

Respuestas (4)

Hay algunos métodos a tener en cuenta al proponer cambios en cualquier empresa. Independientemente de su puesto en la empresa.

1. No juegues al juego de la culpa

Nunca juegues el juego de la culpa. Incluso si puedes ver que todos los problemas provienen de una sola persona. Jugar al juego de la culpa provocará todo un lío de política en el entorno de trabajo sin el cual estarás mucho mejor.

En su lugar, sugiera todas sus mejoras de manera objetiva, como objetivos de todo el equipo.

2. La confianza es clave

Antes de siquiera pensar en sugerir estos cambios, hágalo usted mismo, escriba sus ideas y luego revíselas una y otra vez. No se concentre solo en qué cambios hacer, sino también en cómo va a sugerir estos cambios.

Los cambios deben parecer simples y fáciles. Si le toma 20 minutos y 3 páginas detallar un solo cambio, probablemente sea demasiado largo y complicado con demasiados puntos de falla potenciales para que la gente quiera aceptarlo.

Preste atención a los puntos débiles de sus propios argumentos, asegúrese de tener respuestas y asegúrese de que sean buenas respuestas. "No sé" puede ser un asesino cuando intenta que la gente acepte sus cambios.

La confianza es clave, debe parecer que sabe lo que está haciendo y debe parecer que sabe cómo hacerlo. Si no confía en sus cambios, la gente no confiará en usted.

3. Enfoque de abajo hacia arriba

Antes de sugerirle sus ideas al CEO, debe verificar que el resto de la empresa esté de acuerdo con usted.

Comience con las personas que lo rodean, las personas con las que trabaja a diario, hábleles sobre sus ideas y vea lo que piensan. Vea lo que les gusta y lo que no les gusta, y vea si están de acuerdo en que sus cambios serían para mejor.

Luego pase a su gerente, muéstrele sus cambios, muéstrele que tiene el apoyo del resto del equipo. Muéstrele que lo mejor para él o ella es realizar estos cambios y tendrá su apoyo.

4. Siga el protocolo adecuado

No intente apresurarse, sugerir sus cambios en la parte superior de la cadena puede parecer una buena idea, pero si no ha pasado por los procesos internos adecuados, entonces está en desventaja.

Estos procesos internos aseguran que todos los que necesitan verlo y aceptarlo tengan la oportunidad de dar su opinión, abordar sus inquietudes y sugerir mejoras.

Obtener la aceptación de su equipo es un juego difícil de jugar, implica asegurarse de que se sientan incluidos y que sientan que se escucha su voz, implica seguir el procedimiento adecuado para que el cambio sea a prueba de balas cuando llegue a las personas. quien puede hacer algo al respecto.

Sea un experto en la materia

Pero lo más importante de todo es que necesitará saber mucho al respecto, si sugiere el cambio, es probable que usted sea la persona que necesite responder a todas las preguntas e inquietudes sobre el cambio. Si no puede responder a las preguntas o mitigar las preocupaciones, perderá respaldo.

Elegir entre bottom up o top down dependería de la localidad geográfica, así como de la cultura de la empresa. Por ejemplo, he oído que en Asia, casi siempre se debe hacer de abajo hacia arriba, pero en EE. UU. hay que tener en cuenta varios factores, por lo que no hay una guía clara.

Es muy importante evitar ser un sabelotodo. Cuando te encuentres con un sentimiento de superioridad, nadie se sentirá inclinado a escucharte. Jugar al juego de la culpa a menudo tampoco es realmente constructivo. Creo que primero necesitas construir una buena relación con tus compañeros de trabajo. Después de eso, intente encontrar momentos en los que pueda discutir este tipo de fallas de codificación. Demostrar objetivamente por qué algunas cosas son malas, usar argumentos objetivos es realmente clave aquí para mantener la discusión alejada de 'pero así es como te gusta hacer las cosas, continuaré como lo hice'. Algunas cosas, como los estándares de codificación, pueden ser un buen tema para una reunión de personal.

Prepárate para ser paciente. El cambio lleva mucho tiempo. Y siempre ten en cuenta que podrías estar equivocado :).

Sin profundizar demasiado en las teorías del cambio de comportamiento u otras ciencias sociales, tuve una experiencia similar en una empresa de software. Había estado allí por menos de un año y me encontré con responsabilidades de aseguramiento de la calidad del proceso. A veces, era incómodo tratar de integrar nuevos hábitos de trabajo en procesos a menudo indefinidos, y también podía ser muy desalentador ver que mis sugerencias minuciosamente investigadas caían en desgracia.

Aquí hay algunos consejos que recogí:

Valor de negocio

No hay necesidad de cambiar si no proporciona un beneficio observable a la organización. Esté preparado para proporcionar investigaciones empíricas o informes sobre las áreas de proceso que desea actualizar y, si es posible, prepare un plan de recopilación y análisis de métricas. Por ejemplo, tal vez su empresa ya realiza un seguimiento de cuánto tiempo lleva corregir los errores. Si los errores a, b y c tardaron x cantidad de tiempo en promedio antes de sus métodos, tal vez pueda probar que los errores d, e y f tardaron menos tiempo en corregirse. Hay muchas cosas relacionadas con el análisis de métricas en la ingeniería de software, y si está interesado en obtener más información, le recomendaría que consulte Goal, Question, Metric (GQM) .

Hable con sus compañeros

Sugerir nuevas formas de hacer las cosas puede alejar a sus compañeros de trabajo y, como señala Paul Hiemstra, puede darle la reputación de ser un sabelotodo (a nadie le gusta un sabelotodo). Tómese un tiempo para hablar con sus compañeros de trabajo y pregúnteles por qué hacen las cosas de la manera en que lo hacen. Puede ser que tengan muy buenas razones, pero también es muy probable que sepan que las cosas podrían mejorar. Trate de hacer que los procesos de cambio sean un esfuerzo de equipo proveniente de dentro de la organización y no como cambios impuestos desde el exterior. Para leer más, consulte cultura organizacional y asimilación cultural .

Momento y lugar adecuados

Demasiado cambio demasiado rápido causará resistencia. En nuestra pequeña empresa, teníamos reuniones retrospectivas todos los meses después de entregar nuestras actualizaciones a nuestro cliente. Este fue el momento perfecto para decir "Me di cuenta de que teníamos algunos problemas con x este mes. Lo estuve investigando y leí sobre muchas personas en una situación similar que tuvieron éxito con y. ¿Alguien está interesado en probarlo?" La implementación de cambios uno a la vez puede brindar a todos la oportunidad de practicar el nuevo proceso y sentirse cómodos con él antes de probar algo nuevo. Además, puede ayudar implementar un cambio cuando hay un poco de espacio para respirar y no en medio de un sprint.

Proporcionar opciones

Esto viene de hablar con tus compañeros, y es bastante básico. Digamos, si su empresa no proporciona control de versiones, no diga simplemente "OK, así es como se instala git..." Cuando se trata de actualizar procesos, es bueno proporcionar opciones. Nuevamente con el ejemplo de git, presente a la organización los conceptos de control de versiones: qué es y qué beneficios tiene. Luego hable sobre las diferentes opciones y cómo se comparan entre sí. No salte con su herramienta favorita simplemente porque es con lo que se siente más cómodo; se trata de darle a la organización la libertad de experimentar y jugar con diferentes opciones. Diablos, he tenido muchas conversaciones con compañeros de trabajo sobre nuevas herramientas que comenzaron con "¡Oye, mira este nuevo juguete que tengo!"

TL;RD

Hable con sus compañeros de trabajo antes de intentar cambiar la forma en que hacen las cosas y esté preparado para demostrar por qué vale la pena cambiar algo.

Además de lo dicho por Paul Hiemstra:

Xaisoft, en cada nivel de antigüedad/jerarquía hay un límite de cosas que puedes cambiar. Un desarrollador/ingeniero junior puede sugerir cambios en las rutinas, pero casi todas las partes interesadas deben percibirlo como una persona muy brillante para que el cambio tenga éxito. A medida que crece su experiencia, se amplía el alcance de los cambios factibles. Pero el mayor potencial para fomentar cambios proviene de los puestos gerenciales de nivel medio.

Eso sí, hay que preguntarse:

  • ¿Vale la pena el cambio que propongo?

  • ¿Cuáles serán los efectos negativos del cambio?

Debo decir que me disgusta profundamente el cambio por cambiar, odio las modas de gestión y las palabras de moda. Cualquier cosa que altere la rutina establecida y los procedimientos operativos estándar en el lugar de trabajo reduce la productividad y es inmediatamente perjudicial para el resultado final, mientras que los efectos positivos (si los hay) se retrasan . Piénsalo.

EDITAR: Como de costumbre, los cambios son un arma de doble filo. Si se queda significativamente rezagado con respecto a la tecnología de vanguardia, muy a menudo pierde. Si realiza cambios continuos en la forma en que funciona su organización, las personas que lo rodean se estresarán y posiblemente perderán la confianza. La mejor solución a la parte tecnológica del problema es cuando los empleados están acostumbrados a mantenerse al día. Desafortunadamente, no funciona para la estructura y los procedimientos internos: aquí, para ser productivo, es necesario cierto grado de estabilidad y libertad de las "reorganizaciones" superficiales inspiradas en la gestión.


Aquí están las conclusiones:

  • Por favor, inicia los cambios contigo mismo.

  • Gane algo de respeto de sus colegas; no intentes imponer revoluciones a otros a menos que estés razonablemente seguro de su éxito.

  • Considere siempre múltiples vías de mejora y realice un análisis de costo-beneficio antes de llegar a una reunión con propuestas a medias.

Es por eso que dije "Hay más..." en mi publicación. Solo he visto el código durante 2 días y las cosas que mencioné fueron solo cosas simples. No se trata tanto de esas cosas en particular, sino de cómo convencer a otros objetivamente sobre formas alternativas. Simplemente estaba dando algunos ejemplos. Solo mencioné los estándares de codificación una vez, pero no diría que ninguna de las cosas es superficial. Todo afecta a todo.
Debo decir que no estoy de acuerdo con que cualquier cosa que altere la rutina establecida disminuya la productividad. Por ejemplo, la introducción del control de versiones tiene un impacto negativo de bajo a moderado en la productividad en el front-end, con un rendimiento mucho mayor a relativamente corto plazo.
@AmyBlankenship: considere el tiempo dedicado a instalar VCS e inculcar la nueva rutina. Hay un pico negativo transitorio; a veces es una perturbación puramente psicológica. ¿Se ve abrumado por una mejora genuina algún tiempo después? Depende... El otro problema aquí es el número de interrupciones por unidad de tiempo. La interrupción continua genera estrés e incertidumbre.
Hm, en la situación que tenía en mente (mi propia experiencia) ya estaba instalado, pero nadie lo estaba usando. La otra cara de la moneda es que negarse a realizar cambios (o hacerlo con demasiada lentitud) significa que no tiene suficiente ancho de banda para seguir realizando los cambios incrementales que necesita. Así es como la gente todavía está en ASP clásico escribiendo HTML que estaba desactualizado en 2007, por ejemplo.
@AmyBlankenship: está bien, diferentes suposiciones sobre VCS. No existe un estándar sobre cuán grandes deben ser los cuantos de cambio porque las industrias, las organizaciones y los conjuntos de habilidades difieren. Si los empleados están acostumbrados a mantenerse al día, la parte tecnológica del problema está resuelta; no así para los cambios organizacionales (imagine que su título, descripción del trabajo y supervisor directo se cambian 6 veces al año).
El OP no está hablando de cambios organizacionales (o, supongo, compañeros de trabajo que están acostumbrados o interesados ​​​​en mantenerse al día).