¿Cómo puedo abogar por un calendario de lanzamiento semi-estricto en un entorno de aversión al riesgo?

Recientemente, he estado cada vez más plagado de lo que tendría que describir como una de mis experiencias más frustrantes y mortales en esta profesión: tener que sentarme en una versión que ha sido probada, reevaluada, puesta en escena y para todos los efectos y los propósitos están listos para enviar / desplegar .

Como experto en soluciones integrales y no solo como programador, entiendo e incluso he abogado por la necesidad de un control de cambio adecuado. Pero últimamente, el tenue equilibrio entre cubrir nuestras bases y enviar a tiempo se ha vuelto desproporcionado, y he tenido poco o ningún éxito en restaurarlo a algo cuerdo.

Estoy buscando argumentos convincentes para ayudar a convencer a la administración de aversión al riesgo que:

1. El equipo de desarrollo debe (o debe) poder establecer su propio calendario de lanzamiento, dentro de lo razonable (de 1 a 3 meses debe ser lo suficientemente conservador para todas las compañías excepto las más grandes de Fortune 500);

2. Las versiones de software son hitos importantes y no deben tratarse de forma cautelosa; en otras palabras, los retrasos / paros innecesarios son muy perjudiciales y deben considerarse solo como último recurso para algún problema comercial crítico; y

3. Las entidades externas (que no son de desarrollo / que no son de TI) que desean (o demandan) participar como partes interesadas tienen la responsabilidad de cooperar con el equipo de desarrollo para cumplir con el cronograma de lanzamiento, especialmente en la última semana más o menos antes del envío planificado fecha (es decir, prueba / puesta en escena del usuario).

Lo anterior son afirmaciones que me parecen ciertas en base a la experiencia, pero parece que ahora estoy en la posición de tener que demostrarlo , por lo que estoy pidiendo algo un poco más carnoso aquí, si tal cosa existe.

¿Alguien que haya tenido que "vender" la idea de un ciclo de lanzamiento fijo (o tal vez semiflexible) a la gerencia puede dar algunos consejos sobre qué argumentos / estrategias son efectivos o persuasivos y cuáles no? Además de la obvia disputa del cronograma y los costos hundidos, ¿hay alguna información / evidencia sólida que sea útil para demostrar que el envío es realmente importante, incluso en un entorno "corporativo"?

Alternativamente, estoy abierto a escuchar argumentos constructivos sobre por qué la flexibilidad de programación (incluso durante un período de semanas / meses) es más importante que el envío a tiempo; Es difícil para mí creer en este momento, pero tal vez ellos saben algo que yo no.

_{Tenga en cuenta que hemos realizado lanzamientos, y esto pasó por todas las etapas, excepto la producción. Los problemas se rastrean utilizando un rastreador de errores comercial y todos los problemas, el 100% de ellos, que se asignaron a esta versión se cerraron. Me doy cuenta de que es difícil de creer y ese es realmente el punto: no tiene sentido que una liberación al 100%, completa, completamente probada y aprobada por las partes interesadas sea retrasada por la administración por razones inexplicables, pero eso es lo que sucedió, eso es lo que ha estado sucediendo, ese es el problema a resolver.}

Joel Spolsky dice que un equipo de desarrollo de software es un esquema para convertir capital (dinero) en software de trabajo. Honestamente, a partir de su pregunta, parece que su equipo es bueno en eso: está obteniendo un software decente por cantidades razonables de dinero invertido.

Ahora, por supuesto, el siguiente paso es poner el software en servicio. Hasta que su empresa decida hacer eso, no hay forma de que obtengan un retorno de su inversión de capital. El software que se encuentra en el estante listo para implementarse es como un inventario en el almacén: los costos están hundidos, el capital de la compañía ya se ha gastado. También hay un costo de oportunidad: su grupo eligió hacer este proyecto en lugar de otra cosa.

Además, el valor del software recientemente desarrollado que se encuentra en el estante es algo así como el valor de una caja de queso en el refrigerador de un restaurante: se pudre lentamente. Su valor disminuye porque sus competidores se ponen al día. También disminuye porque se vuelve más difícil y arriesgado poner en servicio un nuevo software a medida que sus desarrolladores pasan a otras cosas. Después de un par de años en el estante, en realidad puede ser inútil. En ese caso, su empresa ha optado por descartar el capital que invirtió en su desarrollo. Es posible que los propietarios de la empresa, los accionistas, estén disgustados por esto.

