Cómo vender desarrollo ágil a clientes (cascada)

A nuestra tienda de desarrollo realmente le gustaría hacer proyectos más ágiles, pero tenemos un problema para conseguir clientes a bordo. Muchos clientes quieren un presupuesto y una fecha límite. Es difícil vender a un cliente en un proyecto ágil cuando nuestros competidores tienen plazos fijos basados ​​en cascada y precios fijos. Sabemos que sus números fijos son malos, pero el cliente no lo sabe. Entonces, terminamos viéndonos mal para el cliente porque no podemos fijar el precio o una fecha límite, pero nuestros competidores sí.

Entonces, ¿cómo puede lograr que su fuerza de ventas venda con éxito un proyecto que utiliza métodos de desarrollo ágiles, o un producto que se desarrolla utilizando dichos métodos? Toda la información que encontré parece centrarse en la gestión de proyectos y desarrolladores.

La clave para hacerlo bien es mediante el uso de un contrato de soporte.

Básicamente, cuando vende al cliente por primera vez, lo vende en función de su experiencia y lo hace en cascada. Eso significa un contrato que establece el alcance y una fecha límite firme. Esto es lo que el cliente quiere. El cliente más o menos conoce el alcance. Waterfall funciona muy bien, en un entorno de alcance fijo y definido, diría que funciona mejor que ágil en dichos entornos. Y en este caso le da al cliente un nivel de comodidad cuando la tendencia es estar nervioso porque nunca ha trabajado con usted antes. Está bien, Agile no siempre es mejor que la cascada.

Entonces tiene un contrato de precio fijo para X scope. Luego le dice al cliente " Mire, va a querer hacer cambios, y va a necesitar que lo apoyemos después de la producción, dejemos de lado el 20% de su presupuesto para que estas cosas sean utilizadas según sea necesario por medios de un contrato de soporte ".

Si se produce un cambio durante el proyecto, simplemente aplazarlo para que se maneje bajo el contacto de soporte. (Asumiendo que este cambio causaría una seria interrupción al proyecto)

Los términos del contacto de soporte son los siguientes: "El trabajo a realizar por hora, según lo solicitado por el cliente, puede utilizarse para solicitudes de cambio o soporte y mantenimiento general del sistema ". ¡ BAM! Estás en Agile

Luego puede continuar extendiendo el contacto de soporte y simplemente usar el contacto de soporte como el medio para ejecutar nuevos proyectos. Además, si estas horas se compran y pagan por adelantado , generalmente le damos al cliente un descuento del 15%. Es ganar-ganar.

Ágil no excluye plazos y presupuestos. Si era cliente y fui a un desarrollador y me dijeron que no podían darme una fecha límite o un costo estimado, cuestionaría su cordura. Y decirles que simplemente no entienden no va a funcionar: necesitan poder presupuestar y planificar.

No necesitan conocer su proceso de desarrollo. Necesitan saber cuánto tiempo llevará desarrollar funciones y cuánto costará. Dales un número basado en la suposición (espuria) de que sus requisitos son 100% precisos, y cuando sus requisitos cambien, entonces cambia tus estimaciones.

Esto les da las partidas presupuestarias y las fechas de implementación que desean, y cuando las cosas cambian, su proceso le permite verse flexible y complaciente.

Parece que sus vendedores están creando una capa de falta de comunicación entre sus equipos de desarrollo y sus clientes. Si no han estado vendiendo en el mercado de TI durante mucho tiempo, pueden ver su papel como "mover el producto", lo que significa obtener una firma en un contrato "lo que sea necesario". En resumen, están motivados para cerrar, independientemente de lo que prometan. En tales circunstancias, van a seguir el idioma del cliente lo más de cerca posible.

Tengo un récord roto citando esto, pero aquí va: usted está en la mesa de operaciones y, cuando va por debajo del cirujano, dice "lo sacaremos de aquí a tiempo y dentro del presupuesto". Excelente. ¿Estaré vivo?

Si está trabajando en los órganos internos de una empresa, ¿se detiene en algún punto arbitrario? Por lo general, una aplicación se ve afectada por fuerzas que ni usted ni su cliente controlan: regulaciones, clima comercial, comportamiento de la competencia, la aparición de algún nuevo paradigma, etc. Si simplemente dice 'haremos' cosa x 'por' precio y ', entonces el cliente volverá tres meses después y dirá: "bueno ...". En general, significa que saben algo que no sabían cuando accediste a un proyecto en cascada.

