Considerações sobre a implementação de baixo código - Manual de especificações internas | Tecnologia de contagem | Grande Baía Guangdong-Hong Kong-Macau (GBA) - MiCount
Documentação interna - Leitura obrigatória

Notas sobre implementações de baixo código para a tecnologia de contagem

Código da equipa - Normas de qualidade - Prevenção de riscos - Satisfação do cliente

a qualidade em primeiro lugar
o cliente reina supremo
a tempo
Otimização contínua

Coisas que têm de ser feitas antes de um projeto poder começar (chave)

1Revisão dos contratos e das autorizações

Os seguintes elementos devem ser confirmados antes do início do projeto:

  • O cliente assinou um contrato formal com condições de pagamento claras (pagamento antecipado recebido)
  • A autorização da plataforma está em vigor (número de conta, palavra-passe, nível de permissão confirmado)
  • O âmbito do projeto foi definido (lista de caraterísticas, critérios de entrega, condições de aceitação)
  • Ciclo do projeto definido (calendário das etapas, programa de tratamento da extensão)
  • Foram designadas pessoas responsáveis (gestor de projeto, líder técnico, contraparte do cliente)

Proibições

A execução não pode ser iniciada sem um contrato assinado

Nenhum recurso de desenvolvimento pode ser investido até que os adiantamentos sejam recebidos.

Não se comprometer com o prazo de entrega sem clareza do âmbito

2Pesquisa e confirmação de requisitos

Deve ser efectuado um estudo aprofundado das necessidades:

  • Organização de reuniões de pesquisa de requisitos (pelo menos 3 partes envolvidas: empresa cliente, TI cliente, equipa de aritmética)
  • Documentação detalhada dos requisitos (descrições textuais + fluxogramas + diagramas de protótipos)
  • Identificar os principais pontos problemáticos (definição de prioridades: P0/P1/P2/P3)
  • Avaliação da viabilidade técnica (se as capacidades da plataforma são satisfeitas, se é necessária uma segunda unidade)
  • O cliente confirma os requisitos por escrito (confirmação por correio eletrónico/assinatura, evitar compromissos verbais)

Aviso de risco

⚠️ Requisitos pouco claros são a razão número um para o fracasso de um projeto

⚠️ Todas as alterações das necessidades devem passar por um processo formal (pedido escrito + avaliação + orçamento + confirmação)

3Seleção da tecnologia e conceção da arquitetura

A seleção da tecnologia deve ser considerada:

  • Se as capacidades da plataforma satisfazem os requisitos (funcionalidade, desempenho, concorrência)
  • Avaliação da magnitude dos dados (volume de dados estimado para 3 anos, tendo em conta a escalabilidade)
  • Identificação dos requisitos de integração (interface com sistemas existentes: ERP/CRM/OA, etc.)
  • Requisitos de conformidade de segurança (requisitos de equivalência, privacidade dos dados, registos de auditoria)
  • Opções de implementação (implementação em nuvem/privada/híbrida)

O que fazer e o que não fazer durante a execução do projeto (importante)

4Comunicação com o cliente e gestão de expectativas

Manter uma comunicação transparente e de alta frequência:

  • Relatórios de progresso semanais (e-mails/reuniões sobre o progresso, problemas, planos para a próxima semana)
  • Sincronização atempada dos riscos (riscos de extensão, dificuldades técnicas, falta de recursos)
  • Gerir as expectativas dos clientes (não prometer demasiado, não esconder os problemas)
  • Registar todas as comunicações (actas de reuniões, trocas de mensagens electrónicas, capturas de ecrã do Microsoft)
  • Processo de gestão de alterações (as alterações de requisitos devem ser objeto de aprovação formal)

5Qualidade e especificação do código

Garantir a manutenção do código:

  • Convenções de designação (designação uniforme de formulários, campos, processos, funções)
  • Especificação de anotação (a lógica principal deve ser anotada para manutenção posterior)
  • Reutilização de código (evitar a duplicação do desenvolvimento, encapsular componentes públicos)
  • Cobertura dos testes (funcionais, de limites, de stress)
  • Revisão do código (os módulos principais devem passar pela revisão pelos pares)

6Segurança e cópia de segurança dos dados

A segurança dos dados é o principal objetivo:

  • Controlo da autoridade (princípio do menor privilégio, revisão periódica da autoridade)
  • Cópia de segurança dos dados (diária, conservada durante pelo menos 30 dias)
  • Dessensibilização de dados sensíveis (não são utilizados dados de produção no ambiente de teste)
  • Registos de operações (registo de operações críticas para rastreabilidade)
  • Formação em segurança (a formação em segurança é obrigatória para os administradores de clientes)

