Meu nome é Alexandra Kamzeeva, trabalho como analista de sistemas há 9 anos, dos quais 3,5 anos na Lamoda. Eu leio muito, analiso a documentação atual e crio uma nova. No meu trabalho, sempre estruturo as informações e as torno o mais convenientes possível.
Os prós de uma boa descrição de sistema são:
- ajuda a encontrar as informações de que você precisa com mais rapidez e facilidade do que em uma descrição não estruturada;
- reduz o risco de falha do projeto;
- torna mais fácil a integração dos funcionários.
Fizemos um modelo para essa descrição que qualquer equipe pode usar. Neste artigo, contarei a você com exemplos o que nos levou a criar um modelo de descrição do sistema, a história de sua criação e como ele é usado agora no Lamoda.
O que é um modelo e por que ele é necessário
Primeiro, descreverei minha compreensão do padrão. Vamos fingir que preciso encontrar um carro pequeno em uma sala desarrumada. Não é um fato que eu possa lidar com isso. Mas posso acidentalmente pisar na peça Lego.
Agora vamos imaginar que todos os brinquedos são colocados em seus lugares e classificados. Posso ver com antecedência em que box estão todos os carros, vou encontrar o que preciso mais rápido, mais fácil e não vou perder os nervos com isso.
Da mesma forma com a documentação. Um modelo é tal ordem. Fizemos uma estrutura para descrever um sistema que qualquer equipe pode usar.
Em que condições trabalhamos com documentação
Lamoda tem mais de 100 sistemas que automatizam a entrega de pedidos, contact center, armazém, estúdio fotográfico e outros processos operacionais e de negócios. Mais de 300 engenheiros estão envolvidos no desenvolvimento e suporte. Qualquer um deles pode precisar de uma descrição de qualquer um desses 100 sistemas.
Cada equipe descreve independentemente seu sistema em um espaço separado no Confluence. O responsável técnico está necessariamente envolvido na documentação, pois é obrigado a registrar as informações. Além disso, o sistema é descrito por testadores e desenvolvedores ativos que lamentam apenas por perder o conhecimento. E, claro, analistas, já que a documentação é uma de nossas principais ferramentas.
Pode parecer que essa liberdade leva ao caos. Mas não é assim, porque temos uma cultura empresarial: uma atitude responsável em relação à documentação, compartilhamento aberto de conhecimento, o hábito de registrar artefatos de projeto e sistema. Essa tradição se desenvolveu em parte devido a projetos malsucedidos. Os incidentes provaram para as equipes de desenvolvimento a importância de documentar os processos e a funcionalidade do sistema.
A seguir, contarei alguns casos em que a documentação confusa ou a falta dela gerou problemas.
Basta adicionar dois botões
O primeiro problema que nos levou a criar um modelo - não tínhamos uma descrição de alguns sistemas, o que levou a falhas e melhorias.
Tínhamos um projeto de Self Order Management (SOM). Decidimos adicionar dois botões à conta pessoal do cliente: "Transferência da data de entrega" e "Cancelar encomenda". Antes disso, o cliente só podia cancelar ou reagendar um pedido ligando para o contact center. É claro que alguns compradores não tiveram tempo ou desejo de se comunicar com a operadora. Com isso, o representante de vendas poderia trazer um pedido desnecessário ou não encontrar o cliente em casa. Nesses casos, Lamoda assume os custos. O projeto era necessário e importante.
Parece adicionar dois botões! Na verdade, havia muita lógica por trás deles nos quatro sistemas. A mudança da ordem passa pelo sistema de processamento - um enorme monólito onde você pode tocar em algo em um lugar e atirar em outro. Infelizmente, as sutilezas de seu trabalho não foram descritas na documentação, eles não prestaram atenção a isso durante a concepção do projeto. Após o lançamento, os botões não funcionaram como esperado e foi revertido. Como resultado, em vez de dois homens-mês, esse projeto levou seis meses.
Obviamente, obtivemos esse resultado não apenas pela falta de documentação. Mas se tivéssemos uma descrição clara dos processos de cancelamento e transferência de um pedido, talvez o resultado fosse diferente.
Integração complexa
O segundo problema que nos levou a criar um modelo é a complexidade da integração. Vim trabalhar para a equipe do sistema de processamento de pedidos. Para imersão, li a documentação no espaço do sistema e em três seções encontrei três descrições diferentes da essência principal do nosso sistema - o status do pedido.
Nesse caso, não funcionou para tornar a integração mais fácil. Essa documentação não ajudou a transferir conhecimento para colegas que não haviam encontrado nosso sistema anteriormente.
Problema de quadro em branco
O terceiro pré-requisito para a criação do modelo é o problema da tela em branco. Para cada novo sistema, o líder de tecnologia deve criar o espaço apropriado do zero. O líder técnico pensa sobre quais seções criar. Antes de criar o modelo, o funcionário estudou outros espaços e olhou quais seções são usadas e serão úteis para seu sistema. Isso costumava levar muito tempo.
Como criamos o modelo e o que aconteceu
Todas as semanas, analistas de sistema fazem um stand-up e discutem questões que são encontradas em projetos e não apenas. E mais de uma vez os colegas reclamaram da dificuldade de encontrar informações e entender os espaços dos diversos sistemas. Visto que queimamos constantemente por causa disso, decidimos tomar em nossas mãos a descrição dos sistemas aos quais estamos apegados. E então ficará claro o que fazer.
Primeiro, identificamos os atributos de um bom modelo:
- .
- . , , . , . .
- . , , , .
- .
Em seguida, analisamos a descrição atual de vários sistemas e identificamos seções comuns:
Na seção de projetos e recursos, havia especificações para o desenvolvimento de projetos. As seções Desenvolvimento e QA continham informações específicas para desenvolvimento e testadores. Na seção de incidentes, foram descritos os incidentes ocorridos no sistema e suas soluções.
Compartilhamos a ideia de um modelo com outros colegas em reuniões informais (almoços na cozinha, stand-ups, vizinhos de equipe com quem você conversa periodicamente) e criamos um grupo de trabalho de voluntários. Eles eram representantes de diferentes competências: dois gerentes, três líderes técnicos e dois testadores. Eles adicionaram as seguintes seções ao modelo:
Em seguida, testamos o modelo de descrição do sistema com colegas com ampla competência: chefes de departamentos de TI, líderes de tecnologia experientes e líderes de teste de grandes projetos de integração. Eles acabaram adicionando algumas seções mais úteis:
Verificar a qualidade do modelo
Verificamos o documento resultante em relação à nossa definição de um bom modelo em Lamoda:
- Ajuda você a encontrar as informações de que precisa com mais rapidez e facilidade. Temos uma estrutura conveniente: eu me movo ao longo da árvore e entendo o que está localizado e onde. Se precisar de informações sobre os processos do sistema (por exemplo, cancelar um pedido), vou para “Descrição dos principais processos”.
- As informações do sistema não são duplicadas devido à atomicidade das partições. Por exemplo, você pode descrever os imprimíveis em uma seção e, em seguida, consultá-los na seção “Descrição dos processos principais” para que as informações não se repitam.
- . Lamoda, . , -. — .
- . .
Fizemos um bom modelo para descrever os sistemas Lamoda. Espero que seja útil para outras empresas também. Quero destacar especialmente as três seções seguintes:
Descrição dos principais processos do sistema . Sim, parece óbvio que esta seção é necessária. Mas por alguma razão nem sempre existe, como foi o nosso caso com os botões de cancelamento e transferência de um pedido. Se tivéssemos descrito os processos de cancelamento e reprogramação com antecedência, o risco de falha do projeto seria reduzido.
Lista de verificação- uma seção que lembra o que há de mais importante no processo regular. Por exemplo, temos uma “Lista de verificação para conectar um novo método de pagamento” na descrição do sistema de gerenciamento de métodos de pagamento. Diz que devemos coordenar a adição ou alteração de um meio de pagamento com o departamento de contabilidade, com o contact center, com a entrega e com outras unidades de negócio.
Uma vez que esquecemos de informar o contact center sobre a mudança na forma de pagamento. E quando o cliente ligou para o nosso contact center e perguntou sobre isso, a operadora não pôde dizer nada. Isso gerou um conflito entre o contact center e a equipe de desenvolvimento responsável pelos métodos de pagamento. Após este incidente, criamos listas de verificação para lançamentos de projetos importantes, conectando novos parceiros, etc.
Página inicial do Space- uma seção com informações sobre por que este sistema é necessário, sobre a composição da equipe e as partes interessadas. Devemos coordenar as mudanças no sistema e os recursos de desenvolvimento com as partes interessadas. Portanto, é ótimo quando você pode obter essas informações apenas olhando para o Confluence.
Aí indicamos informações sobre a composição da equipe para entender quem entrar em contato em caso de dúvidas sobre o sistema. Também ajuda os iniciantes com a cabeça inchada. É ótimo quando um novo funcionário pode espionar com quem acabou de falar, quem é essa pessoa, qual é sua função e qual é o seu nome.
Como comecei a usar o modelo em meu sistema
- Em primeiro lugar, criei as seções necessárias do modelo sem preencher. Foi fácil e não demorou mais que 30 minutos.
- Então, o mais difícil foi: marcamos reuniões regulares com o líder técnico, nas quais começamos a analisar a documentação do nosso sistema. Na primeira reunião, dividimos as páginas atuais em três pilhas.
Enviamos tudo irrelevante e desnecessário para a primeira pilha. Excluímos essas páginas ou as enviamos para o arquivo.
A segunda pilha é necessária, mas irrelevante. Marcamos as páginas como irrelevantes, criamos uma tarefa no Jira e depois atualizamos essas informações de acordo com nosso backlog.
A terceira pilha é a mais simples. Quando tudo está claro, as seções são relevantes - nós apenas as movemos para o lugar certo.
Antes dessas reuniões, descrições de processos e arquitetura, notas de testadores e desenvolvedores e incidentes estavam espalhados por todo o espaço. Também não havia home page.
Em 6 horas de reuniões, obtivemos um excelente resultado. Do caos, formamos estrutura e ordem. Agora você pode descobrir onde encontrar descrições de processos, informações sobre a arquitetura e sobre incidentes. E o mais importante, agora temos uma página inicial. Aqui foi escrito porque um sistema de processamento de pedidos é necessário e quem é o seu stakeholder.
Nosso grande sistema está envolvido em quase todas as linhas de negócios. Mas antes não tínhamos nosso próprio stakeholder. Enquanto estávamos fazendo a página inicial, discutimos com o CTO com quem coordenar as mudanças no sistema. Assim, foi determinado um colega, que priorizou as melhorias. Agora parece um fato engraçado que a criação da página inicial levou ao surgimento de um stakeholder.
Como distribuímos o modelo
Resultados semelhantes sobre o uso do modelo foram recebidos por outros analistas que o implementaram em suas próprias direções. Assim, cobrimos a maioria dos sistemas que estão ativamente envolvidos em muitos projetos de integração.
Tínhamos equipes cujos sistemas costumavam estar envolvidos em projetos de integração, mas não havia descrição suficiente sobre eles. Normalmente havia necessidade de documentação, então não houve necessidade de vender a ideia.
Demonstramos experiência bem-sucedida na aplicação de modelos a líderes de tecnologia e gerentes de tais equipes. Algumas equipes, com base em nosso exemplo, organizaram sua documentação por conta própria, outras pediram ajuda aos analistas.
Feedback sobre o modelo
Nosso modelo não é uma descrição de sistema obrigatória ou obrigatória. Os colegas usam o modelo como base, se precisarem dele, e o editam de acordo com suas necessidades. Por exemplo, eles transferem trocas de subseção para seção se o sistema consistir principalmente deles.
Todos os nossos sistemas são diferentes na descrição, mas a estrutura geral e a lógica geral ainda são preservadas. Agora podemos encontrar mais facilmente informações sobre os processos em que o sistema consiste, sobre a arquitetura do sistema e assim por diante.
Na Lamoda, gostamos de compartilhar conhecimento. Temos grandes projetos de integração que motivam isso. Enviamos links para descrições atualizadas dos sistemas, e os colegas recebem as informações necessárias sem perguntas adicionais aos líderes de tecnologia já carregados.
2 anos depois de criar o modelo, entrevistei colegas e recebi um bom feedback da maioria. Eles usam o template, editando a estrutura a seu gosto.
Mas também existem pessoas que pensam que não precisamos de documentação e um modelo. Basicamente, esse é o raciocínio das equipes daqueles sistemas em que já não há necessidade urgente de documentar algo.
Eles trabalham em sistemas que dificilmente mudam: não há projetos de integração, não há necessidade de contar a outros colegas sobre esses sistemas e, portanto, não há desejo de documentar.
Acho que antes de iniciar um grande projeto, nossa cultura e os grandes solavancos vão lembrá-lo de documentar os principais processos, e eles vão mudar de ideia.
Conselhos para si mesmo e para aqueles que querem repetir nosso caminho
- , , , , . , .
- . , . , .
- , , . : , , . . , .