¿Cómo puedo abogar por un programa de lanzamiento semi-estricto en un entorno adverso al riesgo?

12

Recientemente me he sentido cada vez más afectado por lo que tendría que describir como una de mis experiencias más frustrantes y mortales en esta profesión: tener que participar en un lanzamiento que se haya probado, re-probado, por etapas, y para todos los propósitos y propósitos está listo para enviar / implementar .

Como un tipo de soluciones integrales y no solo como un programador hardcore, entiendo e incluso he defendido la necesidad de un control de cambio adecuado. Pero últimamente, el tenue equilibrio entre cubrir nuestras bases y el envío a tiempo se ha desviado mucho, y he tenido poco o ningún éxito en restaurarlo en algo sano.

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

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

  2. Las versiones de software son hitos importantes y no deben tratarse de manera despiadada; en otras palabras, las demoras / interrupciones innecesarias son altamente disruptivas y deben considerarse solo como último recurso a algún problema comercial crítico; y

  3. Las entidades externas (que no son de desarrollo / no de TI) que quieren (o demandan) participar, ya que los interesados tienen la responsabilidad de cooperar con el equipo de desarrollo para cumplir con el calendario de lanzamiento, especialmente en la última semana más o menos antes de la fecha de envío planificada (es decir, prueba / organización del usuario).

Las anteriores son afirmaciones que suenan verdaderas para mí basadas en la experiencia, pero parece que ahora estoy en la posición de tener que demostrar , así que ' Estoy pidiendo algo un poco más carnoso aquí, si tal cosa existe.

¿Puede alguien que haya tenido que "vender" a la administración la idea de un ciclo de lanzamiento fijo (o quizás semi-flexible) a la gerencia para dar algunas sugerencias sobre qué argumentos / estrategias son efectivas o persuasivas y cuáles no? Aparte de la obvia contención en el cronograma y los costos irrecuperables, ¿existen datos o pruebas que puedan ser útiles para afirmar que el envío es realmente importante, incluso en una configuración "corporativa"?

Alternativamente, estoy abierto a escuchar argumentos constructivos sobre por qué la flexibilidad de la 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 ahora, pero tal vez ellos saben algo que yo no.

Tenga en cuenta que hemos lanzado 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 un lanzamiento al 100%, completo, probado y aprobado por los interesados se demore por la administración por razones inexplicables, pero eso es lo que sucedió. eso es lo que está sucediendo, ese es el problema a resolver.

    
pregunta Aaronaught 10.03.2012 - 17:45

8 respuestas

7

Joel Spolsky dice que un equipo de desarrollo de software es un esquema para convertir capital (dinero) en software funcional. Honestamente, según su pregunta, parece que su equipo es bueno en eso: está obteniendo un software decente por una cantidad razonable de dinero invertido.

Ahora, por supuesto, el siguiente paso es poner el software en servicio. Hasta que su empresa decida hacerlo, 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 algo así como un inventario en el almacén: los costos se hunden, el capital de la compañía ya está gastado. También hay un costo de oportunidad: su grupo eligió hacer este proyecto en lugar de otra cosa.

Lo que es má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 la nevera 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 más riesgoso poner el nuevo software en servicio a medida que sus desarrolladores pasan a otras cosas. Después de un par de años en el estante, puede que en realidad no valga la pena. En ese caso, su empresa ha optado por descartar el capital que invirtieron en su desarrollo. Es posible que los propietarios de la empresa, los accionistas, estén descontentos con esto.

Hay una cosa que tú, como desarrollador, debes descubrir. ¿Está su software realmente listo para implementarse al final del ciclo de lanzamiento que está proponiendo? ¿Está listo para comenzar o hay mucho más 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 despliegue? ¿Han sido entrenados 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 compañía lista para hacer ese cambio? ¿Has elaborado un esquema para ejecutar cosas en paralelo, para asegurarte de que las nuevas cosas funcionen tan bien como las viejas?

Todos estos costos de implementación pueden reducir fácilmente el costo de solo desarrollar el software. Un sabio equipo de gestión de proyectos hace todo lo posible para planificar, presupuestar y programar todo eso. ¿Has hecho ese trabajo? ¿Lo has dejado claro a la gerencia? Si no, es posible que sean prudentes ir despacio en sus lanzamientos.

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 los cambios a la velocidad que su equipo puede producir.

También es posible que su equipo de administración sea disfuncional. ¿Su equipo ha desarrollado algo que el resto de la empresa no quiere? ¿Sus nuevas cosas amenazan a su equipo de ventas o producción? Si es así, es posible que algún ejecutivo lo esté torpedeando diciendo que es demasiado arriesgado lanzarlo. No hay nada que puedas hacer al respecto a menos que seas el CEO.

