Como posso defender um cronograma de lançamento semi-estrito em um ambiente avesso a riscos?

Recentemente, tenho sido cada vez mais atormentado pelo que eu teria que descrever como uma das minhas experiências mais frustrantes e de matar a moral nesta profissão: ter que me sentar em um lançamento que foi testado, re-testado, encenado e para todos os efeitos. e finalidades está pronto para enviar / implantar .

Como um cara versátil em soluções e não apenas um codificador hardcore, eu compreendo e até advoguei a necessidade de um controle de alterações adequado. Ultimamente, no entanto, o tênue equilíbrio entre cobrir nossas bases e enviar a tempo foi desequilibrado, e tive pouco ou nenhum sucesso em restaurá-lo para algo sadio.

Estou procurando argumentos convincentes para ajudar a convencer o gerenciamento avesso a riscos de que:

1. A equipe de desenvolvimento deve (ou deve) ser capaz de definir seu próprio cronograma de lançamento - dentro do razoável, é claro (1-3 meses devem ser conservadores o suficiente para todas, exceto as maiores empresas da Fortune 500);

2. As liberações de software são marcos importantes e não devem ser tratadas com prudência; em outras palavras, atrasos / paradas desnecessárias são altamente perturbadores e devem ser considerados apenas como último recurso para algum problema crítico dos negócios; e

3. Entidades externas (que não são de desenvolvimento / que não são de TI) que desejam (ou demandam) envolver-se como partes interessadas têm a responsabilidade de cooperar com a equipe de desenvolvimento para cumprir o cronograma de lançamento, especialmente na última semana antes da expedição planejada data (ou seja, teste / preparação do usuário).

As afirmações acima são verdadeiras para mim, com base na experiência, mas parece que agora estou na posição de provar isso - por isso estou pedindo algo um pouco mais corpulento aqui, se isso existe.

Alguém que teve que "vender" a idéia de um ciclo de liberação fixo (ou talvez semi-flexível) para o gerenciamento pode dar algumas dicas sobre quais argumentos / estratégias são eficazes ou persuasivas e o que não é? Além da contenção óbvia do cronograma e dos custos irrecuperáveis, existem dados / evidências concretas que seriam úteis para afirmar que a remessa é realmente importante, mesmo em um ambiente "corporativo"?

Como alternativa, estou aberto a ouvir argumentos construtivos sobre por que a flexibilidade do cronograma (mesmo durante um período de semanas / meses) é mais importante do que o envio dentro do cronograma; é difícil para mim acreditar agora, mas talvez eles saibam algo que eu não sei.

_{Observe que fizemos lançamentos, e isso passou por todas as etapas, exceto pela produção. Os problemas são rastreados usando um rastreador de erros comercial e todos os problemas - 100% deles - atribuídos a esta versão foram encerrados. Percebo que é difícil de acreditar e esse é exatamente o ponto - não faz sentido que um lançamento 100% completo, com recursos completos, totalmente testado e aprovado pelas partes interessadas seja atrasado pela gerência por razões inexplicáveis, mas foi o que aconteceu, é isso que está acontecendo, esse é o problema a ser resolvido.}

Joel Spolsky diz que uma equipe de desenvolvimento de software é um esquema para converter capital (dinheiro) em software funcional. Honestamente, a partir da sua pergunta, parece que sua equipe é boa nisso: você está obtendo software decente por quantias razoáveis ​​de dinheiro investido.

Agora, é claro, o próximo passo é colocar o software em serviço. Até que sua empresa decida fazer isso, não há como obter um retorno sobre seu investimento de capital. O software na prateleira, pronto para implantar, é como um inventário no depósito: os custos são baixos, o capital da empresa já é gasto. Há também um custo de oportunidade: seu grupo optou por fazer esse projeto em vez de outra coisa.

Além do mais, o valor do software recém-desenvolvido na prateleira é como o valor de uma caixa de queijo na geladeira de um restaurante: apodrece lentamente. Seu valor diminui porque seus concorrentes o alcançam. Ele também diminui porque fica mais difícil e arriscado colocar novos softwares em serviço à medida que seus desenvolvedores passam para outras coisas. Depois de alguns anos na prateleira, pode ser inútil. Nesse caso, sua empresa optou por descartar o capital investido no desenvolvimento. É possível que os proprietários da empresa - os acionistas - fiquem descontentes com isso.

