¿Están los procesos de mi equipo fuera de control?

Soy un líder de equipo de desarrollo de software (recientemente tomé el control de un nuevo equipo) y, en última instancia, responsable de mantener una alta productividad, buena calidad y prioridades organizadas.

Tengo 6 desarrolladores senior en mi equipo, pero las cosas se sienten como un desastre aquí. La situación es que tengo que atender las solicitudes de JIRA de aproximadamente 10 puntos de contacto diferentes en nuestra empresa, y todos ellos representan diferentes unidades de negocios o clientes.

El problema que tengo es que mi trabajo consiste principalmente en apagar incendios todo el día y asegurarme de que se estén trabajando los problemas de todos. Desafortunadamente, la cultura en nuestra empresa ha sido la alta productividad (lanzamientos rápidos) pero la baja calidad (errores de producción), y nuestros clientes no aceptarán un retraso repentino en los resultados.

¿Cuáles son algunas buenas formas de manejar esto? Tengo toneladas de teorías, pero estoy buscando una respuesta de alguien que realmente tenga experiencia laboral en una situación como la mía.

Aquí hay una pequeña lista de cómo funcionan las cosas:

• Cada desarrollador es responsable de una aplicación y servicios específicos que interactúan con él;
• Normalmente, las versiones son probadas por el cliente en un servidor de producción simulado y luego implementadas en el servidor en vivo;
• Cada aplicación es utilizada por un promedio de 50-80 personas, con 8 aplicaciones en total.

Gracias

nuestros clientes no aceptarán un retraso repentino en los resultados

Bueno, entonces tienen que aceptar la mala calidad que están obteniendo.

Lo que tiene que hacer para cambiar esto es lograr que sus clientes acepten la realidad del desarrollo de software (¡o cualquier otra producción!): Que apresurar las cosas afecta la calidad.

Crea una lista grande de las cosas que están yendo mal, de las cosas que están rotas, las veces que han tenido motivos para quejarse. Explíqueles la razón de estos problemas y dígales qué le gustaría hacer para cambiar eso. Asegúrese de explicarles el porcentaje de tiempo que su equipo pasa apoyando y arreglando aplicaciones en vivo. Si no está recopilando los datos sobre eso, ahora es el momento de comenzar (y recopilarlos durante un mes antes de presentar la información a los clientes).

Obtenga las partes interesadas clave en una habitación y diga: "¿Desea que X sea reparado, o quiere que se entregue Y? Solo tenemos tiempo para uno de los dos". Hacer de ellos responsable de establecer las prioridades, y tener claro que tienen una capacidad limitada. Si solicitan algo nuevo, pregúnteles qué están dispuestos a sacrificar de su hoja de ruta actual para lograrlo.

Pregúntele a su equipo qué tiempo y recursos necesitan para "arreglar las cosas" (tanto en términos de corregir errores básicos como en términos de solucionar problemas más grandes en la calidad del código / arquitectura / etc.). Incluya esos elementos en la lista de cosas que sus partes interesadas deben priorizar.

Lo mejor que hice en mi trabajo actual fue reunir a los 8 principales interesados ​​en una habitación al mismo tiempo, y colocar un montón de 16 fichas que representaran las nuevas características que se habían solicitado. Me aparté de la mesa y dije: "podemos entregar uno de estos a la vez. ¿En qué orden los quieres?" Permítales debatir entre ellos sobre la prioridad comercial en lugar de que se quede atrapado en el medio.

Dejar de caer y rodar. Los incendios necesitan combustible y, a menudo, se presentan en forma de pánico. Dedique tiempo para manejarse a sí mismo y al equipo en orden. Evalúe a sus desarrolladores y vea si tiene alguno que no sea lo suficientemente hábil y / o que no trabaje lo suficiente para producir los resultados que desea. Decida quién se queda (y haga un esfuerzo para mantenerlos), quién necesita un pequeño empujón, el resto tiene que irse. Evalúe el soporte y las herramientas que obtienen sus programadores para asegurarse de que puedan hacer su trabajo. Asegúrese de seguir las pruebas de sonido, la revisión, el control de origen y la documentación. Las buenas personas con buenas herramientas deben ser responsables de hacer un buen trabajo.

Tiene que haber un sistema para saber qué necesita hacer su equipo, en qué está trabajando actualmente y cuándo esperan que se complete. Muchas metodologías, teorías, software, pizarras de borrado en seco y notas adhesivas, documentos y correos electrónicos para hacerlo. Haga que algo funcione haciendo que todos se adhieran a él. Si todos tienen algún aporte al sistema, hay más incentivos para seguirlo.