Hay una cosa que usted, como desarrollador, debe descubrir. ¿Está su software realmente listo para implementarse al final del ciclo de lanzamiento que está proponiendo? ¿Está listo para funcionar o hay mucho trabajo por hacer y dinero para gastar a medida que su empresa lo pone en producción? ¿Su empresa posee los servidores y las licencias de software que necesita para implementar su software? ¿Su producto de trabajo incluye un plan de implementación? ¿Se ha capacitado a los usuarios finales? ¿Se han convertido los datos de producción? Si su nuevo software implica un cambio en la forma en que su empresa hace negocios, ¿está la empresa lista para hacer ese cambio? ¿Ha elaborado un esquema para ejecutar cosas en paralelo, para asegurarse de que las cosas nuevas funcionen tan bien como las viejas?

Todos esos costos de implementación pueden eclipsar fácilmente el costo de solo desarrollar el software. Un equipo de administración de proyectos inteligente hace todo lo posible para planificar, presupuestar y programar todo eso. ¿Has hecho ese trabajo? ¿Le ha dejado claro a la gerencia? Si no, es posible que sean sabios ir despacio en sus implementaciones.

Es posible que un programa de implementación de software ágil moderno no esté sincronizado con el ritmo de cambio que el resto de su empresa espera. Es posible que sus usuarios finales, sus partes interesadas, simplemente no puedan absorber el cambio al ritmo que su equipo puede producirlo.

También es posible que su equipo de administración sea disfuncional. ¿Ha desarrollado su equipo algo que el resto de la empresa no quiere? ¿Sus nuevas cosas amenazan a su equipo de ventas o producción? Si es así, algún ejecutivo puede estar torpedeándolo al decir que es demasiado arriesgado desplegarse. No hay nada que puedas hacer al respecto a menos que seas el CEO.

Solicitó argumentos convincentes para la implementación oportuna de software. Hay un argumento realmente convincente: el retorno de la inversión. La compañía eligió invertir en este software, y ahora eligen desperdiciar la inversión a medida que su software se pudre lentamente en el estante.

Un argumento secundario para la implementación oportuna es la moral de su equipo. Date prisa y espera no es una buena manera de motivar a los desarrolladores creativos para que hagan un buen trabajo. Puede perder su equipo si no obtienen la satisfacción de ver su trabajo entrar en servicio.

Primero, mira este video:

http://the99percent.com/videos/5822/Seth-Godin-Quieting-the-Lizard-Brain

Resumen Ejecutivo:

La forma de enviar a tiempo y dentro del presupuesto es la siguiente: cuando se acaba el tiempo o se queda sin dinero, realiza el envío. Eso es.

La razón por la cual la mayoría de los proyectos no se envían a tiempo es porque alguien viene con "solo una característica o corrección más" para insertar en el lanzamiento, justo antes de que esté listo para enviar, en un momento del ciclo de desarrollo cuando sus recursos son muy escaso, y ahora tienes que luchar. Esto se llama paliza, y sucede porque mientras no envíe, no tendrá que preocuparse de que la gente le diga que su producto es una mierda.

La forma de curar la paliza es forzando a las personas a hacerlo al comienzo del ciclo de desarrollo del producto , no al final.

Hacer cambios en el producto en las semanas previas a la fecha de lanzamiento es muy perjudicial, por razones obvias. Esto es cierto si el cambio es una nueva característica, un cambio en el proceso de desarrollo de software o un intento de corregir un error de larga data que no está en el programa de desarrollo.

Cuando alguien viene a buscarme una solución o un cambio al final del ciclo de desarrollo, siempre les pregunto esto: "¿Qué quieren que no haga para que pueda hacer lo suyo?"

Si necesita un motivador de dinero, es esto: los estudios demuestran que cuanto más tarde espere en el ciclo de vida del software para implementar una función o solución, más costoso será. Exponencialmente No es difícil probar esto.

Usted ha descrito claramente los problemas que enfrenta, sin embargo, no tengo claro por qué los gerentes se comportan de esta manera. ¿Puedes aclarar? Por ejemplo, si cree que está listo para desplegar, ¿alguien está en desacuerdo? De ser así, ¿quién y por qué? ¿Son ex burócratas del gobierno?