Há uma coisa que você, como desenvolvedor, deve descobrir. Seu software está realmente pronto para implantar no final do ciclo de lançamento que você está propondo? Está pronto para começar, ou há muito mais trabalho a fazer e dinheiro para gastar enquanto a sua empresa o coloca em produção? Sua empresa possui os servidores e licenças de software que você precisa para lançar seu software? Seu produto de trabalho inclui um plano de implantação? Os usuários finais foram treinados? Os dados de produção foram convertidos? Se o seu novo software envolve uma alteração na maneira como sua empresa faz negócios, ela está pronta para fazer essa alteração? Você já elaborou um esquema para executar as coisas em paralelo, para garantir que as coisas novas funcionem tão bem quanto as coisas antigas?

Todos esses custos de implantação podem facilmente diminuir o custo de apenas desenvolver o software. Uma equipe sábia de gerenciamento de projetos faz o possível para planejar, orçar e agendar todas essas coisas. Você já fez esse trabalho? Você deixou claro para a gerência? Caso contrário, é aconselhável que eles sejam lentos em seus lançamentos.

É possível que um cronograma moderno de lançamento de software ágil esteja fora de sincronia com o ritmo de mudança que o restante da sua empresa espera. Seus usuários finais - seus stakeholders - talvez não consigam absorver as mudanças na taxa que sua equipe pode produzi-las.

Também é possível que sua equipe de gerenciamento esteja disfuncional. Sua equipe desenvolveu algo que o resto da empresa não deseja? Suas novas coisas ameaçam a sua equipe de vendas ou produção? Nesse caso, algum executivo pode estar torpedeando dizendo que é muito arriscado sair. Não há nada que você possa fazer sobre isso, a menos que você seja o CEO.

Você solicitou argumentos convincentes para lançamentos oportunos de software. Há um argumento realmente convincente: retorno do investimento. A empresa optou por investir nesse software e agora está optando por desperdiçar o investimento, à medida que o software apodrece lentamente na prateleira.

Um argumento secundário para lançamentos oportunos é o moral de sua equipe. Apressar-se e esperar não é uma boa maneira de motivar desenvolvedores criativos a fazer um bom trabalho. Você pode perder sua equipe se eles não tiverem a satisfação de ver o trabalho deles entrar em serviço.

Primeiro, assista a este vídeo:

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

Sumário executivo:

A maneira como você envia dentro do prazo e do orçamento é a seguinte: quando o tempo está acabando ou o dinheiro acaba, você envia. É isso aí.

A razão pela qual a maioria dos projetos não é entregue pontualmente é porque alguém vem com "apenas mais um recurso ou correção" para inserir no release, imediatamente antes de você estar pronto para o envio, em um momento do ciclo de desenvolvimento em que seus recursos estão disponíveis. mais escasso, e agora você tem que lutar. Isso se chama thrashing, e acontece porque, desde que você não envie, não precisará se preocupar com as pessoas dizendo que seu produto é péssimo.

A maneira como você cura o thrashing é forçando as pessoas a fazê-lo no início do ciclo de desenvolvimento do produto , não no final.

Fazer alterações no produto nas semanas imediatamente anteriores à data de lançamento é muito perturbador, por razões óbvias. Isso é verdade se a alteração é um novo recurso, uma alteração no processo de desenvolvimento de software ou uma tentativa de corrigir um bug de longa data que não está no cronograma de desenvolvimento.

Quando alguém vem a mim para uma correção ou alteração no final do ciclo de desenvolvimento, sempre pergunto a eles: "O que você quer que eu não faça para que eu possa fazer o que você faz?"

Se você precisa de um motivador financeiro, é o seguinte: os estudos comprovam que, quanto mais tarde você espera no ciclo de vida do software para implementar um recurso ou correção, mais caro ele é. Exponencialmente. Não é difícil provar isso.

Você descreveu claramente os problemas que enfrenta, no entanto, não sei ao certo por que os gerentes estão se comportando dessa maneira. Você pode esclarecer? Por exemplo, você acredita que está pronto para implantar. Alguém discorda? Se sim, quem e por quê? Eles são ex-beaurocratas do governo

