He aquí la mejor pregunta de hoy de mi larga lista de correos electrónicos. Los comerciales no quieren Scrum en una empresa porque creen que no pueden comprometerse con el cliente para cerrar tratos.
"Primero tenemos que firmar el contrato. El cliente no firma el contrato si la fecha de finalización, el precio y la lista de características no figuran en él. Cuando se utiliza la cascada, el cliente tiene todo eso. Así es como funcionan las ventas. Eso es lo que les ofrecemos. Con SCRUM, ni la fecha de finalización ni la lista de características están definidas. Y el precio final tampoco está definido. Así no podemos vender nada".
Esta es mi respuesta...
Sus vendedores no tienen ni idea de Scrum. Deberían asistir al curso ScrumMaster para saber de qué están hablando. Primero podrían empezar a aplicar Scrum a su trabajo en Ventas. Entonces podrían entender lo que deberían hacer los desarrolladores.
Nuestro grupo de capital riesgo lleva a cabo adquisiciones de empresas utilizando Scrum. El más joven de nuestro equipo es el antiguo Vicepresidente Senior de Ventas Globales de Oracle. Probablemente podría dar una buena respuesta a tu equipo de ventas y quizá ayudarles a empezar a utilizar Scrum.
Básicamente, un plan de ventas exige cerrar acuerdos. Esta es la cartera de productos. Los vendedores deben conocer la velocidad de cierre. Tienen una lista de tareas que deben realizarse para cerrar el trato a medida que la oportunidad avanza por el embudo de ventas. Todo esto se puede trazar en el tablero Scrum. Deben disponer de un gráfico que muestre el cierre de la operación para un Sprint. Pueden anotar los ingresos obtenidos.
Las operaciones inmediatas están listas para cerrarse. Las más lejanas están en fase de planificación para su cierre. Las operaciones más lejanas se pronostican como si fueran funciones de software. Sabes que alcanzarás una velocidad de cierre, pero no sabes exactamente qué operaciones se cerrarán.
Así que para Scrum, ya sea para ventas o para desarrollo de software, se necesita un plan (product backlog). Hay que priorizar la cartera de productos. Los equipos individuales deben estimar la velocidad de cierre, los ingresos deben comprometerse en el plan en función de la velocidad de cierre y los proyectos deben ESTAR HECHOS (tanto si se trata de cerrar planes de ventas como de finalizar contratos de desarrollo de software). Siempre hay una hoja de ruta propiedad del propietario del producto a partir de la cual se asumen los compromisos.
Esto es exactamente lo contrario de lo que dice el comercial. Tenemos muchos equipos que dicen que están haciendo Scrum pero no tienen backlog de producto, estimaciones, velocidad y burndown. Su vendedor debe haber visto algunos de estos equipos disfuncionales y malinterpretado completamente Scrum.
Trifork, en Dinamarca, realiza sus ventas con Scrum. Todos sus vendedores son ScrumMasters. Cada vez que dejan de actualizar el tablero Scrum, empiezan a perder la pista de los acuerdos y los ingresos, y necesitan volver a centrarse en actualizar el tablero Scrum. El vicepresidente de ventas se encarga del tablero, ya que la mayoría de los empleados están de viaje todo el tiempo.
Cuando cierran un contrato de desarrollo de software, un comercial es a veces el ScrumMaster que dirige el equipo de desarrollo de software. De este modo, los vendedores ganan dinero para la empresa mientras venden, en lugar de malgastarlo en gastos y aumentar el coste de las ventas. Una vez dentro de la empresa como ScrumMaster pueden vender aún más cosas.
En cuanto al desarrollo, algunas de las principales empresas del mundo están haciendo contratos a precio fijo en Scrum. Conocen todas las características, las calculan y se comprometen a una fecha de entrega. A continuación, aplican un proceso ágil para terminar el contrato antes de tiempo y ahorrar dinero al cliente, al tiempo que aumentan sus márgenes. Puede que sus equipos Scrum se encuentren en una fase muy temprana de madurez y no sean capaces de asumir los compromisos que necesitan los comerciales. O no han formado adecuadamente a los vendedores. Esto es responsabilidad de su Jefe Product Owner. ¿Tiene uno?