Esto suena mucho como un problema de alineación de capacidad vs deseo, tienes el deseo de liberar, pero no la capacidad (autoridad), aquellos con la autoridad no tienen el deseo.

Debe descubrir por qué carecen del deseo: es una razón de marketing (consérvelo por otro año mientras le damos un poco más de leche a la versión anterior), es miedo / confianza (si tiene errores, nos hará quedar mal) , nos cuesta dinero ..., falta de recursos (no puede pagar el costo de envío / empaque / material de relaciones públicas), ¿es comercial donde sus fondos oscuros se hunden en ganancias excesivas y no quieren que gane dinero ( No es tan tonto como parece).

También sospecho que hay poco respeto entre las partes involucradas, por lo tanto, no se están produciendo discusiones razonables para adultos.

Lo sentimos, no es la respuesta específica que ha pedido, aunque espero que tenga en cuenta algunas cosas.

Lo primero que debe considerar es asegurarse de que sus lanzamientos no sean de alto riesgo .

Idealmente, sus solicitudes de cambio deberían tener una sección llamada como Mitigación de riesgos , que contiene instrucciones sobre cómo retroceder a la versión anterior si las cosas salen mal. En cuanto al riesgo, ninguna cantidad de pruebas previas puede sustituir una opción simple para revertir el cambio.

• ^{En un entorno de aversión al riesgo, no puedo imaginar una forma de hacer cambios irreversibles sin dolor.
  Si muchos / la mayoría de sus lanzamientos entran en esta categoría, es posible que desee reconsiderar su arquitectura.}

El riesgo de NO liberar es estar expuesto, si desea que el programa del equipo de desarrollo sea tratado seriamente.

Si sus versiones ofrecen soluciones para problemas de producción / soporte y cortes, esto es bastante fácil de hacer simplemente enumerando estos y señalando que la producción está en riesgo de repetirlos a menos que se actualice.

Una medida realmente efectiva disponible para que el equipo de desarrollo luche contra los deslizamientos de lanzamiento para asegurarse de que el riesgo de no lanzar aumente con el tiempo . Esto se puede lograr con versiones internas que se ejecutan en un horario fijo, proporcionando una lista "acumulativa" de soluciones a problemas de producción.

• Simplemente hablando, los chicos que bloquean su lanzamiento XXdeben ser conscientes no solo de que incurren en el riesgo de tener Nproblemas de producción para permanecer sin resolver, sino también esa semana (o mes) más tarde, tendrán un lanzamiento XX+1en su cola de aprobación, lo que bloqueará incurrir en el riesgo de que los N+Mtipos de problemas de producción permanezcan sin resolver, y que este también será el caso con XX+2otras versiones "internas" proporcionadas por el equipo de desarrollo.

La forma descrita anteriormente esencialmente hace una conexión más estricta y más explícita entre las actualizaciones de su aplicación y los problemas de producción.

Debido a eso, puede esperar una mayor participación en los problemas de producción . Puede utilizarlos como una oportunidad para promover su visión de actualizaciones programadas más estrictas. Incluso puede activar algunas escaladas usted mismo para acelerar el proceso de adoptar el enfoque deseado.

• ^{"... recomiendo considerar actualizar la aplicación a la versión más nueva ( XXo posterior). La que está implementada actualmente en su entorno ( XX-2) está muy desactualizada: dos versiones principales detrás de la base de código actual. Como resultado, los detalles de tales fallas simples son profundamente oculto en los registros y la basura informa indescifrable a los clientes en lugar de descripciones claras de fallas, lo que hace que los usuarios y el soporte pierdan tiempo investigando problemas que son realmente simples "
   
  Arriba hay un comentario que agregué hace un tiempo en el rastreador de problemas de soporte para el ticket relacionado con un incidente de producción particular. Poco después, los "interesados" se pusieron en contacto con el equipo de desarrollo para preguntarles cómo realizar un seguimiento de nuestras versiones y cómo pueden ayudar a implementar en su entorno. Ah, y también actualizaron rápidamente deXX-2versión también. :)}

Cuando ocurre la escalada de producción, es mejor estar preparado para presentar su visión de forma rápida y clara.