Isso parece muito com um problema de alinhamento de capacidade versus desejo, você tem o desejo de liberar, mas não a capacidade (autoridade), aqueles com autoridade não têm o desejo.

Você precisa descobrir por que eles não têm esse desejo - é uma razão de marketing (mantenha-a por mais um ano, enquanto ordenhamos a versão antiga por um pouco mais), é medo / confiança (se houver bugs, isso nos fará parecer ruins) , custam-nos dinheiro ..., falta de recursos (não pode arcar com o custo de remessa / embalagem / material de relações públicas), é comercial onde alguns obscuros afundam em lucros excessivos baixos e eles não querem que você ganhe dinheiro ( Não é tão bobo quanto parece).

Eu também suspeito que haja pouco respeito entre as partes envolvidas, portanto, discussões razoáveis ​​com adultos não estão ocorrendo.

Desculpe - não é a resposta específica que você pediu, mas espero algumas coisas para pensar.

A primeira coisa a considerar é garantir que seus lançamentos não sejam de alto risco .

Idealmente, suas solicitações de mudança devem ter a seção chamada Mitigação de Risco , contendo instruções sobre como reverter para a versão anterior, se algo der errado. Em termos de risco, nenhuma quantidade de testes anteriores pode substituir uma opção simples para reverter a alteração.

• ^{Em ambiente avesso a riscos, não consigo imaginar uma maneira de tornar indevidas alterações irreversíveis .
  Se muitos / a maioria de seus lançamentos se enquadram nessa categoria, convém reconsiderar sua arquitetura.}

O risco de NÃO ser liberado deve ser exposto, se você quiser que o cronograma da equipe do desenvolvedor seja tratado com seriedade.

Se seus lançamentos fornecerem correções para problemas de produção / suporte e interrupções, isso é bastante fácil, basta listá-las e apontar que a produção corre o risco de repeti-las, a menos que seja atualizada.

Uma medida realmente eficaz disponível para a equipe de desenvolvimento lutar contra desvios de versão para garantir que o risco de não liberar aumente ao longo do tempo . Isso pode ser alcançado com versões internas em execução em horário fixo, fornecendo uma lista "cumulativa" de soluções para problemas de produção.

• Em termos simples, os caras que bloqueiam sua liberação XXprecisam estar cientes não apenas de que eles correm o risco de ter Ntipos de problemas de produção como não resolvidos, mas também que, semana (ou mês) depois, eles terão liberação XX+1na fila de aprovação, bloqueando o que correm o risco de que N+Mtipos de problemas de produção permaneçam não resolvidos - e esse também será o caso de XX+2outros lançamentos "internos" fornecidos pela equipe de desenvolvimento.

A maneira descrita acima essencialmente torna a conexão mais rígida e explícita entre as atualizações do aplicativo e os problemas de produção.

Por isso, você pode esperar um envolvimento maior nas escalações dos problemas de produção . Você pode usá-las como uma oportunidade para promover sua visão de atualizações agendadas mais rigorosas. Você mesmo pode acionar algumas escalações para acelerar o processo de adoção da abordagem desejada.

• ^{"... recomendamos considerar a atualização do aplicativo para uma versão mais recente ( XXou posterior). A que está atualmente implantada no seu ambiente ( XX-2) está seriamente desatualizada - duas versões principais por trás da atual base de código. Como resultado, os detalhes de falhas simples são: profundamente oculto nos logs e lixo indecifrável é relatado pelo aplicativo aos clientes, em vez de descrições claras de falhas - fazendo com que os usuários e o suporte percam tempo investigando problemas realmente simples "
   
  Acima está um comentário que eu adicionei há algum tempo no rastreador de problemas de suporte do ticket relacionado a um incidente de produção específico. Logo depois, as "partes interessadas" entraram em contato com a equipe de desenvolvimento perguntando como acompanhar nossos lançamentos e como eles podem ajudar na implantação em seu ambiente. Ah, e eles também atualizaram rapidamente deXX-2versão também. :)}

Quando a escalada da produção acontece, é melhor você estar preparado para apresentar sua visão de maneira rápida e clara.

