Get best of the week

Quais erros os gerentes em um site remoto

Olá Habr! Eu não sou um desenvolvedor, mas um gerente. Por algum tempo, fui ensinado a gerenciar pessoas e depois mergulhei no mundo sombrio do desenvolvimento, onde tudo dá errado, como dizem na universidade. Agora estou liderando a prática de gerenciar o ciclo de vida do software e quero lhe contar algumas coisas que podem ser importantes para líderes de equipe e PMs relacionados à mudança para um site remoto. Porque em nossas equipes as pessoas já estavam começando a apertar os olhos. E então mostrarei e falarei sobre nossa pilha de automação para controle remoto, e como liberaremos as liberações dos bate-papos no telefone com um botão, em vez de elevar a VPN a um perímetro seguro, e isso acelerará a coordenação e ajudará a coordenar o dia a dia.

O primeiro conselho é suficiente para atrair seu pessoal!



Eu sei que parece muito estúpido, mas muitos gerentes, não vendo pessoas por perto, começam a compensar de alguma forma seu desejo de garantir que eles funcionem. Aqui estão os chats:


Pica - pau em sua forma

pura.Se houver uma tarefa para aumentar a eficácia da equipe agora e no futuro, deixe as pessoas em paz. E defina os 15 minutos diariamente pela manhã. Eu já conseguia ver a sincronização geral do projeto uma vez a cada quatro horas, e o diário por duas horas, e os gerentes que caíam em frustração, que estavam acostumados a negociar cara a cara com alguém.

O que aconteceu com o desenvolvimento remoto no CROC


Mudamos de maneira muito simples, porque já temos uma estrutura de distribuição geográfica de escritórios de desenvolvimento. Nos últimos anos, eles estão acostumados ao fato de que o dia útil de um dos desenvolvedores pode começar a partir das 23:00, horário de Moscou. Consequentemente, quase não havia problemas de gerenciamento para equipes com esses participantes, mas para aqueles que trabalhavam no mesmo fuso horário, dificuldades poderiam surgir. Por exemplo, uma das minhas equipes precisava de novos compromissos no Zoom para a sincronização e começou a selecionar o horário ideal. No início, eles faziam isso na segunda e quarta-feira, e depois na quarta e sexta-feira, porque alguns dos desenvolvedores optaram por trabalhar nos fins de semana e relaxar de segunda a terça-feira. Isso se deve em parte ao fato de eles estarem menos disponíveis nas salas de bate-papo atualmente.

A segunda coisa importante - já tínhamos ferramentas para conectar bate-papos, rastreadores, uma rede social corporativa e toda a pilha de devops de CI / CD, e tudo isso foi parcialmente re-vinculado para que os dados de um sistema fossem inseridos automaticamente em outro. Por exemplo, concordamos em algo no bate-papo, você pode dizer ao bot para trazê-lo para Jira. E ele vai derrapar. Se você fizer isso sozinho, precisará entrar, perfurar todos os campos e assim por diante, bem, e de alguma forma conectar-se ao perímetro protegido. Um bot é mais fácil. O mais difícil é o sistema de autorização. Nós pensamos nisso, estragamos tudo e fizemos mais de um ano atrás.

Como tudo começou.Primeiro, todos mudaram para um site remoto e se acostumaram a isso por uma semana. Alguém tem cadeiras ruins e as costas doem, os filhos de alguém mordem os pés em casa, a esposa de alguém fica feliz que o marido passa mais tempo com a família e pede a cada cinco minutos para abrir uma lata. Uma semana estabeleceu ferramentas. Então, de repente, os desenvolvedores perceberam que estavam felizes por estarem em casa. E você não precisa ir a lugar algum, ir a lugar algum, mas nas reuniões fica imediatamente claro quem era necessário e quem foi nomeado para o ritual. Bem, as reuniões começaram a começar a tempo, porque não há razão para se atrasar. Então os gerentes começaram a sofrer, porque a comunicação com o cliente se transformou em um inferno. Começamos a agendar reuniões regulares de três horas (três a quatro dias seguidos) no calendário, apenas para concluir o contrato com um advogado, caso contrário, tudo ficaria suspenso por meses. Enquanto isso funciona.