Lo que podría funcionar en tal situación es demostrarle a su propio personal de ventas cómo es conducir un cañón. A cada paso hay sorpresas. No es posible ver más de tres meses, por lo que si un cliente solicita un proyecto de 18 meses, será irreconocible para cuando esté a punto de completarse. Por lo tanto, su representante de ventas debe comenzar por encontrar la recompensa financiera del proyecto. ¿Esto aumentará las ventas en $ 10 millones? Si es así, ¿vale la pena invertir $ 2,000,000 para hacer esos $ 10 millones adicionales? Si el cliente y el representante de ventas están convergiendo en un compromiso de $ 500,000, entonces algo podría estar mal y nadie puede decir qué es, simplemente no se siente bien. Lo que 'no se siente bien' es un compromiso de hacer algo que corre el riesgo de ser inútil.

Los dos últimos modelos de aviones jet han tenido una historia de problemas. Healthcare.gov ni siquiera necesita discusión. Si puede encontrar libros o intercambiar historias de prensa en los aviones, puede mencionar cómo se hicieron ciertas suposiciones que demostraron ser optimistas, y que los proyectos incumplieron sus plazos repetidamente. A menudo esto se debió a subestimar la complejidad. Si realmente no puede entender qué tan complejo es hasta que comience a codificarlo, necesitará una 'ronda inicial' para tener una mejor idea de los problemas reales. El límite del presupuesto debe ser una fracción de las ganancias adicionales totales (o ingresos en algunos casos), y ese número tiene que ser más de lo que cualquiera cree que costará el proyecto actual. Si puede mostrar cómo se puede pasar el último hito sin exceder el 'límite de pago',

El obstáculo principal para lograr los beneficios del desarrollo de software externo Agile-Scrum es integrarlo con los mecanismos de control existentes. Estos mecanismos de control se estipulan debido a varios requisitos previos de la organización y normalmente se actualizan utilizando el enfoque y la metodología de Cascada lineal.

A continuación se muestran cuatro de estos requisitos previos organizacionales típicos:

• Grandes corporaciones globales: en estas organizaciones de matriz jerárquica, el control de cartera de arriba hacia abajo es la regla del día. El enfoque ágil de espíritu libre tiene dificultades para adaptarse a los controles rigurosos. Específicamente, los conceptos inherentes al plan ágil libre hacen que Agile-Scrum sea difícil de tragar para la organización.

• Industrias altamente reguladas: los organismos de cumplimiento y gobierno requieren que algunas industrias tengan un estricto mecanismo de control vinculante. Estos pueden ser, por ejemplo, unidades de negocios de investigación y desarrollo de productos de equipos médicos, aviones y productos farmacéuticos. Si bien los equipos individuales pueden operar Agile-Scrum, el proceso de desarrollo debe seguir un método rígido de enfoque de Cascada lineal para la trazabilidad y la gobernanza.

• Productos predefinidos complejos: algunos productos integrados que incluyen hardware, software, incrustados y más se desarrollan como un contrato con un cliente final bajo un conjunto predefinido de requisitos. En estos casos, el grado de flexibilidad de los requisitos es pequeño, aunque mayor de lo previsto inicialmente. El concepto de una cartera de pedidos totalmente flexible de Agile-Scrum sufre considerablemente en estos casos.

• Departamentos de TI genéricos: gran parte de las actividades diarias y semanales en los departamentos de TI orientados al mantenimiento son ad hoc. Los cambios en los horarios diarios son numerosos e inmediatos. Las interferencias constantes en el trabajo en equipo son la norma. El concepto de time boxing y sin interferencia es difícil de mantener en estas situaciones.

Naturalmente, muchas veces las cuatro categorías discretas detalladas anteriormente, en realidad se mezclan; Por lo tanto, es común encontrar un producto complejo en una gran empresa global que debe cumplir con la regulación de la empresa.

Basado en la experiencia práctica, el método recomendado para abordar estos escenarios y otros es capacitar a Agile PMO para que actúe como un facilitador, conductor y traductor entre los equipos emergentes de Agile-Scrum y los elementos Linear Waterfall.

Consulte la tabla a continuación para obtener pautas específicas

Fuente - Interfaz entre cascada lineal y enfoques ágiles por Michael Nir