Uma coisa que você achará útil é escolher quem é responsável por uma derrapagem específica da versão. Basicamente, você precisa ser capaz de responder rápida e claramente a perguntas como "quem é responsável pelo fato de a liberação planejada não ter acontecido?" Se você não estiver pronto, eles podem escolher o caminho de menor resistência e colocar a culpa em você. Como apontado nos comentários para outra resposta , "Você pode entrar em água quente da qual sua gerência está tentando protegê-lo".

Por último, mas não menos importante,

vai levar tempo

(você provavelmente já sabe disso, mas parece que vale a pena declarar explicitamente)

O que você procura pode ser descrito como mudança de atitude, de "é arriscado liberar " a "é arriscado NÃO liberar ". As mudanças de atitude raramente acontecem da noite para o dia, pode ser necessária paciência para concluir a mudança.

Há um grande ponto de interrogação pairando sobre sua pergunta e é por isso que sua empresa não deseja lançar o software. Nem sempre é apenas um caso simples de aversão ao risco. Freqüentemente, existem outras causas subjacentes que nem sempre são transmitidas das alturas gerenciais. Então, minha pergunta para você é: "Você se sentou com seu chefe e perguntou por que o lançamento do produto está sendo realizado?".

Há uma grande diferença entre gerenciar riscos e evitá-los. Pode haver razões legais ou de marketing para atrasar o lançamento de um produto. Pode haver problemas de confiança entre o gerenciamento e a equipe de desenvolvimento. O produto pode não atender às necessidades do cliente, mesmo que seja exatamente o que o cliente solicitou meses atrás. Pode até ser um caso de alguém na gerência que está tentando esconder a culpa por atrasos em outro lugar, ou até mesmo um atraso de terceiros que é necessário para concluir algo antes que o produto seja enviado. Eu poderia criar dezenas de cenários. Muitas vezes, o desenvolvedor assume aversão ao risco sem entender o outro lado da equação que não ficou aparente. Por outro lado, pode ser simplesmente complacência, conflito entre indivíduos dentro de uma empresa,

Em todos os casos, é importante ter mais informações sobre os motivos dos atrasos na liberação do produto e usá-las para criar um caso de liberação do produto o mais rápido possível. Sim, pode ser muito frustrante, mas existem outras maneiras de lidar com essas situações sem arriscar um confronto com seus chefes ou um esgotamento. Em situações semelhantes, eu próprio coletei informações, documentei qualquer progresso que fiz e, se piorou, simplesmente arquivei o projeto e passei para outra coisa. Onde eu pude colocar um projeto de volta aos trilhos para o lançamento geralmente é o resultado de apresentar um caso comercial sólido com base nas informações que recebi como feedback para as perguntas que levantei. Onde não consegui convencer a gerência de que o produto deve ser enviado, Eu documentei a relutância em enviar como sendo simplesmente um caso de projeto concluído e aguardando a aprovação da liberação pela gerência. Então, asseguro-me de que meu gerente assine meu documento como aceito e entendido pela gerência, para que minha bunda seja coberta, se eles tentarem me culpar mais tarde por uma não liberação.

Você sempre precisa pontilhar seus 's' e cruzar 'T's' para evitar que os atrasos na remessa sejam atribuídos a você mais tarde (não importa o quão injusto), e também é importante evitar ficar muito emocionalmente vinculado a esses problemas, a menos que você goste da ideia de uma úlcera bem merecida. Olhando para a sua própria situação com um certo desapego profissional, você pode encontrar uma solução porque se colocou efetivamente a uma "distância" maior do problema. Se você não pode argumentar, pode ser necessário deixá-lo escapar por um tempo, mas, para argumentar em primeiro lugar, você precisa parecer profissionalmente desapegado e ter argumentos baseados em informações intimamente ligadas a sua empresa e seu funcionamento interno.

Outra coisa que eu pensei sobre o que pode ser de alguma ajuda para você talvez seja ler o Lean Software Development e ver se há algo valioso que possa estar relacionado à situação da sua empresa, principalmente nos primeiros capítulos. Eu acho que foi o capítulo 4 que discute a questão de entregar o mais rápido possível e tem algo relacionado a atrasos nos custos.

Eu diria que a maneira mais fácil / eficaz de vender um release é reduzir as ferramentas por um tempo, quando estiver pronto. Faça outra coisa, inicie um novo projeto, trabalhe nos bugs do projeto existente. Não faça mais nada até que seja enviado pela porta - afinal, por que se preocupar em fazê-lo se não for quando estiver pronto?