Usted solicitó argumentos convincentes para la implementación oportuna del software. Hay un argumento realmente convincente: el retorno de la inversión. La compañía optó por invertir en este software, y ahora están eligiendo desperdiciar la inversión a medida que su software se descompone lentamente en el estante.

Un argumento secundario para lanzamientos oportunos es la moral de su equipo. Apresurarse y esperar no es una buena manera de motivar a los desarrolladores creativos a hacer un buen trabajo. Puede perder su equipo si no obtienen la satisfacción de ver que su trabajo se pone en servicio.

    
respondido por el O. Jones 10.03.2012 - 23:46
5

Primero, mira este video:

enlace

Resumen ejecutivo:

  

La forma en que realiza el envío a tiempo y dentro del presupuesto es la siguiente: cuando se queda sin   Si te quedas sin dinero, envías. Eso es todo.

     

La razón más   los proyectos no se envían a tiempo es porque alguien viene junto con "solo   una característica o solución más "para insertar en el lanzamiento, justo antes de que estés   Listo para enviar, en un momento del ciclo de desarrollo en el que sus recursos son más escasos y ahora tiene que codificar. Esto se llama paliza, y sucede porque como   siempre y cuando no envíe, no tiene que preocuparse por que la gente le diga   Tu producto apesta.

     

La forma de curar las palizas es forzando   personas que lo hagan 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 ya sea que el cambio sea una característica nueva, 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 acude a mí para arreglarlo o cambiarlo al final del ciclo de desarrollo, siempre le pregunto esto: "¿Qué desea que no haga para que pueda hacer su trabajo?" em>

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 característica o solución, más costoso será. Exponencialmente. No es difícil probar esto.

    
respondido por el Robert Harvey 10.03.2012 - 19:33
4

Usted ha descrito claramente los problemas a los que se enfrenta, sin embargo, no tengo claro por qué los gerentes se están comportando de esta manera. ¿Puedes aclarar? Por ejemplo, si crees que está listo para implementarse, ¿hay alguien en desacuerdo? Si es así, ¿quién y por qué? ¿Son ex gobernadores beaurócratas?

Esto se parece mucho a un problema de alineación entre la capacidad y el deseo, tienes el deseo de liberar, pero no la capacidad (autoridad), aquellos con la autoridad no tienen el deseo.

Necesitas descubrir por qué carecen de este deseo: es un motivo de mercadeo (manténlo por un año más mientras ordeñamos la versión anterior un poco más), es miedo / confianza (si tiene errores, hará nos vemos mal, nos cuestan dinero ..., falta de recursos (no puedo pagar el costo de envío / empaque / material de relaciones públicas), es comercial donde puedes obtener un poco de dinero para obtener un exceso de beneficios pobres y no te quieren Ganar 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 llevando a cabo discusiones razonables de adultos.

Lo siento, no es la respuesta específica que ha pedido, aunque espero que haya un par de cosas en que pensar.

    
respondido por el mattnz 10.03.2012 - 22:11
2

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

Lo ideal es que sus solicitudes de cambio tengan una sección llamada Mitigación de riesgos , que contenga instrucciones sobre cómo volver a la versión anterior si las cosas salen mal. En cuanto al riesgo, ninguna prueba previa puede sustituir una opción simple para revertir el cambio.

  • En un entorno adverso al riesgo, no puedo imaginar una manera de hacer que los cambios irreversibles sean indoloros.
    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 se expondrá, si desea que el programa del equipo de desarrollo sea tratado con seriedad.

Si sus lanzamientos entregan correcciones para problemas de producción / soporte e interrupciones, esto es bastante fácil de hacer simplemente enumerándolos y señalando que la producción corre el riesgo de repetirlos a menos que se actualice.

Una medida realmente efectiva disponible para el equipo de desarrollo para luchar contra las notas de liberación para asegurar que el riesgo de no lanzar aumente con el tiempo . Esto se puede lograr con lanzamientos internos que se ejecutan en un horario fijo, proporcionando una lista "acumulativa" de soluciones a problemas de producción.

  • En pocas palabras, los individuos que bloquean su lanzamiento XX deben tener en cuenta no solo que corren el riesgo de tener N tipos de problemas de producción para seguir sin resolver, sino que también esa semana (o mes) más tarde, tendrán la liberación de XX+1 en su cola de aprobación, el bloqueo que incurrirá en el riesgo de N+M de los tipos de problemas de producción sigue sin resolverse, y este también será el caso con XX+2 y otras versiones "internas" suministradas por el equipo de desarrollo.

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

Debido a eso, puede esperar una mayor participación en escalada de problemas de producción . Puede usar estos como una oportunidad para promover su visión de actualizaciones programadas más estrictas. Incluso puede desencadenar algunas escalas para acelerar el proceso de adopción del enfoque deseado.

  • "... se recomienda considerar la actualización de la aplicación a una versión más reciente ( XX o posterior). La que se implementa 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 están profundamente ocultos en los registros y la aplicación informa a la basura indescifrable en lugar de descripciones de fallas claras, lo que hace que los usuarios pierdan tiempo investigando problemas que son realmente simples " / em>

    Arriba hay un comentario que agregué hace algún tiempo en el rastreador de problemas de soporte para el ticket relacionado con un incidente de producción en particular. Poco después, los "grupos de interés" se pusieron en contacto con el equipo de desarrollo y le preguntaron cómo realizar un seguimiento de nuestros lanzamientos y cómo pueden ayudar a implementar en su entorno. Ah, y también se actualizaron rápidamente desde la versión XX-2 , también. :)

