Oi Meu nome é Oleg e sou desenvolvedor front-end do Alfa Bank. Quero contar uma pequena história filosófica - sobre a abordagem de engenharia para o desenvolvimento, sobre meu primeiro emprego e o rake que colecionei lá, sobre por que os checklisters são muito importantes (e salvam vidas).
E também sobre como continuar trabalhando de forma produtiva e não cavar em muitas tarefas pequenas e nem muito.
Tudo começou com o caos.
No meu primeiro emprego (não Alpha, não), de alguma forma, fui pego e imediatamente jogado na fenda, eles disseram, cara, agora você faz CRM, o comp está lá. O que fazer e como fazer - eu não entendi nada. O que eles costumam fazer em tal situação? É isso mesmo - eles correm para seus colegas e começam a verificar com eles como entregar o código ao servidor, como estão as coisas com o git, quais práticas usamos e quais não, e assim por diante. Essa abordagem me ajudou, e eu constantemente aconselho outras pessoas a fazê-lo. Faça, faça perguntas, mesmo que lhe pareça óbvio, especifique o que precisa ser esclarecido. Isso é normal. Não é normal não perguntar.
Meu próximo passo foi usar livros. Porque quando eu estava retornando perguntas e obtendo respostas como "Yuzay linter", me peguei pensando que sabia fazer tudo isso, mas não entendi bem o porquê. Eu estava sinceramente interessado em saber onde as pernas crescem em todos os processos e decidi procurar ajuda nos livros. “Código puro”, “Código perfeito” - em geral, fui ao conjunto padrão, onde eles dizem que a função não deve ter mais de 30 linhas. Devo dizer imediatamente que não ajudou a entender tudo e controlar o caos.
Sim, comecei a escrever visivelmente mais limpo, mas o caos na forma de um monte de tarefas, que eu normalmente não conseguia resolver, não desapareceu. Os colegas decidiram ajudar com conselhos sábios como "Cara, você não tem margem suficiente, vamos ler sobre a margem aqui e tudo ficará bem com você, se você também der o Scrum-master".
Bem sim. Ágil sozinho é uma coisa boa. Mas quando você trabalha em equipe. E o Edge de uma face é um pouco estranho. Comecei a cavar mais, encontrei livros kaizen. E então eu conheci a teoria da restrição do sistema e o livro "Propósito". Muitos provavelmente o leem, então apenas observarei brevemente que uma das principais mensagens aqui não é melhorar tudo em todos os lugares e imediatamente, mas primeiro encontre um problema e corrija-o. Corrigido - procure o próximo e corrija-o. O autor chegou a isso através de abordagens de engenharia, porque os engenheiros fazem algo assim - eles procuram um problema e o resolvem.
Ok, isso é letra, vamos nos aproximar da prática.
Na vida
Suponha que você tenha algum tipo de processo esférico no vácuo em que haja um designer, front-end e testador. O designer desenha layouts e botões em um dia, o front-end trabalha em três dias com isso e o testador precisa de dois dias. Parece ser um esquema simples e fica imediatamente claro onde melhorar o processo - no front-end, porque seu trabalho leva mais tempo. Ou seja, o ponto de otimização é encontrar o estágio mais lento do processo.
Mas este é um exemplo simples com três variáveis. Obviamente, o trabalho geralmente é diferente. E muito diferente. O processo fica complicado quando você possui um back-end, documentação, CI / CD e outros dispositivos importantes.
E não será possível pegar imediatamente e dizer qual processo é o mais lento e por onde começar. Aqui, o processo de otimização do estágio mais lento ficará assim:
- Precisamos encontrar a restrição, a mais lenta.
- Decida como usá-lo o máximo possível.
- Subordine tudo à decisão.
- Desenvolver (expandir) a restrição.
- Volte e repita.
Pode parecer confuso, por isso vou escrever com mais detalhes.
O que fazer, você tem alguma tarefa paralela com a qual está ocupado?
Nesse caso, você procurará a rota mais longa por dias no total. Na foto acima, são cerca de 6 dias. Comece com esse processo mais longo. Acontece que neste exemplo você melhorará o back-end, pois leva 4,5 dias. Isso também não é tão difícil, mas quando você chega a esse ponto e começa a fazê-lo, percebe que a vida se torna mais fácil.
Voltarei a exemplos do meu caos de trabalho. Eu tenho um monte de tarefas e não tenho tempo. Percebi que há uma limitação no frontend (isto é, em mim), que o problema não está no testador, porque ele encontra bugs, principalmente do meu lado. Para fazer algo a respeito, comecei a pensar em como usar essa restrição.
E ele decidiu que precisamos mudar o processo para que haja apenas um ponto de entrada - uma pessoa que tome decisões sobre se faremos a tarefa ou não. Como houve casos em que uma pessoa veio e disse: Oleg, precisamos mover o botão aqui um pouco para a direita. E depois outro. E em meia hora alguém com uma tarefa semelhante. E parece que pequenas coisas e lixo, mas no final eu costurei completamente, tentando agradar a todos.
Agora eu tento fazer não mais que 2 tarefas em paralelo (em paralelo e não simultaneamente). Anteriormente, eu podia dar uma tarefa ao testador e fazer o seguinte, mas se o testador encontrasse um erro, eu precisava verificar, lembrar e mudar para o código que foi escrito lá, o que é mais difícil do que parece quando você alterna com frequência. E, em geral, a troca é cara. Tente não executar mais de 2 tarefas em paralelo. 3 tarefas já são uma maneira de costurar.
Vamos pensar em como subordinar todo o resto à decisão. Parece lógico, sim, que, se houver tantas tarefas, você não precisará lançar um slide? Por exemplo, você espera que uma pessoa execute três tarefas de complexidade aproximadamente igual em três dias. Se em dois dias de três ele fez apenas uma tarefa, provavelmente ele não se encaixa no plano, então jogar mais tarefas de cima para ele é algo desmotivador.
Mais sobre restrições
Obviamente, as restrições podem ser expandidas. No nosso exemplo, contrate outra frente. Também é lógico, mais frentes - eles terão tempo para concluir mais tarefas. Em seguida, a restrição será transferida para outro local.
Há também uma abordagem na qual eles expandem não o número de unidades, mas suas competências. Eu tenho um exemplo vivo - o testador poderia me ajudar no front end se eu conhecesse o front end. No meu colega, o scrum-master começou a escrever o frontend por conta própria, porque estava interessado, ele fez alguns recursos lá com um brilho, e se divertiu e a equipe ajudou. Não desejo fazer isso em casa, porque o resultado pode ser muito diferente, mas como exemplo, existe uma abordagem desse tipo - sim, e às vezes funciona.
Lista de verificação
As listas de verificação realmente ajudam a tornar a vida mais fácil. Esta
lista de verificação do Alfa-Bank agora ajuda muito no meu trabalho
, onde há algumas etapas que precisam ser concluídas.
Cheklists até salvam vidas, darei um pequeno trecho do livro
“Entenda os riscos. Como escolher o curso certo ":
No início da aviação, os pilotos voavam em aviões que não estavam tão equipados com equipamentos técnicos como hoje. As listas de verificação começaram a ser usadas na Força Aérea dos EUA somente depois que ficou claro que o bombardeiro B-17 é um avião muito grande e não pode ser controlado por apenas uma pessoa. Em 2009, quando os dois motores morreram no voo 1549 da US Airways imediatamente após decolar do aeroporto de La Guardia, os pilotos executaram todas as ações da lista de verificação em uma emergência, incluindo uma tentativa de reiniciar os motores. Os comissários de bordo, novamente de acordo com as listas de verificação, monitoraram rigorosamente a preparação adequada dos passageiros para um pouso de emergência. Listas de verificação como essas são uma maneira simples e barata de aumentar a segurança.
Na medicina, uma imagem diferente é observada. A cada ano, o uso indevido de cateteres venosos centrais causa aproximadamente 80 mil casos de infecção da corrente sanguínea e, como resultado, cerca de 28 mil pessoas morrem em unidades de terapia intensiva em hospitais americanos. E aqueles pacientes que conseguem sobreviver passam, em média, mais uma semana adicional em terapia intensiva. O custo total do tratamento de tais infecções é estimado em US $ 2,3 bilhões por ano. O que pode salvar essas pessoas? Melhores medicamentos para tratar infecções, melhores tecnologias? A resposta é: melhorar a cultura dos erros.
Em 2001, Peter Pronovost, do Johns Hopkins Hospital, elaborou uma lista de verificação simples para os médicos de ressuscitação verificarem se essas medidas podem reduzir a propagação da infecção. Aqui estão cinco etapas sucessivas projetadas para impedir a entrada de bactérias perigosas no paciente:
1) lavar as mãos com sabão;
2) tratar a pele do paciente com anti-séptico à base de clorexidina;
3) cubra o paciente com uma folha estéril;
4) use máscara, chapéu, avental e luvas estéreis;
5) aplique material estéril sobre o cateter após a inserção do cateter na veia.
Nesta lista, cada uma das medidas de proteção era bem conhecida, não continha nada de novo. Pronovost pediu aos enfermeiros que trabalhavam em sua unidade de terapia intensiva para ver se os médicos seguiam essas 5 regras. Os enfermeiros relataram que, ao instalar um cateter, mais de um terço de todos os pacientes tiveram uma ou mais dessas regras não seguidas. A taxa de infecção da corrente sanguínea no hospital naquela época era de 11%.
Pronovost convenceu a administração do hospital a permitir que os enfermeiros interrompessem os médicos se eles perdessem alguma das cinco medidas prescritas. Essa inovação revolucionária violou a estrutura hierárquica em que a equipe paramédica (principalmente mulheres) não tinha o direito de dar instruções aos cirurgiões (principalmente homens). Após um ano, durante o qual essas instruções foram rigorosamente seguidas, a taxa de infecção da corrente sanguínea em pacientes hospitalares diminuiu de 11% para 0 (!). E nos 15 meses seguintes, apenas 2 casos dessa infecção foram notados. Somente neste hospital, a lista de instruções preveniu 43 infecções, 8 mortes e economizou US $ 2 milhões.
Para mostrar que o efeito de usar a lista de verificação não se limitou ao seu hospital, Pronovost convenceu mais de cem unidades de terapia intensiva em Michigan a participar de um estudo conjunto em larga escala. É importante observar que cada um deles desenvolveu sua própria lista de ações mais relevantes para sua cultura.
As unidades de terapia intensiva participantes do estudo relataram que anteriormente tinham um total de 695 casos de infecção da corrente sanguínea devido ao uso de cateteres. Apenas três meses após o início do uso de listas de verificação na maioria dos departamentos, a taxa de infecção do paciente caiu para zero. As demais unidades de terapia intensiva também conseguiram reduzir significativamente esse indicador no ano e meio em que o estudo foi realizado. Esse programa em larga escala para salvar vidas foi implementado sem o uso de tecnologias caras e sem aumentar o número de funcionários do hospital.Ou seja, cada um desses pontos era conhecido, isso não é algum tipo de novidade ou outra coisa. Peter simplesmente o projetou no formato de lista de verificação e o tornou obrigatório. Só isso.
Tentamos melhorar não apenas nossos resultados, mas também os resultados de outras pessoas, por isso atualizamos constantemente nossa lista de verificação de trabalho. Se de repente eu esqueci algo e não fiz algo no processo, coloquei na lista de verificação para não esquecer da próxima vez. Anteriormente, as maquetes eram frequentemente devolvidas ao designer para retrabalho, embora ele dissesse que entendia tudo imediatamente e faria tudo certo e, depois disso, ele acabou de nos pedir uma lista de verificação, joguei fora uma peça para o design, e ficou mais fácil.
Classifiquei minha lista de verificação por ação - 1 ação = 1 item da lista de verificação. A principal coisa aqui também é não descansar muito fortemente e não entrar em listas de verificação por uma questão de lista de verificação. Page Make Up é um bom ponto. "Criar controles" - ainda mais, ajudará a não esquecer os controles e suas nuances.
Uma lista de verificação pode ser hierárquica: layout da página -> layout da página -> layout da página.
Por que apenas codificar não é suficiente
Testes são necessários. Mas eles nem sempre são necessários. Por exemplo, você faz um pouso uma vez e não planeja voltar a ele mais tarde - então não faz sentido forçar muito. Você pode cobrir seletores com unidades ou usar end2end, mas os testes de unidade para o resto são uma perda de tempo.
Mas é por isso que a codificação não é suficiente. Mais uma vez, um exemplo do primeiro trabalho - tive que mudar alguma coisa, fui até meus colegas e conversei sobre isso, eles responderam que estavam ocupados. E meu sprint está queimando. E não há ninguém para ajudar. Como resultado, ele começou a se entender em competências adicionais.
Suponha que você tenha alguma boa habilidade, por exemplo, trabalhando com CI / CD. O designer forneceu o layout e saiu de férias, você fez algumas edições ou perguntas, mas até ele voltar das férias, é isso, o processo vale a pena. Expanda suas habilidades, porque se o ponto fraco do processo está no lado do design, bem, o designer é costurado por várias razões, você pode ajudá-lo. Este é um conjunto adicional de conhecimentos, mas pode ser dominado. Claro, não estou falando de substituir completamente e completamente um especialista, estou falando de habilidades básicas.
Conclusões
É útil abordar o assunto como engenheiro. Mesmo que seu trabalho não seja de natureza de engenharia. Ele permite que você não apresente tudo sem pensar em uma fileira, mas encontre um problema e apresente apenas o que contribui para sua solução.
Precisa se comunicar e discutir soluções. A comunicação é, em princípio, difícil de superestimar. Às vezes, surgem problemas por causa da chamada iniciativa silenciosa. Tivemos um caso em que recebemos um desenvolvedor .Net e uma tarefa simples para ele escrever testes. Ele rapidamente escreveu tudo, testes, testes de unidade, seleciona e, por algum motivo, começou a fazer algo além do que estava na tarefa. Aparentemente, na crença de que isso será útil para nós. Como resultado, tudo o que ele fez nos levou a gastar muito tempo em sincronização adicional e, depois, tudo isso foi para o lixo em essência. Só por causa de problemas básicos de comunicação. Não faça isso.
Bem, uma lista de livros úteis:
- Teoria de restrição do sistema (E. Goldratt)
- Gerenciamento crítico de projetos em cadeia (E. Goldratt)
- Gemba kaizen - uma maneira de reduzir custos e melhorar a qualidade (M. Imai)
- Gerenciamento Ágil: Liderança e Gerenciamento de Equipe (A. Jürgen)
- Extrema programação explicada (K. Beck)
Uma apresentação detalhada pode ser encontrada
aqui .
Você usa listas de verificação, considera-as necessárias? Se você tem alguma maneira de manter ou criar uma lista de verificação, compartilhe nos comentários.