¿Cómo sugerir mejoras del proyecto en un entorno rígido / de mente estrecha?

Definitivamente se encuentra en una posición difícil, y lo aplaudo por tratar de mejorar las cosas para su grupo. Una cosa que te sugiero es que no trates de abordar todo a la vez. Mire los problemas específicos que enfrenta, decida cuáles abordar primero (tal vez en función de lo fácil que es convencer al resto del equipo, tal vez en función de cuáles puede obtener estadísticas). Una vez que tenga algunos éxitos, le ayudará a presentar su caso para cambios futuros.

No menciona si su equipo está en una sola ubicación o distribuido. La mayoría de mis sugerencias a continuación están dirigidas a grupos ubicados en el mismo lugar, pero puede adaptar muchas de ellas para equipos distribuidos.

Aquí hay algunas sugerencias (sin ningún orden en particular):

• Asegúrate de hablar con el resto del equipo en situaciones individuales. Quizás otras personas estén viendo los mismos problemas o tengan el mismo dolor. Trate de obtener una imagen más grande de todo.

• No tenga miedo de mejorar sus propias prácticas, incluso si el equipo no va a seguir una de sus sugerencias. Considere implementarlo para su propia parte del trabajo, a menos que se le indique que no lo haga. Sin embargo, definitivamente hable de eso con el PM (no lo haga a escondidas). Parece que ya está haciendo esto con el control de fuente, pero no tenga miedo de implementar otras cosas también.

• Hablando de otras herramientas/prácticas a considerar:

  • revisiones de diseño (incluso las revisiones informales por encima del hombro son mejores que nada)
  • revisiones de código
  • pruebas unitarias automatizadas
  • servidor de compilación automatizado

• Adapte la práctica de desarrollar pequeñas unidades de funcionalidad a la vez. Asegúrese de que puede verificar el código de trabajo diariamente (más o menos). Asegúrate de estar siempre avanzando, incluso si es solo un pequeño paso. Hable con el PM sobre la aplicación de esto también en todo el equipo.

• Una vez que haya llegado al punto en el que el código está "siempre" en un estado de funcionamiento, sugiera a su PM que su equipo adapte un horario regular para reunirse con el cliente para mostrar el progreso.

  • Estas revisiones pueden ayudar a garantizar que su equipo esté creando la solución adecuada. Es mucho mejor descubrir que una semana o dos han ido por el camino equivocado, que descubrir que 6 meses han ido en la dirección equivocada.
  • Es probable que el cliente se sienta más cómodo con su estado, ya que habrá visto visualmente dónde se encuentra.
  • Estas reuniones pueden ser un buen momento para discutir prioridades (qué abordar a continuación), así como cualquier problema que haya surgido o riesgos que puedan materializarse en el futuro.

• Recordatorios visuales y controles de proceso.

  • ¿Todos en el equipo saben cuáles son los objetivos principales del proyecto? No me refiero a "terminar este producto para la fecha X", sino más bien a "asegúrate de que los usuarios califiquen nuestro producto con 4 estrellas o más". Asegúrese de que el equipo comprenda estos objetivos y colóquelos en el área del proyecto. O simplemente en la pared de su cubo/oficina si no hay un área de equipo.
  • ¿Todos en el equipo tienen la misma visión del proceso de desarrollo? Considere implementar un tablero de seguimiento de elementos de trabajo que muestre el proceso de desarrollo de su equipo. Si bien probablemente sugeriría un tablero kanban (y el proceso que ayuda a impulsar), esto podría ser simplemente un reflejo de dónde están las cosas actualmente y qué cosas están por venir. Si bien una versión electrónica de esto es mejor que nada, tenerlo visible para todo el equipo en una pizarra grande parece tener más impacto en mi experiencia.
    • Una vez que tenga esto en su lugar, comience a tener reuniones diarias cortas (15 minutos o menos) con otros miembros del equipo frente a la pizarra. Concentre la conversación en las áreas en las que las personas necesitan ayuda o en los problemas que ven surgir.
    • si el equipo no está preparado para eso o si no hay un área para una versión de equipo de esto, al menos considere poner uno para las cosas que se le han asignado, y dedique unos minutos cada día a revisarlo