Cuando ocurra una escalada de producción, es mejor que esté preparado para presentar su visión de manera rápida y clara.

Una cosa que le resultará útil es seleccionar y realizar un seguimiento de quién es responsable para un deslizamiento de la versión en particular. Básicamente, debe poder responder de manera rápida y clara a una pregunta como "¿quién es responsable del hecho de que el lanzamiento planificado no ocurrió?" Si no estás listo, pueden elegir el camino de menor resistencia y echarte la culpa. Como se señala en comenta a otra respuesta ," Podría meterse en el agua caliente de la que su gerencia está tratando de protegerlo ".

El último pero no el menos importante,

llevará tiempo

(probablemente ya lo sepas, pero vale la pena decirlo explícitamente)

Lo que busca puede describirse como un cambio de actitud, desde "es arriesgado liberar " hasta "es arriesgado NO lanzar ". Los cambios de actitud rara vez ocurren de la noche a la mañana, podría ser necesaria la paciencia para completar el cambio.

    
respondido por el gnat 19.03.2012 - 14:29
1

Hay un gran signo de interrogación sobre tu pregunta y es por eso que tu empresa no desea lanzar el software. No siempre es solo un caso simple de aversión al riesgo. A menudo hay otras causas subyacentes que a menudo no se transmiten desde las alturas gerenciales elevadas. Así que mi pregunta para usted es: "¿Se sentó con su jefe y le preguntó por qué se retrasó el lanzamiento del producto?".

Hay una gran diferencia entre administrar el riesgo y evitarlo. Puede haber razones legales o de marketing para retrasar el lanzamiento de un producto. Podrían ser temas de confianza entre la gerencia y el equipo de desarrollo. Es posible que el producto no se adapte a 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 lo cubra seriamente mientras intenta cambiar la culpa por la demora en otra parte, o incluso la demora de un tercero que debe completar algo antes de que se envíe su producto. Podría llegar a docenas de escenarios. Muy a menudo, el desarrollador asume la aversión al riesgo sin entender 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 compañía, o incluso un temor de que el producto falle en el mercado por alguna razón que resulte en demoras aparentemente ridículas.

En todos los casos, es importante tener más información sobre los motivos de los retrasos en el lanzamiento del producto y usar esa información para crear un caso para lanzar su producto tan pronto como sea posible. Sí, puede ser muy frustrante, pero hay otras formas de lidiar con estas situaciones sin arriesgar la confrontación con sus jefes o un agotamiento. En situaciones similares, yo mismo he reunido información, documentado cualquier progreso que he hecho y, si no, empeoró, simplemente archivé el proyecto y me mudé a otra cosa. Donde he podido volver a encarrilar un proyecto para su lanzamiento, generalmente ha sido el resultado de presentar un caso de negocios sólido basado en la información que he recibido como retroalimentación a las preguntas que he planteado. Donde no he podido convencer a la gerencia de que el producto debería enviarse, he documentado que la renuencia a realizar el envío es simplemente un caso de proyecto terminado y en espera de la aprobación de la liberación por parte de la gerencia. Luego me aseguro de que mi administrador firme mi documento como aceptado y comprendido por la gerencia, de modo que mi propio trasero esté cubierto si intentan culparme más tarde por una no publicación.

Siempre es necesario que salpiques tu I y T cruzado para evitar que los retrasos en el envío se te culpen más tarde (no importa lo injusto), y también es importante evitar estar demasiado ligado emocionalmente a tales problemas a menos que te guste la idea de un pozo Úlcera ganada. Al observar su propia situación con un cierto desapego profesional, es posible que encuentre una solución porque se ha colocado efectivamente a una "distancia" mayor como lo era el problema. Si no puede presentar su caso, es posible que tenga que dejarlo pasar un tiempo, pero para poder presentar su caso en primer lugar, debe parecer un profesional desapegado y tener argumentos basados en información que esté íntimamente relacionada. Su empresa y su funcionamiento interno.

