Soy un líder tecnológico para un equipo pequeño. 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.
Por lo general, la interacción sigue el siguiente patrón. 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. Se culpa a mi equipo, se siente desanimado y hay una atmósfera general de derrota , me siento desanimado y derrotado.
Claramente, el proceso general está roto. Desafortunadamente, no hay mucho que pueda hacer porque no estoy en una posición de poder aquí. Mi enfoque actual es recordarle gentilmente al cliente acerca de nuestra fecha de inicio versus la fecha límite, el alcance de la Función, etc. Sin embargo, parece que estoy poniendo excusas.
¿Han estado en situaciones similares? ¿Qué ha funcionado / no ha funcionado para usted?
fuente
Respuestas:
Realmente necesitas hablar con tu jefe sobre esto y establecer algunas reglas básicas:
El codificador limpio de Robert Martin tiene un muy buen capítulo sobre cómo comunicar estas cosas a su jefe. No es tu culpa si el equipo de ventas está haciendo compromisos imposibles.
Cuando obtiene una nueva función, USTED la estima y usa PERT para tener una distribución de probabilidad. "Debería hacerlo en 4 días, pero puede tomar hasta 8". Defender su posición. NUNCA negocies un presupuesto con un vendedor, terminarás comprometiéndote con lo imposible.
Después de algunas iteraciones de esto, es de esperar que el vendedor se harta de que parezca un tonto y que ajuste el comportamiento a "Consultaré con el equipo de desarrollo y veré cuándo podemos hacerlo" en lugar de una promesa de que termines rotura.
fuente
Principalmente lo que funciona es decir la verdad al poder.
Reúne los hechos. Presente los hechos. Deje que el cliente aprenda (o no aprenda) a su propio ritmo.
¿Por qué su equipo es consciente de la culpa? Si el cliente lo está pasando por alto y está hablando directamente con el equipo, se está volviendo ineficaz y necesita descubrir por qué.
Su equipo debe ignorar la "culpa" o la falta de culpa. Simplemente deben crear software, y usted simplemente debe comunicarle al cliente lo que está haciendo y cuándo lo está haciendo.
El cliente debería --- eventualmente --- crecer para comprender el proceso. Se necesita una gran cantidad de repeticiones para romper los malos hábitos. Mucho.
fuente
He estado en esta situación exacta y no fue agradable. Sin embargo, un enfoque que hice fue mantener meticulosamente un registro del trabajo que se encuentra actualmente en desarrollo. Cuando surgen tareas, le recuerda al cliente, a la gerencia o al gerente de proyecto que otro trabajo va a fallar, ya que ahora esto se ha convertido en su prioridad (a veces eso puede hacer que adivine y luego sigue presionando para que se alargue el plazo).
De lo contrario, supongo que debe intentar martillar ese cincel en el muro de piedra que es el gerente del proyecto / enlace con el cliente / gerencia / vendedor que está tratando con el cliente y está de acuerdo con estos plazos. A menudo critiqué el hecho de que si están de acuerdo en que algo llevará 5 días, obviamente están hablando de 5 días de desarrollo, lo que significa que lleva 5 días desde que lo recibes (no cuando cuelgan el teléfono juntos y luego pasan los próximos dos días redactando una palabra elegante doc).
Sin embargo, dado que usted es el líder del desarrollo, cualquier decisión como esta es irrelevante si no se le consulta en primer lugar.
También debe intentar proteger a su equipo de esto tanto como pueda. Aunque es difícil, deben mantenerse fuera de la política de gestión / cliente tanto como puedan. Si este no es el caso, se requiere más martilleo.
Básicamente, no lo disfruté y no importa cuán duro sea el proceso, no fue perfecto. Sin embargo, logré mejorar un poco las cosas.
fuente
Lo único que probablemente puede hacer es hablar con el cliente. Simplemente describa lo que sucede tal como lo ve, describa todos los riesgos, etc. Tuve una situación similar y estaba realmente enojado. Incluso ahora, cuando soy responsable de todas las estimaciones técnicas, a menudo escucho: queremos que se haga el lunes. Solo digo: no lo entenderá, discutamos qué es exactamente lo que le gustaría tener para el lunes, y luego a menudo parece que todas las características críticas son bastante fáciles de implementar y el lunes está absolutamente bien. Todas las demás funciones se programan para versiones posteriores.
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.
fuente
Es un buen comienzo recordarle al cliente que su fecha de inicio es posterior a la fecha en que solicitan la función. También debe hablar con quienquiera que hable por primera vez con el cliente para obtener detalles sobre la función para que puedan decirle al cliente en ese momento cuál sería un mejor plazo. Como ya está en comunicación con el cliente, puede decir "¿quién fue en el Departamento Y que estuvo de acuerdo con este plazo?"
Si no lo dejan entrar en las conversaciones o le dicen que se calle y cumpla con los plazos que acuerdan, puede recordarles que se vería mejor para toda la empresa si su equipo llegara a tiempo y de la manera para lograr eso es obtener su opinión sobre los plazos.
fuente
Arregle el flujo de información.
Lamentablemente, el poder lo tomas principalmente tú mismo en lugar de que te lo otorguen otros.
fuente
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.
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.
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.
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.
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.
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.
fuente
Encuentre un foro para acercarse a quien establece estos plazos. Hágales saber que pueden consultarlo y presentarle algo más realista. Las alternativas son: puede decirle al cliente que no va a suceder o ellos pueden decirle al cliente.
Puede presentarlo como lo puede hacer en X número de días una vez que su equipo comience a trabajar en él. Tal vez esa fue la confusión? Es un error honesto a menos que ocurra una y otra vez. Entonces es solo negligencia.
Supongo que su equipo ha cumplido estos plazos en el pasado.
fuente
Desafortunadamente, es endémico en nuestra industria, por lo que muchas agencias digitales / de software no saben nada sobre el funcionamiento interno o los requisitos de su empresa. Muchos solo se preocupan por el efectivo rápido. Como muchos han dicho antes, si no proporciona las estimaciones o los plazos, informe a la gerencia. ¿Cómo es posible entregar un trabajo técnico por tiempo x sin una estimación de una persona técnica que conozca el cronograma del equipo de desarrollo?
Si todo lo demás falla, vete.
fuente
Déle al Gerente de Proyecto / Jefe / Cliente los estimados y horarios alcanzables, pídale que confirme su plan, o calcule en qué quiere que trabaje primero, luego retírese - no lo involucre ni lo entretenga de ninguna manera.
Si regresa con un plan de proyecto que no refleja sus estimaciones, envíelo a él con una declaración: "No negocio estimaciones". y alejarse.
Asegúrese de tener mucha documentación de CYA. Deje en claro a todos los involucrados que está guardando estos documentos. Envié por correo electrónico dichos registros a mi dirección de correo electrónico personal y envié un correo electrónico a mi jefe, lo cual fue muy exitoso.
fuente
Aquí hay un enfoque que debería parecer constructivo en lugar de señalar con el dedo. No te estoy acusando de esto, solo digo que no funciona bien tener una excusa con alguien más culpable, independientemente de la verdad de la acusación.
Después de que esto suceda, haga una autopsia para calcular cuánto tiempo tardó realmente en completar el proyecto, o lo habría hecho si lo hubiera terminado. Luego calcule cuántas horas de recursos tenía disponibles desde el momento en que tuvo suficiente información y la luz verde para trabajar en ella. Convierta estos números en cuántos programadores adicionales se necesitarían para cumplir con la fecha límite.
Ahora tenga una conversación con su jefe a lo largo de estas líneas:
fuente