mas, no mundo real, a versão real é um problema de outra pessoa; você deve enviá-la para ela e tratá-la como uma versão. Uma vez fora da sua porta, é enviado. Se eles apenas se sentarem, não é problema seu (de fato, é ótimo, nenhum bug é relatado! W00t! Bônus por uma liberação sem erros durante toda a rodada;))

Portanto, você precisa de um sistema de controle de alterações e de um gerente de versão. Então tudo é fácil (exceto que você precisa gerenciar o controle de alterações, portanto, o controle de origem e as compilações de implantação são muito necessários. Requer organização, mas se você estiver organizado, é fácil).

Não consigo imaginar que colocar a equipe de desenvolvimento no comando dos negócios da maneira que você descreve seja uma "coisa boa". Isso pode mascarar o problema real, mas, a menos que a equipe de desenvolvimento esteja na posição correta para avaliar os insumos das vendas, marketing , etc. etc. corre o risco de ser liberado pelos motivos errados (e potencialmente ruins).

Se eu entendi o seu problema, você concluiu o projeto e tem um produto que não pode mostrar a ninguém fora da sua empresa. (Espero que isso resuma, li todo o tópico e estou tendo problemas para colocar o dedo nele)

Você tentou:

1. Pedir à gerência que um cliente ou conjunto de clientes atue como partes interessadas durante o desenvolvimento? Geralmente, você pode encontrar um cliente para fazer lançamentos intermediários e fornecer feedback. Eles podem ser grandes advogados quando for a hora de liberar. Mesmo uma "versão limitada" para um cliente pode ser suficiente para ajudar a influenciar o gerenciamento
2. Construindo um plano de liberação, incluindo liberações de pontos. Ou seja, você pode liberar o 3.4 hoje, porque o lançamento do 3.4.1 está planejado para hoje + 1 mês. Isso, juntamente com a boa idéia de que você já mencionou que uma cadência de liberação ajuda a esta mensagem.
3. Obtenha suporte, vendas ou marketing do seu lado. Crie correções que resolveriam as três principais solicitações de suporte e você poderá obter um aliado de outro departamento. Se você não conseguir obter uma parte interessada do cliente como no 1, tente com algumas pessoas de vendas. Ofereça-se disponível para reuniões de vendas e traga o produto. Quando estiver viajando, mostre ao vendedor que você está com o produto (em qualquer estado em que esteja) e faça com que eles o procurem.

Para responder à sua outra pergunta sobre "por que a gerência faria um release?" As empresas fazem isso o tempo todo em campos que não são SW e não acho que seja sem precedentes. Por exemplo, você tem uma nova versão pronta para ser testada e concluída. Mas a versão antiga ainda não foi substituída pela concorrência. Uma vez que a concorrência libera um produto concorrente para você, a versão antiga, o gerenciamento libera a versão aguardando na prateleira e perturba o mercado, retarda a concorrência e mantém as vendas e a reputação de líder de mercado. Liberar muito cedo dá uma mãozinha aos concorrentes que possam ter uma idéia melhor do seu roteiro e tentar derrotá-lo até o final do jogo.

Com tudo o que foi dito ... A Navalha de Hanlon é provavelmente a resposta certa :-)

Afaste-se dessa empresa, eles não entendem software. Mas, falando sério, software é o que faz o sistema funcionar, imagine se você estivesse fabricando carros, as fábricas de carros são lentas? eles esperam nos lançamentos dos carros? Eles são incrementais e burocráticos? Não, eles tentam fazer as coisas da maneira mais rápida e limpa possível. Você tem um problema de gerenciamento e deve trabalhar nisso como um conflito de gerenciamento, tente falar com eles nos termos deles. Pergunte o que o risco significa para eles e tente minimizá-lo. Os sentimentos de seus desenvolvedores também são importantes, pois devem lidar com as decisões que serão tomadas por sua intervenção. Eles ficarão felizes em fazer todas as noites chegarem a tempo? Quais seriam os prêmios / penalizações? Etc. Agora, darei a você uma abordagem prática para esse problema, um pouco extremo, mas solicite uma auditoria.