Una cosa que encontrará útil es elegir y rastrear quién es responsable de un deslizamiento de lanzamiento particular. Básicamente, debe poder responder rápida y claramente a preguntas como "¿quién tiene la responsabilidad por el hecho de que no se realizó la liberación planificada?" Si no está listo, pueden elegir el camino de menor resistencia y echarle la culpa a usted. Como se señaló en los comentarios a otra respuesta , "Usted podría meterse en el agua caliente de la cual su gerencia está tratando de protegerlo".

El último pero no menos importante,

tomará tiempo

(probablemente ya lo sepas pero parece que vale la pena declararlo explícitamente)

Lo que busca puede describirse como un cambio de actitud, desde "es arriesgado liberar " hasta "es arriesgado NO liberar ". Los cambios de actitud rara vez ocurren de la noche a la mañana, es posible que se necesite paciencia para completar el turno.

Hay un gran signo de interrogación sobre su pregunta, y es por eso que su empresa no desea lanzar el software. No siempre es un simple caso de aversión al riesgo. A menudo hay otras causas subyacentes que a menudo no se transmiten desde las altas alturas gerenciales. Entonces mi pregunta para usted es: "¿Se ha sentado con su jefe y le ha preguntado por qué se retrasa el lanzamiento del producto?".

Hay una gran diferencia entre gestionar el riesgo y evitarlo. Puede haber razones legales o de marketing para retrasar el lanzamiento de un producto. Podrían ser problemas de confianza entre la gerencia y el equipo de desarrollo. El producto puede no satisfacer las necesidades del cliente, incluso si es exactamente lo que el cliente solicitó hace meses. Incluso podría ser el caso de alguien en la gerencia que cubra seriamente el culo mientras trata de eliminar la culpa de la demora en otro lugar, o incluso una demora de un tercero que debe completar algo antes de que se envíe su producto. Podría idear docenas de escenarios. Muy a menudo, el desarrollador asume la aversión al riesgo sin comprender el otro lado de la ecuación que no se ha hecho evidente. Por otro lado, puede ser simplemente complacencia, conflicto entre individuos dentro de una empresa,

En todos los casos, es importante tener más información sobre las razones de los retrasos en el lanzamiento del producto y utilizar esa información para crear un caso para lanzar su producto lo antes posible. Sí, puede ser muy frustrante, pero hay otras formas de lidiar con estas situaciones sin arriesgarse a enfrentarse con sus jefes o al agotamiento. En situaciones similares, yo mismo he reunido información, documentado cualquier progreso que haya hecho, y luego, si las cosas empeoraron, simplemente archivé el proyecto y pasé a otra cosa. El hecho de que haya podido volver a encaminar un proyecto para su lanzamiento generalmente ha sido el resultado de hacer un caso comercial sólido basado en la información que he recibido como respuesta a las preguntas que he planteado. Donde no he podido convencer a la gerencia de que el producto debe enviarse, He documentado la renuencia a enviar como simplemente un caso de proyecto terminado y esperando la aprobación de la liberación por parte de la gerencia. Luego me aseguro de que mi gerente firme mi documento como aceptado y entendido por la gerencia para que mi propio trasero esté cubierto si intentan culparme más tarde por una no divulgación.

Siempre debe puntear sus I y cruces de T para evitar retrasos en el envío que luego se le culpe (no importa cuán injustamente), y también es importante evitar estar demasiado emocionalmente ligado a tales problemas a menos que le guste la idea de una úlcera bien merecida. Al observar su propia situación con un cierto desapego profesional, puede encontrar una solución que se presenta porque efectivamente se ha colocado a una "distancia" mayor del problema. Si no puede presentar su caso, es posible que deba dejarlo pasar por un tiempo, pero para presentar su caso en primer lugar, debe parecer desapegado profesionalmente y tener argumentos basados ​​en información que esté íntimamente relacionada con su empresa y su funcionamiento interno.

Otra cosa que acabo de pensar y que podría serle de ayuda es leer Lean Software Development y ver si hay algo valioso que pueda relacionarse con la situación de su empresa, particularmente en los primeros capítulos. Creo que fue el capítulo 4 el que trata el tema de entregar lo más rápido posible y tiene algo relacionado con los costos de demora.