Algo más sobre lo que acabo de pensar que podría ser de alguna ayuda para usted, es quizás leer Lean Software Development , y vea si hay algo valioso que pueda estar relacionado con la situación de su empresa, especialmente en los primeros capítulos. Creo que fue el capítulo 4 el que trata el tema de la entrega lo más rápido posible y tiene algo relacionado con los costos de demora.

    
respondido por el S.Robins 13.03.2012 - 03:47
0

Yo diría que la forma más fácil / efectiva de vender una versión es desactivar las herramientas por un tiempo cuando esté listo para funcionar. Haga algo más, comience un nuevo proyecto, trabaje en errores para el proyecto existente. No le hagas más a éste hasta que se envíe 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, debes enviárselo y luego tratarlo como un lanzamiento. Una vez que está fuera de su puerta, se envía. Si solo se sientan en él, no es tu problema (de hecho, es genial, ¡no se informa de ningún error en él! ¡W00t! Bonos por un lanzamiento sin errores en todos los aspectos;))

Así que, de todos modos, necesitas un sistema de control de cambios y un administrador de versiones. Entonces todo es fácil (excepto que usted necesita administrar el control de cambios, por lo que las compilaciones de implementación y control de origen son muy necesarias. Requiere organización, pero si está organizado, es fácil).

    
respondido por el gbjbaanb 13.03.2012 - 00:50
0

No puedo imaginar que poner al equipo de Dev a cargo del negocio de la forma en que lo describe es una "cosa buena". Puede ocultar el problema real, pero a menos que el equipo de Dev esté en la posición correcta para sopesar las entradas de ventas, marketing, etc., se arriesga a liberar por razones incorrectas (y potencialmente malas).

Si entiendo su problema, ha completado el proyecto y tiene un entregable que no puede mostrar a nadie fuera de su compañía. (Espero que esto lo resuma, leí todo el hilo y tengo problemas para identificarlo)

Has intentado:

  1. ¿Pedir a la administración que un cliente o un grupo de clientes actúen como partes interesadas durante el desarrollo? Por lo general, usted puede encontrar un cliente para tomar versiones intermedias y dar su opinión. Pueden ser grandes defensores cuando sea el momento de la liberación. Incluso una "versión limitada" para un cliente podría ser suficiente para ayudar a la gestión de balanceo
  2. Construyendo un plan de lanzamiento incluyendo lanzamientos de puntos. Es decir, puede lanzar 3.4 hoy porque la versión 3.4.1 está prevista para hoy + 1 mes. Esto junto con la buena idea que ya mencionó que una cadencia de lanzamiento ayuda a este mensaje.
  3. Obtenga soporte, ventas o marketing de su lado. Incorpore soluciones que resolverían las 3 solicitudes de soporte principales y puede obtener un aliado de otro departamento. Si no puede obtener un cliente interesado como en el número 1, inténtelo con algunos vendedores. Ofrezca estar disponible para reuniones de ventas y llevar el producto. Cuando esté en el camino, muéstrele a la persona de ventas que está con el producto (en el estado en el que se encuentre) haga que lo hagan por usted.

Para responder a su otra pregunta sobre "¿por qué la administración se sienta en un lanzamiento?" Las empresas hacen esto todo el tiempo en campos que no son SW y no creo que no tenga precedentes. Por ejemplo, tiene una nueva versión que está 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 competencia, la versión anterior, la administración 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 de líder del mercado. Liberar demasiado pronto les da la mano a los competidores que podrían tener una mejor idea de su plan de trabajo y tratar de ganarle hasta el final.

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

    
respondido por el Al Biglan 13.03.2012 - 02:50
-1

Aléjate de esa compañía, no entienden el software. Pero en serio, el software es lo que hace que el sistema funcione, imagínese si estuviera haciendo coches, ¿son lentas las fábricas de automóviles? ¿Esperan los lanzamientos de coches? ¿Son incrementales y burocráticos? No, intentan hacer las cosas de la manera más rápida y limpia posible. Tiene un problema de administración y debe trabajar en él como un conflicto de administración, trate de hablar sobre sus términos. Pregunte qué significa el riesgo para ellos, luego intente minimizarlo. Los sentimientos de tus desarrolladores también son importantes, ya que deben lidiar con las decisiones que se tomarán con tu intervención. ¿Estará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 a este problema, un poco extremo, pero solicite una auditoría. Eso le dará herramientas para hablar con la gerencia sobre los problemas que ve, pero desde un punto de vista externo, y también mejorará su imagen con ellos.

    
respondido por el alfa64 29.04.2012 - 20:22

Lea otras preguntas en las etiquetas