Como documentar uma estratégia para atualizar o software comercial?

Question

Não atualizamos nosso sistema operacional RDBMS ou servidor por quase uma década. Outro pacote de software de missão crítica está chegando há duas décadas e não é suportado por seu fornecedor há muito tempo. Alguns dos nossos gestores parecem pensar que isso é uma coisa boa - nós poupamos toneladas de dinheiro por não comprar as atualizações! Agora, uma peça crítica de software precisa de uma atualização, mas a nova versão não suportará o material de uma década. Agora, um punhado de pessoas está perdendo nossos cabelos tentando descobrir como atualizar tudo de uma só vez com tempo mínimo de inatividade.

Em um esforço para resolver isso, alguns de nós estão considerando a criação de um documento de plano estratégico de TI na esperança de que possamos adotá-lo como parte do plano estratégico geral da agência. Eu me ofereci para tentar montar a seção "Gerenciamento do Ciclo de Vida do Software" (ou algo parecido) para resolver o problema mencionado acima (com as pranchetas provavelmente em um documento separado do plano estratégico). Quase todos os fornecedores de software publicam ciclos de vida e planos de depreciação para seus produtos, e é bastante fácil determinar um "ponto ideal" para cada parte do software, considerando essas informações juntamente com as necessidades de nossa organização. A parte complicada (para mim de qualquer maneira) é colocar o plano de cada peça em algo mais coeso.

Como posso documentar que os clientes de desktop A, B, C ... são dependentes do OS X e RDBMS Y, que por sua vez dependem do SO do servidor Z, e aqui está como mantemos todos eles em seu pontos"? Deve haver livros por aí, mas todo o meu googling só me levou a coisas sobre as táticas de atualização de um único software, em vez da estratégia para determinar quando implementar essas táticas.

    

Answer 1

Parece que você está tentando resolver muitos problemas de uma só vez (e não parece uma boa ideia).

Pelo que eu li:

• SO e aplicativos desatualizados
• sem estratégia a longo prazo
• problemas ao documentar sua infraestrutura
• necessidade urgente de atualizar parte crítica da infraestrutura

Atualizando "peça crítica de software"

Sua infraestrutura está desatualizada devido à decisão de alguém é fácil de entender. Provavelmente pareceu uma boa ideia em algum momento no passado. Isso se resume ao que Michael Hampton escreveu em comentários: Para a gerência, você está falando de vantagens e desvantagens (riscos). Então, se a gerência está disposta a assumir um risco, então ok (seja qual for a sua opinião pessoal), e é responsabilidade deles a partir de agora. Mas alguém do pessoal de TI precisa dizer a eles quais são os riscos.

Então, a primeira coisa que eu gostaria de procurar é: Os gerentes sabiam sobre os riscos do software desatualizado? Eles foram informados?

Honestamente, eu sinto que você provavelmente não encontrará nada útil sobre isso, então eu não gastaria muito tempo com isso. É apenas algo que pode ajudá-lo ao longo das linhas de "estávamos lhe dizendo nos últimos cinco anos".

Eu simplesmente faria uma análise do que a atualização realmente significa. Prepare uma planilha simples com atividades e quanto tempo elas levarão (se você não sabe, dê a sua melhor estimativa e explique explicitamente que você não tem certeza). Mas lembre-se que essa "tarefa de atualização" não está bem especificada, é impossível fazer isso como fix-time / fix-price.

Fazer essas listas também ajudará você a detalhar todo o problema. A próxima coisa é criar um registro de riscos e uma lista de recursos que você precisa.

No final, você deve ter uma lista de atividades, lista de riscos, listar materiais / pessoas que você precisa. Em uma palavra, não lide com a atualização como um problema cotidiano, faça isso como um PROJETO. Isso permitirá que você tenha pelo menos algum controle sobre a necessidade aguda de sua empresa.

Se você tiver problemas com a análise de quais atividades precisam ser realizadas, você pode tentar um mapa mental (meu favorito é o xMind) e depois convertê-lo para um documento mais formal.

Note que quando você tem algumas opções de como fazer o upgrade, você deve dar aos seus gerentes um writeup de possíveis soluções (se houver mais), resumidas em poucas frases, incluindo custo, resultado e risco; idealmente mencionar a opção que você recomenda e por quê. Porque a escolha final é deles - afinal, eles são gerentes.

Talvez neste caso específico: Mencione que a atualização pode não ser possível.

Sem estratégia a longo prazo

A criação de um plano estratégico não o ajudará agora. Isso não ajudará em nada se for um documento fabricado dentro do seu departamento de TI. O plano estratégico é algo que precisa estar ligado às necessidades do negócio.

Exemplo de necessidade comercial: em dois anos, estaremos abrindo novos escritórios na China e na Austrália.

Tarefas de TI derivadas: Esteja preparado para fazer com que os novos funcionários sofram as conseqüências, crie infra-estrutura em escritórios estrangeiros, forneça treinamento para novos funcionários (possivelmente usando seu idioma nativo), forneça conectividade segura ...

Se as coisas correrem bem, você pode ter uma estratégia, talvez ... daqui a alguns meses? Então, cerca de meio ano até que tudo seja acordado?

Manter e documentar sua infraestrutura

Isto é herança do passado e agora você tem que mudar as coisas. Prioritizar. Faça uma lista de coisas que você quer / precisa fazer agora para atualizar a maioria das coisas. Escolha o que pode esperar, faça um roteiro grosseiro. (Este roteiro deve fazer parte de sua estratégia de TI quando você tiver um.)

Se você está atualizando algo que correu bem, lide com isso diariamente. Se você está lidando com algo que pode dar errado (é "grande" em termos de tempo gasto, pessoas alocadas, etc.), lide com isso como um projeto.

Existem ferramentas que podem ajudá-lo com dependências de documentação e serviços - CMDBs (iTop, por exemplo). Mas fazê-lo funcionar pode levar algum tempo e você ainda precisa de alguma ferramenta de documentação. A melhor ideia é configurar um wiki para a documentação onde todos podem começar a documentar / fazer anotações a partir de agora. Você pode configurar um wiki em meia hora, então é uma maneira muito eficaz de começar as coisas.

Nota pessoal: A atualização do sistema operacional antigo seria enorme, sem mencionar a documentação (provavelmente ruim / ausente). Não é mais fácil instalar servidores novamente, migrar aplicativos e documentar tudo desde o início?