O próximo passo- a questão é que os desenvolvedores em um site remoto precisam de motivação. Não é como no escritório. É muito importante não pressionar, é muito importante colocar uma tarefa interessante e fornecer uma imagem do resultado desejado. Caso contrário, haverá procrastinação, e o próprio líder a projetará. Sair da cama para fazer algo chato é simplesmente fisicamente difícil. Os líderes do projeto devem ter igual escopo para a tomada de decisões. Nossa situação é que o TK geralmente não muda, mas a força dentro do sprint pertence à equipe e não ao gerente de projeto.

Naturalmente, no caminho mais longe, você pode quebrar a lenha bem engraçada.

O que poderia dar errado?


Bem, primeiro você precisa lembrar que, apesar da emergência (e ele tinha muitas pessoas depois de mudar para um site remoto), é melhor seguir os processos. Para um de nossos clientes, enviamos uma liberação do desenvolvedor para o desenvolvedor. Sinhro depois de um puxão para eles. Nós lançamos o lançamento, eles tiveram que realizar testes de integração e regressão. E guarde na minha comida. E no dia seguinte, eles escrevem e nos pedem para lançar essa versão em um ambiente de teste. Porque eles imediatamente o colocaram no local e depois se lembraram de que seria bom sincronizar nosso ambiente. Felizmente, o lançamento não caiu, mas, do meu ponto de vista, parece um pouco inseguro ou algo assim.

Para outro cliente, restauramos um dos projetos de terceiros após a transferência do trabalho para um site remoto. Tudo é muito mais simples lá: os especialistas do cliente lançam o banco de dados, ao mesmo tempo em que, por algum motivo, colocam texto sem formatação com senhas, também fora. Alguns jovens kulhackers invadiram tudo, naturalmente.

Você provavelmente conhece o resumo diário das vulnerabilidades do Zoom e o fim da história com vazamento de registros. Nem todos os executivos (geralmente das tarefas de TI de configuração de negócios) entenderam o que é o Zoom, como funciona exatamente e que algumas coisas confidenciais não valem a pena ser mencionadas durante a gravação. Fizemos um memorando para os clientes sobre como usar qual canal. Parece ter ajudado. Pelo menos muitos engenheiros industriais mais velhos suspiraram um pouco mais. E eles pararam de adicionar "mydomain.ru" às conferências gerais, sem especificar se eles conhecem esse funcionário.

Outro de nossos clientes esqueceu que havia flores no escritório que precisavam ser regadas. Descobrimos isso acidentalmente ao analisar ameaças. Flores salvas.

As reuniões com o cliente foram divididas naquelas em que as pessoas ainda usam gravatas em casa e nas quais você pode se dar ao luxo de sentar em pijamas. Em uma de nossas reuniões, o desenvolvedor principal saiu do banheiro, bem na espuma. Ninguém se opôs.



Para os especialistas em Agile que estão acostumados a conversar, colando adesivos nas paredes, ocorreu um colapso criativo, porque agora ficou impossível fazê-lo. Em muitos casos, Trello ou Miro resolveram o problema. Todo mundo se tornou mais fácil. Tenho o prazer de ver como meus colegas aprendem a se comunicar em um novo ambiente a partir do zero, e sua socialidade não lhes dá bônus como antes.

Uma boa abordagem é gravar em algum lugar próximo aos modos de cada desenvolvedor. Estamos familiarizados com isso por causa da geografia, mas acréscimos como “das 16:00 às 19:00 apenas por telefone em casos urgentes” ajudam muito. É aqui que a solicitação para o arquivo dock e os resultados das verificações funcionam muito bem: você pode fazê-lo da cama, se quiser. Porque, caso contrário, você terá que esperar pela manhã seguinte de oito a nove horas. Tentamos transmitir a mesma pilha simples aos clientes com quem trabalhamos de perto, porque se estamos acostumados com o fato de o documento passar de sistema para sistema, a pilha atlasiana do cliente pode não estar disponível e será necessário enviar arquivos * .docx com relatórios intermediários.