Yo diría que la forma más fácil / efectiva de vender un lanzamiento es bajar las herramientas por un tiempo cuando esté listo. Haga otra cosa, comience un nuevo proyecto, trabaje en errores para el proyecto existente. No le hagas más a este hasta que lo envíes por la puerta; después de todo, ¿por qué molestarse en hacerlo si no sale cuando está listo?

pero en el mundo real, el lanzamiento real es un problema de otra persona, deberías enviárselo y luego tratarlo como un lanzamiento. Una vez que está fuera de su puerta, se envía. Si simplemente se sientan en él, no es su problema (de hecho, ¡es genial, no se informan errores! W00t! Bonificaciones por una versión libre de errores en general;))

Por lo tanto, de todas formas necesita un sistema de control de cambios y un administrador de versiones. Entonces todo es fácil (excepto que es necesario administrar el control de cambios, por lo que el control de origen más las compilaciones de implementación son muy necesarias. Requiere organización, pero si está organizado, es fácil).

No puedo imaginar que poner al equipo de desarrollo a cargo del negocio de la manera que usted describe es "algo bueno". Puede enmascarar el problema real, pero a menos que el equipo de desarrollo esté en la posición correcta para sopesar los aportes de las ventas y el marketing. , etc., etc., corre el riesgo de ser liberado por razones incorrectas (y potencialmente malas).

Si entiendo su problema, ha completado el proyecto y tiene una entrega que no puede mostrar a nadie fuera de su empresa. (Espero que esto lo resuma, leí todo el hilo y tengo problemas para señalarlo)

Has probado:

1. ¿Solicitar a la gerencia un cliente o un conjunto de clientes que actúen como partes interesadas durante el desarrollo? Por lo general, puede encontrar un cliente para tomar versiones intermedias y dar su opinión. Pueden ser grandes defensores cuando es hora de lanzar. Incluso una "versión limitada" para un cliente podría ser suficiente para ayudar a influir en la gestión
2. Creación de un plan de lanzamiento que incluya lanzamientos puntuales. Es decir, puede lanzar 3.4 hoy porque la versión 3.4.1 está planificada para hoy + 1 mes. Esto, junto con la buena idea que ya mencionó, de que una cadencia de lanzamiento ayuda a este mensaje.
3. Obtenga soporte, ventas o marketing de su parte. Cree soluciones que resuelvan las 3 principales solicitudes de soporte y puede obtener un aliado de otro departamento. Si no puede obtener un cliente interesado como en el n. ° 1, pruébelo con un par de vendedores. Oferta para estar disponible para reuniones de ventas y llevar el producto. Cuando esté de viaje, muéstrele al vendedor que está con el producto (en cualquier estado en el que se encuentre) que lo atraiga por usted.

Para responder a su otra pregunta sobre "¿por qué la administración se quedaría en un lanzamiento?" Las empresas hacen esto todo el tiempo en campos que no son SW y no creo que tenga precedentes. Por ejemplo, tiene una nueva versión lista para usar, todo probado y listo. Pero la versión anterior aún no ha sido desplazada por la competencia. Una vez que la competencia lanza un producto de la versión anterior, la gerencia lanza la versión que está esperando en el estante e interrumpe el mercado, retrasa la competencia y mantiene las ventas y la reputación como líder del mercado. El lanzamiento demasiado pronto da la mano a los competidores que podrían tener una mejor idea de su hoja de ruta y tratar de ganarle al final del juego.

Con todo lo dicho ... La navaja de afeitar de Hanlon es probablemente la respuesta correcta :-)

Aléjese de esa compañía, no entienden el software. Pero en serio, el software es lo que hace que el sistema funcione, imagina que si estuvieras haciendo autos, ¿las fábricas de autos son lentas? ¿Esperan los lanzamientos de automóviles? ¿Son incrementales y burocráticos? No, intentan hacer las cosas de la manera más rápida y limpia posible. Tiene un problema de gestión y debe trabajar en él como un conflicto de gestión, trate de expresarlos en sus términos. Pregunte qué significa el riesgo para ellos, luego intente minimizarlo. Los sentimientos de sus desarrolladores también son importantes, ya que deben hacer frente a las decisiones que tomará su intervención. ¿Serán felices haciendo todas las noches para enviar a tiempo? ¿Cuáles serían los premios / penalizaciones? Etc. Ahora le daré un enfoque práctico para este problema, un poco extremo, pero solicite una auditoría.