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

12

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.

Aaronaught
fuente
Buena suerte. Como desarrolladores de una compañía anterior, peleamos esta batalla desde el otro lado hasta el medio. Tuvimos implementaciones por capricho porque la empresa necesitaba correcciones de errores y mejoras "inmediatamente". Te deseo lo mejor en tu esfuerzo.
TheDevOpsGuru
¿Alguna vez su gerencia ha estudiado el costo de oportunidad de esperar un lanzamiento?
chrisaycock
@chrisaycock: Dudo que hayan estudiado o realmente entiendan el costo de oportunidad desde cualquier ángulo. Sin embargo, solo decir la frase "costo de oportunidad" no va a influir en nadie; Necesito algo específico que señalar.
Aaronaught
¿Por qué no puede comenzar a trabajar en la próxima versión de su software mientras espera que se lance la actual?
krlmlr
@ user946850: puedo, en teoría. Eso no cambia nada de lo que se ha dicho en esta pregunta. No niega el efecto desmoralizador de tener las manos atadas y haber trabajado en algo que no se liberará, ni el efecto masivamente disruptivo de lidiar con una liberación de mitad de ciclo.
Aaronaught

Respuestas:

7

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.

O. Jones
fuente
1
Gran respuesta. Lo curioso, en mi caso, es que incluso los costos de implementación básicamente se han gastado. ¡Solo tenemos que accionar el interruptor! Excepto que, metafóricamente hablando, necesitamos un interruptor de unión para activar el interruptor y no hay ninguno disponible para las próximas 7 semanas.
Aaronaught
1
¡Guauu! La ciencia médica conoce este problema como inversión craneorrectal gerencial. ¿Necesitas estar trabajando en otro lugar?
O. Jones
5

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.

Robert Harvey
fuente
1
Todo esto es un buen consejo, pero no creo que sea realmente pertinente; Definitivamente no dije y no quise decir que los cambios de alcance de último minuto están causando demoras. De lo que estoy hablando es de obstáculos burocráticos lanzados por personas que simplemente se resisten a cualquier cambio en el entorno de producción, especialmente en lo que respecta a los clientes.
Aaronaught
Eso sí, releyendo mi pregunta, supongo que no hice mucho para aclarar que no hubo cambios en el alcance, por lo que tampoco puedo criticar esta respuesta.
Aaronaught
4

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.

Mattnz
fuente
1
El penúltimo párrafo es un análisis bastante bueno del problema: es una cuestión política, no técnica. Obviamente, por razones de privacidad, no puedo entrar en detalles mucho más elaborados, y tampoco creo que sea realmente pertinente para la solución. Independientemente de quién está "bloqueando" y por qué, creo que la única solución a largo plazo es convencer a la alta gerencia de que el equipo de desarrollo debe tener el control del proceso y específicamente de un proceso que incluya fechas de envío firmes planificadas con anticipación.
Aaronaught
3
Un punto a tener en cuenta: no es normal que Dev esté a cargo de las fechas de entrega. Dev ha aportado información sobre estas fechas, pero a menos que las fechas se establezcan por razones comerciales, en lugar de razones técnicas, la empresa está en problemas.
mattnz
Realmente hace un buen punto resaltando la sutileza aquí: se trata más de obtener un compromiso ejecutivo detrás de las fechas de envío regulares que de tener un control completo sobre el cronograma. Por supuesto, el negocio finalmente decidirá cuándo y con qué frecuencia enviar, pero estos deben decidirse con mucha anticipación, con el equipo de desarrollo teniendo una contribución significativa , y lo más importante de todo es que no pueden debatirse 2 semanas antes (o peor) , 2 semanas después ) la fecha de envío esperada a menos que haya una razón comercial sólida, con la responsabilidad del bloqueador para justificarlo.
Aaronaught
Cualquier otro proceso, para mí, es solo un caos. Si no tiene idea de cuándo se enviará realmente su proyecto, es casi imposible hacer el alcance o el diseño adecuados.
Aaronaught
2
@Aaronaught: puede ser tan simple como política / colaboración. Podría meterse en agua caliente de la que su gerencia está tratando de protegerlo. Permítame sugerir esta lógica: suponga que el envío no es lo mejor para el negocio en todos y cada uno de los casos. Por lo tanto, debe haber algunas razones / situaciones en las que a la empresa le interesa no realizar envíos. No conocer la situación completa de arriba a abajo no lo hace equivocarse, tampoco hace que la administración se equivoque.
jasonk
2

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.

mosquito
fuente
1

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.

S.Robins
fuente
1
No hay signo de interrogación. No mencioné ninguno de estos escenarios porque no hay ninguno pertinente. Por supuesto, lo que está diciendo aquí sería razonable dado que no hay contexto, pero la pregunta se escribió asumiendo que la gente me creería cuando digo que he agotado todas las vías de investigación.
Aaronaught
@Aaronaught En el contexto de mi respuesta, no se trata de no creerte. A menudo, cuando creemos que hemos hecho todo, hay otra opción para probar, o si no, es valioso hacer que otros expresen algo con la esperanza de que pueda ser directamente relevante para usted, incluso si dice lo obvio. Puede ser que alguien más se encuentre en una situación similar, y esta respuesta puede aplicarse más estrechamente a ellos (para eso es también este sitio). Independientemente de que mi último párrafo siga siendo relevante, aunque ofreceré una pequeña edición además.
S.Robins
0

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).

gbjbaanb
fuente
Estaba preocupado por la primera parte de su respuesta [herramientas de abajo] pero cuando leí el resto, creo que esta es una buena manera de manejarlo.
jasonk
0

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 Biglan
fuente
-1

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.

alfa64
fuente