Em várias equipes, houve um problema com o fato de as reuniões serem enviadas para o calendário sem olhar para esse mesmo calendário. Podem ser feitos três convites por slot, e o próprio slot já está ocupado. Isso também é resolvido de forma organizacional e simples.

Aqui estão os nossos desenvolvedores dizem:

Eles fizeram um bot para a demo - mais para quem todos são mais. E tudo bem com as crianças sentadas.
— - . , . , , : 10 000 10 , , . , -, , . , , ! , , . : , , , - . . … , .
Não há diferença com o desenvolvimento convencional em um site remoto. Bem, você ainda trabalha com serviços. Há muito tempo, houve um caso em que meu colega acidentalmente pregou um servidor VPN através do qual ele se conectou para manter esse servidor VPN ... Com uma janela de cinco minutos para atualizar o sistema, a carga caiu repentinamente quando o aplicativo foi interrompido e antes do lançamento da nova versão (na época). atualizações semi-manuais) ... Ou quando você executa os comandos rm -rf / data e percebe que o possui produtivamente e mais rápido e mais rápido ctrl-c.
Chatops do fumante:



Eles fizeram um relançamento para um colega que já havia sido liberado. Anulando seu trabalho. Felicidade.

Existem exemplos de pilha?


Sim, aqui estão elas:

Solicitar Link


Gitlab + timcity

Bots ajudam

Gitlab + jira



gitlab + timcity

Diagrama de montagem

Exemplo de pipeline de desenvolvimento

Este é um exemplo de bate-papo técnico



Os devops e as ferramentas de CI / CD das equipes normais já foram elaborados. Do ponto de vista do controle do processo, é importante que a cada etapa seja necessário reduzir o número de ações desconfortáveis, deixando apenas as úteis. Por exemplo, acima, você vê bots que relatam o status do lançamento - esse envio é muito mais conveniente do que entrar e observar como ele está lá. Mas o valor real aparece quando tudo isso permite que você crie um processo contínuo de "discutiu o problema no chat" para "definir todas as tarefas com links para a discussão", "a tarefa foi anexada e varrida por todos os sistemas" para a compilação, além de todas as métricas necessárias foram removidas ao longo do caminho como marcas de auto-estima. Para os desenvolvedores, esse projeto foi um desafio, porque geralmente eles escrevem código, em vez de desenhar arquiteturas, escrever conceitos etc. E se o desenvolvimento for automatizado o máximo possível,então, para muitas equipes, a automação da troca de documentos ou documentos não é muito bem implementada.

Aqui está um exemplo. A tarefa é considerada concluída quando cada linha no ToR será um link de trabalho para a tabela de referência cruzada.

Os passos são
:



, . - .

() «»:



. , . - .

- -:



( ) «» ( ). Jira . . «» , . — . . «».

Sou gerente, em que devo me concentrar agora?





Uma prioridade importante não é compartilhar rapidamente, mas se comunicar normalmente. O mundo já mudou e agora existem duas ameaças importantes para as empresas: esgotamento profissional (se você se envolver em gerenciamento de pica-paus e expulsar pessoas) e a questão de uma reestruturação completa das estruturas de gerenciamento, quando as equipes entendem que podem fazer tudo de forma autônoma e com um novo líder informal . Isso pode resultar no fato de que, no final da crise, toda a equipe, tão difícil de encontrar e treinar, se levantará e partirá imediatamente para seu próprio projeto. Portanto, repito mais uma vez - mesmo que sua produtividade caia, não entenda seu pessoal. É do seu interesse.

Se for interessante discutir o processo puramente de liderança separadamente, faremos um seminário on-line no dia 27, às 16:00, aqui você pode se inscrever. Será sobre como você pode criar o processo, vários erros e casos de gerenciamento, separação de responsabilidades (especialmente com segurança da informação), fluxo de documentos entre desenvolvedores, analistas, testadores, um pouco sobre CI / CD. Bem, mesmo que pareça que você já sabe tudo, você pode fazê-lo como um verdadeiro Jedi - inscreva-se em um webinar, abaixe o som e sente-se lá para fazer seu trabalho!

More articles:


All Articles