• métodos adicionales de comunicación del equipo: algunos de estos tienen propósitos superpuestos, puede mezclar y combinar para adaptarse a su equipo

  • wiki
    • tienes esto
    • asegúrese de animar a otros a agregarle
    • si recibe información que es útil para el equipo (piense en el tráfico de correo electrónico que dice cómo hacer algo), comience a copiarlo en la wiki
  • lista de distribución de correo electrónico
    • bueno para enviar información que todo el equipo necesita
    • necesita a alguien responsable de agregar nuevos miembros al equipo de manera oportuna
    • si es importante guardar la información para más tarde, alguien debe ingresarla en el wiki
  • servidor de chat interno
    • excelente manera de lanzar preguntas rápidas sin preocuparse de que la información confidencial salga de la empresa
    • como arriba, alguien puede necesitar copiar la información a la wiki
  • servidor de preguntas y respuestas
    • básicamente, una versión interna de Stack Exchange
    • las respuestas podrían terminar haciendo referencia a la wiki
    • Es posible que las respuestas deban copiarse en wiki.

• Inicie un club de lectura: concéntrese en libros que se apliquen a los problemas que su equipo realmente ve. Con suerte, las personas que han estado en su empresa por más tiempo terminarán hablando sobre cómo pueden ver que el libro se aplica a lo que han experimentado en el pasado, lo que los hace pensar más en ello y le brinda más información sobre la situación. . En mi mente, algunas sugerencias para temas de libros incluirían:

  • implementar el cambio dentro de las empresas (Fearless Change)
  • Metodologías ágiles y lean (demasiadas para nombrarlas)
  • prácticas de desarrollo (Programador Pragmático, Código Completo, El Código del Desarrollador).

Todas estas son excelentes ideas. Lo que debe tener cuidado es cómo los presenta. No, por ejemplo,

¡No puedo creer que los IDIOTAS no estén controlando la fuente!

(Estoy exagerando para el efecto aquí)

sino más bien:

He leído acerca de algunas organizaciones que han implementado el control de código fuente y realmente han podido ahorrar tiempo y dinero...

(Hablar de tiempo y dinero hará que los oídos de tu jefe se animen).

¡Buena suerte!

Necesitas métricas por encima de cualquier otra cosa para esta cruzada, y debes elegir tus batallas sabiamente. No hay ningún método o herramienta que pueda resistir el uso indebido, por lo que las mejoras sugeridas son fáciles de "demostrar que están equivocadas" por parte de las personas involucradas, pero no al 100% a bordo. Así que busque algunas victorias fáciles para ganarse la confianza de la gerencia y, lo que es más importante, de los miembros del equipo.

Comience con algo pequeño, en lo que sea fácil realizar mediciones fiables antes/después. Haga un plan para mejorar esta área y manténgase firme; no acepte una versión de su plan que diga "lo haría". Al mantener su primera mejora pequeña y barata, esto debería ser más fácil de digerir para todos.

Si tiene éxito en hacer una mejora medible, creará una oportunidad para que todos los demás crean que el cambio es posible y verá sugerencias que llegan de todos los rincones. No es el único en la empresa que sabe que las cosas podrían mejorar, pero probablemente sea el único que cree que es posible. Este es el cambio más importante que tu actitud proactiva puede provocar :)

Eres ambicioso, eso es bueno, yo soy así. Trabajé en una casa de software de nueva creación, luego seguí moviéndome a través de organizaciones más grandes durante el período de tiempo.

Cada vez que quería hacer un cambio mediante la automatización de un proceso. Finalmente, me di cuenta de que la mayoría de las pequeñas empresas que no están trabajando en soluciones empresariales se preocuparán principalmente por el tiempo de comercialización (ganar dinero). Es posible que no existan en el próximo año o seis meses, por lo que generalmente piensan que una mejor calidad y automatización es un lujo que desean, pero que no pueden pagar.

Deberá justificar el gasto a su gerencia, y descubrí que no es fácil de hacer. Por lo general, estarán de acuerdo contigo y dirán que es bueno, pero puede esperar hasta que sea realmente necesario.

Ahora estoy trabajando para una casa de software exitosa (todavía una empresa relativamente pequeña) donde todo está impulsado por la automatización de procesos (Integración Continua). Ahora es parte de nuestra cultura, pero nos tomó un tiempo llegar aquí.

Ahora, con respecto a las herramientas que ha mencionado, sí, creo que son buenas y, en general, puede ponerlas en funcionamiento en unos pocos días. Pero esto es solo la punta de un iceberg, ¿tal vez tiene sentido encontrar un entorno de trabajo con una cultura diferente?

Editar:

Mi respuesta se basa en lo que he experimentado anteriormente. Sugerí cambiar un entorno de trabajo porque anteriormente había intentado automatizar procesos en empresas más pequeñas, pero fracasé porque lo único que les preocupaba era el tiempo de comercialización. Todo lo que querían hacer era sacar el sistema por la puerta y no preocuparse por lo que podría pasar en los siguientes seis meses.