estritamente proibido

Proibir a realização de testes diretos no ambiente de produção

Proibição da divulgação de dados dos clientes

Proibição de palavras-passe fracas (deve cumprir as regras relativas às palavras-passe fortes)

7otimização do desempenho

Concentrar-se no desempenho do sistema:

  • Otimização de consultas (evitar pesquisas em tabelas completas, criar índices)
  • Otimização do processo (redução de nós de aprovação desnecessários)
  • Otimização do front-end (redução do tempo de carregamento da página)
  • Teste de simultaneidade (simulação de cenários de pico de utilização)
  • Monitorizar alertas (configurar a monitorização do desempenho para detetar problemas a tempo)

Entrega do projeto e critérios de aceitação

8Formação e documentação do utilizador

A formação deve ser concluída antes da entrega:

  • Formação de administradores (configuração do sistema, gestão de direitos, manutenção de dados)
  • Formação do utilizador final (operações básicas, resolução de problemas comuns)
  • Preparação de materiais de formação (manuais de funcionamento, tutoriais em vídeo, FAQ)
  • Avaliação da eficácia da formação (avaliações, questionários)
  • Registos de formação arquivados (fichas de inscrição, fotografias de formação, resultados de avaliação)

9Preparação para a entrada em funcionamento e transição

Lista de controlo pré-lançamento:

  • Preparação do ambiente de produção (abertura de contas, configuração de permissões, inicialização de dados)
  • Validação da migração de dados (migração de dados históricos, verificações da integridade dos dados)
  • Teste de pressão de desempenho (simulação de cenários reais para garantir que o desempenho está de acordo com a norma)
  • Programa de cópia de segurança (cópia de segurança dos dados, programa de reversão)
  • Plano de resposta a emergências (processo de resolução de problemas, lista de contactos)

10Aceitação e entrega

Processo de aceitação formal:

  • Demonstração das funções (item por item de acordo com a lista do contrato)
  • Teste de aceitação pelo cliente (funcionamento efetivo pelo cliente para identificar problemas)
  • Retificação de problemas (registar a lista de problemas e rectificá-los dentro de um prazo)
  • Relatório de aceitação (relatório de aceitação escrito, assinado por ambas as partes)
  • Entrega de produtos (código fonte, documentação, contas, materiais de formação)

Serviço pós-venda e otimização contínua

11Compromisso de tempo de resposta

A resposta é classificada de acordo com a urgência do problema:

  • Nível P0 (falha do sistema): resposta em 15 minutos, resolução em 2 horas
  • Nível P1 (falha na função principal): resposta em 30 minutos, resolução em 4 horas
  • Nível P2 (problemas de funcionalidade geral): resposta no prazo de 2 horas, resolução no prazo de 1 dia útil
  • Nível P3 (recomendação de otimização): resposta no prazo de 1 dia útil, programada para tratamento adequado

12Inspecções regulares e otimização

Serviços proactivos para prevenir problemas:

  • Verificações mensais de saúde (monitorização do desempenho, análise de registos, revisão de permissões)
  • Propostas de otimização trimestrais (otimização em função da utilização)
  • Planeamento anual de actualizações (actualizações da versão da plataforma, melhorias de funcionalidade)
  • Inquéritos de satisfação dos utilizadores (recolha regular de feedback dos clientes)

13Deposição e reutilização de conhecimentos

Arquivo de experiências de projectos:

  • Relatório de síntese do projeto (êxitos, dificuldades, recomendações de melhoria)
  • Documentação da solução técnica (conceção da arquitetura, código de base, resolução de dificuldades)
  • Deposição de biblioteca de componentes (extração de componentes genéricos para reutilização em projectos subsequentes)
  • Partilha de boas práticas (formação da equipa interna, actualizações da base de dados de conhecimentos)

lembrete final

Qualidade em primeiro lugar É melhor ir devagar do que garantir a qualidade
O cliente em primeiro lugar Ponha-se no lugar do cliente
Trabalho de equipa Pedir ajuda quando se tem um problema, não o fazer sozinho
Aprendizagem contínua Concentrar-se nas novas funcionalidades da plataforma para melhorar as competências técnicas
Proibição de autorizações não autorizadas As necessidades fora do âmbito devem ser escaladas para avaliação

© 2015-2035 Shanghai MiCount Tecnologia da Informação Ltd | ICP License No. 16007722-8