Obtenga una mejor comprensión de lo que esperan los clientes. Esto puede no ser parte de su trabajo. Puede haber otras personas que fingen que su cabello está en llamas, sus clientes están descontentos y el cielo se está cayendo. Es lo que hacen y algunos son realmente buenos en eso. Si todo es una emergencia, entonces nada es una emergencia porque no todo se hará. Ofrezca participar en discusiones con clientes ocasionalmente. Encontrarás que muchos 'buenos para tener' se convierten en 'rompidores de trato' cuando llegan al equipo de desarrollo. Sea el enlace técnico o alguna otra excusa para ayudar. Hacer promesas que no puedes cumplir es peor que decirles lo que no quieren escuchar en primer lugar. Queremos hacer un buen trabajo, por lo que necesitamos 8 semanas y no 5. Serán más felices a la larga.

En última instancia, debe educar a sus clientes sobre el desarrollo de software e involucrarlos en el proceso tanto como sea posible. Lo que están viendo ahora es la entrega rápida de nuevas funciones, pero también errores en el software. Si bien estarán contentos con el primero, no estarán (o no deberían estar) con el segundo.

Debe explicarles que con mejores procesos, mientras que la entrega del nuevo software se retrasará por una pequeña cantidad, habrá menos errores (nunca habrá cero). Si puede llegar a un acuerdo de que este es el camino a seguir, podrá comenzar a introducir los procesos que necesita para recuperar el control sobre su desarrollo.

El uso del proceso ágil podría ayudar aquí, ya que sugieren (y en algunos mandatos de implementación) que el cliente está incluido como parte del equipo. Si involucra a los clientes muy de cerca, verán qué está funcionando y qué puede producir de primera mano.

Mi opinión (experiencia limitada): creo que hay dos problemas que resolver. Primero, el proceso de calidad. ¿Usas scrum / cascada / algo intermedio? En scrum, puede agregar tareas adicionales para cada historia: 1 para elaborar un guión / plan de prueba, otro para ejecutarlo, otro para una revisión de código, etc. En cascada, ¿puede simplemente agregar estos pasos?

El otro problema es el problema principal masivo que existe en todas partes en el software. Gestión de expectativas. Es decir, aumentar el tiempo de alguien que grita que necesita un botón para hacer X para que se entregue.

Si puede agregar pasos adicionales al proceso y hacer un gran anuncio al respecto [ahora estamos implementando este proceso de calidad: ¡lo que significará menos tiempo para corregir errores! y mejores resultados de calidad! correo electrónico / reuniones grandes, etc. para informarles], y entregar resultados con regularidad (ala scrum), la idea es que aquellos a quienes entregue aprenderán y verán el valor en los pasos adicionales del proceso, y lo comprarán. Menos tiempo arreglando errores = más tiempo implementando y probando características.

¿Los clientes no aceptarán un retraso repentino en los resultados? Más o menos tienen que hacerlo. Está claro que no puede continuar como está. ¿Quizás pueda agregar los pasos de control de calidad adicionales y luego, si es necesario, agregar más miembros del equipo? Pero los pasos de calidad son absolutamente necesarios.

Nuevamente, si usa scrum o similar, puede apuntar a un sprint de una semana para que haya entregas regulares de resultados. Eso complacerá a las personas tanto como un cambio rápido.

Espero que ayude hasta cierto punto ... espero que no me haya perdido el punto.

Lo que ha descrito suena muy normal y no es realmente alarmante.

• Los clientes generalmente tienen una mentalidad diferente sobre lo que es importante que los ingenieros. Nos gusta que las cosas estén bien, pero los clientes se enfrentan a una realidad que premia la puntualidad sobre la pureza. Necesitan resolver sus problemas rápidamente para ser competitivos, y eso es exactamente lo que le están pagando.
• Establecer prioridades es demasiado grande y difícil de manejar para una sola persona, ya que tiene una acumulación de problemas importantes (por lo que está utilizando JIRA), y los tenientes que administran cada área de interés es la mejor opción que tenemos para mantener el trabajo impotente al frente el horario.

No hay nada de que preocuparse. Dicho esto, puede ahorrarse mucho dolor transfiriendo la mayor parte de las tareas de administración al cliente que paga, involucrándolos en el proceso de desarrollo de establecimiento de prioridades y hasta la tecnología, automatizando la mayor parte de la rutina. posible.