Cómo vender el desarrollo Agile a clientes (en cascada)

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

Básicamente, cuando usted vende al cliente por primera vez, lo hace en base a 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 quiere el cliente. El cliente más o menos conoce el alcance. La cascada funciona muy bien, en un fijo y amp; entorno de alcance definido, yo diría que funciona mejor que ágil en tales entornos. Y en este caso, le brinda al cliente un nivel de comodidad cuando la tendencia es estar nervioso porque nunca ha trabajado con usted antes. Eso está bien, Agile no siempre es mejor que la cascada.

Así que tienes un contrato de precio fijo para el alcance de X. Luego le dice al cliente “ Mire, va a querer hacer cambios, y va a necesitar que lo apoyemos en la producción posterior, separemos el 20% de su presupuesto para estas cosas que se utilizarán en forma conjunta. base de necesidad por medio de un contrato de soporte . "

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

Los términos del contacto de soporte son los siguientes " El trabajo a realizar por hora, según lo solicite el cliente, se puede utilizar 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 se pagan por adelantado , generalmente le damos al cliente un descuento del 15%. Es ganar-ganar.

Agile no excluye plazos y presupuestos. Si yo fuera cliente y fuera a un desarrollador y me dijeran 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 saber su proceso de desarrollo. Necesitan saber cuánto tiempo llevará desarrollar funciones y cuánto costará. Déles un número basado en la suposición (falsa) de que sus requisitos son 100% exactos, y cuando cambien sus requisitos, cambie sus 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 su personal de ventas está 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 función 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 prometen. En tales circunstancias, van a seguir el lenguaje del cliente lo más cerca posible.

Soy un récord roto que cita esto, pero aquí va: usted está en la mesa de operaciones y mientras va bajo el control del cirujano dice 'lo tendremos fuera de aquí a tiempo y dentro del presupuesto'. Genial. ¿Estaré vivo?

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

Lo que podría funcionar en tal situación es demostrarle a su propio personal de ventas cómo es una unidad a través de un cañón. A cada paso hay sorpresas. No es posible que salgan más de unos tres meses, por lo que si un cliente solicita un proyecto de 18 meses, ya no estará reconocido cuando esté casi terminado. Por lo tanto, su representante de ventas debe comenzar por encontrar la recompensa financiera del proyecto. ¿Aumentará esto 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 el compromiso de hacer algo que corre el riesgo de ser inútil.

Los dos últimos modelos de aviones de reacción tienen un historial de errores. Healthcare.gov ni siquiera necesita discusión. Si puede encontrar libros o historias de la prensa comercial en los aviones, puede mencionar cómo se hicieron ciertas suposiciones que resultaron ser optimistas, y que los proyectos no cumplieron con sus plazos repetidamente. Muchas veces esto se debió a subestimar la complejidad. Si realmente no puede descubrir qué tan complejo es hasta que comience a codificarlo, necesitará una "ronda inicial" para tener una mejor idea de los problemas reales. El recorte presupuestario debe ser una fracción del total de las ganancias adicionales (o ingresos en algunos casos), y ese número tiene que ser más de lo que nadie cree que costará el proyecto actual. Si puede mostrar cómo se puede pasar el último hito sin exceder el "límite de pago", debería ser posible vender el proyecto como un esfuerzo ágil.

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

A continuación se describen cuatro de estos requisitos previos de organización 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 sin plan Agile, 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 desarrollo de productos y de investigación de equipos médicos, aeronaves y productos farmacéuticos. Si bien los equipos individuales pueden operar Agile-Scrum, el proceso de desarrollo debe seguir un método de enfoque de cascada lineal rígido para la trazabilidad y la gobernabilidad.

• Productos complejos predefinidos: algunos productos integrados que incluyen hardware, software integrado 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 que el previsto inicialmente. El concepto de un backlog 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 impulsados por el mantenimiento es ad hoc. Los cambios en los horarios diarios son numerosos e inmediatos. Interferencias constantes en el trabajo de los equipos son la norma. El concepto de boxeo en el tiempo y ninguna 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 la PMO Agile para que actúe como habilitador, conductor y traductor entre los equipos emergentes de Agile-Scrum y los elementos de la cascada lineal.

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

Fuente- Interfaz entre la cascada lineal y los 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 los puntos de la historia durante la reunión.

Luego le vendemos al cliente una cantidad 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 afinar su acumulación / 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 en funcionamiento para que pueda supervisar el progreso y obtener nuevos conocimientos.

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