Establecimos 2 o 3 sesiones de estimación con el cliente potencial y nuestros desarrolladores donde discutimos el trabajo en cuestión y establecemos los criterios de aceptación. Los desarrolladores estiman el trabajo en puntos de la historia durante la reunión.

Luego vendemos al cliente una serie de puntos de historia. Esto es posible porque tiene una buena idea del valor de los puntos de la historia. Le decimos que tiene la posibilidad de ajustar su cartera / alcance durante el proyecto y que será fácil debido al uso de los puntos de la historia. También le decimos que habrá una entrega frecuente de software de trabajo para que pueda monitorear el progreso y obtener nuevos conocimientos.

Al acordar una cantidad de puntos de historia, se garantiza que el cliente obtendrá valor por su dinero. Si no cambia su cartera de pedidos, tiene su proyecto de precio fijo / alcance fijo, pero mi experiencia es que hará cambios. Al hacer las estimaciones en presencia del cliente potencial, intentamos construir una relación basada en la apertura y la confianza.

Logramos convencer a los clientes como usted describe, que "quieren un presupuesto y una fecha límite", y estaban contentos de que realmente quisiéramos entender lo que necesitaban, en lugar de trabajar desde un documento. Mostramos que queríamos invertir en estos proyectos.

Durante las sesiones de estimación, estimamos toda su cartera de pedidos. Esto dio x puntos de historia. Sugerimos agregar un 25% para aquellas características que aún no estaban claras o conocidas en ese momento. Con la cartera de pedidos estimada adjunta al contrato, se les aseguró que obtendrían todo por el presupuesto fijo.

Originalmente, la oferta era tiempo y material. Como querían tener una oferta de precio fijo, sugerimos trabajar por el precio que les dimos y usar los puntos de historia adicionales del 25% para contingencias. Si las cosas salieron bien, la parte del 25% que no se utilizó para cubrir los retrasos que encontramos se utilizaría para brindar más funcionalidad al cliente.

Esto los estimuló de varias maneras: primero, hicieron todo lo posible para permitir que nuestros desarrolladores trabajaran lo más rápido posible, ya que esto era claramente en su propio interés. Nunca tuvimos que esperar respuestas a las preguntas. En segundo lugar, realmente entendieron el concepto de los puntos de la historia. Antes de que comenzara el proyecto, ya habían eliminado algunas de las historias y nos pidieron que estimáramos otras historias. No se necesitaban negociaciones contractuales complicadas para esto.

Los mantuvimos informados del progreso y mantuvimos una comunicación muy abierta. Recibían un informe de progreso cada 2 semanas: x% de los puntos de la historia realizados en y% del tiempo estimado deja z% de los puntos de historia adicionales disponibles. Tuvimos un comienzo un poco difícil, pero logramos alcanzar las estimaciones al final del proyecto, lo que dejó el 100% de los puntos de historia adicionales disponibles para un desarrollo adicional. El cliente estaba contento porque obtuvo todo lo que realmente necesitaba (y eso fue un poco diferente de sus funciones solicitadas inicialmente, eliminó algunas y agregó otras).

El cliente también estaba contento porque todo se entregó en el plazo previsto (donde también hizo todo lo posible para ayudarnos a perseguir tickets, responder preguntas de inmediato, involucrar a los usuarios en reuniones de análisis semanales y también involucrarlos en pruebas funcionales).

Mi empresa estaba contenta porque entregamos a tiempo y dentro del presupuesto. Mi empresa también estaba feliz porque el éxito de este proyecto abrió la puerta a más proyectos. Incluso nos mencionaron en la revista mensual del cliente que se envió a personas de todo el mundo.

Hacer buenas estimaciones fue la parte más difícil del proyecto, pero tener las sesiones de estimación por adelantado nos ayudó a comprender la dificultad y los riesgos. Nos permitió dar una estimación basada en hechos y eliminó muchas incógnitas.

Intentar utilizar métodos ágiles en un entorno de consultoría / licitación es muy difícil cuando el cliente no está a bordo.

Si están acostumbrados al estilo Cascada "aquí están nuestros requisitos, ¿cuánto y cuánto tiempo llevará?" tipo de proyectos, y lo están poniendo a licitación no hay realmente ningún momento para convencerlos de que Agile o cualquier otra forma es mejor.

Agile tiene su ventaja (y desventajas, por supuesto), pero, francamente, el cliente a menudo no conoce ni se preocupa por los detalles detrás de escena.

