Trabajo como gerente de proyectos para Live Typing. El año pasado, escribimos en nuestro blog corporativo que si la fecha límite se rompe, lo principal es no sorprender y advertir al cliente. Pero cuanto más trabajamos, más nos damos cuenta de que peores que los plazos no cumplidos solo pueden ser complejos, los clientes emocionales y los equipos se agotan bajo su presión.
Las empresas que han adquirido un par de clientes habituales durante el trabajo, saben cómo filtrar clientes potenciales sospechosos incluso en la etapa de la primera llamada y pueden permitírselo. Por desgracia, los estudios jóvenes en busca de experiencia y ganancias, por desgracia, no pueden prescindir de tales clientes.
Antes de entrar en el top ten de varias clasificaciones de la industria,
Live Typing trabajó con un cliente que desmotivó tanto al equipo que la gente comenzó a abandonar la empresa. Por las razones que analizaré a continuación, acordamos nuevamente con el cliente. Temiendo una nueva crisis en las relaciones, desarrollé una táctica de gestión especial para mantener al equipo sano y salvo. Después de todo, encontrar un desarrollador genial es difícil, y capacitar y adaptar un nuevo empleado es más costoso que mantener uno antiguo. Además, los detalles de la subcontratación es tal que después de este proyecto, los desarrolladores tomarán el siguiente, y es importante que lo hagan con cerebros que no se han eliminado por completo.
Sobre cómo lo hice, lea el artículo.
Por razones obvias, llamaré al cliente simplemente "cliente". Incluso en el proyecto, con una cooperación reiterada, dentro del equipo no lo llamamos de otra manera. Por qué Sobre esto a continuación.
Antecedentes
Hace dos años, nos llegó un proyecto. Antes de llegar a nosotros, unos cinco equipos trabajaron en él y acumuló un código heredado decente.
Las relaciones del cliente con los equipos anteriores estaban lejos de las de los socios, por lo que con él decidió tomar automáticamente una posición ofensiva y cerrarse con un muro de desconfianza.
Para acelerar la comunicación y el desarrollo, el primer gerente de proyecto hizo que el chat en Slack fuera común para el cliente y el equipo: la aplicación no fue desarrollada por nosotros y planteó muchas preguntas que tuvieron que ser respondidas rápidamente al cliente. En la mayoría de los casos, esta metodología acelera la transferencia de información entre los miembros del equipo, pero nuestro cliente no se negó la oportunidad de hacer comentarios groseros ni en el chat ni en forma personal a una persona específica.
El cliente recurrió a personalidades, lo que resultó en conflictos abiertos, y su nombre se escuchó incluso de aquellos que no estaban involucrados. Como resultado, la compañía perdió al menos un empleado que no pudo soportar esta actitud, y varios más se fueron después de un par de meses. Las razones formales para irse parecían ser diferentes, pero sabemos algo.
Cuando el cliente se quedó sin dinero, nos separamos. Vale la pena señalar que el dinero se fue, incluido el soporte para código heredado y el desarrollo de funcionalidad por el bien de la funcionalidad.
El cliente luego regresó. Nos convenció de que quería desarrollar la aplicación desde cero, abandonando el código obsoleto, reduciendo la funcionalidad y comunicándose en un estilo diferente. Lo aceptamos, pero después de un tiempo la historia comenzó a repetirse.
El cliente no confiaba en nuestras calificaciones y ofertas. Tenía su propia idea de cómo debería funcionar el producto. También entendimos cómo hacerlo, pero el cliente no percibió los argumentos y, en lugar de un socio con experiencia en el desarrollo de aplicaciones, vio en nosotros solo las manos que hacen realidad su lista de deseos. No sabemos las razones por las cuales el cliente se puso en esa posición y no va a especular.
La situación se estaba calentando. Recordando cómo se desarrollaron los eventos en el pasado, priorizamos en un orden inusual para nosotros: en primer lugar, debe salvar al equipo y solo luego cerrar con éxito el proyecto y, si es posible, mantener la lealtad del cliente.
Tácticas de protección para clientes complejos.
Ahora echemos un vistazo a las técnicas que nos ayudaron a lograr nuestro objetivo, los errores que no debe repetir y las conclusiones que puede utilizar en su trabajo.
Explicar el valor del diseño.
Entonces, el proyecto comenzó desde cero. En el contexto de esta decisión, surgió una propuesta para hacer MVP y pagar nuestro trabajo de acuerdo con el modelo de precio fijo. Esto parecía lógico, porque si no hay un código de otra persona, entonces no hay riesgos con él.
La desventaja del precio fijo como modelo de pago es que priva al proyecto de flexibilidad: mientras se implementa la funcionalidad, que las partes acordaron en la tarea técnica, el mercado puede cambiar y el resultado del trabajo ya no resolverá los problemas reales del usuario. Es posible desarrollar MVP a un precio fijo solo si ha probado exhaustivamente todas las hipótesis, diseñado las especificaciones técnicas y escrito la documentación detallada. Nuestro cliente simplemente descuidó el diseño, o más bien, lo asumió.
La historia con la elección de un servicio para chats es indicativa. El cliente investigó las posibles soluciones técnicas por sí mismo y nos dio la opción de varios servicios: "¿Cuál es mejor?" Elegimos el servicio A porque se adaptaba al proyecto en un conjunto de métodos API y, desde el punto de vista del desarrollo y la integración, era mejor que el servicio B. No diseñamos el servicio para que funcione con nuestra infraestructura y no verificamos nada más que estos criterios formales: ni estabilidad , sin velocidad de respuesta, nada, no había presupuesto. Chat terminó respondiendo más lentamente de lo que podría si hubiera tiempo para verificar.
No caigas en las manipulaciones en el espíritu de "Si lo necesitas para completar una tarea, ¡hazlo gratis! ¡Tiene que hacerlo bien! ”Si existen tales: la esencia del desarrollo de la subcontratación es resolver los problemas del cliente por dinero del cliente.
El analista debe diseñar. Tiene el conocimiento que le permite comprender y articular claramente lo que el cliente necesita exactamente en la final, y construir una arquitectura de sistema común: qué servicios estarán en el producto, si hay integración con sistemas de terceros, cómo van las solicitudes entre servicios, dónde se almacena la información, cómo se entrega, etc. Esto es necesario, en primer lugar, para que el producto del cliente funcione de manera rápida y confiable, y en segundo lugar, para asesorar sobre lo que puede ahorrar y qué es exactamente lo que no vale la pena.
Hacer que el significado de MVP sea el mismo para todos
Lo que MVP significó para nosotros:
- acordamos la funcionalidad básica de la aplicación y pulimos al ideal solo aquellas características que se relacionan con ella. Otras funciones deberían funcionar para que no haya deseo de cerrar la aplicación;
- hacemos un mínimo de funcionalidad necesaria para resolver un problema comercial, y no tenemos un área de administración diseñada;
- posponemos la personalización hasta más tarde, es decir, usamos componentes en el diseño que pueden reutilizarse en múltiples pantallas, rechazamos elementos de diseño complejos y simplificamos el diseño si es necesario.
Pero los clientes MVP tienen diferentes interpretaciones. ¿Qué significó esto para los nuestros?
- funcionalidad mínima por dinero mínimo.
En el futuro, de alguna manera sucedió que se mantuvo el "dinero mínimo" y se agregó la posición "sabemos cómo hacerlo, así que hagamos lo que decimos".
Tal posición amenaza una sociedad normal. La amenaza solo se puede eliminar mediante el diseño y una tarea funcional, que detalla todo lo que la aplicación debería poder hacer. ¿Hay nuevos requisitos y sugerencias no comprometidos? Consulte la Ley Federal y ofrezca comprar tiempo. Tal vez esto sea formalismo y no se centre en el cliente, pero es justo en relación con su empresa.
Una vez más: MVP se combina con la corrección cuando hay diseño. No lo teníamos, pero deberías tenerlo.
Deja que los desarrolladores discutan contigo
Y nunca trabaje con un diseño no comprometido del cliente, cómo trabajamos.
Los desarrolladores suelen estar vinculados: tan pronto como se establezca la tarea, lo harán. Pero en proyectos con un presupuesto limitado, la implementación de cada tarea potencialmente compleja debe ser cuestionada para flexibilizarla y cumplir con la fecha límite.
La fuente de tales tareas fue inesperadamente el diseño que trató el diseñador del lado del cliente. A nuestros desarrolladores se les dijo que si solicitan algunas correcciones, se enviarán de inmediato, por lo que comenzamos a trabajar no con la versión estática del diseño, sino en el editor de Figma, donde se creó este diseño. Los desarrolladores hicieron una evaluación y se pusieron a trabajar.
Y luego, uno por uno en el diseño, comenzaron a aparecer elementos que no eran originalmente, esto se podía ver desde la copia de seguridad, que hice por si acaso. Pero antes de comenzar el desarrollo es imposible verificar si una pieza de diseño en particular ha cambiado, al menos porque el desarrollador toma las tareas en un orden conveniente para sí mismo.
Identificar inconsistencias ayudó a esa misma libertad de expresión. El desarrollador podría acercarse a mí y atraer no solo los elementos que no se pueden inventar rápidamente, sino también los elementos que están en el diseño del cliente, esto es comprensible, porque el diseñador mismo los introdujo en secreto allí, pero no en nuestra copia. Estos elementos no se incluyeron en la evaluación, lo que significa que no debemos tratarlos por nuestra cuenta.
En el mundo del desarrollo saludable, el precio fijo no permite aumentar la cantidad de trabajo y cambiar las condiciones sobre la marcha.
Mantenga al cliente alejado del equipo.
La última vez que conectamos a los desarrolladores y al cliente directamente, hay equipos en los que se cree que el gerente debe primero monitorear los términos y el presupuesto, y no servir como transmisor de los requisitos del cliente.
Esta es una gran metodología con sus ventajas: la reacción de cada lado es más rápida, el equipo comprende mejor la tarea comercial, su autoridad crece y el gerente no muere como transmisor. Pero sabiendo que el cliente puede volverse personal, lo aislé del equipo. Solo el cliente, el gerente de cuenta y el gerente de proyecto, es decir, yo, permanecimos en el chat.
¿Qué nos dio? Moderé la comunicación y no permití que las relaciones personales envenenaran la rutina laboral. En momentos en que el cliente criticaba al equipo en su forma, respondí que tomaríamos medidas y castigaríamos al empleado. Las observaciones muestran que para tranquilizar a algunos clientes, es suficiente sacrificar a alguien del equipo incluso por diversión, por lo que el empleado continuó trabajando con calma y ni siquiera sabía que había sido castigado.
Si sospecha que el cliente está inquieto, no traiga al equipo con él al menos por un tiempo, hasta que esté convencido de lo contrario.
Reformular los comentarios del cliente al equipo
En una atmósfera de constante desconfianza y crítica, el equipo ya no logra procesar la retroalimentación en la forma en que llega, y el cliente comienza a pensar que el equipo llega a trabajar solo con malas intenciones, y las encarna.
¿Qué hacer con este gerente? La edición cosmética no perjudicaría: eliminé la evaluación de la personalidad de los comentarios, dejando solo la redacción del error sin pérdida de significado. Y como no recibe ningún elogio del cliente, no olvidé darle al equipo mis propios comentarios, para aquellas tareas que no plantearon preguntas, lo que significa que se realizaron bien desde el punto de vista del cliente.
Fue:
"La aplicación no funciona de pago. ¿Qué manos hiciste?Se convirtió en:
"Chicos, la aplicación tiene algo que pagar, el cliente pide averiguarlo, aquí están las capturas de pantalla. Y con las animaciones que se retrasaron hace una semana, todo estuvo bien ”.No te apresures a conseguir errores
Introducir errores en el administrador de tareas tan pronto como se recibieron del cliente es por falta de experiencia. Armado con un ojo crítico, el gerente ayudará a ahorrar horas de desarrolladores y un probador. Simplemente hablando con el cliente o pidiendo reproducir las acciones que condujeron al error y grabar el video, puede comprender que el error no es una prioridad o apareció porque el cliente estaba haciendo algo mal, y ahora, ya no necesita editarlo. Así que eliminé una cuarta parte de los errores entrantes, y otra parte estaba relacionada con el servicio de soporte de servicio integrado: había suficientes SDK de terceros en el proyecto.
No mencione el nombre del cliente.
Quizás la idea más importante. Según el antiguo recuerdo de una parte del equipo, expresar el nombre de un cliente provocó una actitud parcial hacia cualquier comentario de su parte, sin importar cuán adecuado fuera. Y se me ocurrió llamar al cliente solo al cliente, lo que redujo lo negativo. Parece que todos entienden de quién están hablando, pero créanme: este matiz ha mejorado la ecología del proyecto.
Conclusión
Para mayor claridad, decidí reducir todo lo anterior a una tabla sobre el principio de "Cómo no hacerlo y cómo hacerlo".
Pero nuestro consejo será útil para usted al mínimo si la persona responsable de trabajar con los clientes entrantes en su empresa, o el gerente de cuenta revela fallas de los clientes en la etapa de negociación.
Aquí hay algunos puntos importantes a los que ahora estamos prestando atención:
- Lo que dice el cliente sobre el contratista anterior, si lo fue. Si habla negativamente de él, existe la posibilidad de que no perciba ninguna opinión que no sea la suya e impondrá sus decisiones.
- ¿El cliente tiene experiencia en TI? Para un cliente con experiencia, el proceso de desarrollo plantea menos preguntas.
- Si él negocia por cada centavo o no. Cuanto más alto sea el deseo del cliente de pagar menos, más dispuesto y tercamente argumenta.
Espero que este artículo sea útil para alguien. Y si ya estaba en mi lugar, díganos cómo resolvió clientes tan difíciles.