Con respecto a la empresa actual para la que trabajo, un director técnico sabe cómo se supone que debe funcionar la empresa de ingeniería de software. Contrató a las personas adecuadas, nos dividió en departamentos (front-end, back-end, db, lado del servidor, evaluadores, "madurez del proceso", líderes de control de calidad, etc.). Nuestros procesos están impulsados ​​por la integración continua y puedo entrar en detalles de lo que hemos logrado o no hemos logrado. Somos bastante buenos, pero nuestro modelo de madurez de capacidad (http://en.wikipedia.org/wiki/Capability_Maturity_Model) todavía está entre dos y tres, es bueno, pero queda un largo camino por recorrer. En su organización, parece que requerirá un gran esfuerzo pasar del nivel uno al nivel dos. Por eso te he preguntado si te has planteado cambiar de entorno laboral.

Lo crea o no, la mayoría de las organizaciones, ya sea que se trate de capacidades de PM u otras capacidades comerciales, están bajas en la escala de madurez. Gartner estima que entre el 70% y el 80% de las organizaciones se encuentran en el nivel 1 o 2 de una escala de 5 puntos para BPM. Antes de implementar cualquier cambio, o incluso antes de proponer un cambio, forme un órgano rector/de competencia, un grupo de recursos con ideas afines que incluirá a aquellos con rango, para comenzar la identificación de problemas, la identificación de oportunidades, la investigación, la capacitación, la construcción de un caso para cambio, etc. Este grupo puede convertirse en una organización similar a una PMO o puede disolverse en el futuro, pero es casi esencial para poner las cosas en marcha. Hemos comprobado en nuestra consultoría BPM que esto es casi ley.

Entonces, a pesar de sus ideas, dé un paso atrás y analice la idea de este grupo de competencias de PM.

Puede ser contraproducente entrar en esto con la perspectiva de que la organización que está tratando de cambiar es "rígida" o "de mente estrecha". Esos términos tienen connotaciones negativas que pueden socavar cualquier cambio positivo que esté tratando de hacer.

Recomendaría dar un paso atrás y observar todas las cosas que la empresa hace bien. Por ejemplo, parecen estar haciendo felices a suficientes clientes que pueden crecer, contratar gente y pagar sus salarios (sin mencionar el alquiler y otros gastos).

Comprender lo que hacen bien ayudará a mejorar la entrega de estos cambios y proporcionará una comprensión más profunda de cómo realizar los cambios y qué cambios tendrán más posibilidades de éxito. También lo ayudará a aumentar la cantidad de personas interesadas en hacer cambios, ya que es probable que haya muchas más personas que quieran ayudar a la empresa que personas que quieran "rebelarse".

No quiero sonar demasiado zen al respecto, pero no hay un conjunto de recomendaciones único para todos. El tipo de mejoras que busca realizar provienen de relaciones de confianza y una comprensión respetuosa de la empresa actual.

Estoy impresionado por su deseo de hacer todo lo posible para ayudar a su empresa. Tengo algunas ideas sobre cómo puedes empezar de a poco, para no ser insistente. Creo que el mayor problema radica en la falta de un proceso comercial utilizado en su empresa. Sugiero centrarse en esto antes de buscar mejorar los problemas en la programación, porque está rodeado de expertos en programación que son capaces de realizar estos cambios por sí mismos. En cambio, la implementación de procesos estandarizados mantendrá al equipo organizado y enfocado. Aquí hay algunas formas en que puede comenzar a construir estos procesos sin ser sincero al respecto:

• Aproveche esas herramientas de PM . Basecamp es ideal para tareas pendientes. Si está buscando una mejor comunicación, considere aplicaciones como Slack para enviar mensajes. Si desea automatizar sus flujos de trabajo para mejorar la gestión de procesos, considere Tallyfy. Invite a sus compañeros de trabajo a estas aplicaciones, no tardarán más de unos minutos en darse cuenta de lo que se están perdiendo.
• No hay necesidad de sermonear a sus compañeros de trabajo. Intente acercarse al gerente y mostrarle cuán eficiente se ha vuelto al usar estas aplicaciones o esbozar el proceso comercial. Con suerte, él o ella apreciarán su pasión por el crecimiento del negocio. Sin embargo, si eso no funciona, continúe usando estas herramientas con sus compañeros de trabajo, sin intentar venderles nada descaradamente.

Incluso si solo unas pocas personas siguen tus pasos, en un equipo de solo 20 puedes tener un impacto. Con suerte, a partir de ahí, sus herramientas de gestión de procesos comerciales se extenderán por toda la empresa una vez que los de mente estrecha comiencen a ver resultados.