Una de las principales tareas en mi plato es comunicarme con el cliente. Una cosa que encuentro particularmente difícil es tratar con los plazos porque son obligatorios por el cliente y con frecuencia no se me consulta.
Si se supone que usted es responsable de comunicarse con el cliente, ¿por qué no se le consulta sobre la programación (y el presupuesto) para que pueda comunicar esta información entre las personas responsables de ellos dentro de su organización y sus contrapartes del lado del cliente? Creo que solucionar este problema será un gran beneficio para usted, su equipo y su proyecto.
Al cliente se le ocurre una característica que desea agregar, característica X. La característica X se vería bien en el lanzamiento de la aplicación de la próxima semana que está a unos 6 días hábiles. En este punto, la solicitud de función debe pasar por la aprobación y, con frecuencia, hay otras dependencias que deben tratarse. Finalmente, N días después, la solicitud de función llega a mi equipo. Incluso si la fecha límite original (que fue establecida por un administrador que no es desarrollador) era factible, ya no lo es.
Este sistema de programación parece extraño, por decir lo menos.
En mis experiencias, el cliente se registra para un lanzamiento en particular. Pueden enviar una lista de características y cambios que quieran y cuando quieran, y luego negociar con el equipo que construye el software. O pueden dar una lista de características priorizadas al equipo de desarrollo, y el equipo de desarrollo proporciona estimaciones sobre cuándo pueden enviar varios conjuntos de características. También hay otras variantes.
Pero una cosa que nunca he visto permitida es que un cliente pueda cambiar el lanzamiento tan tarde en el juego, especialmente a una semana de un lanzamiento. Eso no parece correcto poner a los diseñadores, desarrolladores y evaluadores bajo ese tipo de presión. Si está haciendo un desarrollo iterativo, si es una característica de alta prioridad, solo asegúrese de agregarla a la forma de trabajo atrasado y tómela lo antes posible. Si no es una función de alta prioridad, definitivamente no la necesitan durante esta versión y pueden esperar hasta la próxima.
Recomendaría establecer algunas reglas básicas que se adapten a sus equipos de diseño, desarrollo, prueba y entrega, así como a su cliente, para incluir congelaciones, congelaciones de código y entregas. Póngalos por escrito, obtenga el compromiso de todos y cúmplalo. Si cede una vez, se espera que se doble más y perderá el control del proceso.
Desafortunadamente, no hay mucho que pueda hacer porque no estoy en una posición de poder aquí.
Puede que no estés solo. Pero parece que sus diseñadores y / o desarrolladores y / o evaluadores están bajo mucha presión para cumplir con los horarios. Debes sentarte con tus superiores como equipo y explicar la situación. Primero, haga que su organización se comprometa a mejorar en el proceso, luego trabaje con el cliente para obtener su aceptación de cómo van a funcionar las cosas.
Sin embargo, esto se parece mucho a que estoy poniendo excusas.
Cuando comienzas a poner excusas, puede ser el momento de tener una conversación difícil o una conversación crucial . Yo recomendaría uno de esos dos libros. Leerlos me ha ayudado a mejorar mis habilidades de comunicación, especialmente cuando necesitas enfrentar una situación difícil donde las tensiones son altas en todos los lados.
Para abordar algunas de las otras respuestas.
Lamentablemente, el poder lo tomas principalmente tú mismo en lugar de que te lo otorguen otros.
No sé a dónde va Andrea con esto. Sí, debe corregir el flujo de información. Pero debe trabajar con los PM y el cliente para asegurarse de que todos sepan qué se acordó (de todos modos, supongo) al comienzo del proyecto. Si el acuerdo, por algún motivo, no funciona, vuelva a visitarlo y redistribuya el trabajo y los roles a las personas que mejor se adapten a ellos.
No tomas el poder ni luchas contra el poder, pero trabajas con él, tratando de domarlo y hacerlo funcionar para todos.
El problema es que el cliente conoce principalmente el valor comercial de la función, pero no se da cuenta de su complejidad. Solo discuta y aclare. Siempre.
Esta cita de loki2302 es bastante acertada . Uno de sus trabajos como ingeniero de software es asegurarse de que las personas adecuadas sepan cosas como cuán difícil es una tarea, cuánto tiempo llevará y qué tipo de opciones y riesgos existen al hacer algo. Como comunicador principal para su equipo, transmitir esta información de su organización a su cliente es, en teoría, su trabajo.