Implementando grandes mudanças no sistema [fechado]

Question

Se você conhece a frase “construa um para jogar fora”, bem, parece que já fizemos isso;estamos atingindo os limites da versão 1 do nosso aplicativo online.É hora de limpar as coisas:

• Reorganizando código e UI
• Unificando processos de UI
• Adicionando mais funcionalidades
• Construindo para o futuro
• Modificando nossa estrutura de banco de dados para lidar com todos os itens acima

Qual é a melhor maneira de fazer essa transição acontecer?

Queremos evitar lançar todos os nossos usuários para um novo sistema (depois que estiver concluído) ...eles surtariam e não conseguiríamos lidar com a carga de chamadas.Nossos usuários abrangem toda a gama, desde tipos de software tecnicamente proficientes, usados ​​para escrever, até aqueles que não sabem o que é HTML.

Deveríamos iniciar uma nova "instalação" do nosso sistema e mover os usuários para ele gradualmente depois de garantirmos que esse novo design resolva suficientemente os problemas da versão 1?

Deveríamos (de alguma forma) mudar cada módulo do nosso sistema de forma incremental e faseada?Isso pode ser difícil porque o layout do banco de dados mudará, resultando na necessidade de ajustar o "código principal" e o código de vários módulos adjacentes.

É comum ter um conjunto de clientes "testadores beta" confiáveis ​​e pacientes usando uma versão de ponta de um aplicativo?(O objetivo aqui seria obter feedback e testar bugs em um novo sistema)

Algum outro conselho?Experiência em primeira mão?

Answer 1

A resposta, receio, é que depende.Depende do tipo de aplicativo e do tipo de usuários que você possui.Sem saber o que é o sistema e o alcance das mudanças na versão, fica difícil oferecer uma resposta.

Dito isto, existem algumas regras práticas.

Em primeiro lugar, evite o lançamento do big bang.Qualquer lançamento de um sistema terá problemas.A indústria está repleta de projetos em que as pessoas pensaram que o lançamento bang-bang era uma ótima ideia, apenas para que problemas iniciais fizessem o lançamento cair de joelhos. Cuil foi uma causalidade recente e de alto perfil do lançamento do big bang.

Para tornar os problemas iniciais administráveis, você precisa trabalhar inicialmente com um pequeno número de usuários e, em seguida, aumentar lentamente o número de usuários.

Em segundo lugar, o que você absolutamente deve fazer é coloque o usuário em primeiro lugar.O usuário deve realizar o mínimo de trabalho possível para usar a V2 do sistema.A quantidade ideal de trabalho seria zero.

Isso significa que se você optar por migrar lentamente os usuários de um sistema para outro, você são responsáveis ​​por garantir que todos os seus dados e configurações sejam migrados.Por exemplo, não faça nada estúpido como dizer ao usuário que ele deve usar V1 para todos os registros antes de 09/12/2008 e V2 para todos os registros depois.

O objetivo do lançamento da V2 deveria ser facilitar a vida dos usuários, e não torná-la desnecessariamente mais difícil.

Em terceiro lugar, tenha um programa beta.Isto se aplica até mesmo a aplicativos de intranet.O desenvolvimento de uma aplicação é muito parecido com o método de Newton-Raphson para encontrar a raiz de um polinômio.Você adivinha o que o usuário deseja, entrega ao usuário, o usuário fornece feedback e, lenta mas seguramente, cada iteração o leva mais perto da solução para o problema.

Um programa beta irá ajudá-lo a encontrar a raiz muito mais rápido do que apenas impingir novas versões às pessoas sem tempo para que comentem sobre as mudanças.Os betas ajudam a envolver seus usuários mais cedo e fazem com que eles se sintam incluídos no processo;cuja importância não posso enfatizar o suficiente.

Answer 2

Acabamos de implementar um novo sistema de CRM para nossos usuários e deixe-me dizer que foi uma péssima ideia fazer dessa forma:Foi extremamente doloroso para minha equipe e para nossos clientes.

Eu usaria todos os meios possíveis para fazer lançamentos graduais, mesmo que isso significasse trabalhar mais.Você ficará grato porque não terá que passar por esforços heróicos para movimentar tudo, e seus clientes apreciarão a capacidade de serem apresentados ao produto um pouco de cada vez.

Espero que ajude!

Answer 3

Eu concordo com Estevão que liberações graduais são melhores.É como reformar uma casa:acabar com isso parece uma boa ideia inicialmente.Mas significa que você tem que planejar tudo com antecedência, contratar vários empreiteiros e sair.Então algo muda no plano ou um empreiteiro desaparece, e todo o tempo que você esperava economizar acabou.Enquanto isso, a mudança gradual dá a todos a oportunidade de parar e pensar entre as etapas.Às vezes, você pode evitar alterações posteriores quando as alterações anteriores funcionarem melhor do que o planejado.

Eu trabalho em um sistema que teve um enorme problema de dimensionamento.Fizemos uma lista de todas as mudanças que achamos necessárias e as priorizamos por impacto provável.Então começamos a fazer uma mudança de cada vez.Na metade da lista, descobrimos que havíamos resolvido o problema de escala.Ainda tenho a lista, mas talvez nunca precise terminá-la.Estou livre para adicionar recursos e resolver outros problemas.

Claro, há momentos em que é melhor segurar a bala e destruir tudo.Mas isso é muito menos comum do que as pessoas tendem a acreditar.E para sistemas operacionais críticos, a decisão de “desmontar” pode ser fatal.Vejamos os grandes projetos governamentais que todos concordam que devem ser trazidos para a era da computação moderna, mas não podem fazê-lo porque alguns serviços vitais serão perdidos.Se a filosofia fosse uma mudança gradual, talvez eles tivessem sido modernizados peça por vez.

Answer 4

Parece rearquitetura incremental deve ser sua frase de efeito ágil preferida.

Nunca fiz isso em um aplicativo da web, mas passei por algumas mudanças bastante radicais no aplicativo cliente que foram feitas de forma incremental.Se você investir um pouco de tempo antecipadamente para garantir que as peças do trabalho sejam sequenciadas de maneira bastante sensata, isso pode funcionar bem.Um pequeno investimento em bons recursos de refatoração será muito útil se você ainda não os tiver.Posso recomendar pessoalmente jetBrains Resharper se você estiver usando .NET e baseado em Java, acredito que o IntelliJ IDEA inclui funcionalidade semelhante.