Nos las arreglamos para convencer a los clientes como usted describe, que "quieren un presupuesto y una fecha límite", y estaban felices de que quisiéramos entender realmente lo que necesitaban, en lugar de trabajar en un documento. Demostramos que queríamos invertir en estos proyectos.

Durante las sesiones de estimación, estimamos su retraso total. Esto le dio x puntos de historia. Sugerimos agregar un 25% para aquellas características que aún no estaban claras o no se conocían en ese momento. Con el atraso estimado adjunto al contrato, se les aseguró que obtendrían todo para 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 el 25% de puntos de historia adicionales para la contingencia. Si las cosas salieron bien, la parte del 25% que no se utilizó para cubrir los retrasos que encontramos se usaría para ofrecer más funcionalidad al cliente.

Esto los estimuló de varias maneras: primero, hicieron todo lo que pudieron para permitir que nuestros desarrolladores trabajen 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, entendieron realmente el concepto de los puntos de la historia. Antes de que comenzara el proyecto, ya habían eliminado algunas de las historias y nos habían pedido que estimáramos otras historias. No se necesitaron negociaciones contractuales complicadas para esto.

Les mantuvimos informados del progreso y mantuvimos una comunicación muy abierta. Recibieron un informe de progreso cada 2 semanas: el x% de los puntos de historia realizados en y% del tiempo estimado deja el z% de los puntos de historia adicionales disponibles. Tuvimos un comienzo un poco difícil, pero logramos ponernos al día con 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 era un poco diferente de sus características inicialmente solicitadas, 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 buscar 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 feliz porque lo entregamos a tiempo y dentro del presupuesto. Mi compañía 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 las 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 de las incógnitas.

Tratar de usar los métodos Agile 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 de cascada "aquí están nuestros requisitos, ¿cuánto y cuánto tiempo tomará?" Escriba proyectos, y lo están poniendo a licitación, realmente no hay tiempo 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 sabe o se preocupa por los detalles entre bastidores.

Quieren 2 cosas: costo y escala de tiempo. Y una vez que les digas eso, entonces lo quieren más barato y más rápido. Y sabes qué, lo queremos todo. Todos los requisitos. Ninguno puede esperar, o ser cortado.

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

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

Sin embargo, tienen que llegar a escalas de tiempo y costos en función de algunos requisitos generales. Tal vez tengan a algunos de los muchachos de la tecnología para reinarlos, pero necesitan hacer una venta para mantener las cosas en funcionamiento.

  

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

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

Dé estimaciones de la cantidad de trabajo necesario (eso es un presupuesto después de todo), pero déjelos tener el poder (leer: responsabilidad) para incluir lo que quieren que se ajuste a su presupuesto.

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

Otra parte de abordar esto es tal vez intentar y usar ambos enfoques. Utilice el enfoque de cascada con la gente de la alta gerencia y la negociación de contratos. Por ejemplo, 'un sistema para permitir que los clientes mantengan carteras y tomen decisiones de inversión utilizando dispositivos tanto de navegador como móviles (Apple y Android)'. o algo así. Luego use Agile para el desarrollo del equipo de desarrollo en las funciones 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 que Agile sea tu diferenciador. Sé que muchas, si no la mayoría de las grandes organizaciones, no están haciendo Agile. Sin embargo, la mayoría de las pequeñas empresas (la gran mayoría en mi experiencia) son. Creo que Agile está creciendo rápidamente y esto continuará. La ventaja de esta ruta es que está lanzando lo que más desea 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 gustan las pruebas. Tener productos bien probados puede ser más fácil de vender para algunos clientes. Un libro que me parece útil en esta área es "Pruebas ágiles" de Adison Wesley Press.

También puede usar los eventos actuales para respaldar su caso. Por ejemplo, el sitio de atención médica actual (escrito en octubre de 2012) es un excelente ejemplo de cómo NO manejar los cambios que se necesitaron 2 semanas antes de su lanzamiento. Además, el aparente exceso de ingeniería probablemente habría sido mejor abordado 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 cascada a ágil. Como mínimo, los conversos que no eran tus 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 del proyecto. Debe asegurarse de estar abordando esas necesidades, y si busca los testimonios de una empresa sobre el cambio, notará que surge directamente. Si te fijas en los testimonios de los desarrolladores sobre el cambio, te darás cuenta de que muchas veces no.