Quieren 2 cosas: costo y escala de tiempo. Y una vez que les dices eso, lo quieren más barato y antes. Y sabes qué, lo queremos todo. Todos los requisitos Nadie puede esperar ni ser picado.

Y por mucho que me disgusten los vendedores en la mayoría de los ámbitos de la vida, no seas demasiado duro con los vendedores. Ese es un trabajo duro.

No construyen software, en su mayoría no tienen idea de cómo funciona todo más allá de las palabras de moda.

Sin embargo, tienen que proponer escalas de tiempo y costos basados ​​en algunos requisitos imprecisos. Tal vez tienen algunos de los técnicos con ellos para reinar, pero necesitan hacer una venta para mantener las cosas en marcha.

Entonces, ¿cómo puede lograr que su fuerza de ventas venda con éxito un proyecto que utiliza métodos de desarrollo ágiles, o un producto que se desarrolla utilizando dichos métodos?

Al hacer que su fuerza de ventas traiga al cliente a la oficina. El objetivo de ágil es obtener comentarios inmediatos del cliente para que pueda producir lo que quiere (y no más). Tráelos y pregúntales qué quieren. Dos semanas después, tráigalos y muéstrales una demostración / prototipo. Véndelos en esa interacción. Muéstreles el progreso y explique que este tipo de iteración es lo que le gustaría hacer para que obtengan exactamente lo que quieren.

Proporcione estimaciones sobre la cantidad de trabajo necesario (después de todo, eso es un presupuesto), pero permítales tener el poder (léase: responsabilidad) de incluir lo que quieren incluir en su presupuesto.

Creo que la respuesta es que, en la mayoría de los casos, probablemente no. Intentaría ver esto inicialmente como una pequeña parte de su negocio, quizás el 20%, con el resto bajo un modelo tradicional. Con el tiempo, trataría de centrarme más en los productos y clientes de Agile e intentar hacer que esa parte crezca más.

Otra parte de abordar esto es quizás intentar usar ambos enfoques. Utilice el enfoque en cascada con la gerencia superior y la gente de negociación de contratos. Por ejemplo, 'un sistema para permitir a los clientes mantener carteras y tomar decisiones de inversión utilizando dispositivos basados ​​en navegador y teléfonos móviles (Apple y Android)'. o algo así. Luego use Agile para el desarrollo del equipo de desarrollo en las características más detalladas, por ejemplo, Crear página de inicio, Crear página de inicio de sesión, Crear historial de administración de Portolio, Crear inicio de sesión móvil, etc.

Otra idea es hacer de Agile tu diferenciador. Sé que muchas organizaciones, si no la mayoría, no están haciendo Agile. Sin embargo, la mayoría (la gran mayoría en mi experiencia) de pequeñas empresas lo son. Creo que Agile está creciendo rápidamente y esto continuará. La ventaja de esta ruta es que estás lanzando lo que más quieres hacer a los clientes que ya lo reconocen. Este enfoque requerirá algo de trabajo a lo largo del tiempo sin garantía de éxito.

También puede encontrar algo de tracción si a sus clientes les gusta la prueba. Tener productos bien probados puede ser una venta más fácil para algunos clientes. Un libro que encuentro útil en esta área es 'Agile Testing' de Adison Wesley Press.

También puede usar eventos actuales para respaldar su caso. Por ejemplo, el sitio de atención médica actual (que escribió esto en octubre de 2012) es un gran argumento sobre cómo NO manejar los cambios que se necesitaban 2 semanas antes de la puesta en marcha. Además, la aparente sobre ingeniería probablemente habría sido abordada mejor con métodos más ágiles.

Póngase en contacto con clientes anteriores que estén contentos con su trabajo. Especialmente si son conversos de Waterfall to Agile. Por lo menos, conversos que no eran sus clientes.

Sus testimonios (como cliente) superarán cualquier cosa y todo lo que puedas decir. Pueden abordar las preocupaciones y los temores de su nuevo cliente más de lo que usted podría hacerlo.

Desde una perspectiva de gestión, un presupuesto y una fecha límite es una necesidad comercial para el proyecto. Debe asegurarse de satisfacer esas necesidades, y si mira los testimonios de una empresa sobre el cambio, notará que surge directamente. Si observa los testimonios de los desarrolladores sobre el cambio, notará que muchas veces no es así.